Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range

[David Farmer <[e-mail]>]

On 12/17/12 15:24 , John G. Scudder wrote:
> The WGLC period has ended. Thanks to all for your thoughtful comments.
> While well-considered positions were advanced both opposing, and
> supporting, advancement of the document, there's a clear consensus in
> favor of advancing it. So, we will request advancement.

Good to hear.

> There's an ongoing subthread as to what exact range to request. It seems
> to be proceeding usefully, so let's extend that part of the discussion
> until the solstice (December 21). Please try to confine your comments to
> the subject of what range to request.

On the issue of the exact range;

I have trouble supporting the idea of starting the range at 4B or 4.2B, 
I see no justification for reserving nearly 300M or even 100M ASNs for 
private use.

The original discussion was that the 1023 we have now isn't enough, I 
agree, as do most of the rest of you it seems.  There were numbers in 
the 10k to 50K range talked about as reasonable numbers that people saw 
immediate use cases for.  It was then discussed to round that up a 
couple orders of magnitude so we wouldn't have to revisit this again in 
our life-times.  That seemed like a good idea.  So, 1M was talked about 
and since there are now 4B ASNs that didn't sound that unreasonable, its 
only 0.02% of the 32bit ASNs.  And the original 1023 is 1.5% of the 
16bit ASNs by comparison.

In discussions and through a poll at the working group meeting, the top 
24bits of the 32bit range was selected, that's now 16M ASNs, another 
order of magnitude plus some.  That choice was arbitrary, but 24bits is 
at least explainable as a nice bit boundary, and its still is only 0.4% 
of the 32bit ASNs, this is what the draft has in it currently.

Now the issue of a human/decimal/regexp friendly range has come up as 
being very desirable, I think this is a valid issue.  However, I see no 
justification to add yet another order of magnitude or more of ASNs to 
achieve this goal, taking it to the 100M or 300M range of ASNs and using 
2% or 7% of the 32bit ASNs.

We can start the range at a fairly reasonable point from a 
human/decimal/regexp friendliness point of view and actually reduce the 
size of the range just a little in the process, by selecting 4.28B as 
the beginning of the private ASN range.  Leaving just under 15M private 
ASNs for use.  This seems like way more than enough and several orders 
of magnitude more than any use cases I've heard of.  And, there would be 
no danger of any entity running out, probably any 100 entities for that 
matter.

I just had another thought for making them even more 
human/decimal/regexp friendly.  What if as-plain was changed to use 
32bit ones' complement representation.  Then the range in the draft 
would be 4278190080 to 4294967294 in 32bit decimal or -1677215 to -1 in 
32bit ones' complement, that's probably not going to happen, but they 
sure would be human/regexp friendly. :)  Also, it doesn't look like this 
was explored, at least not in the text of RFC 5396.  Hey we could even 
call it as-neg-plain. :)  Enough math geek silliness.

So, if someone can provide a reasonable justification for 100M private 
use ASNs, or even 10M for that matter, I'm all ears. Otherwise my 
suggestion is to start the range at 4.28B

Thanks

-- 
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================