patrick@ianai.net (I Am Not An Isp) writes:
You said you wanted routers that followed the RFC. The RFC does not mention list AS_PATH length as a route selection criteria. I have been told that the draft for the next rev specifically prohibits using AS_PATH length as a route selection criteria.
Patently false. In particular, the spec allows an implementation to invoke local policy when computing the local preference of a route. An implementation can reasonably incorporate the AS path length in its local preference calculations as part of its policy. Tony
At 05:09 PM 11/17/98 -0800, Tony Li wrote:
patrick@ianai.net (I Am Not An Isp) writes:
You said you wanted routers that followed the RFC. The RFC does not mention list AS_PATH length as a route selection criteria. I have been told that the draft for the next rev specifically prohibits using AS_PATH length as a route selection criteria.
Patently false. In particular, the spec allows an implementation to invoke local policy when computing the local preference of a route. An implementation can reasonably incorporate the AS path length in its local preference calculations as part of its policy.
Guess that answers the question. So the draft for the next version of BGP does not list as-path length as a necessary criteria, but does leave the door open for vendor implementations (much like the current standard). This, of course, leads to many, many other questions (such as the possibility routing loops caused by different local policies as was seen with implementations of BGP4), but few of which are of a truly operational issue. So I will apologize for starting a thread based on mis-information and go back to my cave.
Tony
TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle
| This, of course, leads to many, many other questions (such as the | possibility routing loops caused by different local policies as was seen | with implementations of BGP4), but few of which are of a truly operational | issue. So I will apologize for starting a thread based on mis-information | and go back to my cave. Different local policies should all be reflected in the LOCAL_PREF, which should be distributed to all nodes within the domain. This should lead to consistent decisions within the domain and thus should avoid stable forwarding loops. Tony
The key to this is that the administrative preference in question has domain scope. Assuming you are correctly implementing iBGP, whether with a full mesh, reflectors, or confederations, and assuming consistent announcements from external route originators, then you can't make a loop because the same policy is in effect for all the routers in the AS. Incomplete iBGP implementations and router-local administrative preferences can easily be used to create loops, but that is certainly not a problem with BGP. Ben On Tue, Nov 17, 1998 at 05:49:21PM -0800, Tony Li wrote:
| This, of course, leads to many, many other questions (such as the | possibility routing loops caused by different local policies as was seen | with implementations of BGP4), but few of which are of a truly operational | issue. So I will apologize for starting a thread based on mis-information | and go back to my cave.
Different local policies should all be reflected in the LOCAL_PREF, which should be distributed to all nodes within the domain. This should lead to consistent decisions within the domain and thus should avoid stable forwarding loops.
Tony
participants (3)
-
Ben Black -
I Am Not An Isp -
Tony Li