On Sep 23, 2011, at 7:06 AM, George, Wes wrote:
-----Original Message-----
From: Owen DeLong [mailto:owen(_at_)delong(_dot_)com]
Sent: Thursday, September 22, 2011 6:32 PM
To: George, Wes
Cc: Jari Arkko; ietf(_at_)ietf(_dot_)org;
draft-weil-shared-transition-space-request(_at_)tools(_dot_)ietf(_dot_)org;
draft-bdgks-arin-shared-transition-space(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt>
(IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
2) Should draft-weil or draft-bdgks or both be formal updates to RFC1918 as
additional private-scope use cases?
I don't believe so. I believe that conflating these drafts with RFC-1918
would only serve to further increase the
probability that someone would consider this additional space for the same
purpose. I would not oppose
adding a reference to RFC-1918 that links to these documents as additional
related considerations.
WEG] "adding a reference to RFC1918 that links to..." means updating RFC1918,
which is why I suggested it. It is not necessary to rewrite/replace/obsolete
1918, and I believe that some of the language that you added to bdgks after
our discussion about how these cases are different from 1918 would be fine to
help prevent conflation between the two. It's incumbent upon us to ensure
that the draft is very crisp in defining acceptable and unacceptable uses of
the space and its relationship to existing RFC1918 uses, and I believe that
this is quite doable. Regarding increased risk of off-label use, all we can
say is "don't do this" and "only do this" using the strongest language we
feel appropriate. What implementers ultimately decide to do will be driven by
their individual business and technical needs more than whether or not we
choose to update 1918 formally.
If the scope of "updating RFC-1918" you intended was a simple reference, then,
yes, I can support that idea.
I took "updating RFC-1918" to mean something more along the lines of
incorporating these drafts into 1918
instead of giving them their own RFC numbers which I think would be
counterproductive.
There is urgency to make the space available for use, so, the split you
describe does not actually help. The urgency
is to make this space available before providers start having to deploy
NAT444 without it, or, at this point, more
accurately, to limit the amount of NAT444 deployed using GUA, Squat Space, or
any of the other alternatives
that these drafts show are a significantly worse alternative vs. this /10
shared transition space.
Pushing draft weil back as you describe would be extremely harmful IMHO.
WEG] this is exactly the type of hand-waving I'm trying to avoid when
discussing whether there's actually this much urgency and what is driving it.
While I've heard good support for this reservation of shared transition
space, and the concern that if we screw around for too long the address space
will be gone, I have not heard anyone saying "I need this within the next few
weeks (or even months) or I'm going to have to do something else." It's been
over a year since this round of discussion started (with
draft-weil-opsawg-provider-address-space-00), and yet no one has
unequivocally said "I'm being materially impacted by your failure to get this
done *right now*." As may be obvious, I work for a broadband residential ISP.
This idea of when/if we have to do CGN is pretty important to us and to my
colleagues in the industry right now, and I'm not hearing event horizons
earlier than 12-18 months. If anything, people are starting to look at this
and say, "wow, this is going to s
uck, I wonder how long I can hold it off?" So I simply don't see the necessity
for short-circuiting the process. Even if the timeframe is more like 6 months,
we still have time to do this correctly.
I speak for no one but myself, but if you fall into the category of needing
this address space ASAP, you'd be wise to speak up to lend credence to the
perceived sense of urgency.
I suspect that the operators most likely to choose alternative solutions
immediately in the absence of moving this forward are also the ones least
likely to be reading this list, unfortunately.
We already have assurance from ARIN that the space will not go away. Mr. Curran
has assured us that the space will be set aside if we get to the point where
that must be done to prevent it from getting otherwise allocated.
I'm really not trying to hand-wave, but, while I don't work for a residential
ISP, I do talk to people from a lot of them in my travels, both large and
small. I know that there are providers already starting to deploy LSN for some
of their customers. (To a certain extent, much of the residential broadband in
India is already behind one or more layers of LSN, but I wouldn't consider that
situation particularly representative of the problem.)
I wish I could give you a list of the providers I've talked to, but, frankly, I
don't remember which ones they were, these are Q&A and other hallway
discussions from various conferences. However, some excerpts go like this:
"We either need the /10 to move forward soon, or, we'll be forced to
use squat space."
"I'll probably have to start deploying LSN one way or another in the
next 60 days."
"I'm dreading LSN. Especially if I end up having to hack it without
reserved space."
Admittedly, I hear these things more often when I am in Asia than when I am in
the ARIN region. However, I believe this is intended to apply equally well to
all regions and that ARIN is providing the space primarily because they have
the largest pool of remaining available addresses.
I do hope that there are at least some such providers on here that will confirm
what I have said, but, I don't know. The majority of operational residential
ISPs don't actually have much presence in the IETF, if any.
Owen
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf