idnits 2.17.1 draft-gredler-rtgwg-igp-label-advertisement-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 5, 2013) is 4009 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 normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Downref: Normative reference to an Informational RFC: RFC 6571 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-01 == Outdated reference: A later version (-03) exists of draft-minto-2547-egress-node-fast-protection-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group H. Gredler, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track S. Amante 5 Expires: November 6, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 May 5, 2013 12 Advertising MPLS labels in IGPs 13 draft-gredler-rtgwg-igp-label-advertisement-04 15 Abstract 17 Historically MPLS label distribution was driven by session oriented 18 protocols. In order to obtain a particular routers label binding for 19 a given destination FEC one needs to have first an established 20 session with that node. 22 This document describes a mechanism to distribute FEC/label mappings 23 through flooding protocols. Flooding protocols publish their objects 24 for an unknown set of receivers, therefore one can efficiently scale 25 label distribution for use cases where the receiver of label 26 information is not directly connected. 28 Application of this technique are found in the field of backup 29 (Bypass, R-LFA) routing, Label switched path stitching, egress 30 protection, explicit routing and egress ASBR link selection. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on November 6, 2013. 55 Copyright Notice 57 Copyright (c) 2013 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 4 74 3. Use cases for IGP label distribution . . . . . . . . . . . . . 5 75 3.1. Increase LFA backup coverage using 'Directed 76 Forwarding' . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. Egress ASBR Link Selection . . . . . . . . . . . . . . . . 6 78 3.3. Tail end protection of BGP service routes . . . . . . . . 7 79 3.4. Explicit Path Routing through Label Stacking . . . . . . . 8 80 3.5. Link and Node Protection LSPs . . . . . . . . . . . . . . 10 81 3.6. Stitching MPLS Label Switched Path Segments . . . . . . . 11 82 3.7. T-LDP replacement for infrastructure labels . . . . . . . 12 83 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 MPLS label allocations are predominantly distributed by using the LDP 94 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 95 those protocols have in common that they are session oriented, which 96 means that in order to learn the Label Information database of a 97 particular router one needs to have a direct control-plane session 98 using the given protocol. 100 There are a couple of practical use cases where the consumer of a 101 MPLS label allocation may not be adjacent to the router having 102 allocated the label. Bringing up an explicit session using existing 103 label distribution protocols between the non-adjacent label allocator 104 and the label consumer is the existing remedy for this dilemma. 106 For LDP protection routing LDP next next hop labels [NNHOP] have been 107 proposed to provide the 2 hop neighborhood labels. While the 2 hop 108 neighborhood provides good backup coverage for the typical network 109 operator topology it is inadequate for some sparse for example ring 110 like topologies. 112 Depending on the application, retrieval and setup of forwarding state 113 of such >1 hop label allocations may only be transient. As such 114 configuring and un-configuring the explicit session is an operational 115 burden and therefore should be avoided. 117 The use cases described in this document are equally applicable to 118 IPv4 and IPv6 carried over MPLS. Furthermoe the proposed use of 119 distributing MPLS Labels using IGP prototocols adheres the 120 architectural principles laid out in [RFC3031]. 122 2. Motivation and Applicability 124 It may not be immediate obvious, however introduction of Remote LFA 125 [I-D.ietf-rtgwg-remote-lfa] technology has implied important changes 126 for an IGP implementation. Previously the IGP had a one-way 127 communication path with the LDP module. The IGP supplies tracking 128 routes and LDP selects the best neighbor based upon FEC to tracking 129 routes exact matching results. Remote LFA changes that relationship 130 such that there is a bi-directional communication path between the 131 IGP and LDP. Now the IGP needs to learn about if a label switched 132 path to a given destination prefix has been established and what the 133 ingress label for getting there is. The IGP needs to push that label 134 for the tracking routes of destinations beyond a remote LFA neighbor. 136 Since the IGP is now aware of label switched paths and it does create 137 forwarding state based on label information it makes sense to 138 distribute label switched paths by the IGP as well. 140 3. Use cases for IGP label distribution 142 This section lists example use cases which illustrate IGP 143 distribution of MPLS label switched paths. 145 3.1. Increase LFA backup coverage using 'Directed Forwarding' 147 Deployment of Loop free alternate backup technology [RFC5286] results 148 in backup graphs whose coverage is highly dependent on the underlying 149 Layer-3 topology. Typical network deployments provide backup 150 coverage less than 100 percent (see RFC 6571 Section 4.3 for Results 151 [RFC6571]) for IGP destination prefixes. 153 By closer examining the coverage gaps from the referenced production 154 network topologies, it becomes obvious that most topologies lacking 155 backup coverage are close to ring shaped topologies (Figure 1). 157 Remote LFA [I-D.ietf-rtgwg-remote-lfa] has introduced the notion of a 158 "remote" LFA neighbor. This helper router which is both in P and Q 159 space could forward the traffic to the final destination. Router 'H' 160 is in P space, however due to the actual metric allocation router 'H' 161 is not in Q space. 163 +-----+ 164 | D | 165 +-----+ 166 / \ 167 / M1 \ M4 >= (M1 + M2 + M3) 168 / \ 169 +-----+ +-----+ 170 | PLR | | H | 171 +-----+ +-----+ 172 \ / 173 \ M2 / M3 174 \ / 175 +-----+ 176 | E | 177 +-----+ 179 Figure 1: Coverage gap analysis 181 The protection router (PLR) evaluates for a primary path to 182 destination 'D' if {E -> H -> D} is a viable backup path. Because 183 the metric M4 {H -> D} is higher than the sum of the original primary 184 path and the path from router 'H' to the PLR, this particular path 185 would result in a loop and therefore is rejected. 187 Now consider that router 'H' would advertise a label for FEC 'D', 188 which has the semantics that H will POP the label and forward to the 189 destination node 'D'. This is done irrespective of the underlying 190 IGP metric 'M4' it is a 'strict forwarding' label. The PLR router 191 can now construct a label stack where the outermost label provides 192 transport to router 'H'. The next label on the MPLS stack is the IGP 193 learned 'strict forwarding label' label. Note that the label 'strict 194 forwarding' semantics are similar to a 1-hop ERO (Explicit route 195 object). The Remote 'LFA' calculation would need to get changed, 196 such that even if a node is not in PQ space, but rather in P space, 197 it may get used as a backup neighbor if it advertises a strict 198 forwarding label to the final destination. A recursive version of 199 the algorithm is applicable as well as long a node in P space has 200 some non looping LSP path to the final destination. The PLR router 201 can now program a backup path irrespective of the undesirable 202 underlying layer-3 topology. 204 Using existing tunnels for backup routing has been previously 205 described in [I-D.bryant-ipfrr-tunnels]. Section 5.2.3 'Directed 206 forwarding' describes an option to insert a single MPLS label between 207 the tunnel and the payload. Traffic may thereby be directed to a 208 particular neighbor. The mechanism described in this document, is an 209 MPLS specific manifestation of 'Directed forwarding'. 211 3.2. Egress ASBR Link Selection 213 In the topology described in Figure 2. router 'S' is facing a 214 dilemma. Router S receives a BGP route from all of its 4 upstream 215 routers. Using existing mechanism the provider owning AS1 can 216 control the loading of its direct links *to* its ASBR1 and ASBR2, 217 however it cannot control the load of the links beyond the ASBRs, 218 except manually tweaking the eBGP import policy and filtering out a 219 certain prefix. It would be more desirable to have visibility of all 220 four BGP paths and be able to control the loading of those four paths 221 using Weighted ECMP. Note that the computation of the 'Weight' 222 percentage and the component doing this computation (Router embedded 223 or SDN) is outside the scope of this document. 225 If all the ASes would be under one common administrative control then 226 the network operator could deploy a forwarding hierarchy by using 227 [RFC3107] to learn about the remote-AS BGP nexthop addresses and 228 associated labels. An ingress router 'S' would then stack the 229 transport label to its local egress ASBR and the remote ASBR supplied 230 label. In reality it is hard to convince a peering AS to deploy 231 another protocol just in order to easier control the egress load on 232 the WAN links for the ingress AS. 234 A 'strict forwarding' paradigm would solve this problem: An Egress 235 ASBR (e.g. ASBR 1 and 2) allocates a strict forwarding label toward 236 all of its peering ASes and advertises it into its local IGP. The 237 forwarding state of all those labels is to POP off the label and 238 forward to the respective interface. The ingress router 'S' then 239 builds a MPLS label stack by combining its local transport label to 240 ASBR1 or ASBR2 with the IGP learned label pointing to the remote-AS 241 ASBR. 243 -------------traffic-flow---------> 244 <-----------signaling-flow--------- 246 : 247 : AS3 248 : +-------+ 249 AS1 _:___+ ASBR3 | 250 / : +-------+ 251 +-------+ : 252 | ASBR1 | : AS4 253 +-------+ : +-------+ 254 / \_:___+ ASBR4 | 255 / : +-------+ 256 / : 257 +-----+ : 258 | S | : 259 +-----+ : AS5 260 \ : +-------+ 261 \ _:___+ ASBR5 | 262 \ / : +-------+ 263 +-------+ : 264 | ASBR2 | : AS6 265 +-------+ : +-------+ 266 \_:___+ ASBR6 | 267 : +-------+ 268 : 270 Figure 2: Egress ASBR Link selection 272 ASBR {1,2} may want to periodically check the liveliness state to the 273 endpoint of the label (ASBR {3,4,5,6}) which they are advertising. 274 BFD Echo mode [RFC5880] is suitable technology to ensure liveliness 275 state of undirectional links. 277 3.3. Tail end protection of BGP service routes 279 [I-D.minto-2547-egress-node-fast-protection] describes how PE routers 280 advertising their labeled routes could get protected from node- 281 failures. This is a local repair technology being dependent upon 282 successful construction of a LFA path from any PLR to the 'protector 283 PE' in a network. 285 >>>>>>>>CTX-label>>>>>> 286 // \\ 287 // \\ 288 +------+ +------+ +------+ +------+ +------+ +------+ 289 | CE1 +---+PEingr+---+PEprot+---+ P +---+ PLR +-X-+PEegr + 290 +------+ +------+ +------+ +------+ +------+ +------+ 291 \\ \ / // 292 >>>>>>>>>>>>>>>>>>>>>>primary-LSP>>>>>>>> 293 \ / 294 \ +------+ / 295 \___+ CE2 +____/ 296 +------+ 298 Figure 3: Backup Context advertisement 300 Assume a primary LDP LSP from the 'ingress PE' router to the 'egress 301 PE' router. Now consider the FRR calculation from the 'PLR' router 302 if its direct link to the 'egress PE' router fails (X) or the entire 303 'egress PE' goes down. The 'PLR' cannot find a LFA path to local- 304 repair the traffic to the 'protector PE'. This is because the 305 'protector PE' router has not yet converged, and hence would want to 306 forward the traffic to the original PE egress router, such that a 307 temporal forwarding loop would be established. 309 Using IGP advertisement of MPLS Labels the 'protector PE' router can 310 advertise a Label which identifies backup traffic such that arriving 311 traffic, can be forwarded using a context specific forwarding table, 312 rather than the main LSP transit table. The advertised context label 313 is a unidirectional pointer to the 'egress PE' router. The LFA 314 calculation of the PLR gets augmented such that it considers 315 advertised labels pointing to the original tail-end of the LSP. The 316 network learns thereby an egress LSP point which is is as good as the 317 original egress LSP point. 319 3.4. Explicit Path Routing through Label Stacking 321 IGP advertised strict forwarding labels can be utilized for 322 constructing simple EROs via virtue of the MPLS label stack. In a 323 classical traffic engineering problem (Figure 4) is illustrated. The 324 best IGP path between {S,D} is {S, R3, R4, D}. Unfortunately this 325 path is congested. It turns out that the links {S, R1}, {R1, R4} and 326 {R2, R4} do have some spare capacity. In the past a C-SPF 327 calculation would have passed the ERO {S, R1, R4, R2, D} down to RSVP 328 for signaling. One of the features that RSVP provides, is that it 329 keeps track of all the reservations over a particular link, enabling 330 bandwidth reservations of all ingress/egress pairs in a network. 331 What is a feature for bandwidth reservations, may become a scaling 332 harm, as the RSVP signaled paths may not be shared with other nodes 333 in the network. This is a use case for constructing explicit routed 334 paths, without the need to neither track per LSP control-plane state 335 for each link, nor to program per LSP forwarding state. 337 +----+ +----+ 338 | R1 +---------+ R2 | 339 +----+ 2 +----+ 340 / \ | \ 341 / 2 \ | \ 2 342 / \ | \ 343 +-----+ \ | +-----+ 344 | S | \ 5 | 5 | D | 345 +-----+ \ | +-----+ 346 \ \ | / 347 \ 1 \ | / 1 348 \ \ | / 349 +----+ +----+ 350 | R3 +---------+ R4 | 351 +----+ 1 +----+ 353 Figure 4: Explicit Routing using Label stacking 355 Consider now every router along the path does advertise a strict 356 forwarding label for its direct neighbor. Router S could now 357 construct a couple of paths for avoiding the hot links without 358 explicitly signaling them. 360 o {S, R1, R2, D} 362 o {S, R1, R4, D} 364 o {S, R1, R4, R2, D} 366 Note that not every hop in the ERO needs to be unique label in the 367 label stack. This is undesired as existing forwarding hardware 368 technology has got upper limits how much labels can get pushed on the 369 label stack. In fact an existing tunnel (for example LDP tunnel {S, 370 R1, R2} can be reused for certain path segments. 372 3.5. Link and Node Protection LSPs 374 In a network that is utilizing IGP advertised labels, it is still 375 critical to perform fast restoration, with packet forwarding 376 restoration times that are comparable or better than those of RSVP 377 Fast Re-Route (FRR) [RFC4090]. In a classic link failure scenario 378 (Figure 5) is illustrated. The best IGP path between {S,D} is {S, 379 R3, R4, D}. When the directly adjacent link between R3 to R4 380 experiences a failure, (e.g.: fiber cut), the length of time to 381 restore packet forwarding, from S to D, is dependent on several 382 factors: propagation delay during forwarding of new Link State PDU's; 383 artificial delays that may be introduced during the flooding of Link 384 State PDU's (i.e.: LSP/LSA generation intervals, LSA/LSP transmit and 385 retransmit pacing); artificial delays that may be introduced during 386 CSPF computations (i.e.: SPF throttling) and, finally, time necessary 387 to program new label forwarding entries in hardware. The overall 388 length of IGP convergence time, in particular due to artificial 389 delays introduced by various IGP timers that could have been 390 manipulated by operators, will be substantially worse than those 391 observed in networks who have deployed RSVP Fast Re-Route for Link 392 and/or Node Protection. 394 In those networks that use RSVP FRR, there are pre-established Bypass 395 LSP's to immediately restore packet forwarding on an alternate path, 396 until a later time when a head-end LSR is able to signal a new LSP 397 that is routed around the failure. In the below example, an RSVP FRR 398 Bypass LSP may be pre-established along {R3, R1, R2, R4} to provide 399 Link Protection of the R3 to R4 link. When that link fails, R3 will 400 immediately start forwarding traffic along the {R3, R1, R2, R4} 401 Bypass LSP while simultaneously signaling in the Control Plane to the 402 Head-End LSR, S, that the R3 to R4 link has failed. This allows time 403 for S to run CSPF to calculate a new, optimal forwarding path around 404 the link failure; signal a new LSP through intermediate LSRs; and, 405 finally, S may perform "make-before-break" to start forwarding 406 traffic on the new LSP. 408 +----+ +----+ 409 | R1 +---------+ R2 | 410 +----+ 2 +----+ 411 / | | \ 412 / 2 | | \ 2 413 / | | \ 414 +-----+ | | +-----+ 415 | S | | 4 | 5 | D | 416 +-----+ | | +-----+ 417 \ | | / 418 \ 1 | | / 1 419 \ | | / 420 +----+ +----+ 421 | R3 +---------+ R4 | 422 +----+ 1 +----+ 424 Figure 5: Protection LSPs using Label stacking 426 A method is required achieve fast restoration, immediately after a 427 node or link failure, in a network utilizing IGP labels. One method 428 to achieve this goal is discussed in Section 3.1, Increase LFA backup 429 coverage using 'Directed Forwarding'. In this case, R2 would need to 430 advertise a FEC for D with a Directed Forwarding label, 200, for its 431 output interface to D. In addition, R1 would also need to advertise a 432 Directed Forwarding Label, 100, to R2 out its directly attached 433 interface: R1 to R2. At this point, R3 would compute a secondary 434 path to D perhaps using the path {R3, R1, R2, D}. R3 could then pre- 435 program its LFIB with a primary LSP from R3 to R4 and simultaneously 436 pre-program its LFIB with a secondary, fast-restoration path {R3, R1, 437 R2, D}. In this scenario, when a link failure of R3 to R4 occurs, R3 438 would perform the appropriate label operations to restore packet 439 forwarding along the alternate path: {R3, R1, R2, D}. Specifically, 440 R3 would swap 1 label, (the received label from S would be swapped 441 with 200), push one label, (the DF label advertised by R1 to forward 442 the packet out its directly connected link to R2). This would result 443 in the following label stack as the packet is being transmitted by R3 444 out to R1: {100, 200}. 446 3.6. Stitching MPLS Label Switched Path Segments 448 One of the shortcomings of existing traffic-engineering solutions is 449 that existing label switched paths cannot get advertised and shared 450 by many ingress routers in the network. In the example network 451 (Figure 6) a LSP with an ERO of {R4, R2, R6} has been established in 452 order to utilize two unused north / south links. The only way to 453 attract traffic to that LSP is to advertise the LSP as a forwarding 454 adjacency. This causes loss of the original path information which 455 might be interesting for a potential router which might wants to use 456 this LSP for backup purposes. A computing router would need to have 457 all underlying fate-sharing and bandwidth utilization information. 459 +----+ +----+ +----+ 460 | R1 +---------+ R2 +---------+ R5 | 461 +----+ 2 +----+ 2 +----+ 462 / \ | \ \ 463 / 2 \ | \ \ 2 464 / \ | \ \ 465 +----+ \ | \ +----+ 466 | S | \ 5 | 5 \ 5 | D | 467 -----+ \ | \ +----+ 468 \ \ | \ / 469 \ 1 \ | \ / 1 470 \ \ | \ / 471 +----+ +----+ +----+ 472 | R3 +---------+ R4 |---------+ R6 | 473 +----+ 1 +----+ 1 +----+ 475 Figure 6: Advertising path segments 477 The IGP on R4 can now advertise the LSP segment by advertising its 478 ingress label and optionally pass the original ERO, such that any 479 upstream router can do their fate-sharing computations. Potential 480 ingress routers now can use this LSP as a segment of the overall LSP. 481 Furthermore ingress routers can combine label advertisements from 482 different routers along the path. For example router S could stacks 483 its LDP path to R2 {S, R1, R2} plus the IGP learned RSVP LSP {R4, R5, 484 R6} plus a strict forwarding label {R6, D}. 486 3.7. T-LDP replacement for infrastructure labels 488 Consider Figure 7. There is a LSP {S, R1, R2, D} which seeks link- 489 protection against failure of the {R1, R2} link using R-LFA. 491 +----+ +----+ 492 | R1 +----X----+ R2 | 493 +----+ 1 +----+ 494 / >>>>LSP-A->D>>>> \ 495 / 1 // \\ \ 1 496 / // \\ \ 497 +-----+ // \> +-----+ 498 | S | | D | 499 +-----+ +-----+ 500 \ / 501 \ 2 / 4 502 \ / 503 +----+ +----+ 504 | R3 +---------+ R4 | 505 +----+ 3 +----+ 507 Figure 7: Avoidance of T-LDP for obtaining infrastructure labels 509 The Remote LFA Calculations results in the following Node sets. 511 o Extended P set: {R4} 513 o Q set: {R2, D, R4} 515 o PQ set: {R4} 517 The PLR router (R1) needs to obtain the label-bindings from R4 518 towards the final destination D in order to push the two LSPs {R1, S, 519 R3, R4} and {R4, D}. State of the art is to establish a targeted LDP 520 session between PLR (R1) and the R-LFA Neighbor (R4). It would be 521 desirable to avoid dynamic bringup of T-LDP sessions. Rather the IGP 522 should supply the corresponding Label Bindings. Furthermore it would 523 be desirable to apply some form of message compression, such that 524 (unlike T-LDP) not per-FEC label bindings need to be exchanged. 525 Applying Label Block style encoding [RFC4761] would be a suitable 526 technology to compress the messaging overhead. 528 4. Acknowledgements 530 Many thanks to Yakov Rekhter, Ina Minei, Stephane Likowski and Bruno 531 Decraene for their useful comments. 533 5. IANA Considerations 535 This memo includes no request to IANA. 537 6. Security Considerations 539 This document does not introduce any change in terms of IGP security. 540 It simply proposes to flood existing information gathered from other 541 protocols via the IGP. 543 7. References 545 7.1. Normative References 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 551 Label Switching Architecture", RFC 3031, January 2001. 553 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 554 BGP-4", RFC 3107, May 2001. 556 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 557 (VPLS) Using BGP for Auto-Discovery and Signaling", 558 RFC 4761, January 2007. 560 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 561 Specification", RFC 5036, October 2007. 563 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 564 MPLS and GMPLS Traffic Engineering -- Resource Reservation 565 Protocol-Traffic Engineering (RSVP-TE) Extensions", 566 RFC 5151, February 2008. 568 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 569 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 571 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 572 (BFD)", RFC 5880, June 2010. 574 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 575 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 576 Alternate (LFA) Applicability in Service Provider (SP) 577 Networks", RFC 6571, June 2012. 579 7.2. Informative References 581 [I-D.bryant-ipfrr-tunnels] 582 Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP 583 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 584 (work in progress), November 2007. 586 [I-D.ietf-rtgwg-remote-lfa] 587 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 588 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01 589 (work in progress), December 2012. 591 [I-D.minto-2547-egress-node-fast-protection] 592 Jeganathan, J. and H. Gredler, "2547 egress PE Fast 593 Failure Protection", 594 draft-minto-2547-egress-node-fast-protection-01 (work in 595 progress), October 2012. 597 [NNHOP] Chen, E., Shen, N., and A. Tian, "Discovering LDP Next- 598 Nexthop Labels", November 2005, . 601 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 602 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 603 May 2005. 605 Authors' Addresses 607 Hannes Gredler (editor) 608 Juniper Networks, Inc. 609 1194 N. Mathilda Ave. 610 Sunnyvale, CA 94089 611 US 613 Email: hannes@juniper.net 615 Shane Amante 616 Level 3 Communications, Inc. 617 1025 Eldorado Blvd 618 Broomfield, CO 80021 619 US 621 Email: shane@level3.net 622 Tom Scholl 623 Amazon 624 Seattle, WA 625 US 627 Email: tscholl@amazon.com 629 Luay Jalil 630 Verizon 631 1201 E Arapaho Rd. 632 Richardson, TX 75081 633 US 635 Email: luay.jalil@verizon.com