Re: [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document

[Jon Mitchell <[e-mail]>]

On Fri, Aug 24, 2012 at 05:30:53PM +0700, Randy Bush wrote:
> for your amusement, today in the routing worshop in phom penh, the
> lecture includes rfc 2770 and using only one asn for a large number
> of customers multi-homed to my network.  aside from the benefits i
> remembered, i was reminded that it even makes peer groups sexier.

Randy -

Sure, RFC2270 seems to be one reasonable solution for the use case of an
ISP providing ASNs to single homed customers that do not require route
connectivity to each other except via default, and yes, I'm aware of it
and seen it deployed at multiple places I've worked.  Of course, the
unsaid thing in this draft is that using a seperate (private) ASN per
customer site was not viable due to limited private use ASN space (which
ISP in 1998 when this was published was not anticipating endless
growth!).  Although this would require one more line in your configs per
peer (but in modern BGP implementations not necessarily provide better
update generation which can occur based on same policy applied rather
than peer-groups), but may have some operational/troubleshooting
benefits.  That said, let's assume that you are correct that the
benefits outweigh the cons for using a dedicated ASN for this scenario
in every operators mind.

In other situations, I've seen a similiar approach implemented with
seperate private ASNs to get rid of the implications of section 3.1, not
for Internet table routes, but for routes to be leaked that are internal
to the larger network.  What are "customers of an ISP" in this RFC may
be seperate engineering groups who run regions, DCs, sites, or
sub-organizations... in a large organization.  In these cases, using
seperate (typically private) ASN's allows arbitrary connections between
sites, the use of multiple backbone options (all from internal networks
again which may or may not utilize a public ASN, not Internet
backbones), and the entire organizations routes to be able to be
received from all sites (which is useful when default lies in another
direction than where you want to send traffic).  I believe using
multiple private ASNs in these scenarios is less a hack than trying to
achieve the same with disabling loop detection, arbitrarily mandating no
connectivity between these sub(orgs/sites) and/or requiring them to
merge BGP everytime they bring up a backend connection.  Depending on
the function of said network, there may or may not be an Internet
connectivity requirement for any of these networks at all.  I personally
don't see the use of private ASNs in these cases as an end run around
the RIR's, as Internet connectivity is not a primary function of these
ASNs and if they do have to send some routes to the Internet (which is
not the case for every network) then these would likely come from a
public "boundary" ASN between them and other ISPs, that provides the
private AS stripping function.

Now we've covered a couple of use cases, but my overall position is that
private use ASNs are used in many situations with various routing
requirements, likely a number of which we will not have properly
identified even if we continue to go back and forth on every current and
possible future use case of BGP in networks.  I personally don't feel
the need to debate whether or not all these use cases are valid, as I
think that is orthogonal to whether having a large range is useful.
After all, this is not a draft about keeping or getting rid of private
ASNs.

Jon