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

[Shane Amante <[e-mail]>]

Tony,

On Dec 6, 2012, at 8:19 AM, Tony Tauber <[e-mail]> wrote:
> Not at all what I had in mind.  What I had in mind was a situation where a carrier is using a separate ASN for every one of thousands of some type of site or customer (because there are so many private ASNs, don't worry!)  Then they have policies which say "when a route comes with such and such an origin AS, do something or other".  Of course, stripping the private AS internally will break such policy logic.
> 
> Then they acquire another carrier whose clever engineers had the same type of thinking and now the presumption of uniqueness w/in their deployment scope is broken.  Sometimes such things can be aided by clever use of hack-y vendor features (unless remove-private-as is part of the BGP standard); sometimes not.
> 
> That problem was the one I was trying to articulate.

In all fairness, the above is true of all private/reserved "numbers" used by two, disparate networks that are being consolidated into one, e.g.: RFC 1918 addresses.  I'd go a bit further and say that all competent engineers understand and acknowledge this risk, regardless of whether it's private ASN's or RFC 1918 addresses, as they are in the design phases.  I would also assert, based on personal experience of the last several years, that when such consolidations happen, there are conversations and planning that occurs between "clever engineers" of _both_ networks /prior/ to the day of "flipping the switch" so-to-speak where the two networks start to become one.  Furthermore, given that the "standard" private ASN's (64512-65534), and other vendor-proprietary BGP knobs, are already deployed and, most likely, in use by one or both networks, then such due diligence & planning MUST already be common practice among those clever engineers ... so, I'm unclear how NOT extending the private ASN space makes this any different?

Admittedly, all of the above is "not fun" nor as easy as using globally unique ASN's.  However, that's not an available option on the table, because operators don't have an economically feasible _choice_ to use globally unique ASN's.  (See previous discussion on changing RFC 1930 and/or RIR policies if you want to fix that).  

Just to be clear, my recommendation is still to publish this draft as a RFC.

-shane


> The problem that Jay seemed to have in mind of backward compatibility and semantics of what is considered a private AS is different (and something I hadn't considered, so glad he mentioned it.)
> 
> Tony
> 
> On Wed, Dec 5, 2012 at 3:49 PM, Robert Raszuk <[e-mail]> wrote:
> All,
> 
> I think both Tony and Jay forgot that routing and reachability is not
> about originator AS .. it is about prefixes they advertise.
> 
> If peering ISP AS chooses to peer with private as or remove private as
> from AS-PATH or for completeness substitute with their own it is all
> ok. He takes responsibility to route data to such customer(s).
> 
> Any subsequent removal of private as in the path also results in the
> same responsibility of the provider who permits private AS for
> peering.
> 
> I am not sure why there is concern with it on the list.
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr