Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[Jon Mitchell <[e-mail]>]

This is a long email, revisiting almost everyone of the numbering
discussions in the draft, but I'll try to respond inline mostly to the
nice summary you have at bottom.

Jon

On Wed, Dec 12, 2012 at 10:22:22PM +0000, Nick Hilliard wrote:
> 
> Bit-aligned 4278190080 to 4294967294:
> 
> 	pros:
> 	- out of the way of RIR assignments

and consistent with placement of the existing range

> 
> 	cons:
> 	- impossible to recognise visually in operational context

Well, for a long period of time, operators will know to look carefully
at ASN's in the 4B range unless IANA or some other RFC vastly changes
the current allocation method.

> 	- the bounding regexp is ridiculous

Depending on implentation this is true, but the existing range meets
this definition as well.  I'm sympathetic to this argument however.

> 	- the numbers are large enough that they will attract typos
> 	- complete mouthful and impossible to transmit down e.g. phone, across the
> room, etc (yes, we shout ASNs across the room, and sometimes even talk to
> customers).

I encourage your drafts to deprecate 4B ASN, MAC addresses and IPv6.

My general feeling is that if you are configuring a small number of
sites and your operations is confined to a single room and voice
communication is your primary method still, you are likely to be happy
with just using ASN 65000 (meets all of your criteria).  If you have
more than 1000 sites you are trying to stick an ASN on, hopefully you
are taking a more programmtic view to operating and troubleshooting the
network, or at least have figured out that email / IM and other
communication methods are more reliable than voice for network
operations.  Then again, my credit card number has 16 digits and I've
managed to communicate that over the phone succesfully a number of
times.

> 
> Low, decimal-aligned range:
> 
> 	pros:
> 	- immediately identifiable as private in operational context
> 	- out of the way of RIR assignments

You've suggested a range that eventually could be right in the middle of
IANA assignments (forever is a long time).

> 	- trivial bounding regexp
> 	- smaller numbers mean fewer typos

See previous comment on every other type of thing you can't call accross
the room today.  Even most (unpreviously heard and therefore not easily
grouped) IPv4 addresses can easily be typo'd if we suggest that most
humans are unable to keep more than 7 digits easily in short term
memory.

> 900000 to 999999 would work fine for me.  I'd be even happier with
> 90000-99999.  In fact I'd be really pleased with the lower range because I
> can relate to 5 digit numbers even more easily than 6 digit numbers - but
> perhaps 10k private ASNs may not be enough for crazy large lab models.

The not having to revisit this argument again and force vendor
implementations in the years to come was part of the justification for a
large range.  Since the purpose of the draft is a single organization
and it's for private use (not public as some seem bent on inferring),
I'd suggest you can choose more human readable sub-ranges within the
allocation for your network or lab assuming you need over 1K ASNs.

> 
> What we need to get over is this idea that bit alignment is relevant to
> asn allocation policy.  It simply isn't.
> 
> This is an operational draft.  Please let's request a range which works
> well for operators.

I'm sympathetic to the human recognizable (but not use small or lower
value ranges) and regex arguments to utilize a decimal boundary and the
original draft started there.  An alternate proposal that is not as
silly as 4B+ but still does not consume a significant portion of the
total space (if there was widespread concensus in the WG to change the
existing one, given that we are in LC already) could be:

4200000000 - 4294967294

Although this is even larger than the existing range, it still is a a
very small portion of the existing range, and I think no one is
seriously concerned it's the size of the new range (versus having one)
is concerning as there is no belief that will correlate to any specific
behavior.

Jon