idnits 2.17.1 draft-ietf-idr-avoid-transition-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 243. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2796 (ref. 'BGP-RR') (Obsoleted by RFC 4456) == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgp-identifier-06 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Chen 3 Internet Draft S. Sangli 4 Expiration Date: May 2006 Cisco Systems 6 Avoid BGP Best Path Transitions from One External to Another 8 draft-ietf-idr-avoid-transition-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 In this document we propose a revision to the BGP route selection 36 rules that would avoid unnecessary best path transitions between 37 external paths under certain conditions. The proposed revision would 38 help the overall network stability, and more importantly, would 39 eliminate certain BGP route oscillations in which more than one 40 external paths from one BGP speaker contribute to the churn. 42 1. Introduction 44 The last two steps of the BGP route selection (Sect. 9.1.2.2, [BGP]) 45 involve comparing the BGP identifiers and the peering addresses. The 46 BGP identifier (treated either as an IP address, or just an integer 47 [BGP-ID]) for a BGP speaker is allocated by the AS to which the 48 speaker belongs. As a result, for a local BGP speaker, the BGP 49 identifier of a route received from an external peer is just an 50 random number. When routes under consideration are from external 51 peers, the result from the last two steps of the route selection is 52 therefore "random" as far as the local BGP speaker is concerned. 54 It is based on this observation that we propose a revision to the BGP 55 route selection rules that would avoid unnecessary best path 56 transitions between external paths under certain conditions. The 57 proposed revision would help the overall network stability, and more 58 importantly, would eliminate certain BGP route oscillations in which 59 more than one external paths from one BGP speaker contribute to the 60 churn. 62 2. Specification of Requirements 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [RFC2119]. 68 3. The Algorithm 70 Consider the case in which the existing best path A is from an 71 external peer, and another external path B is then selected as the 72 new best path by the route selection algorithm described in [BGP]. 73 When neither Path A nor Path B is eliminated by the route selection 74 algorithm prior to Step f) - BGP identifier comparison (Sect. 9.1.2.2 75 [BGP]), we propose that the existing best path (Path A) be kept as 76 the best path (thus avoiding switching the best path to Path B). 78 This algorithm SHOULD NOT be applied when either path is from a BGP 79 Confederation peer. 81 In addition, the algorithm SHOULD NOT be applied when both paths are 82 from peers with identical BGP identifier (i.e., there exist parallel 83 BGP sessions between two BGP speakers). As the peering addresses for 84 the parallel sessions are typically allocated by one AS (possibly 85 with route selection considerations), the algorithm (if applied) 86 could impact the existing routing setup. Furthermore, by not applying 87 the algorithm, the allocation of peering addresses would remain as a 88 simple and effective tool in influencing route selection when 89 parallel BGP sessions exist. 91 4. The Benefits 93 The proposed revision to the BGP route selection rules avoids 94 unnecessary best path transitions between external paths under 95 certain conditions. Clearly the revision would help reduce routing 96 and forwarding changes in a network, thus help the overall network 97 stabilities. 99 More importantly, as shown in the following example, the proposed 100 revision can be used to eliminate certain BGP route oscillations in 101 which more than one external paths from one BGP speaker contribute to 102 the churn. Note however, that there are permanent BGP route 103 oscillation scenarios [RFC3345] that the mechanism described in this 104 document does not eliminate. 106 Consider the example in Fig. 1 where 108 o R1, R2, R3 and R4 belong to one AS 109 o R1 is a route reflector with R3 as its client. 110 o R2 is a route reflector with R4 as its client. 111 o The IGP metrics are as listed. 112 o External paths (a), (b) and (c) are as described in Fig. 2. 114 +----+ 40 +----+ 115 | R1 |--------------| R2 | 116 +----+ +----+ 117 | | 118 | | 119 | 10 | 10 120 | | 121 | | 122 +----+ +----+ 123 | R3 | | R4 | 124 +----+ +----+ 125 / \ | 126 / \ | 127 (a) (b) (c) 129 Figure 1 131 Path AS MED Identifier 132 a 1 0 2 133 b 2 20 1 134 c 2 10 5 136 Figure 2 138 Due to the interaction of route reflection [BGP-RR] and MEDs, the 139 best path on R1 keeps churning between (a) and (c), and the best path 140 on R3 keeps churning between (a) and (b). 142 With the proposed algorithm R3 would not switch the best path from 143 (a) to (b) even after R1 withdraws (c) toward its clients, and that 144 is enough to stop the route oscillation. 146 Although this type of route oscillations can also be eliminated by 147 other route reflection enhancements being developed, the proposed 148 algorithm is extremely simple and can be implemented and deployed 149 immediately without introducing any backward compatibility issues. 151 5. Remarks 153 The proposed algorithm is backward-compatible, and can be deployed on 154 a per-BGP-speaker basis. The deployment of the algorithm is highly 155 recommended on a BGP speaker with multiple external BGP peers 156 (especially the ones connecting to an inter-exchange point). 158 Compared to the existing behavior, the proposed algorithm may 159 introduce some "non-determinism" in the BGP route selection - 160 although one can argue that the BGP Identifier comparison in the 161 existing route selection has already introduced some "randomness" as 162 described in the introduction section. Such "non-determinism" has 163 not been shown to be detrimental in practice, and can be completely 164 eliminated by using the existing mechanisms (such as setting 165 LOCAL_PREF or MED) if so desired. 167 6. IANA Considerations 169 This extension does not require any action by IANA. 171 7. Security Considerations 173 This extension does not introduce any security issues. 175 8. Acknowledgments 177 The idea presented was inspired by a route oscillation case observed 178 on the BBN/Genuity backbone in 1998. The algorithm was also 179 implemented and deployed at that time. 181 The authors would like to thank Yakov Rekhter and Ravi Chandra for 182 their comments on the initial idea. 184 9. Normative References 186 [BGP] Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 187 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. 189 [BGP-RR] T. Bates, R. Chandra, and E. Chen, "BGP Route Reflection - 190 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, March 1997. 195 10. Non-normative References 197 [BGP-ID] E. Chen and J. Yuan, "AS-wide Unique BGP Identifier for 198 BGP-4", Work in Progress, draft-ietf-idr-bgp-identifier-06.txt, 199 November 2005. 201 [RFC3345] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border 202 Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 203 3345, August 2002. 205 11. Author Information 207 Enke Chen 208 Cisco Systems, Inc. 209 170 W. Tasman Dr. 210 San Jose, CA 95134 212 Email: enkechen@cisco.com 214 Srihari R. Sangli 215 Cisco Systems, Inc. 216 170 W. Tasman Dr. 217 San Jose, CA 95134 219 Email: rsrihari@cisco.com 221 12. Intellectual Property Considerations 223 The IETF takes no position regarding the validity or scope of any 224 Intellectual Property Rights or other rights that might be claimed to 225 pertain to the implementation or use of the technology described in 226 this document or the extent to which any license under such rights 227 might or might not be available; nor does it represent that it has 228 made any independent effort to identify any such rights. Information 229 on the procedures with respect to rights in RFC documents can be 230 found in BCP 78 and BCP 79. 232 Copies of IPR disclosures made to the IETF Secretariat and any 233 assurances of licenses to be made available, or the result of an 234 attempt made to obtain a general license or permission for the use of 235 such proprietary rights by implementers or users of this 236 specification can be obtained from the IETF on-line IPR repository at 237 http://www.ietf.org/ipr. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights that may cover technology that may be required to implement 242 this standard. Please address the information to the IETF at ietf- 243 ipr@ietf.org. 245 13. Full Copyright Notice 247 Copyright (C) The Internet Society (2005). 249 This document is subject to the rights, licenses and restrictions 250 contained in BCP 78, and except as set forth therein, the authors 251 retain all their rights. 253 This document and the information contained herein are provided on an 254 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 255 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 256 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 257 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 258 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 259 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.