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

[Richard Hartmann <[e-mail]>]

Dear all,

I support this draft.

I am unsure of where to attach my first reply in this discussion so I
picked a more or less random one. There are several points to be made about
the preceding discussion so I resorted to replying en bloc, no inline to
specific messages.
FYI, I am firmly in the operational sector and, obviously, my position
reflects that.


* This RFC builds upon RFC 1930, so it adds rationale for private AS, it
does not need to prove it in the first place, merely to extend the range. I
agree that more specific examples to support this draft would be a good
thing. Both in this current discussion and for the benefit of anyone
reading it in the future.

* Like it or not, private AS numbers are here to stay. There's apparently a
need for more than a thousand AS numbers and any new range should be chosen
so that there are no foreseeable limits.
** This new range should also allow for sub-allocation within one or more
private entities
** Adding a second range can ease operational pains if the first one is
fragmented for historical or other reasons. Obviously, this will not help
in all cases, but it's nice to have backup

* Hierarchy is a proven way to contain local complexity, thus reducing
global complexity
** With 2^32 AS numbers, it's very likely that operators will not limit
themselves to the existing range. It's better to contain this in a
well-known range. Otherwise, rogue ASes _will_ happen, over time.
** The global cost of assigning blocks of 10,000 or more AS numbers to end
users in ways of new policy, synchronization across RIRs, actual
implementation etc can easily be avoided with no or next to no cost

* The range needs to be human readable.
** Humans should be able to detect this range at a glance
** Humans will need to implement any filters, especially when vendors have
not yet implemented this new range in their code.
** While RE do exist to handle more complex numbers, decimal boundaries
make this problem trivial to handle. You don't even need RE, globs will
suffice.

* Updating of built-in vendor filters will take some time, but claiming
that `remove private-as` is ambiguous is setting up a straw-man. Simply
extending the syntax would work wonderfully. `remove private-as rfcXXX` may
be hamfisted, but you get the general idea.

* If two entities merge/tunnel/interconnect otherwise, it's their
obligation to plan ahead. I am willing to bet that AS numbers are of lesser
concern in most cases than RFC1918 addresses. And even if this argument was
valid, it's worse currently than it will be once this draft is published as
RFC.


Personally, I would tend towards 9,000,000 - 9,999,999 as that will allow
ten segments of 100k AS numbers each, but the limits are more or less
arbitrary. It's important to me that they are on decimal boundaries, give
enough space for future use, and short enough to see at a glance, in this
order.


Richard