> what matters: AS-PATH > how it looks: every AS which sees this route, and propogates it to > external peers, attests to that fact.
Wrong. As someone who has been long involved in the writing of BGP specs, and someone who has worked, for a long time, on BGP, I can tell you that the "semantic of BGP" has never been that the AS Path is used for anything other than determining if the path is loop free. Anyone who tells you that the "BGP semantic" is that the update has traversed the path shown in the AS Path attribute simply doesn't understand BGP. A few examples showing this simply isn't the case. 1. Private AS Stripping. At certain edges, a provider may peer with an organization that does not have an AS number. In these cases, the peering organization may use a private AS Number, which is then stripped by the upstream. In all such cases, the AS Path does not --by intention-- represent the "path of the update." 2. Local AS No Prepend. In some situations, it's useful (and good) to send an update that has another AS in the path than the AS number you're peering on. This occurs, for instance, in L3VPNs, and when providers are merging two different AS numbers. If this were a real "threat" to BGP and it's operation, then this feature wouldn't have been built by any vendors --but it was created, at the request of service providers (some of whom are now arguing that the AS Path is somehow untouchable). 3. Confederations. In the case where an organization decides to break their network up into multiple administrative domains, or to combine multiple administrative domains, several autonomous systems --with public, routable AS numbers-- may be configured into a confederation. In this case, the AS Path continues to have the AS numbers through which the update passes added to the attribute. The "additional" AS numbers are stripped off at the opposite edge of the confederation. Once again, the AS Path is not anything special here, it's just another attribute, and it certainly does not represent the path the update takes through the network. 4. Wide AS'. According to RFC4893, the way in which BGP will migrate from narrow AS numbers to wide AS numbers is: For any speaker that peers with a speaker in an AS that doesn't support wide numbers, place the AS path in a community, and place a "holder" AS number in the AS Path. When receiving an update with a community containing portions of the AS Path, move these portions back into the AS Path proper. Again, the AS Path is not seen as something that "cannot be touched or changed," but rather a simple attribute designed to show one specific thing --loop freeness. There is no concept here of the AS Path showing the route the update itself, took. 5. AS Sets. If a speaker aggregates a group of NLRIs into a single advertisement, the speaker can/should build an AS Set to indicate the group of AS' from which the NLRIs represented in the aggregate were collected. Again, the AS Path doesn't have anything to do with "the path the update took through the network." I could go on giving examples, but to state, "BGP's semantic is that the AS Path represents the path through which the update has traveled," is simply untrue. :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
