Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

[Owen DeLong <[e-mail]>]

On Sep 23, 2011, at 7:06 AM, George, Wes wrote:

> -----Original Message-----
> From: Owen DeLong [mailto:[e-mail]]
> Sent: Thursday, September 22, 2011 6:32 PM
> To: George, Wes
> Cc: Jari Arkko; [e-mail]; [e-mail]; [e-mail]
> 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 suck, 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