idnits 2.17.1 draft-gredler-rtgwg-igp-label-advertisement-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For construction of the Bypass LSP a constrained-SPF (C-SPF) calculation is commenced. The C-SPF calculation computes an alternative path to R4, without transiting the {R3, R4} link. Furthermore the backup path MUST not violate any SRLGs with respect to the {R3, R4} link. A possible backup path result for R3 is {R3, R1, R2, R4}. -- The document date (May 15, 2013) is 3991 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 16, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 May 15, 2013 12 Advertising MPLS labels in IGPs 13 draft-gredler-rtgwg-igp-label-advertisement-05 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 16, 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 . . . . . . . 12 82 3.7. T-LDP replacement for infrastructure labels . . . . . . . 13 83 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 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. Furthermore the proposed use of 119 distributing MPLS Labels using IGP prototocols adheres to 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. 330 One of the functions that RSVP-TE provides, is that it keeps track of 331 all the reservations over a particular link, enabling support for 332 such traffic engineering features as bandwidth constraints, LSP 333 priorities, and LSP preemption. However, support for these features 334 with RSVP-TE has a cost associated with it, as it does require a node 335 to maintain control and data plane state for all the individual 336 point-to-point LSPs traversing the node (modulo the LSPs that rely on 337 the LSP hierarchy). This is a use case for constructing explicitly 338 routed paths, without the need to maintain per LSP control/data plane 339 state on the nodes traversed by the LSP. This use case assumes that 340 either support for bandwidth constrains, LSP priorities, and LSP 341 preemption is not needed, or that such support is provided by means 342 outside of this document. 344 +----+ +----+ 345 | R1 +---------+ R2 | 346 +----+ 2 +----+ 347 / \ | \ 348 / 2 \ | \ 2 349 / \ | \ 350 +-----+ \ | +-----+ 351 | S | \ 5 | 5 | D | 352 +-----+ \ | +-----+ 353 \ \ | / 354 \ 1 \ | / 1 355 \ \ | / 356 +----+ +----+ 357 | R3 +---------+ R4 | 358 +----+ 1 +----+ 360 Figure 4: Explicit Routing using Label stacking 362 Consider now every router along the path does advertise a strict 363 forwarding label for its direct neighbor. Router S could now 364 construct a couple of paths for avoiding the hot links without 365 explicitly signaling them. 367 o {S, R1, R2, D} 369 o {S, R1, R4, D} 371 o {S, R1, R4, R2, D} 373 Note that not every hop in the ERO needs to be unique label in the 374 label stack. This is undesired as existing forwarding hardware 375 technology has got upper limits how much labels can get pushed on the 376 label stack. In fact an existing tunnel (for example LDP tunnel {S, 377 R1, R2} can be reused for certain path segments. 379 3.5. Link and Node Protection LSPs 381 In a network that is protecting nodes and links using IGP advertised 382 labels, it is critical to perform fast restoration using local- 383 repair, with packet forwarding restoration times comparable to RSVP 384 Fast Re-Route (FRR) [RFC4090] or Loop Free Alternates [RFC5286]. 386 First consider the timing of events assuming control-plane 387 convergence as the sole repair mechanism. In Figure 5 a link failure 388 scenario is illustrated. The best IGP path between {S,D} is {S, R3, 389 R4, D}. When the directly adjacent link between R3 to R4 experiences 390 a failure, (e.g.: fiber cut), the length of time to restore packet 391 forwarding, from S to D, is dependent on several factors: 393 1. artificial (generation and pacing) delay of link-state updates 395 2. propagation delay of link-state updates 397 3. SPF throttling 399 4. programming forwarding state 401 The overall length of IGP convergence time, is largely dependent on 402 the slowest router programming changed forwarding state. This is 403 inherent unpredictable due to the CPU load and overall scheduling 404 state in the affected systems, hence control-plane as the sole repair 405 technology is ineffective. In contrast, local-repair technology 406 helps to minimize transient packet loss. In local-repair technology 407 a backup path is programmed ahead of time. Once the link fails a 408 forwarding plane may immediately change forwarding state (= local- 409 repair) to the backup path. This keeps the traffic flowing until the 410 control-plane calculates and installs the new primary path and backup 411 path tuples forwarding state for a given destination in the network. 413 In the below example, the IGP calculates using C-SPF and pre- 414 establishes a FRR Bypass LSP along {R3, R1, R2, R4} to provide Link 415 Protection of the R3 to R4 link. When that link fails, R3 will 416 local-repair traffic along the {R3, R1, R2, R4} Bypass LSP while 417 simultaneously signaling in the Control Plane to the Head-End LSR, S, 418 that the R3 to R4 link has failed. This allows time for S to run 419 C-SPF to calculate a new, optimal forwarding path around the link 420 failure; signal a new LSP through intermediate LSRs; and, finally, S 421 may perform "make-before-break" to start forwarding traffic on the 422 new LSP. 424 Note that the algorithmic complexity of a single-destination C-SPF is 425 much less compared to the the all-destination, per-neighbor forward 426 SPF and per-neighbor reverse SPF a router doing Remote LFA 427 [I-D.ietf-rtgwg-remote-lfa] calculations. 429 +----+ +----+ 430 | R1 +---------+ R2 | 431 +----+ 2 +----+ 432 / | | \ 433 / 2 | | \ 2 434 / | | \ 435 +-----+ | | +-----+ 436 | S | | 4 | 5 | D | 437 +-----+ | | +-----+ 438 \ | | / 439 \ 1 | | / 1 440 \ | | / 441 +----+ +----+ 442 | R3 +---------+ R4 | 443 +----+ 1 +----+ 445 Figure 5: Protection LSPs using Label stacking 447 For construction of the Bypass LSP a constrained-SPF (C-SPF) 448 calculation is commenced. The C-SPF calculation computes an 449 alternative path to R4, without transiting the {R3, R4} link. 450 Furthermore the backup path MUST not violate any SRLGs with respect 451 to the {R3, R4} link. A possible backup path result for R3 is {R3, 452 R1, R2, R4}. 454 Next R3 needs to construct the label stack for this particular Bypass 455 LSP. Assume that each router along the Bypass LSP has advertised a 456 label binding for reaching its direct neighbor. 458 o R1: to R2, Label 102 460 o R2: to R4, Label 204 462 o R3: to R1, Label 301 464 Now R3 can construct the the label-stack fully describing the bypass 465 LSP: For the last hop from R2 to R4, label 204 is pushed on the stack 466 For the penultimate hop from R1 to R2, label 102 is pushed on the 467 stack Since the first hop of the Bypass LSP is a local choice, there 468 is no need to encode an actual label (label 301), but rather program 469 a nexthop forwarding action to R1. 471 RSVP headends learn about all their bypasses using RESV messages. 473 When stacking IGP advertised labels, there is no direct comparable 474 concept of a 'single head-end' node. All one-hop LSPs are in fact 475 head-end nodes of their own and since there is no end-to-end 476 signaling there is also no way about learning the bypasses that 477 transit nodes have set up. IGP advertised labels hence mandate that 478 all Bypass LSPs needs to be signaled to the rest of the network, such 479 that the edge routers can have full insight (and control) what links 480 may get utilized during local-repair. This is necessary, such that 481 an edge router who may wants to enforce path policy constraints (e.g. 482 end-to-end delay, hop count, path diversity, SRLG) can prefer or 483 avoid certain paths (and their Bypasses) for path construction. 485 3.6. Stitching MPLS Label Switched Path Segments 487 One of the shortcomings of existing traffic-engineering solutions is 488 that existing label switched paths cannot get advertised and shared 489 by many ingress routers in the network. In the example network 490 (Figure 6) a LSP with an ERO of {R4, R2, R6} has been established in 491 order to utilize two unused north / south links. The only way to 492 attract traffic to that LSP is to advertise the LSP as a forwarding 493 adjacency. This causes loss of the original path information which 494 might be interesting for a potential router which might wants to use 495 this LSP for backup purposes. A computing router would need to have 496 all underlying fate-sharing and bandwidth utilization information. 498 +----+ +----+ +----+ 499 | R1 +---------+ R2 +---------+ R5 | 500 +----+ 2 +----+ 2 +----+ 501 / \ | \ \ 502 / 2 \ | \ \ 2 503 / \ | \ \ 504 +----+ \ | \ +----+ 505 | S | \ 5 | 5 \ 5 | D | 506 -----+ \ | \ +----+ 507 \ \ | \ / 508 \ 1 \ | \ / 1 509 \ \ | \ / 510 +----+ +----+ +----+ 511 | R3 +---------+ R4 |---------+ R6 | 512 +----+ 1 +----+ 1 +----+ 514 Figure 6: Advertising path segments 516 The IGP on R4 can now advertise the LSP segment by advertising its 517 ingress label and optionally pass the original ERO, such that any 518 upstream router can do their fate-sharing computations. Potential 519 ingress routers now can use this LSP as a segment of the overall LSP. 520 Furthermore ingress routers can combine label advertisements from 521 different routers along the path. For example router S could stacks 522 its LDP path to R2 {S, R1, R2} plus the IGP learned RSVP LSP {R4, R5, 523 R6} plus a strict forwarding label {R6, D}. 525 3.7. T-LDP replacement for infrastructure labels 527 Consider Figure 7. There is a LSP {S, R1, R2, D} which seeks link- 528 protection against failure of the {R1, R2} link using R-LFA. 530 +----+ +----+ 531 | R1 +----X----+ R2 | 532 +----+ 1 +----+ 533 / >>>>LSP-A->D>>>> \ 534 / 1 // \\ \ 1 535 / // \\ \ 536 +-----+ // \> +-----+ 537 | S | | D | 538 +-----+ +-----+ 539 \ / 540 \ 2 / 4 541 \ / 542 +----+ +----+ 543 | R3 +---------+ R4 | 544 +----+ 3 +----+ 546 Figure 7: Avoidance of T-LDP for obtaining infrastructure labels 548 The Remote LFA Calculations results in the following Node sets. 550 o Extended P set: {R4} 552 o Q set: {R2, D, R4} 554 o PQ set: {R4} 556 The PLR router (R1) needs to obtain the label-bindings from R4 557 towards the final destination D in order to push the two LSPs {R1, S, 558 R3, R4} and {R4, D}. State of the art is to establish a targeted LDP 559 session between PLR (R1) and the R-LFA Neighbor (R4). It would be 560 desirable to avoid dynamic bringup of T-LDP sessions. Rather the IGP 561 should supply the corresponding Label Bindings. Furthermore it would 562 be desirable to apply some form of message compression, such that 563 (unlike T-LDP) not per-FEC label bindings need to be exchanged. 564 Applying Label Block style encoding [RFC4761] would be a suitable 565 technology to compress the messaging overhead. 567 4. Acknowledgements 569 Many thanks to Yakov Rekhter, Ina Minei, Stephane Likowski and Bruno 570 Decraene for their useful comments. 572 5. IANA Considerations 574 This memo includes no request to IANA. 576 6. Security Considerations 578 This document does not introduce any change in terms of IGP security. 579 It simply proposes to flood existing information gathered from other 580 protocols via the IGP. 582 7. References 584 7.1. Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 590 Label Switching Architecture", RFC 3031, January 2001. 592 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 593 BGP-4", RFC 3107, May 2001. 595 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 596 (VPLS) Using BGP for Auto-Discovery and Signaling", 597 RFC 4761, January 2007. 599 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 600 Specification", RFC 5036, October 2007. 602 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 603 MPLS and GMPLS Traffic Engineering -- Resource Reservation 604 Protocol-Traffic Engineering (RSVP-TE) Extensions", 605 RFC 5151, February 2008. 607 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 608 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 610 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 611 (BFD)", RFC 5880, June 2010. 613 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 614 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 615 Alternate (LFA) Applicability in Service Provider (SP) 616 Networks", RFC 6571, June 2012. 618 7.2. Informative References 620 [I-D.bryant-ipfrr-tunnels] 621 Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP 622 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 623 (work in progress), November 2007. 625 [I-D.ietf-rtgwg-remote-lfa] 626 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 627 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01 628 (work in progress), December 2012. 630 [I-D.minto-2547-egress-node-fast-protection] 631 Jeganathan, J. and H. Gredler, "2547 egress PE Fast 632 Failure Protection", 633 draft-minto-2547-egress-node-fast-protection-01 (work in 634 progress), October 2012. 636 [NNHOP] Chen, E., Shen, N., and A. Tian, "Discovering LDP Next- 637 Nexthop Labels", November 2005, . 640 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 641 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 642 May 2005. 644 Authors' Addresses 646 Hannes Gredler (editor) 647 Juniper Networks, Inc. 648 1194 N. Mathilda Ave. 649 Sunnyvale, CA 94089 650 US 652 Email: hannes@juniper.net 653 Shane Amante 654 Level 3 Communications, Inc. 655 1025 Eldorado Blvd 656 Broomfield, CO 80021 657 US 659 Email: shane@level3.net 661 Tom Scholl 662 Amazon 663 Seattle, WA 664 US 666 Email: tscholl@amazon.com 668 Luay Jalil 669 Verizon 670 1201 E Arapaho Rd. 671 Richardson, TX 75081 672 US 674 Email: luay.jalil@verizon.com