In short, see RFC 2270. Some of the primary differences are that several of the BGP attributes are preserved with confederations, versus that autonomous "look and feel" provided by dedicated ASs, not to mention that any such model would assume that the providers employ confederations as well. Also, managing it would be a nightmare. More importantly though, is that if providers allow customers to maintain sub-ASs of a confederation they're placing a considerable amount of trust in the capabilites of those customers, and errors on the customers part could impact much more than just the customers part. -danny
I'm trying to understand the problem being solved by the Cisco private AS removal feature. In particular, what advantages does it offer over confederations, which would seem to do the same thing when externally advertising customer routes? Is there a performance benefit?
RFC1998-style multihoming with a private AS is a possible application, I suppose, for any routes that are NOT marked with NO-EXPORT.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Danny McPherson Sent: Tuesday, May 16, 2000 2:45 PM To: nanog@merit.edu Subject: Re: Private ASN suppression
In short, see RFC 2270.
...as well as rfc2260. to be more specific, we have to note that two different options are considered there. if you use the first one (read rfc), then you cannot use private asn until you're ok with generating inconsistencies (and it seems from the previous discussions of this topic that this becomes (illegal? -> no answer...) practice for some smaller isps). with the second option of 2260, you can use private asn since the more specific pa routes are always aggregated (and you cannot use confederations, btw). after all, as was noted, remove-private-as on cisco can be replaced by a simple route map, and the attribute manipulation functionality should definitely exist on versalars... -- dima.
participants (2)
-
Danny McPherson
-
Dmitri Krioukov