idnits 2.17.1 draft-ietf-idr-bgp-bestpath-selection-criteria-05.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 abstract seems to contain references ([RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 23, 2011) is 4624 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: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 Intended status: Standards Track 4 Expires: February 23, 2012 5 August 23, 2011 7 BGP Bestpath Selection Criteria Enhancement 8 draft-ietf-idr-bgp-bestpath-selection-criteria-05.txt 10 Abstract 12 BGP specification [RFC4271] prescribes 'BGP next-hop reachability' 13 as one of the key 'Route Resolvability Condition' that must be 14 satisfied before the BGP bestpath candidate selection. This 15 condition, however, may not be sufficient (as explained in the 16 Appendix section) and desire further granularity. 18 This document defines enhances the "Route Resolvability Condition" 19 to facilitate the next-hop to be resolved in the chosen data plane. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 23, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Specification Language.........................................3 57 3. Route Resolvability Condition - Modification...................3 58 4. Conclusions....................................................4 59 5. Security Considerations........................................5 60 6. IANA Considerations............................................5 61 7. Acknowledgments................................................5 62 8. Appendix.......................................................5 63 9. References.....................................................8 64 Author's Addresses................................................9 66 1. Introduction 68 As per BGP specification [RFC4271], when a router receives a BGP 69 path, BGP must qualify it as the valid candidate prior to the BGP 70 bestpath selection using the 'Route Resolvability Condition' 71 (section#9.1.2.1 of RFC4271]. After the path gets qualified as the 72 bestpath candidate, it becomes eligible to be the bestpath, and may 73 get advertised out to the neigbhor(s), if it became the bestpath. 75 However, in BGP networks that utilize data plane protocol other than 76 IP, such as MPLS [RFC3031] etc. to forward the received traffic 77 towards the next-hop, the above qualification condition may not be 78 sufficient. In fact, this may expose the BGP networks to experience 79 traffic blackholing i.e. traffic loss, due to malfunctioning of the 80 chosen data plane protocol to the next-hop. This is explained 81 further in the Appendix section. 83 This document defines further granularity to the "Route 84 Resolvability Condition" by (a) resolving the BGP next-hop 85 reachability in the forwarding database of a particular data plane 86 protocol, and (b) optionally including the BGP next-hop "path 87 availability" check. 89 The goal is to enable BGP to select the bestpaths based on whether 90 or not the corresponding nexthop can be resolved in the valid data 91 plane. 93 2. Specification Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Route Resolvability Condition - Modification 101 This document proposes two amendments to 'Route Resolvability 102 Condition', which is defined in RFC4271, in consideration for a 103 particular data plane protocol: 105 1) The next-hop reachability (check) SHOULD be resolved in a 106 forwarding database of a particular data plane protocol. 108 For example, if a BGP IPv4/v6 or VPNv4/v6 path wants to use 109 MPLS data plane to the next-hop, as determined by the policy, 110 then the BGP 'next-hop reachability' should be resolved using 111 the MPLS forwarding database. In another example, if BGP path 112 wants to use the IP data plane to the next-hop, as determined 113 by the policy, then BGP 'next-hop reachability' should be 114 resolved using the IP forwarding database. The latter example 115 relates to MPLS-in-IP encapsulation techniques such as 116 [RFC4817], [RFC4023] etc. 118 The selection of particular data plane is a matter of a policy, and 119 is outside the scope of this document. It is envisioned that the 120 policy would exist for either per-neighbor or per-SAFI or both. A 121 dynamic signaling such as BGP encapsulation SAFI (or tunnel encap 122 attribute) [RFC5512] may be used to convey the data plane protocol 123 chosen by the policy. 125 This check is about confirming the availability of the valid 126 forwarding entry for the next-hop in the forwarding database of the 127 chosen data plane protocol. 129 2) The 'path availability' check for the BGP next-hop MAY be 130 performed. This criterion checks for the functional data plane 131 path to the next-hop in a particular data plane protocol. 133 The path availability check may be performed by any of the OAM data- 134 plane liveness mechanisms associated with the data plane that is 135 used to reach the Next Hop. The data plane protocol for this 136 criterion MUST be the same as the one selected by the previous 137 criterion (#1). 139 The mechanism(s) to perform the "path availability" check and the 140 selection of particular data plane are a matter of a policy and 141 outside the scope of this document. 143 For example, if a BGP VPNv4 path wants to use the MPLS as the 144 data plane protocol to the next-hop, then MPLS path 145 availability to the next-hop should be evaluated i.e. liveness 146 of MPLS LSP to the next-hop should be validated. 148 This check is about confirming the availability of functioning path 149 to the next-hop. Note that it is not necessary to trigger the data- 150 plane liveness mechanism for a given next-hop as a consequence of 151 this check, though it may be an option. Another option is to do it a 152 priori. The selection of a particular option is deemed deployment 153 specific and outside the scope of this document. 155 4. Conclusions 157 Both amendments discussed in section 2 provide further clarity and 158 granularity to help the BGP speaker to either continue to advertise 159 a BGP path's reachability or withdraw the BGP path's reachability, 160 based on the consideration for the path's next-hop reachability 161 and/or availability in a particular data plane. 163 It is not expected that the proposed amendments would negatively 164 impact BGP convergence, barring any implementation specifics. 166 The intention of this document is to help operators to build BGP 167 networks that can avoid self-blackholing. 169 5. Security Considerations 171 This draft doesn't impose any additional security constraints. 173 6. IANA Considerations 175 None. 177 7. Acknowledgments 179 Yakov Rekhter provided critical suggestions and feedback to improve 180 this document. Thanks to John Scudder and Chandrashekhar Appanna for 181 contributing to the discussions that formed the basis of this 182 document. Thanks to Ilya Varlashkin and Michael Benjamin, who made 183 the case to revive this document and provided useful feedback. Also 184 thanks to Keyur Patel, Robert Raszuk and Samita Chakrabarti. 186 This document was prepared using 2-Word-v2.0.template.dot. 188 8. Appendix 190 8.1. Problem Applicability 192 In IP networks using BGP, a router would continue to attract traffic 193 by advertising the BGP prefix reachability to neighbor(s) as long as 194 the router had a route to the next-hop in its routing table, but 195 independent of whether the router has a functional forwarding path 196 to the next-hop. This may cause the forwarded traffic to be dropped 197 inside the IP network. 199 In MPLS or MPLS VPN networks [RFC4364], the same problem is observed 200 if the functional MPLS LSP to the next-hop is not available (due to 201 the forwarding path error on any node along the path to the next- 202 hop). 204 The following MPLS/VPN topology clarifies the problem - 205 <-eBGP/IGP-> <-------MP-BGP------> <-eBGP/IGP-> 207 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 208 ^ 209 ======PE1-PE2 LSP==> ^ 210 ^ 211 a.b.c.d 213 Figure 1 MPLS VPN Network 215 In the network illustrated in Figure 1, the PE1 to PE2 LSP may be 216 non-functional due to any reason such as corrupted MPLS Forwarding 217 Table entry, or the missing MPLS Forwarding table entry, or LDP 218 binding defect, or down LDP session between the P routers (with 219 independent label distribution control) etc. In such a situation, it 220 is clear that the CE1->CE2 traffic inserted into the MPLS network by 221 PE1 will get dropped inside the MPLS network. 223 It is undesirable to have PE1 continue to convey to the CE1 router 224 that PE1 (and the MPLS network) is still the next-hop for the remote 225 VPN reachability, without being sure of the corresponding LSP 226 health. 228 8.1.1. Multi-Homed VPN Site 230 If the remote VPN site is dual-homed to both PE2 and PE3, then PE1 231 may learn two VPNv4 paths to the prefix a.b.c.d. via PE2 and PE3 232 routers, as shown below in Figure 2. PE1 may select the bestpath for 233 the prefix a.b.c.d via PE2 (say, for which the PE1->PE2 LSP is mal- 234 functioning) and advertise that bestpath to CE1 in the context of 235 figure 2. 237 <------MP-BGP------> 239 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 240 \ / ^ 241 \~~~~~~~~~~PE3~~~~~~~/ ^ 242 ^ 243 a.b.c.d 245 Figure 2 MPLS VPN Network - CE2 Dual-Homing 247 This causes CE1 to likely send the traffic destined to prefix 248 a.b.c.d to the PE1 router, which forwards the traffic over the 249 malfunctioning LSP to PE2. It is clear that this MPLS encapsulated 250 VPN traffic ends up getting dropped or blackholed somewhere inside 251 the MPLS network. 253 It is desirable to force PE1 to select an alternate bestpath via 254 that next-hop (such as PE3), whose LSP is correctly functioning. 256 8.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity 258 The local VPN site may have a backup/dial-up link available at the 259 CE router, but the backup link will not even be activated as long as 260 the CE's routing table continues to point to the PE router as the 261 next-hop (over the MPLS/VPN network). 263 <------MP-BGP------> 265 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 266 \ / ^ 267 \~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/ ^ 268 ^ 269 a.b.c.d 271 Figure 3 MPLS VPN Network - CE1-CE2 Backup connection 273 Unless PE2 withdraws the route via the routing protocol used on the 274 PE-CE link, CE1 will not be able to activate the backup link 275 (barring any tracking functionality) to the remote VPN site. 277 In summary, if PE1 could appropriately qualify the BGP VPNv4 278 bestpath, then the VPN traffic outage could likely be avoided. Even 279 if the VPN site was not multi-homed, it is desirable to force PE1 to 280 withdraw the path from CE1 to improve the CE-to-CE convergence. This 281 document proposes a mechanism to achieve the optimal BGP behavior at 282 PE. 284 8.1.3. 6PE or 6VPE 286 This problem is very much applicable to the MPLS network that is 287 providing either 6PE [RFC4978] or 6VPE [RFC4659] service to 288 transport IPv6 packets over the MPLS network. 290 9. References 292 9.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 298 Networks (VPNs)", RFC4364, February 2006. 300 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 301 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 303 9.2. Informative References 305 [RFC3031] Rosen, et al., "Multiprotocol Label Switching 306 Architecture", RFC3031, Jan 2001. 308 [RFC5512] Rosen, E., Mohapatra, P., "BGP Encapsulation SAFI and BGP 309 Tunnel Encapsulation Attribute", RFC5512, April 2009. 311 [RFC4023] Rosen, et al., "Encapsulating MPLS in IP or Generic 312 Routing Encapsulation", RFC4023, March 2005. 314 [RFC4817] Townsley, et al., "Encapsulation of MPLS over Layer 2 315 Tunneling Protocol Version 3", RFC4817, Nov 2006. 317 [RFC4978] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 318 Using IPv6 Provider Edge Routers", RFC4978, Feb 2007. 320 [RFC4659] De Clercq, et al., "BGP-MPLS IP VPN Extension for IPv6 321 VPN", RFC4659, Sep 2006. 323 Author's Addresses 325 Rajiv Asati 326 Cisco Systems 327 7025 Kit Creek Road 328 RTP, NC 27560 USA 329 Email: rajiva@cisco.com