> > "... 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
^^^^^^^^^^^^^^^ that's already pretty a different statement from
"never been .. used for anything other than determining if the path is
loop free."
> 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.
This is an (incomplete:-) list of attributes that have immediately defined
semantics for BGP route selection and propagation. This provides the
primitives that a operator has to use when implementing policies.
The more sophisticated operators define and implement policies (usually)
using vendor specific policy languages (e.g. route-map, RPL, ...)
or more abstract ones (like IETF standards track RPSL);
often the operator's policy implementation provides a new signalling
repertoire for their customers (to allow them additional control of
usage and propagation of the customer routes etc.); usually the signalling
uses community attributes (usually transitive!).
The implementation of policies means evaluating attributes of routes to decide
how to manipulate the attributes used for further processing and propagation
(in particular by setting the input/triggers for above mentioned primitives).
Simple early examples can be found in RFC1998.
Please note all known serious BGP implementations as well as RPSL
support AS path regular expressions in their repertoire of criteria for
evaluating routes; there probably is a reason - I also hear that in some
parts of the Internet AS path filters are used as the primary security
measure (no, I don't!).
Also note that even the examples in RFC1998 use AS path expressions
that do NOT depend on just the immediate neighbor's AS...
> 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.
Does not seem like a relevant question.
Policies are essentially internal to an AS (=black box); they relate
to external input and may create specific output - and of course specifics
can be communicated to other AS operators; so there is no principal
problem for C signalling something to A, and A using that (assuming that
B's policy did not block or distort the signal).
> 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.
??????
Can the AS path attribute fullfill it's "primary function" of loop
prevention if we CAN NOT rely on it including all AS that have propagated
the route? (with "abstraction" caveat for not publicly visible confederation
members!)
I don't see HOW (other than by miracle or additional attributes that are more
reliable in this respect!)
So "C" must be available in the annoucement that B propagates to A (unless
B and C are members of confederation - and confederation members are
only visible inside the confederation) and there is nothing "partial"
in the "knowledge" that A's policy would use...
> 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?
Considering the wide range of applications that have occured in proposals
to use BGP for distributing information in networks I would not be surprised
at all if there are cases that are only very indirectly related to forwarding!
> :-)
:-) :-)
>
> Russ
Ruediger Volk
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
