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:
"
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).
"
<http://tools.ietf.org/html/rfc4271#section-5.1.2>
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.
--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
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
