idnits 2.17.1 draft-idr-bgp-rt-oscillation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4684, but the abstract doesn't seem to directly say this. It does mention RFC4684 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4684, updated by this document, for RFC5378 checks: 2004-06-02) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR D. Duan 3 Internet-Draft J. Heitz 4 Updates: 4684 (if approved) Cisco 5 Intended status: Standards Track K. Patel 6 Expires: September 14, 2017 Arrcus 7 J. Hass 8 Juniper Networks 9 March 13, 2017 11 Persistent Route Oscillation in BGP Constrained Route Distribution 12 draft-idr-bgp-rt-oscillation-01 14 Abstract 16 RFC4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP 17 speakers to exchange Route Target reachability information (RT- 18 Constrain) to restrict the propagation of Virtual Private Network 19 (VPN) routes. In network scenarios where hierarchical route 20 reflection (RR) is used, the existing RT-Constrain mechanism may 21 result in persistent route oscillations within RRs. This document 22 describes the problem and proposes a solution. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 14, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 72 3. Problem Statement - Persistent Route Oscillations . . . . . . 3 73 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 [RFC4684] defines Multi-Protocol BGP (MP-BGP) procedures that allow 83 BGP speakers to exchange Route Target reachability information to 84 restrict the propagation of Virtual Private Network (VPN) routes. 86 [RFC4684] section 3.2 defines a route advertisement rule for Route 87 Target membership information. When advertising an RT membership 88 NLRI to a non-client peer, if the best path as selected by the path 89 selection procedure described in Section 9.1 of [RFC4271] is a route 90 received from a non-client peer, and if there is an alternative path 91 to the same destination from a client peer, then the attributes of 92 the client path are advertised to the peer. [RFC4684] does not 93 clarify which path to choose in case there are multiple client paths 94 to the same destination. 96 In network scenarios where hierarchical route reflection (RR) is 97 used, and multiple such client paths exist, persistent route 98 oscillations might be formed based on which client path attributes 99 are advertised to the non-client peers. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 3. Problem Statement - Persistent Route Oscillations 109 44.44.0.39 44.44.0.199 110 +-----+ +-----+ 111 | RR1 | | RR2 | 112 +----\+ +-/---+ 113 (900 to PE1 and PE2) | \ / | (900 to PE1 and PE2) 114 | \ / | 115 | / \ | 116 | / \ | 117 +-----/ +-----+ 118 44.44.2.196 -> | RR3 | | RR4 | <- 44.44.1.193 119 +-----+ +-----+ 120 (3040)->| \ / |<-(3030) 121 | \ / | 122 | / \ | 123 | (3040)(3030)| 124 +-----+ +-----+ 125 55.55.0.42 -> | PE1 | | PE2 | 55.55.0.43 126 +-----+ +-----+ 127 | | 128 RT-1 RT-1 130 Figure 1. RT-Constrain with Hierarchical Route-reflector 132 In Figure 1, Hierarchical RRs are deployed. RR3 and RR4 are first 133 level Router Reflectors and RR1 and RR2 are the second level Route 134 Reflectors. Each RR is using its own router-id as its cluster-id. 135 PE1 and PE2 are Route Reflector clients of RR3 and RR4 while RR3 and 136 RR4 are Route Reflector clients of RR1 and RR2. Both PE1 and PE2 are 137 advertising the route-target information RT-1 to the first level 138 Router Reflectors RR3 and RR4. RR3 and RR4 are also advertising 139 route-target information to the second level Router Reflectors RR1 140 and RR2. The numbers in the parentheses are nexthop metrics. 142 At step #1, RR3 has two paths for RT-1: one from PE1 and the other 143 from PE2. The path from PE1 has next hop metric 3040 and the path 144 from PE2 has next hop metric 3030. RR3 and RR4 select the path from 145 PE2 as the best path (lower metric). RR3 and RR4 advertise their 146 best paths for RT-1 to the second level router reflectors RR1 and 147 RR2. 149 At step #2, RR1 has two paths for RT-1: one path from RR3 and the 150 other path from RR4. The next hop metric to reach PE1 and PE2 are 151 both 900. On RR1 and RR2, if both paths have the same ORIGINATOR_ID, 152 then the lower peer address will be used to select the best path. 153 RR1 selects the path from RR4 as best path because it has a lower 154 peer address than RR3. RR1 advertises RT-1 back to RR3. 156 When announcing RT-1 to its client (RR3), RR1 will set the 157 ORIGINATOR_ID to itself according to [RFC4684] section 3.2.i. 159 At step #3, RR3 has four paths: the first from PE1, the second from 160 PE2, the third from RR1 and a fourth from RR2. For the purposes of 161 this discussion, the path from RR2 is equivalent to that from RR1. 162 The result is the same if either is chosen. RR3 selects the non- 163 client path from RR1 to PE2 as best path because the ORIGINATOR_ID is 164 lower than that of the paths from PE1 and PE2. Since there are 165 client paths available to reach RT-1, RR3 advertises the path 166 attribute of a client path to RR1 according to [RFC4684] section 167 3.2.ii. RR3 could choose either the path from PE1 or PE2. RR3 168 chooses the path attribute of RT-1 from PE1 at random. 170 At step #4, RR1 receives the updates and recalculates the best path. 171 RR1 has a path from RR4 with ORIGINATOR_ID set to PE2's router-id and 172 a path from RR3 with ORIGINATOR_ID set to PE1's router-id. RR1 173 selects the path from RR3 as best path because of lower 174 ORIGINATOR_ID. RR1 sets the ORIGINATOR_ID to its own router-id and 175 sends it back to RR3. 177 At step #5, RR3 receives the updates from RR1 and drops the updates 178 since its own cluster-id is in the cluster list. Now RR3's routing 179 state goes back to that at step #1 with 2 paths from its clients and 180 the whole cycle starts again. 182 The same thing happens on RR4 as on RR3 and the same thing happens on 183 RR2 as on RR1. 185 These iterations results in a persistent route oscillation for RT-1 186 prefix of RT-Constrain address-family on RR1, RR2, RR3 and RR4. 188 4. Solution 190 The solution is for the Route Reflector always to prefer the client 191 paths when selecting a best path. This preference MUST be expressed 192 before step f) of the BGP Decision Tie Breaking rules in 193 Section 9.1.2.2 of [RFC4271]. It MAY be expressed at a higher step. 194 So at Step #3 on RR3, the best path is still the path from PE2. The 195 oscillation terminates with PE2's path. 197 Note that the scenario can not happen if RR1 and RR2 are in the same 198 cluster. So at step #3, RR3 only has two client paths. The update 199 from the top level Route Reflector will be dropped because of the 200 cluster id check. The oscillation never happens with such a 201 topology. 203 5. IANA Considerations 205 This draft makes no request of IANA. 207 6. Security Considerations 209 This extension to BGP does not change the underlying security issues 210 inherent in the existing [RFC4271] and [RFC4684]. 212 7. Acknowledgements 214 The authors would like to thank Shyam Sethuram, Nitin Kumar, Sameer 215 Gulrajani, Mohammed Mirza and Mike Dubrovskiy. 217 8. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, 221 DOI 10.17487/RFC2119, March 1997, 222 . 224 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 225 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 226 DOI 10.17487/RFC4271, January 2006, 227 . 229 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 230 R., Patel, K., and J. Guichard, "Constrained Route 231 Distribution for Border Gateway Protocol/MultiProtocol 232 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 233 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 234 November 2006, . 236 Authors' Addresses 238 Dongling Duan 239 Cisco 240 170 W. Tasman Drive 241 San Jose, CA 95134 242 USA 244 Email: duan@cisco.com 246 Jakob Heitz 247 Cisco 248 170 West Tasman Drive 249 San Jose, CA 95054 250 USA 252 Email: jheitz@cisco.com 254 Keyur Patel 255 Arrcus, Inc 257 Email: keyur@arrcus.com 259 Jeffrey Hass 260 Juniper Networks 261 1194 N. Mathida Ave 262 Sunnyvale, CA 94089 263 USA 265 Email: jhaas@juniper.net