draft-ietf-idr-avoid-transition-04.txt   draft-ietf-idr-avoid-transition-05.txt 
Network Working Group E. Chen Network Working Group E. Chen
Internet Draft S. Sangli Internet Draft S. Sangli
Expiration Date: June 2006 Cisco Systems Expiration Date: September 2007 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-04.txt draft-ietf-idr-avoid-transition-05.txt
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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.
Abstract Abstract
In this document we propose a revision to the BGP route selection In this document we propose an extension 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 extension 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 BGP speaker contribute to the churn. external path from one BGP speaker contributes to the churn.
1. Introduction 1. Introduction
The last two steps of the BGP route selection (Sect. 9.1.2.2, [BGP]) 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
[BGP-ID]) for a BGP speaker is allocated by the AS to which the [BGP-ID]) for a BGP speaker is allocated by the AS to which the
speaker belongs. As a result, for a local BGP speaker, the BGP speaker belongs. As a result, for a local BGP speaker, the BGP
identifier of a route received from an external peer is just an identifier of a route received from an external peer is just an
random number. When routes under consideration are from external random number. When routes under consideration are from external
peers, the result from the last two steps of the route selection is peers, the result from the last two steps of the route selection is
therefore "random" as 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 an extension to the
route selection rules that would avoid unnecessary best path BGP 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 extension 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 BGP speaker contribute to the more than one external path from one BGP speaker contributes to the
churn. churn.
2. 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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. The Algorithm 3. The Algorithm
skipping to change at page 3, line 10 skipping to change at page 3, line 10
BGP sessions between two BGP speakers). As the peering addresses for BGP sessions between two BGP speakers). As the peering addresses for
the parallel sessions are typically allocated by one AS (possibly the parallel sessions are typically allocated by one AS (possibly
with route selection considerations), the algorithm (if applied) with route selection considerations), the algorithm (if applied)
could impact the existing routing setup. Furthermore, by not applying could impact the existing routing setup. Furthermore, by not applying
the 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.
4. The Benefits 4. The Benefits
The proposed revision to the BGP route selection rules avoids The proposed extension 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 extension 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. stability.
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 extension can be used to eliminate certain BGP route oscillations in
which more than one external paths from one BGP speaker contribute to which more than one external path from one BGP speaker contributes to
the churn. Note however, that there are permanent BGP route the churn. Note however, that there are permanent BGP route
oscillation scenarios [RFC3345] that the mechanism described in this oscillation scenarios [RFC3345] that the mechanism described in this
document does not 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.
skipping to change at page 4, line 29 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 [BGP-RR] and MEDs, the Due to the interaction of the route reflection [BGP-RR] and the
best path on R1 keeps churning between (a) and (c), and the best path MULTI_EXIT_DISC (MED) attribute, the best path on R1 keeps churning
on R3 keeps churning between (a) and (b). between (a) and (c), and the best path 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 extremely simple and can be implemented and deployed algorithm is extremely simple and can be implemented and deployed
immediately without introducing any backward compatibility issues. immediately without introducing any backward compatibility issues.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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 and deployed 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.
9. Normative References 9. Normative References
[BGP] Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol
(BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. 4 (BGP-4)", RFC 4271, January 2006.
[BGP-RR] T. Bates, R. Chandra, and E. Chen, "BGP Route Reflection - [BGP-RR] T. Bates, R. Chandra, and E. Chen, "BGP Route Reflection -
An Alternative to Full Mesh IBGP", RFC 2796, April 2000. An Alternative to Full Mesh IBGP", RFC 4456, April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Non-normative References 10. Non-normative References
[BGP-ID] E. Chen and J. Yuan, "AS-wide Unique BGP Identifier for [BGP-ID] E. Chen and J. Yuan, "AS-wide Unique BGP Identifier for
BGP-4", Work in Progress, draft-ietf-idr-bgp-identifier-06.txt, BGP-4", Work in Progress, draft-ietf-idr-bgp-identifier-08.txt,
November 2005. November 2006.
[RFC3345] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border [RFC3345] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border
Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC
3345, August 2002. 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.
skipping to change at page 7, line 31 skipping to change at page 7, line 31
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
13. Full Copyright Notice 13. Full Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 18 change blocks. 
27 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/