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

[Brian Dickson <[e-mail]>]

On Tue, Jul 3, 2012 at 2:50 PM, Christopher Morrow
<[e-mail]>wrote:

> On Tue, Jul 3, 2012 at 11:54 AM, Robert Raszuk <[e-mail]> wrote:
>
> isn't the case of 'give customers an ASN to peer with us in more than
> one location' just: RFC2270
> why would you pollute your RIB and your configs with private-asn when
> a public is available for this? (or a reason to get a public is
> available for this).


No. For lots of reasons.

RFC 2270 is (a) informational, (b) 14 years old, and (c) talking about
using (and re-using) a _SINGLE_ _private_ ASN for multiple customers.

If you have a single customer with multiple, isolated, non-contiguous
sites, a single ASN won't necessarily work for _that_ customer.
In other words, while it might work some of the time, it won't work in
every case. There are lots of possible similar corner cases.
(E.g. "back-door" routes as either preferred, or as back-up paths, means
that more than just default is needed.)
(Similarly, any kind of tunnel/VPN/GRE/whatever, implemented by the
customer without the SP's involvement.)

One's RIB is polluted by routes, regardless of the attributes of the routes.
There may be very slight benefit to the same ASN being used, but generally
only if the rest of the attributes are identical.
For large customers with lots of sites, this won't hold true.

And, while life is easier when all the ASNs you have are unique _within_
your universe of configs,
nothing changes if some of those ASNs are re-used by someone else (out of
sight from your perspective).


> > And once you apply it once you better apply it everywhere as non uniform
> > configuration which does not follow templates is the worst NOC nightmare.
>
> yes, less complex config, win.
>

Config complexity is orthogonal to standardization via automation.
It is only when you over-ride the tools that you lose the scaling war.

If you have tools that understand a dozen or so variants, and fully capture
the requirements
of each, you can plug in necessary values (e.g. from a database or other
info source),
and crank out the configs. This includes, for example, a private routing
registry, where
prefixes are keyed off of customer objects, including private ASN origin:
fields.

Having mapping references _back_ from the config to the template and
customer, is key.
(Adding your own structure to unstructured description fields has worked
well for me.)

(If you have to dumb things down, you will end up with only dumb customers.
Dumb customers are a commodity, which is ends in a price war with eroded
margins.)

Reality trumps models. 3 nanoseconds per meter might not be acceptable to
some,
but it is the law. :-)

Brian