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

[Nick Hilliard <[e-mail]>]

On 12/12/2012 17:03, David Farmer wrote:
> Come on guys,
> 
> I think the proposed range is more than reasonable, 4,278,190,080 to
> 4,294,967,294. Yes, the start and end of the range are not really that
> human or decimal friendly. 
>
> And, if some how that isn't enough, you can pickup another 5 million
> ASNs with two other adjacent ranges that are only a little less human
> and decimal friendly, 4,279,000,000 to 4,279,999,999 and
> 4,290,000,000,000 to 4,294,999,9999.
> 
> Something more than 16 million ASNs is way more than enough, reserving
> 300 million or more ASNs, just to start the range at the 4 billion point
> is just crazy.

this isn't about what particular subset you could choose to use from this
allocation, and I honestly don't care about the size of the proposed
allocation as long as it's large enough to deal with really pathological
lab cases.  It's about vendors and operators and everyone else tending to
align their choice of private ASN to the boundary of the formal allocation
range, because that's what people naturally do when presented with a big
pile of numbers: they select the first in the range, or maybe the last.
It's also about making the entire range visually easy for operators to
handle so that private ASNs are immediately identifiable as such.  As a
side effect, this will make it much easier to write regexps to handle these
ASN ranges, because the tools we have for mucking around with AS paths tend
to involve RE engines.

It would be operationally more sensible to use a much lower range and
suffer fewer ASNs as a result.  This is because operational people like me
routinely need to visually inspect ASNs in as-paths, and it's a whole lot
easier to distinguish between a 5- or 6-digit numbers than 10 digit numbers.

If the draft ends up with 10 digit private ASNs, operational people will
end up with with a whole pile of "wtf were they _thinking_?" and hair
pulling, as they try to figure out whether they've just typed eight 0s or
nine, or made a mistake in position 4, 5 or 6.  We're human, not machines
and things like this make a difference.

As a side issue, we actually don't really need 2^24 private ASNs,
regardless of how complicated anyone's lab network is, but that is a less
important issue.

I'd like to formally propose a smaller range, decimal aligned, from a lower
starting point.  There are several large blocks free in various areas of
the IANA pool, any of which might be suitable for an allocation for private
use:

www.iana.org/assignments/as-numbers/

>From a subjective point of view, I take this position:

Bit-aligned 4278190080 to 4294967294:

	pros:
	- out of the way of RIR assignments

	cons:
	- impossible to recognise visually in operational context
	- the bounding regexp is ridiculous
	- 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).

Low, decimal-aligned range:

	pros:
	- immediately identifiable as private in operational context
	- out of the way of RIR assignments
	- trivial bounding regexp
	- smaller numbers mean fewer typos

	cons:
	- ?

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.

> Get over it. 

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.

Nick