idnits 2.17.1 draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (August 28, 2009) is 5348 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4659' is defined on line 318, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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: Informational 4 Expires: Jan 2010 5 August 28, 2009 7 BGP Bestpath Selection Criteria 8 draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on Feb 28, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as 57 one of the key 'Route Resolvability Condition' that must be satisfied 58 before the BGP bestpath candidate selection. This condition, however, 59 may not be sufficient (as explained in the Appendix section) and 60 desire further granularity. 62 This document defines enhances the "Route Resolvability Condition" to 63 facilitate the next-hop to be resolved in the chosen data plane. 65 Table of Contents 67 1. Introduction...................................................3 68 2. Specification Language.........................................3 69 3. Route Resolvability Condition - Modification...................3 70 4. Conclusions....................................................4 71 5. Security Considerations........................................5 72 6. IANA Considerations............................................5 73 7. Acknowledgments................................................5 74 8. Appendix.......................................................5 75 9. References.....................................................8 76 Author's Addresses................................................9 78 1. Introduction 80 As per BGP specification [RFC4271], when a router receives a BGP 81 path, BGP must qualify it as the valid candidate prior to the BGP 82 bestpath selection using the 'Route Resolvability Condition' 83 (section#9.1.2.1 of RFC4271]. After the path gets qualified as the 84 bestpath candidate, it becomes eligible to be the bestpath, and may 85 get advertised out to the neigbhor(s), if it became the bestpath. 87 However, in BGP networks that utilize data plane protocol other than 88 IP, such as MPLS [RFC3031] etc. to forward the received traffic 89 towards the next-hop, the above qualification condition may not be 90 sufficient. In fact, this may expose the BGP networks to experience 91 traffic blackholing i.e. traffic loss, due to malfunctioning of the 92 chosen data plane protocol to the next-hop. This is explained further 93 in the Appendix section. 95 This document defines further granularity to the "Route Resolvability 96 Condition" by (a) resolving the BGP next-hop reachability in the 97 forwarding database of a particular data plane protocol, and (b) 98 optionally including the BGP next-hop "path availability" check. 100 The goal is to enable BGP to select the bestpaths based on whether or 101 not the corresponding nexthop can be resolved in the valid data 102 plane. 104 2. Specification Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Route Resolvability Condition - Modification 112 This document proposes two amendments to 'Route Resolvability 113 Condition', which is defined in RFC4271, in consideration for a 114 particular data plane protocol: 116 1) The next-hop reachability (check) SHOULD be resolved in a 117 forwarding database of a particular data plane protocol. 119 For example, if a BGP IPv4/v6 or VPNv4/v6 path wants to use 120 MPLS data plane to the next-hop, as determined by the policy, 121 then the BGP 'next-hop reachability' should be resolved using 122 the MPLS forwarding database. In another example, if BGP path 123 wants to use the IP data plane to the next-hop, as determined 124 by the policy, then BGP 'next-hop reachability' should be 125 resolved using the IP forwarding database. The latter example 126 relates to MPLS-in-IP encapsulation techniques such as 127 [RFC4817], [RFC4023] etc. 129 The selection of particular data plane is a matter of a policy, and 130 is outside the scope of this document. It is envisioned that the 131 policy would exist for either per-neighbor or per-SAFI or both. A 132 dynamic signaling such as BGP encapsulation SAFI (or tunnel encap 133 attribute) [RFC5512] may be used to convey the data plane protocol 134 chosen by the policy. 136 This check is about confirming the availability of the valid 137 forwarding entry for the next-hop in the forwarding database of the 138 chosen data plane protocol. 140 2) The 'path availability' check for the BGP next-hop MAY be 141 performed. This criterion checks for the functional data plane 142 path to the next-hop in a particular data plane protocol. 144 The path availability check may be performed by any of the OAM data- 145 plane liveness mechanisms associated with the data plane that is used 146 to reach the Next Hop. The data plane protocol for this criterion 147 MUST be the same as the one selected by the previous criterion (#1). 149 The mechanism(s) to perform the "path availability" check and the 150 selection of particular data plane are a matter of a policy and 151 outside the scope of this document. 153 For example, if a BGP VPNv4 path wants to use the MPLS as the 154 data plane protocol to the next-hop, then MPLS path 155 availability to the next-hop should be evaluated i.e. liveness 156 of MPLS LSP to the next-hop should be validated. 158 4. Conclusions 160 Both amendments discussed in section 2 provide further clarity and 161 granularity to help the BGP speaker to either continue to advertise a 162 BGP path's reachability or withdraw the BGP path's reachability, 163 based on the consideration for the path's next-hop reachability 164 and/or availability in a particular data plane. 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 for his feedback. 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 to 196 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 health. 227 8.1.1. Multi-Homed VPN Site 229 If the remote VPN site is dual-homed to both PE2 and PE3, then PE1 230 may learn two VPNv4 paths to the prefix a.b.c.d. via PE2 and PE3 231 routers, as shown below in Figure 2. PE1 may select the bestpath for 232 the prefix a.b.c.d via PE2 (say, for which the PE1->PE2 LSP is mal- 233 functioning) and advertise that bestpath to CE1 in the context of 234 figure 2. 236 <------MP-BGP------> 238 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 239 \ / ^ 240 \~~~~~~~~~~PE3~~~~~~~/ ^ 241 ^ 242 a.b.c.d 244 Figure 2 MPLS VPN Network - CE2 Dual-Homing 246 This causes CE1 to likely send the traffic destined to prefix a.b.c.d 247 to the PE1 router, which forwards the traffic over the malfunctioning 248 LSP to PE2. It is clear that this MPLS encapsulated VPN traffic ends 249 up getting dropped or blackholed somewhere inside the MPLS network. 251 It is desirable to force PE1 to select an alternate bestpath via that 252 next-hop (such as PE3), whose LSP is correctly functioning. 254 8.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity 256 The local VPN site may have a backup/dial-up link available at the CE 257 router, but the backup link will not even be activated as long as the 258 CE's routing table continues to point to the PE router as the next- 259 hop (over the MPLS/VPN network). 261 <------MP-BGP------> 263 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 264 \ / ^ 265 \~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/ ^ 266 ^ 267 a.b.c.d 269 Figure 3 MPLS VPN Network - CE1-CE2 Backup connection 271 Unless PE2 withdraws the route via the routing protocol used on the 272 PE-CE link, CE1 will not be able to activate the backup link (barring 273 any tracking functionality) to the remote VPN site. 275 In summary, if PE1 could appropriately qualify the BGP VPNv4 276 bestpath, then the VPN traffic outage could likely be avoided. Even 277 if the VPN site was not multi-homed, it is desirable to force PE1 to 278 withdraw the path from CE1 to improve the CE-to-CE convergence. This 279 document proposes a mechanism to achieve the optimal BGP behavior at 280 PE. 282 8.1.3. 6PE or 6VPE 284 This problem is very much applicable to the MPLS network that is 285 providing either 6PE [RFC4978] or 6VPE [] service to transport IPv6 286 packets over the MPLS network. 288 9. References 290 9.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 296 Networks (VPNs)", RFC4364, February 2006. 298 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 299 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 301 9.2. Informative References 303 [RFC3031] Rosen, et al., "Multiprotocol Label Switching 304 Architecture", RFC3031, Jan 2001. 306 [RFC5512] Rosen, E., Mohapatra, P., "BGP Encapsulation SAFI and BGP 307 Tunnel Encapsulation Attribute", RFC5512, April 2009. 309 [RFC4023] Rosen, et al., "Encapsulating MPLS in IP or Generic Routing 310 Encapsulation", RFC4023, March 2005. 312 [RFC4817] Townsley, et al., "Encapsulation of MPLS over Layer 2 313 Tunneling Protocol Version 3", RFC4817, Nov 2006. 315 [RFC4978] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS 316 Using IPv6 Provider Edge Routers", RFC4978, Feb 2007. 318 [RFC4659] De Clercq, et al., "BGP-MPLS IP VPN Extension for IPv6 319 VPN", RFC4659, Sep 2006. 321 Author's Addresses 323 Rajiv Asati 324 Cisco Systems 325 7025 Kit Creek Road 326 RTP, NC 27560 USA 327 Email: rajiva@cisco.com