Re: [Idr] new ID on expansion of private use ASN range

[Jon Mitchell <[e-mail]>]

Randy / Chris -

Sorry in advance for the long message, I tend to be verbose.  As I
stated in my message to Robert, the use cases I was hoping to solve were
a single customer that has requirements for much more than a thousand
sites (not connected via an IGP which may have unique routing
requirements or redundancy).  I'd venture that the number of private
ASNs (unattached from each other) deployed is at least an order of
magnitude, if not several orders, higher than public ASNs allocated.

This goes to Chris's message as well... there seems to  be interest to
ask for justification of use of these ASNs.  The use of BGP has expanded
so much in Enterprise networks especially for remote site connectivity,
when no justification or process was required to use BGP like they
utilized any other routing protocol internally.  For those who want to
move this to a Public ASN paradigm, I encourage you to submit the
appropriate proposal to change both IANA/RIR policies to be so lenient
that I can walk in and request 10K+ ASNs with minimal justification and
low cost.  I don't see much value in increasing the administrative
burden on the network operators or the registries for ASN processing of
these use cases, but if others do I'm at least interested in seeing the
proposal and how well it is received.  After all, 32 bit ASNs appear to
be "like rain" because of the justification required today, while we at
the same time have determined that the 32 bit IPv4 resource requiring
less justification and using larger allocation blocks was not big enough
long term for growth of networks.

Also if we go down this method of using public ASNs for building larger
internal networks, some folks may want knobs back to hide their
multitude of ASNs from the Internet w/o deploying confederations or
having to aggregate every prefix at a higher level, as they want to
maintain a short and consistent AS_PATH for other reasons.  Also, since
private Use ASNs that are already allocated will likely exist for a
really long time, and no one is proposing some sort of active
notification/deprecation strategy as part of a proposal (yet) we will
still need all the existing knobs / complexitiy in current vendor
implementations on top of the new one.  To me extending the one command
(I'm aware of) that already recognizes private ASNs to strip a second
range seems like a better approach and not overly complex.  Please note
as-override nor allow-as-in are examples of command that fit in this
criteria, but their future use may be lessoned but not eliminated by
this proposal.  

For the other use cases where SPs are providing service to customers who
likely are using private ASNs (either in the existing range or the new),
I encourage these SPs to see if a non-private ASN or range of ASNs can
be allocated to them for these use cases and would support any proposals
that reduce the justification needed to assign these if the existing RiR
policies are deemeed to stingy.

Jon


On Tue, Jul 03, 2012 at 06:05:34PM +0900, Randy Bush wrote:
> the motivation is not clearly stated.  the only thing i could find
> was
> 
>    The limited size of the current range of private use ASNs has led to
>    the usage of a number of implementation specific features that
>    manipulate the AS_PATH or remove AS_PATH based loop prevention
>    described in Section 9 of [RFC4271].
> 
> and it is not clear how more private ASs will ameliorate this.
> 
> perhaps a clear statement of need, and why this is the best solution,
> right up front would be helpful.
> 
> randy