> Not to be pedantic, but the BGP spec *does* say that the AS_PATH documents > the path of an UPDATE, and that each AS must add itself:
No, it says that's the normal mode of operation... There's no MUST in here anyplace: > This attribute identifies the autonomous systems through which routing > information carried in this UPDATE message has passed. > ... > When a BGP speaker propagates a route it learned from another BGP > speaker's UPDATE message, it modifies the route's AS_PATH attribute > based on the location of the BGP speaker to which the route will be > sent: > ... > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as > the last element of the sequence (put it in the leftmost > position with respect to the position of octets in the > protocol message). > " Further, how do we then explain all the examples of the IDR WG, itself, changing the AS Path (such as narrow to wide)? > As I read this, in your example, B would not be conformant with the BGP spec > if it forwarded UPDATEs from C without appending it's own AS. It would > probably be OK to *re-originate* the routes, but that creates a separate set > of problems. So, one point of order might be --approach IDR with this specific question. Is the AS Path in BGP intended to exactly represent --with no changes allowed-- the path through which an update has passed? Or is the primary purpose to prevent loops? Getting the answer to that question might be helpful. As a contributor to BGP, I would say it's only related to loopfreeness, not to the path the update takes --it's not a route explorer, it's a routing update. :-) Russ > > --Richard > > > > On Feb 21, 2011, at 4:18 PM, Russ White wrote: > >> >>> The AS_PATH has always been intended to represent the ASs that >>> propagated the update. >>> >>> The AS_PATH can be used to detect loops ONLY because it does represent >>> the ASs that propagated the update. >> >> Sorry --but I just gave 5 examples of where the AS Path is intentionally >> modified without causing loops. The point is the loopfreeness, not the >> path the update took. >> >> Let me ask this in a different way. Suppose you have the following: >> >> A---B >> +-C-+ >> >> Now, for whatever reason, and with C's full knowledge and consent, B >> decides to advertise C's routes to A without putting itself in the AS >> Path. Is this possible? Yes, it is --using current commercial >> implementations of BGP. Is it wrong? >> >> Well, it doesn't cause a loop, does it? As for policy --isn't that up to >> the contract between B and C? Why should BGP enforce the contract terms >> B and C are able to write between themselves? And yes, this situation >> does exist in the real world --I just happen to be helping a customer >> set this up in a private environment. >> >> :-) >> >> Russ >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
