idnits 2.17.00 (12 Aug 2021) /tmp/idnits36659/draft-ietf-idr-bgp-bestpath-selection-criteria-12.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to directly say this. It does mention RFC4271 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 -- The document date (June 5, 2019) is 1074 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) -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDR Working Group Rajiv Asati 2 Internet Draft Cisco Systems 3 Updates: 4271 (if approved) 4 Intended status: Standards Track 5 Expires: December 5, 2019 6 June 5, 2019 8 BGP Bestpath Selection Criteria Enhancement 9 draft-ietf-idr-bgp-bestpath-selection-criteria-12.txt 11 Abstract 13 BGP specification (RFC4271) prescribes 'BGP next-hop reachability' 14 as one of the key 'Route Resolvability Condition' that must be 15 satisfied before the BGP bestpath candidate selection. This 16 condition, however, may not be sufficient (as explained in the 17 Appendix section) and would desire further granularity. 19 This document defines enhances the "Route Resolvability Condition" 20 to facilitate the next-hop to be resolved in the chosen data plane. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 5, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction...................................................2 57 2. Specification Language.........................................3 58 3. Route Resolvability Condition - Modification...................3 59 4. Conclusions....................................................4 60 5. Security Considerations........................................5 61 6. IANA Considerations............................................5 62 7. Acknowledgments................................................5 63 8. Appendix.......................................................5 64 9. References.....................................................8 65 Author's Addresses................................................9 67 1. Introduction 69 As per BGP specification [RFC4271], when a router receives a BGP 70 path, BGP must qualify it as the valid candidate prior to the BGP 71 bestpath selection using the 'Route Resolvability Condition' 72 (section#9.1.2.1 of RFC4271]. After the path gets qualified as the 73 bestpath candidate, it becomes eligible to be the bestpath, and may 74 get advertised out to the neigbhor(s), if it became the bestpath. 76 However, in BGP networks that utilize data plane protocol other than 77 IP, such as MPLS [RFC3031] etc. to forward the received traffic 78 towards the next-hop, the above qualification condition may not be 79 sufficient. In fact, this may expose the BGP networks to experience 80 traffic blackholing i.e. traffic loss, due to malfunctioning of the 81 chosen data plane protocol to the next-hop. This is explained 82 further in the Appendix section. 84 This document defines further granularity to the "Route 85 Resolvability Condition" by (a) resolving the BGP next-hop 86 reachability in the forwarding database of a particular data plane 87 protocol, and (b) optionally including the BGP next-hop "path 88 availability" check. 90 The goal is to enable BGP to select the bestpaths based on whether 91 or not the corresponding nexthop can be resolved in the valid data 92 plane. 94 2. Specification Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Route Resolvability Condition - Modification 102 This document proposes two amendments to 'Route Resolvability 103 Condition', which is defined in RFC4271, in consideration for a 104 particular data plane protocol: 106 1) The next-hop reachability (check) SHOULD be resolved in a 107 forwarding database of a particular data plane protocol. 109 For example, if a BGP IPv4/v6 or VPNv4/v6 path wants to use 110 MPLS data plane to the next-hop, as determined by the policy, 111 then the BGP 'next-hop reachability' should be resolved using 112 the MPLS forwarding database. In another example, if BGP path 113 wants to use the IP data plane to the next-hop, as determined 114 by the policy, then BGP 'next-hop reachability' should be 115 resolved using the IP forwarding database. The latter example 116 relates to MPLS-in-IP encapsulation techniques such as 117 [RFC4817], [RFC4023] etc. 119 The selection of particular data plane is a matter of a policy, and 120 is outside the scope of this document. It is envisioned that the 121 policy would exist for either per-neighbor or per-SAFI or both. A 122 dynamic signaling such as BGP encapsulation SAFI (or tunnel encap 123 attribute) [RFC5512] may be used to convey the data plane protocol 124 chosen by the policy. 126 This check is about confirming the availability of the valid 127 forwarding entry for the next-hop in the forwarding database of the 128 chosen data plane protocol. 130 2) The 'path availability' check for the BGP next-hop MAY be 131 performed. This criterion checks for the functional data plane 132 path to the next-hop in a particular data plane protocol. 134 The path availability check may be performed by any of the OAM data- 135 plane liveness mechanisms associated with the data plane that is 136 used to reach the Next Hop. The data plane protocol for this 137 criterion MUST be the same as the one selected by the previous 138 criterion (#1). 140 The mechanism(s) to perform the "path availability" check and the 141 selection of particular data plane are a matter of a policy and 142 outside the scope of this document. 144 For example, if a BGP VPNv4 path wants to use the MPLS as the 145 data plane protocol to the next-hop, then MPLS path 146 availability to the next-hop should be evaluated i.e. liveness 147 of MPLS LSP to the next-hop should be validated. 149 This check is about confirming the availability of functioning path 150 to the next-hop. Note that it is not necessary to trigger the data- 151 plane liveness mechanism for a given next-hop as a consequence of 152 this check, though it may be an option. Another option is to do it a 153 priori. The selection of a particular option is deemed deployment 154 specific and outside the scope of this document. 156 4. Conclusions 158 Both amendments discussed in section 2 provide further clarity and 159 granularity to help the BGP speaker to either continue to advertise 160 a BGP path's reachability or withdraw the BGP path's reachability, 161 based on the consideration for the path's next-hop reachability 162 and/or availability in a particular data plane. 164 It is not expected that the proposed amendments would negatively 165 impact BGP convergence, barring any implementation specifics. 167 The intention of this document is to help operators to build BGP 168 networks that can avoid self-blackholing. 170 5. Security Considerations 172 While this draft doesn't impose any additional security constraints, 173 it can help with mitigating one particular type of routing attack in 174 which a BGP speaker could receive routes with an arbitrary next-hop. 175 If the next-hop is not reachable, then those routes/paths would not 176 get selected. 178 6. IANA Considerations 180 None. 182 7. Acknowledgments 184 Yakov Rekhter provided critical suggestions and feedback to improve 185 this document. Thanks to John Scudder and Chandrashekhar Appanna for 186 contributing to the discussions that formed the basis of this 187 document. Thanks to Ilya Varlashkin and Michael Benjamin, who made 188 the case to revive this document and provided useful feedback. Also 189 thanks to Robert Raszuk and Keyur Patel for constructive feedback. 191 This document was prepared using 2-Word-v2.0.template.dot. 193 8. Appendix 195 8.1. Problem Applicability 197 In IP networks using BGP, a router would continue to attract traffic 198 by advertising the BGP prefix reachability to neighbor(s) as long as 199 the router had a route to the next-hop in its routing table, but 200 independent of whether the router has a functional forwarding path 201 to the next-hop. This may cause the forwarded traffic to be dropped 202 inside the IP network. 204 In MPLS or MPLS VPN networks [RFC4364], the same problem is observed 205 if the functional MPLS LSP to the next-hop is not available (due to 206 the forwarding path error on any node along the path to the next- 207 hop). 209 The following MPLS/VPN topology clarifies the problem - 210 <-eBGP/IGP-> <-------MP-BGP------> <-eBGP/IGP-> 212 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 213 ^ 214 ======PE1-PE2 LSP==> ^ 215 ^ 216 a.b.c.d 218 Figure 1 MPLS VPN Network 220 In the network illustrated in Figure 1, the PE1 to PE2 LSP may be 221 non-functional due to any reason such as corrupted MPLS Forwarding 222 Table entry, or the missing MPLS Forwarding table entry, or LDP 223 binding defect, or down LDP session between the P routers (with 224 independent label distribution control) etc. In such a situation, it 225 is clear that the CE1->CE2 traffic inserted into the MPLS network by 226 PE1 will get dropped inside the MPLS network. 228 It is undesirable to have PE1 continue to convey to the CE1 router 229 that PE1 (and the MPLS network) is still the next-hop for the remote 230 VPN reachability, without being sure of the corresponding LSP 231 health. 233 8.1.1. Multi-Homed VPN Site 235 If the remote VPN site is dual-homed to both PE2 and PE3, then PE1 236 may learn two VPNv4 paths to the prefix a.b.c.d. via PE2 and PE3 237 routers, as shown below in Figure 2. PE1 may select the bestpath for 238 the prefix a.b.c.d via PE2 (say, for which the PE1->PE2 LSP is mal- 239 functioning) and advertise that bestpath to CE1 in the context of 240 figure 2. 242 <------MP-BGP------> 244 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 245 \ / ^ 246 \~~~~~~~~~~PE3~~~~~~~/ ^ 247 ^ 248 a.b.c.d 250 Figure 2 MPLS VPN Network - CE2 Dual-Homing 252 This causes CE1 to likely send the traffic destined to prefix 253 a.b.c.d to the PE1 router, which forwards the traffic over the 254 malfunctioning LSP to PE2. It is clear that this MPLS encapsulated 255 VPN traffic ends up getting dropped or blackholed somewhere inside 256 the MPLS network. 258 It is desirable to force PE1 to select an alternate bestpath via 259 that next-hop (such as PE3), whose LSP is correctly functioning. 261 8.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity 263 The local VPN site may have a backup/dial-up link available at the 264 CE router, but the backup link will not even be activated as long as 265 the CE's routing table continues to point to the PE router as the 266 next-hop (over the MPLS/VPN network). 268 <------MP-BGP------> 270 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 271 \ / ^ 272 \~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/ ^ 273 ^ 274 a.b.c.d 276 Figure 3 MPLS VPN Network - CE1-CE2 Backup connection 278 Unless PE2 withdraws the route via the routing protocol used on the 279 PE-CE link, CE1 will not be able to activate the backup link 280 (barring any tracking functionality) to the remote VPN site. 282 In summary, if PE1 could appropriately qualify the BGP VPNv4 283 bestpath, then the VPN traffic outage could likely be avoided. Even 284 if the VPN site was not multi-homed, it is desirable to force PE1 to 285 withdraw the path from CE1 to improve the CE-to-CE convergence. This 286 document proposes a mechanism to achieve the optimal BGP behavior at 287 PE. 289 8.1.3. 6PE or 6VPE 291 This problem is very much applicable to the MPLS network that is 292 providing either 6PE [RFC4978] or 6VPE [RFC4659] service to 293 transport IPv6 packets over the MPLS network. 295 9. References 297 9.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 303 Networks (VPNs)", RFC4364, February 2006. 305 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 306 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 308 9.2. Informative References 310 [RFC3031] Rosen, et al., "Multiprotocol Label Switching 311 Architecture", RFC3031, Jan 2001. 313 [RFC5512] Rosen, E., Mohapatra, P., "BGP Encapsulation SAFI and BGP 314 Tunnel Encapsulation Attribute", RFC5512, April 2009. 316 [RFC4023] Rosen, et al., "Encapsulating MPLS in IP or Generic 317 Routing Encapsulation", RFC4023, March 2005. 319 [RFC4817] Townsley, et al., "Encapsulation of MPLS over Layer 2 320 Tunneling Protocol Version 3", RFC4817, Nov 2006. 322 [RFC4978] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 323 Using IPv6 Provider Edge Routers", RFC4978, Feb 2007. 325 [RFC4659] De Clercq, et al., "BGP-MPLS IP VPN Extension for IPv6 326 VPN", RFC4659, Sep 2006. 328 Author's Addresses 330 Rajiv Asati 331 Cisco Systems 332 7025 Kit Creek Road 333 RTP, NC 27560 USA 334 Email: rajiva@cisco.com