idnits 2.16.02
/tmp/draft-ietf-idr-avoid-transition-05.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, updated by RFC 4748 on
line 261.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 232.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 239.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 245.
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 IETF Trust 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)
== Outdated reference: draft-ietf-idr-bgp-identifier has been published as
RFC 6286
Summary: 1 error (**), 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: September 2007 Cisco Systems
6 Avoid BGP Best Path Transitions from One External to Another
8 draft-ietf-idr-avoid-transition-05.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 an extension to the BGP route selection
36 rules that would avoid unnecessary best path transitions between
37 external paths under certain conditions. The proposed extension would
38 help the overall network stability, and more importantly, would
39 eliminate certain BGP route oscillations in which more than one
40 external path from one BGP speaker contributes 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 an extension to the
55 BGP route selection rules that would avoid unnecessary best path
56 transitions between external paths under certain conditions. The
57 proposed extension would help the overall network stability, and more
58 importantly, would eliminate certain BGP route oscillations in which
59 more than one external path from one BGP speaker contributes 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 comparing all the paths in route selection, if neither Path A
74 nor Path B is eliminated by the route selection algorithm prior to
75 Step f) - BGP identifier comparison (Sect. 9.1.2.2 [BGP]), we propose
76 that the existing best path (Path A) be kept as the best path (thus
77 avoiding switching the best path to Path B).
79 This algorithm SHOULD NOT be applied when either path is from a BGP
80 Confederation peer.
82 In addition, the algorithm SHOULD NOT be applied when both paths are
83 from peers with identical BGP identifier (i.e., there exist parallel
84 BGP sessions between two BGP speakers). As the peering addresses for
85 the parallel sessions are typically allocated by one AS (possibly
86 with route selection considerations), the algorithm (if applied)
87 could impact the existing routing setup. Furthermore, by not applying
88 the algorithm, the allocation of peering addresses would remain as a
89 simple and effective tool in influencing route selection when
90 parallel BGP sessions exist.
92 4. The Benefits
94 The proposed extension to the BGP route selection rules avoids
95 unnecessary best path transitions between external paths under
96 certain conditions. Clearly the extension would help reduce routing
97 and forwarding changes in a network, thus help the overall network
98 stability.
100 More importantly, as shown in the following example, the proposed
101 extension can be used to eliminate certain BGP route oscillations in
102 which more than one external path from one BGP speaker contributes to
103 the churn. Note however, that there are permanent BGP route
104 oscillation scenarios [RFC3345] that the mechanism described in this
105 document does not eliminate.
107 Consider the example in Fig. 1 where
109 o R1, R2, R3 and R4 belong to one AS
110 o R1 is a route reflector with R3 as its client.
111 o R2 is a route reflector with R4 as its client.
112 o The IGP metrics are as listed.
113 o External paths (a), (b) and (c) are as described in Fig. 2.
115 +----+ 40 +----+
116 | R1 |--------------| R2 |
117 +----+ +----+
118 | |
119 | |
120 | 10 | 10
121 | |
122 | |
123 +----+ +----+
124 | R3 | | R4 |
125 +----+ +----+
126 / \ |
127 / \ |
128 (a) (b) (c)
130 Figure 1
132 Path AS MED Identifier
133 a 1 0 2
134 b 2 20 1
135 c 2 10 5
137 Figure 2
139 Due to the interaction of the route reflection [BGP-RR] and the
140 MULTI_EXIT_DISC (MED) attribute, the best path on R1 keeps churning
141 between (a) and (c), and the best path on R3 keeps churning between
142 (a) and (b).
144 With the proposed algorithm R3 would not switch the best path from
145 (a) to (b) even after R1 withdraws (c) toward its clients, and that
146 is enough to stop the route oscillation.
148 Although this type of route oscillations can also be eliminated by
149 other route reflection enhancements being developed, the proposed
150 algorithm is extremely simple and can be implemented and deployed
151 immediately without introducing any backward compatibility issues.
153 5. Remarks
155 The proposed algorithm is backward-compatible, and can be deployed on
156 a per-BGP-speaker basis. The deployment of the algorithm is highly
157 recommended on a BGP speaker with multiple external BGP peers
158 (especially the ones connecting to an inter-exchange point).
160 Compared to the existing behavior, the proposed algorithm may
161 introduce some "non-determinism" in the BGP route selection -
162 although one can argue that the BGP Identifier comparison in the
163 existing route selection has already introduced some "randomness" as
164 described in the introduction section. Such "non-determinism" has
165 not been shown to be detrimental in practice, and can be completely
166 eliminated by using the existing mechanisms (such as setting
167 LOCAL_PREF or MED) if so desired.
169 6. IANA Considerations
171 This extension does not require any action by IANA.
173 7. Security Considerations
175 This extension does not introduce any security issues.
177 8. Acknowledgments
179 The idea presented was inspired by a route oscillation case observed
180 on the BBN/Genuity backbone in 1998. The algorithm was also
181 implemented and deployed at that time.
183 The authors would like to thank Yakov Rekhter and Ravi Chandra for
184 their comments on the initial idea.
186 9. Normative References
188 [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol
189 4 (BGP-4)", RFC 4271, January 2006.
191 [BGP-RR] T. Bates, R. Chandra, and E. Chen, "BGP Route Reflection -
192 An Alternative to Full Mesh IBGP", RFC 4456, April 2006.
194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
195 Requirement Levels", BCP 14, RFC 2119, March 1997.
197 10. Non-normative References
199 [BGP-ID] E. Chen and J. Yuan, "AS-wide Unique BGP Identifier for
200 BGP-4", Work in Progress, draft-ietf-idr-bgp-identifier-08.txt,
201 November 2006.
203 [RFC3345] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border
204 Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC
205 3345, August 2002.
207 11. Author Information
209 Enke Chen
210 Cisco Systems, Inc.
211 170 W. Tasman Dr.
212 San Jose, CA 95134
214 Email: enkechen@cisco.com
216 Srihari R. Sangli
217 Cisco Systems, Inc.
218 170 W. Tasman Dr.
219 San Jose, CA 95134
221 Email: rsrihari@cisco.com
223 12. Intellectual Property Considerations
225 The IETF takes no position regarding the validity or scope of any
226 Intellectual Property Rights or other rights that might be claimed to
227 pertain to the implementation or use of the technology described in
228 this document or the extent to which any license under such rights
229 might or might not be available; nor does it represent that it has
230 made any independent effort to identify any such rights. Information
231 on the procedures with respect to rights in RFC documents can be
232 found in BCP 78 and BCP 79.
234 Copies of IPR disclosures made to the IETF Secretariat and any
235 assurances of licenses to be made available, or the result of an
236 attempt made to obtain a general license or permission for the use of
237 such proprietary rights by implementers or users of this
238 specification can be obtained from the IETF on-line IPR repository at
239 http://www.ietf.org/ipr.
241 The IETF invites any interested party to bring to its attention any
242 copyrights, patents or patent applications, or other proprietary
243 rights that may cover technology that may be required to implement
244 this standard. Please address the information to the IETF at ietf-
245 ipr@ietf.org.
247 13. Full Copyright Notice
249 Copyright (C) The IETF Trust (2007).
251 This document is subject to the rights, licenses and restrictions
252 contained in BCP 78, and except as set forth therein, the authors
253 retain all their rights.
255 This document and the information contained herein are provided on an
256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
258 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
259 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
260 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.