> "... the "semantic of BGP" has never been that the AS Path is used
> for anything other than determining if the path is loop free."
> 
> That assertion seems to ignore the fact that routing decisions often
> take into account path length. Are you saying that such decisions are
> not part of the semantics of BGP, as interpreted by most ASes?

The primary purpose of the AS list in the AS Path is to determine the
loop-freeness of the path, much like a metric in an IGP is used for the
same reason. The AS Path length was added to the decision process,
AFAIK, in order to inject the idea of the "least cost," or shortest
path, once you've arrived at a set of loop free paths.

Now, if you look at the actual attributes placed in BGP in order to
express policy, there are only three available (that I know of):

1. Local preference, which is only within an AS.

2. MED, which is one AS to a directly connected peer, and has always
been accepted as something which can be (and most often is) overriden.

3. Communities, which are either transitive or nontransitive. The only
ones I know of that actually express routing policy are nontransitive
--they only impact the AS I'm peering with.

In other words, the idea that in this network:

A--B--C

A should somehow be able to base any sort of policy on C's policy just
wasn't ever there. And yet --this appears to be precisely what we are
trying to inject into the protocol. Trying to set a policy that you will
not prefer a route from B because it passes through C is basing the
policy on potentially partial information.

I know there's been a strong attempt to disconnect policy towards
routing updates from forwarding policy. To this end --let me ask an open
question to the list. Can anyone on list point me to a policy carried in
BGP, or actually implemented by a BGP speaker, that's not designed to
impact forwarding?

:-)

Russ

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to