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

[Jon Mitchell <[e-mail]>]

On Wed, Dec 19, 2012 at 07:58:13AM -0600, David Farmer wrote:
> On 12/17/12 15:24 , John G. Scudder wrote:
> >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.

I agree there is no immediate use case I'm aware of for such a large
range, I'm failing to see any cons as none of the proposals poses any
real threat to the overall space (I think any real threat to future
changes in allocation or use of the 4B ASN space to maximum would come
from putting the range in places other than the start or end).

> 
> 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

Trying to predict the future is hard.  BGP on VMs could make these
ranges far too small.  This is not to meant to say that eBGP with
private use ASN's has some specific use case scenario here I think we
need to delve into to further the discussion, but it does seem within
the realm of possibility that a single organization (NOT AN ISP or
someone assigning numbers externally) could exceed a 10-100K range with
certain use cases.  This is a viable enough business that companies are
selling BGP routers on VM's as products...

> 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

I think this continues to be a very good idea so this issue does not
need to be re-visited.


> another order of magnitude plus some.  That choice was arbitrary,

The original range was arbitrary, the new range is arbitrary, most
naming and numbering is.  By putting it at end of range it is somewhat
less abitrary as it's a convention at least.

> 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.

I agree 7% is too big.  2% does not seem unreasonable to me.

> 
> 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

I'm OK with this proposal as well.  It (42[8-9]...) is not quite as
identifiable or human friendly as 42... , but fairly close.  In the
view of the overall space, I don't think this is a a vastly different
proposal (in other words, the savings of this number of ASNs may not
be useful, but I'm fine with it, although I still prefer Warren's
suggestion).

Maybe some others would like to weigh in on one of the above options now
that it's a focused discussion (otherwise I plan to make the small edits
discussed in previous threads and move the start of range to
42xxxxxxxx so we can close this out...)

Jon