draft-ietf-idr-avoid-transition-02.txt   draft-ietf-idr-avoid-transition-03.txt 
Network Working Group E. Chen Network Working Group E. Chen
Internet Draft S. Sangli Internet Draft S. Sangli
Expiration Date: December 2005 Cisco Systems Expiration Date: May 2006 Cisco Systems
Avoid BGP Best Path Transitions from One External to Another Avoid BGP Best Path Transitions from One External to Another
draft-ietf-idr-avoid-transition-02.txt draft-ietf-idr-avoid-transition-03.txt
1. Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract Abstract
In this document we propose a revision to the BGP route selection In this document we propose a revision to the BGP route selection
rules that would avoid unnecessary best path transitions between rules that would avoid unnecessary best path transitions between
external paths under certain conditions. The proposed revision would external paths under certain conditions. The proposed revision would
help the overall network stability, and more importantly, would help the overall network stability, and more importantly, would
eliminate certain BGP route oscillations in which more than one eliminate certain BGP route oscillations in which more than one
external paths from one router contribute to the churn. external paths from one BGP speaker contribute to the churn.
3. Introduction 1. Introduction
The last two steps of the BGP route selection (Sect. 9.1.2.2, [1]) The last two steps of the BGP route selection (Sect. 9.1.2.2, [BGP])
involve comparing the BGP identifiers and the peering addresses. The involve comparing the BGP identifiers and the peering addresses. The
BGP identifier, (treated either as an IP address, or just an integer BGP identifier (treated either as an IP address, or just an integer
[2]) for a BGP speaker is allocated by the AS to which the speaker [BGP-ID]) for a BGP speaker is allocated by the AS to which the
belongs. As a result, for a local BGP speaker, the BGP identifier of speaker belongs. As a result, for a local BGP speaker, the BGP
a route received from an external peer is just an random number. When identifier of a route received from an external peer is just an
routes under consideration are from external peers, the result from random number. When routes under consideration are from external
the last two steps of the route selection is therefore "random" as peers, the result from the last two steps of the route selection is
far as the local BGP speaker is concerned. therefore "random" as far as the local BGP speaker is concerned.
It is based on this observation that we propose a revision to the BGP It is based on this observation that we propose a revision to the BGP
route selection rules that would avoid unnecessary best path route selection rules that would avoid unnecessary best path
transitions between external paths under certain conditions. The transitions between external paths under certain conditions. The
proposed revision would help the overall network stability, and more proposed revision would help the overall network stability, and more
importantly, would eliminate certain BGP route oscillations in which importantly, would eliminate certain BGP route oscillations in which
more than one external paths from one router contribute to the churn. more than one external paths from one BGP speaker contribute to the
churn.
4. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5]. document are to be interpreted as described in RFC 2119 [RFC2119].
5. The Algorithm 3. The Algorithm
Consider the case in which the existing best path A is from an Consider the case in which the existing best path A is from an
external peer, and another external path B is then selected as the external peer, and another external path B is then selected as the
new best path by the route selection algorithm described in [1]. new best path by the route selection algorithm described in [BGP].
When neither Path A nor Path B is eliminated by the route selection When neither Path A nor Path B is eliminated by the route selection
algorithm prior to Step f) - BGP identifier comparison (Sect. 9.1.2.2 algorithm prior to Step f) - BGP identifier comparison (Sect. 9.1.2.2
[1]), we propose that the existing best path (Path A) be kept as the [BGP]), we propose that the existing best path (Path A) be kept as
best path (thus avoiding switching the best path to Path B). the best path (thus avoiding switching the best path to Path B).
This algorithm SHOULD NOT be applied when either path is from a BGP This algorithm SHOULD NOT be applied when either path is from a BGP
Confederation peer. Confederation peer.
In addition, the algorithm SHOULD NOT be applied when both paths are In addition, the algorithm SHOULD NOT be applied when both paths are
from peers with identical BGP identifier (i.e., there exist parallel from peers with identical BGP identifier (i.e., there exist parallel
BGP sessions between two routers). As the peering addresses for the BGP sessions between two BGP speakers). As the peering addresses for
parallel sessions are typically allocated by one AS (possibly with the parallel sessions are typically allocated by one AS (possibly
route selection considerations), the algorithm (if applied) could with route selection considerations), the algorithm (if applied)
impact the existing routing setup. Furthermore, by not applying the could impact the existing routing setup. Furthermore, by not applying
algorithm, the allocation of peering addresses would remain as a the algorithm, the allocation of peering addresses would remain as a
simple and effective tool in influencing route selection when simple and effective tool in influencing route selection when
parallel BGP sessions exist. parallel BGP sessions exist.
6. The Benefits 4. The Benefits
The proposed revision to the BGP route selection rules avoids The proposed revision to the BGP route selection rules avoids
unnecessary best path transitions between external paths under unnecessary best path transitions between external paths under
certain conditions. Clearly the revision would help reduce routing certain conditions. Clearly the revision would help reduce routing
and forwarding changes in a network, thus help the overall network and forwarding changes in a network, thus help the overall network
stabilities. stabilities.
More importantly, as shown in the following example, the proposed More importantly, as shown in the following example, the proposed
revision can be used to eliminate certain BGP route oscillations in revision can be used to eliminate certain BGP route oscillations in
which more than one external paths from one router contribute to the which more than one external paths from one BGP speaker contribute to
churn. Note however, that there are permanent BGP route oscillation the churn. Note however, that there are permanent BGP route
scenarios [3] that the mechanism described in this document does not oscillation scenarios [RFC3345] that the mechanism described in this
eliminate. document does not eliminate.
Consider the example in Fig. 1 where Consider the example in Fig. 1 where
o R1, R2, R3 and R4 belong to one AS o R1, R2, R3 and R4 belong to one AS
o R1 is a route reflector with R3 as its client. o R1 is a route reflector with R3 as its client.
o R2 is a route reflector with R4 as its client. o R2 is a route reflector with R4 as its client.
o The IGP metrics are as listed. o The IGP metrics are as listed.
o External paths (a), (b) and (c) are as described in Fig. 2. o External paths (a), (b) and (c) are as described in Fig. 2.
+----+ 40 +----+ +----+ 40 +----+
skipping to change at page 4, line 8 skipping to change at page 4, line 29
Figure 1 Figure 1
Path AS MED Identifier Path AS MED Identifier
a 1 0 2 a 1 0 2
b 2 20 1 b 2 20 1
c 2 10 5 c 2 10 5
Figure 2 Figure 2
Due to the interaction of route reflection [4] and MEDs, the best Due to the interaction of route reflection [BGP-RR] and MEDs, the
path on R1 keeps churning between (a) and (c), and the best path on best path on R1 keeps churning between (a) and (c), and the best path
R3 keeps churning between (a) and (b). on R3 keeps churning between (a) and (b).
With the proposed algorithm R3 would not switch the best path from With the proposed algorithm R3 would not switch the best path from
(a) to (b) even after R1 withdraws (c) toward its clients, and that (a) to (b) even after R1 withdraws (c) toward its clients, and that
is enough to stop the route oscillation. is enough to stop the route oscillation.
Although this type of route oscillations can also be eliminated by Although this type of route oscillations can also be eliminated by
other route reflection enhancements being developed, the proposed other route reflection enhancements being developed, the proposed
algorithm is very simple and can be deployed immediately. algorithm is extremely simple and can be implemented and deployed
immediately without introducing any backward compatibility issues.
7. Remarks 5. Remarks
The proposed algorithm is backward-compatible, and can be deployed on The proposed algorithm is backward-compatible, and can be deployed on
a per-node basis. The deployment of the algorithm is highly a per-BGP-speaker basis. The deployment of the algorithm is highly
recommended on a router with multiple external BGP peers (especially recommended on a BGP speaker with multiple external BGP peers
the ones connecting to an inter-exchange point). (especially the ones connecting to an inter-exchange point).
Compared to the existing behavior, the proposed algorithm may Compared to the existing behavior, the proposed algorithm may
introduce some "non-determinism" in the BGP route selection - introduce some "non-determinism" in the BGP route selection -
although one can argue that the BGP Identifier comparison in the although one can argue that the BGP Identifier comparison in the
existing route selection has already introduced some "randomness" as existing route selection has already introduced some "randomness" as
described in the introduction section. Such "non-determinism" or described in the introduction section. Such "non-determinism" has
"randomness" has not been shown to be detrimental in practice, and not been shown to be detrimental in practice, and can be completely
can be completely eliminated by using the existing mechanisms (such eliminated by using the existing mechanisms (such as setting
as setting LOCAL_PREF or MED) if so desired. LOCAL_PREF or MED) if so desired.
8. Security Considerations 6. IANA Considerations
This extension does not require any action by IANA.
7. Security Considerations
This extension does not introduce any security issues. This extension does not introduce any security issues.
9. Acknowledgments 8. Acknowledgments
The idea presented was inspired by a route oscillation case observed The idea presented was inspired by a route oscillation case observed
on the BBN/Genuity backbone in 1998. The algorithm was also on the BBN/Genuity backbone in 1998. The algorithm was also
implemented at that time. implemented and deployed at that time.
The authors would like to thank Yakov Rekhter and Ravi Chandra for The authors would like to thank Yakov Rekhter and Ravi Chandra for
their comments on the initial idea. their comments on the initial idea.
10. References 9. Normative References
[1] Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 [BGP] Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004.
[2] E. Chen and J. Yuan, "AS-wide Unique BGP Identifier for BGP-4", [BGP-RR] T. Bates, R. Chandra, and E. Chen, "BGP Route Reflection -
<draft-ietf-idr-bgp-identifier-05.txt>, April 2005. An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[3] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border Gateway [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, Requirement Levels", BCP 14, RFC 2119, March 1997.
August 2002.
[4] T. Bates, R. Chandra, and E. Chen, "BGP Route Reflection - An 10. Non-normative References
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [BGP-ID] E. Chen and J. Yuan, "AS-wide Unique BGP Identifier for
Levels", BCP 14, RFC 2119, March 1997. BGP-4", Work in Progress, draft-ietf-idr-bgp-identifier-06.txt,
November 2005.
[RFC3345] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border
Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC
3345, August 2002.
11. Author Information 11. Author Information
Enke Chen Enke Chen
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
e-mail: enkechen@cisco.com
Email: enkechen@cisco.com
Srihari R. Sangli Srihari R. Sangli
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
e-mail: rsrihari@cisco.com
Email: rsrihari@cisco.com
12. Intellectual Property Considerations 12. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 33 change blocks. 
59 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/