idnits 2.17.1 draft-asati-bgp-mpls-blackhole-avoidance-00.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 642. 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 ([RFC4364]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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.) -- The document date (February 23, 2007) is 6271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (ref. 'RFC4389') (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) -- No information found for draft-nalawade-kapoor-idr-bgp-ssa - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Rajiv Asati 2 Internet Draft Cisco Systems 3 Intended status: Informational 4 Expires: August 2007 Raymond Zhang 5 BT 7 Tom Nadeau 8 Cisco Systems 10 Azhar Sayeed 11 Cisco Systems 13 February 23, 2007 15 BGP/MPLS Traffic Blackhole Avoidance 16 draft-asati-bgp-mpls-blackhole-avoidance-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that 21 any applicable patent or other IPR claims of which he or she is 22 aware have been or will be disclosed, and any of which he or she 23 becomes aware will be disclosed, in accordance with Section 6 of 24 BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on Fail 23, 2007. 44 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 In any BGP based MPLS network such as MPLS VPN [RFC4364], an ingress 50 PE router would continue to attract traffic from the CE router by 51 advertising the prefix reachability, even though the Label Switched 52 Path (LSP) from the ingress PE router to the egress PE router may be 53 broken. This causes the VPN traffic to be dropped inside the MPLS VPN 54 network. 56 This document proposes a framework to make BGP consider the MPLS path 57 availability to the "NEXT_HOP" (i.e. egress PE router) during the BGP 58 bestpath candidate selection process. This document also defines a 59 local database for storing the MPLS path health information for one 60 or more IP prefixes and its interaction with BGP. 62 Conventions used in this document 64 In examples, "C:" and "S:" indicate lines sent by the client and 65 server respectively. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC-2119 [RFC2119]. 71 Table of Contents 73 1. Introduction...................................................3 74 2. Problem Details................................................3 75 2.1. VPN Deployment Scenarios..................................4 76 2.1.1. Multi-Homed VPN Site.................................4 77 2.1.2. Single-Homed VPN Site with Site-to-Site Backup 78 Connectivity................................................5 79 3. Proposal.......................................................5 80 3.1. BGP VPNv4 Path Qualification Changes......................6 81 3.1.1. IP reachability and MPLS reachability Checks.........7 82 3.1.2. 2547oIP based BGP VPNv4 paths........................8 83 3.2. LSP Health Database (LHD).................................9 84 3.3. BGP and LHD Interaction..................................11 85 4. IGP and LHD...................................................13 86 5. Applicability.................................................13 87 6. Security Considerations.......................................13 88 7. IANA Considerations...........................................13 89 8. Conclusions...................................................13 90 9. Acknowledgments...............................................13 91 10. References...................................................14 92 10.1. Normative References....................................14 93 10.2. Informative References..................................14 94 Author's Addresses...............................................15 95 Intellectual Property Statement..................................15 96 Disclaimer of Validity...........................................16 98 1. Introduction 100 In the current MPLS VPN architecture [RFC4364], a PE router learns 101 the VPNv4 routes from the remote PE routers either over a PE-PE MP- 102 iBGP session or via a PE-RR MP-iBGP session. The remote PE router(s) 103 accepts the VPNv4 routes with the matching import route-targets and 104 advertise them to the CE router(s). The CE router, in turn, is likely 105 to choose the PE router as the next hop to communicate with the 106 relevant remote VPNv4 destinations. 108 The existing [RFC4364] architecture assumes the ingress PE router to 109 have a working label switched path (LSP) to the egress PE router that 110 advertised the VPNv4 route. 112 2. Problem Details 114 The assumption that the ingress PE router always has a working LSP to 115 the egress PE router that advertised the VPNv4 route, may result in 116 the VPN traffic to be dropped or blackholed inside an MPLS VPN 117 network during an LSP failure event. This is because an ingress PE 118 router could qualify a VPNv4 route (learned via an MP-iBGP session) 119 as a valid route, even though the corresponding next hop is no longer 120 MPLS reachable. 122 <-eBGP/IGP-> <-------MP-BGP------> <-eBGP/IGP-> 124 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 125 ^ 126 ======PE1-PE2 LSP==> ^ 127 ^ 128 a.b.c.d 130 Figure 1 MPLS VPN Network 132 In the network illustrated in Figure 1, the PE1 to PE2 LSP may be 133 non-functional due to any reason such as down LDP session between the 134 P routers, or the corrupted MPLS Forwarding Table entry, or the 135 missing MPLS Forwarding table entry, or LDP binding defect etc. In 136 such a situation, it is clear that the CE1->CE2 traffic inserted into 137 the MPLS network by PE1 will get dropped inside the MPLS network. 139 It is undesirable to have PE1 continue to convey to the CE1 router 140 that PE1 (and the MPLS network) is still the next-hop for the remote 141 VPN reachability, without being sure of the corresponding LSP health. 143 2.1. VPN Deployment Scenarios 145 It is important to understand the downside of the current framework's 146 limitation using the following two deployment scenarios - 148 2.1.1. Multi-Homed VPN Site 150 If the remote VPN site is dual-homed to both PE2 and PE3, then PE1 151 may learn two VPNv4 paths to the prefix a.b.c.d. via PE2 and PE3 152 routers, as shown below in Figure 2. PE1 may select the bestpath for 153 the prefix a.b.c.d via PE2 (say, for which the PE1->PE2 LSP is mal- 154 functioning) and advertise that bestpath to CE1 in the context of 155 figure 2. 157 <------MP-BGP------> 159 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 160 \ / ^ 161 \~~~~~~~~~~PE3~~~~~~~/ ^ 162 ^ 163 a.b.c.d 165 Figure 2 MPLS VPN Network - CE2 Dual-Homing 167 This causes CE1 to likely send the traffic destined to prefix a.b.c.d 168 to the PE1 router, which forwards the traffic over the malfunctioning 169 LSP to PE2. It is clear that this MPLS encapsulated VPN traffic ends 170 up getting dropped or blackholed somewhere inside the MPLS network. 172 It is desirable to force PE1 to select an alternate bestpath via that 173 next-hop (such as PE3), whose LSP is correctly functioning. 175 2.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity 177 The local VPN site may have a backup/dial-up link available at the CE 178 router, but the backup link will not even be activated as long as the 179 CE's routing table continues to point to the PE router as the next- 180 hop (over the MPLS/VPN network). 182 <------MP-BGP------> 184 CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~ 185 \ / ^ 186 \~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/ ^ 187 ^ 188 a.b.c.d 190 Figure 3 MPLS VPN Network - CE1-CE2 Backup connection 192 Unless PE2 withdraws the route via the routing protocol used on the 193 PE-CE link, CE1 will not be able to activate the backup link (barring 194 any tracking functionality) to the remote VPN site. 196 In summary, if PE1 could appropriately qualify the BGP VPNv4 197 bestpath, then the VPN traffic outage could likely be avoided. Even 198 if the VPN site was not multi-homed, it is desirable to force PE1 to 199 withdraw the path from CE1 to improve the CE-to-CE convergence. This 200 document proposes a mechanism to achieve the optimal BGP behavior at 201 PE. 203 3. Proposal 205 The crux of the problem is that the BGP VPNv4 path selection is 206 independent of whether the NEXT_HOP is MPLS reachable or not. 208 This draft proposes a mechanism to enable BGP to poll whether there 209 is a valid "MPLS path" to the NEXT_HOP of the VPNv4 path, before 210 qualifying that VPNv4 path as the bestpath candidate. This mechanism 211 comprises of the following three building blocks that are later 212 explained in detail in the subsequent sections. 214 1. BGP VPNv4 path qualification changes: 216 . Qualifies the VPNv4 path as the bestpath candidate only if its 217 NEXT_HOP is MPLS reachable by polling the LSP Health Database. 219 2. LSP Health Database (LHD): 221 . Maintains the information regarding whether a NEXT_HOP is MPLS 222 reachable or not. 224 3. BGP & LHD Interaction: 226 . Specifies the way BGP and LHD interacts with each other. 228 The proposal helps the ingress PE to either continue to advertise the 229 BGP VPNv4 path's reachability to the CE router by selecting an 230 alternative VPNv4 bestpath, or withdraw the BGP VPNv4 path's 231 reachability from the CE router, during the relevant LSP failure 232 event. 234 3.1. BGP VPNv4 Path Qualification Changes 236 As per BGP specification [RFC4271], when a PE router receives a BGP 237 path such as VPNv4 path, BGP qualifies it as the valid candidate for 238 the BGP bestpath using the "Route Resolvability Condition" (Please 239 see section#9.1.2.1 of RFC4271]. Once the path has been qualified as 240 the bestpath candidate, then it gets subjected to the BGP bestpath 241 calculation, which will select the bestpath out of all "bestpath 242 candidates". 244 The BGP path qualification check-list is highlighted below - 246 1) NEXT_HOP must be IP reachable 248 2) ... 250 The first check (above) requires the NEXT_HOP of the BGP path to be 251 IP reachable. To determine this reachability, BGP checks the global 252 routing table to validate whether the routing table has a specific or 253 less-specific or default route to the NEXT_HOP. This mechanism is 254 also referred to as the "NEXT_HOP Validation". The "NEXT_HOP 255 validation" is done not only for the first time when the BGP (VPNv4) 256 path is first received, but also periodically. 258 The first building block of the proposal is to add another criterion 259 to the "BGP bestpath candidate qualification". The new criterion 260 checks for 'MPLS reachability' to the NEXT_HOP of the BGP path such 261 as VPNv4 path. This means that the NEXT_HOP of the VPNv4 path must be 262 reachable over an MPLS Label Switched Path (LSP). It is desirable to 263 apply this criterion to MPLS only path, as explained in Section 264 3.1.2. 266 Hence, with the proposed addition, the path qualification check-list 267 now expands to - 269 1) NEXT_HOP must be IP reachable 271 + 2) NEXT_HOP much be MPLS reachable 273 3) ... 275 With the above checks in place, if the NEXT_HOP of a VPNv4 path is 276 not IP reachable, then the path will get marked with the "NEXT_HOP IP 277 Unreachable". 279 However, if the NEXT_HOP is IP reachable, but not MPLS reachable, 280 then the BGP VPNv4 path will get marked with the "NEXT_HOP MPLS 281 Unreachable". As a result, the BGP VPNv4 path will get disqualified 282 from becoming the bestpath candidate and will not be considered 283 during the bestpath calculation unless the NEXT_HOP becomes MPLS 284 reachable again. 286 The 'MPLS reachability' to a NEXT_HOP is determined by retrieving the 287 NEXT_HOP specific information from the LSP Health Database (LHD), 288 which is described in section 3.2. The machinery involving BGP and 289 LHD interaction is explained in section 3.3. 291 3.1.1. IP reachability and MPLS reachability Checks 293 The BGP path qualification (involving the NEXT_HOP reachability) is 294 performed not only when the path is received for the first time, but 295 also later on using either a timer-driven model or event-driven model 296 or both. This machinery is not modified by the change proposed in 297 section 3.1. Specifically, the proposal expands the NEXT_HOP 298 reachability check to include checking both: 300 (1) Routing table aka RIB for the IP reachability, and 302 (2) LSP Health Database aka LHD for the MPLS reachability. 304 It is important to note that the LHD check#2 doesn't replace the RIB 305 check#1, but rather complements it. This document doesn't suggest any 306 changes to check#1 whatsoever and assumes that the check#1 will 307 always be performed. Check#2, on the other hand, SHOULD be performed 308 only when appropriate as clarified in section 3.1.2. 310 One benefit of performing both checks, when appropriate as clarified 311 in section 3.1.2, is in the area of troubleshooting, since it will be 312 clear whether the BGP NEXT_HOP is "IP Unreachable" or "MPLS 313 Unreachable". 315 3.1.2. 2547oIP based BGP VPNv4 paths 317 2547oIP technology such as 2547oGRE [RFC4023], 2547oL2TPv3 [RFC3931] 318 etc. doesn't require the usage of the MPLS transport between ingress 319 PE router and egress PE router, hence, it is not desirable to perform 320 the proposed 'MPLS reachability' NEXT_HOP check (check#2) during the 321 BGP VPNv4 path qualification for such BGP paths that utilize IP 322 transport. 324 In the simplest form, the above could be achieved by providing 325 a user configurable parameter to enable or disable the check#2 326 on the router. However, such approach may not work in the 327 deployment involving both 2547oMPLS and 2547oIP BGP VPNv4 328 paths on the same PE router. Two scenarios in which such 329 deployment may be apparent are (a) the network migration from 330 MPLS to IP or vice versa, (b) the part of network inability to 331 do MPLS. 333 This section explains a method by which BGP can decide whether to 334 perform the 'MPLS reachability' check (check#2) for a given BGP path. 336 In this method, the BGP VPNv4 path is flagged (in the relevant BGP 337 data structure) to denote whether BGP VPNv4 path should be subjected 338 to the "'MPLS reachability' to the NEXT_HOP check" during the BGP 339 path qualification. The flag can be updated based on whether the 340 NEXT_HOP information is also conveyed via a separate discovery 341 mechanism such as a separate BGP AFI/SAFI as defined by existing 342 proposals such as [TUN-SAFI], [BGP-TUN], and forthcoming proposals*. 344 If the flag is set to one, then the BGP VPNv4 path is considered to 345 belong to 2547oIP, hence, 'MPLS reachability' check is skipped for 346 the NEXT_HOP(s) of such BGP VPNv4 path(s). 348 If the flag value is zero, the BGP VPNv4 path is considered to 349 belong to 2547oMPLS, hence, 'MPLS reachability' NEXT_HOP check is 350 performed for the NEXT_HOP(s) of such BGP VPNv4 path(s). 352 This method is advantageous since it appropriately takes care of the 353 deployment scenario in which both 2547oMPLS and 2547oIP based VPNv4 354 paths may exist on the same PE router. 356 (* Please note that the forthcoming proposal(s) may let a BGP speaker 357 convey the choice of encapsulation such as MPLS, GRE, L2TPv3 etc. for 358 a given BGP VPNv4 prefix to another BGP speaker. Such proposals are 359 likely to ease the mean of updating the flag discussed here.) 361 3.2. LSP Health Database (LHD) 363 As explained in section 3 and 3.1 earlier, BGP will now be required 364 to check for the MPLS reachability to the NEXT_HOP of the BGP VPNv4 365 path. This means that BGP must somehow obtain the information about 366 NEXT_HOP's MPLS reachability, which is really a forwarding plane 367 element. 369 Since MPLS reachability relies on the forwarding plane, it is optimal 370 to build a database that would keep the information about whether a 371 NEXT_HOP is reachable over an MPLS LSP or not. This database is 372 referred to as LSP Health Database (LHD). 374 BGP would use the information from LHD to perform its "NEXT_HOP 375 reachability" check for MPLS reachability. BGP and LHD interaction 376 could be either timer-driven or event-driven depending upon the 377 implementation, though the document may favor the event-driven 378 interaction for faster convergence. 380 How the LHD is populated is outside the scope of this document and 381 will be covered in a separate document since it may be utilized by 382 other application beyond BGP. 384 In short, the LHD could be populated by any 'LSP-health-probe' 385 mechanism such as LSP pings [RFC4389] or BFD LSP [MPLS-BFD] or 386 so forth, to verify whether the LSP to the NEXT_HOP is 387 established or broken. 389 Although the document expects BGP at an edge router such as PE to 390 utilize the LHD, any other application at any router could utilize 391 the LHD. Three questions become apparent when BGP at PE router needs 392 to utilize the information from the LSP Health Database (LHD) - 394 1. How would the LHD determine the list of BGP NEXT_HOP(s) that need 395 MPLS reachability check? 397 2. How frequently should the PE router check the LSP Health for each 398 NEXT_HOP? 400 3. What actions should BGP take when an LSP starts malfunctioning as 401 recorded in the LHD? 403 There are at least two ways to figure out the answer to Q1. Please 404 see the next section 3.3 "BGP and LHD interaction" for the detailed 405 answer. For now, let's assume that LHD has the list of NEXT_HOPs i.e. 406 IP addresses to monitor the LSP health for. 408 Equipped with the list of NEXT_HOPs, the PE router utilizes the 'LSP- 409 health-probe' such as LSP ping, BFD etc. for each NEXT_HOP to 410 validate the LSP health and record it in the LHD. A simplistic view 411 of LHD is shown below - 413 LSP Health Database Sample:: 414 ---------------------------------- 415 NEXT_HOP Prefix | LSP Established 416 ---------------------------------- 417 192.0.2.11/32 | Yes 418 192.0.2.12/32 | Yes 419 192.0.2.13/32 | Yes 420 192.0.2.14/32 | No 421 ---------------------------------- 422 Figure 4 LSP Health Database - Simplistic View 424 Although Q2 is considered specific to the LHD and beyond the scope of 425 this document, it is likely that the PE router may employ either a 426 timer-driven model or event-driven model to update the LHD entries. 427 The frequency of updating the LHD can also be dictated by a user 428 configurable parameter. The frequency should not affect the BGP-LHD 429 interaction machinery. 431 About Q3, if one or more LSP Health Database (LHD) entries are 432 declared or updated to be broken (shown via "No" in the above 433 simplistic LHD view), then BGP may be notified about it depending on 434 the timer-driven or event-driven model in place. As soon as BGP 435 becomes aware of it, BGP may perform the bestpath calculation i.e. 436 'BGP VPNv4 path qualification' to explore the alternative bestpaths 437 as discussed in section 3.1. Please see more details about this in 438 next section 3.3. 440 3.3. BGP and LHD Interaction 442 At the high level, LSP Health Database (LHD) maintains the LSP health 443 information for one or more addresses that BGP considers as the 444 NEXT_HOPs. BGP utilizes the information from the LHD to declare the 445 'MPLS reachability' for a NEXT_HOP during the BGP VPNv4 path 446 qualification. 448 LHD is constructed and populated using mechanisms that are 449 beyond the scope of this document and will be covered in a 450 different document. 452 If the LHD entry shows the LSP for a NEXT_HOP to be "established", 453 then BGP will declare the 'MPLS reachability' to the NEXT_HOP check 454 to have passed and rest of the BGP bestpath calculation may continue 455 as usual. 457 If the LHD shows the LSP for a NEXT_HOP to be not established, then 458 BGP will declare the NEXT_HOP 'MPLS reachability' to have failed and 459 will mark the dependent BGP VPNv4 paths as 'NEXT_HOP MPLS 460 Unreachable'. This will result in such BGP VPNv4 paths be 461 disqualified from becoming the bestpath candidate, and subsequently, 462 PE could update the CE neighbors through one of the following two 463 actions - 465 Assuming the presence of alternative BGP VPNv4 path, PE could 466 select a new bestpath, and advertise it to the CE neighbors. 468 Assuming no other alternative BGP VPNv4 path, PE will withdraw 469 the VPNv4 path(s) from the CE neighbors (independent of the 470 PE-CE routing protocol). 472 It is obvious that BGP will have to interact with LHD for each of the 473 NEXT_HOPs of the BGP VPNv4 paths. The following logical question then 474 becomes apparent - How does the router determine which LSPs i.e. 475 NEXT_HOPs should be validated within the LHD ? 477 The document discusses the following two approaches to help LHD 478 obtain the list of NEXT_HOPs - 480 4. The simplest way is to have the router issue 'LSP-health-probe' 481 for all the host routes since all the NEXT_HOPs are almost always 482 available as the host routes i.e. /32 routes in the routing table. 483 However, every host route is not expected to be the NEXT_HOP, 484 hence, this approach is NOT optimal or accurate since LSP health 485 would be measure for unwanted host routes for no benefits. 486 Moreover, there might be a few fake host routes i.e. /32 routes 487 (including PPP generated /32 routes) that are not really the 488 NEXT_HOPs. 490 5. The optimal approach is to have the LHD rely on the BGP to provide 491 the list of NEXT_HOPs. BGP should already have a list of the BGP 492 NEXT_HOPs to use it to perform the IP rechability checks. It is 493 logical and appropriate to have LHD perform the LSP Health checks 494 for the NEXT_HOPs specified in this list. Additionally, the list 495 must specify whether LHD should consider all or a subset of the 496 list (since one or more NEXT_HOP may not require MPLS reachability 497 check; This may also depend on the AFI/SAFI of the BGP route). 498 Such inclusion may help to return an appropriate diagnostic code 499 in the MPLS OAM messages such as MPLS ping etc. 501 Although BGP bestpath calculation and LHD check are independent of 502 each other, one may trigger the other i.e. the BGP bestpath 503 calculation may trigger the LHD check for one or more LHD entries, as 504 well as an LHD entry update may trigger the BGP bestpath calculation 505 for the BGP prefixes learned from the NEXT_HOP pertaining to the LHD 506 entry. 508 In the case of LHD entry update providing the trigger to perform 509 the BGP bestpath calculation it is desirable to perform the BGP 510 bestpath calculation only for those BGP prefixes whose NEXT_HOP got 511 updated in the LHD to attain an optimal behavior. 513 LHD will also have to keep up with the changes in the NEXT_HOP list. 514 In other words, if the PE router learns one or more VPNv4 prefix with 515 the new NEXT_HOP (this could happen when a new PE router is added to 516 the network), then the BGP will update the NEXT_HOP list, which then 517 should be provided to LHD for further processing. 519 In summary, BGP utilizes the information from the LHD to declare the 520 'MPLS reachability' to a NEXT_HOP during the BGP VPNv4 path 521 qualification. Although BGP bestpath calculation and LHD check are 522 independent of each other, one may trigger the other. 524 4. IGP and LHD 526 This proposal requires neither any changes in the IGP, nor any 527 interaction between IGP and LHD. 529 5. Applicability 531 This proposal, although targeted to VPN prefix, can very well be 532 extended to any BGP prefix whose NEXT_HOP utilizes MPLS transport. 533 Few examples are VPNv6, labeled BGP IPv4 prefix [RFC3107], labeled 534 BGP IPv6 prefix etc. 536 6. Security Considerations 538 This draft doesn't impose any additional security constraints. 540 7. IANA Considerations 542 None. 544 8. Conclusions 546 None. 548 9. Acknowledgments 550 The authors would like to thank Russ White, Luca Martini, John 551 Monaghan, Chip Popoviciu, Vijay Bollapragada, Carlos Pignataro etc. 552 for their comments and suggestions. 554 This document was prepared using 2-Word-v2.0.template.dot. 556 10. References 558 10.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 564 Networks (VPNs)", RFC4364, February 2006. 566 [RFC4023] Rosen et al., "Encapsulating MPLS in IP or Generic Routing 567 Encapsulation", RFC4023, March 2005 569 [RFC3931] Lau, J., Townsley, M., and Goyret I., "Layer Two Tunneling 570 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005 572 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 573 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 575 [RFC4389] Kompella, K., and Swallo, G., "Detecting Multi-Protocol 576 Label Switched (MPLS) Data Plane Failures", RFC 4379, 577 February 2006 579 [RFC3107] Rosen E. and Rekhter Y., "Carrying Label information in 580 BGP-4", RFC 3107, May 2001 582 10.2. Informative References 584 [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., Swallow, G., "BFD 585 for MPLS LSPs", draft-ietf-bfd-mpls, work in progress. 587 [TUN-SAFI] Nalawade et al, "BGP Tunnel SAFI", draft-nalawade-kapoor- 588 tunnel-safi-05.txt. 590 [BGP-TUN] Kapoor R., Nalawade G., "BGP4 Tunnel Encapsulation 591 attribute", draft-nalawade-kapoor-idr-bgp-ssa-03.txt, 592 work in progress. 594 Author's Addresses 596 Rajiv Asati (Editor) 597 Cisco Systems 598 7025 Kit Creek Road 599 RTP, NC 27560 USA 600 Email: rajiva@cisco.com 602 Raymond Zhang 603 BT 604 2160 E. Grand Ave. 605 El Segundo, CA 90245 USA 606 Email: Raymond_zhang@bt.infonet.com 608 Tom Nadeau 609 Cisco Systems 610 300 Beaver Brook Road 611 Boxborough, MA, 01719 USA 612 Email: tnadeau@cisco.com 614 Azhar Sayeed 615 Cisco Systems 616 300 Beaver Brook Road 617 Boxborough, MA, 01719 USA 618 Email: asayeed@cisco.com 620 Intellectual Property Statement 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at 642 ietf-ipr@ietf.org. 644 Disclaimer of Validity 646 This document and the information contained herein are provided on an 647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 649 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 650 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 651 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Copyright Statement 656 Copyright (C) The IETF Trust (2007). 658 This document is subject to the rights, licenses and restrictions 659 contained in BCP 78, and except as set forth therein, the authors 660 retain all their rights. 662 Acknowledgment 664 Funding for the RFC Editor function is currently provided by the 665 Internet Society.