idnits 2.17.1 draft-gredler-rtgwg-igp-label-advertisement-03.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 (April 5, 2013) is 4038 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 -- No information found for draft-minto-2547 - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: October 05, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 April 5, 2013 12 Advertising MPLS labels in IGPs 13 draft-gredler-rtgwg-igp-label-advertisement-03 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 (LFA) 29 computation, Label switched path stitching, egress protection, 30 traffic engineering 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." 52 This Internet-Draft will expire on October 05, 2013. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 3 72 3. Use cases for IGP label distribution . . . . . . . . . . . . . 3 73 3.1. Increase LFA backup coverage using 'Directed Forwarding' . 3 74 3.2. Egress ASBR Link Selection . . . . . . . . . . . . . . . . 5 75 3.3. Tail end protection of BGP service routes . . . . . . . . 6 76 3.4. Explicit Path Routing through Label Stacking . . . . . . . 7 77 3.5. Stitching MPLS Label Switched Path Segments . . . . . . . 8 78 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 MPLS label allocations are predominantly distributed by using the LDP 89 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 90 those protocols have in common that they are session oriented, which 91 means that in order to learn the Label Information database of a 92 particular router one needs to have a direct control-plane session 93 using the given protocol. 95 There are a couple of interesting use cases where the consumer of a 96 MPLS label allocation may not be adjacent to the router having 97 allocated the label. Bringing up an explicit session using existing 98 label distribution protocols between the non-adjacent label allocator 99 and the label consumer is the existing remedy for this dilemma. 101 For LDP protection routing LDP next next hop labels [NNHOP] have been 102 proposed to provide the 2 hop neighborhood labels. While the 2 hop 103 neighborhood provides good backup coverage for the typical network 104 operator topology it is inadequate for some sparse for example ring 105 like topologies. 107 Depending on the application, retrieval and setup of forwarding state 108 of such >1 hop label allocations may only be transient. As such 109 configuring and un-configuring the explicit session is an operational 110 burden and therefore should be avoided. 112 2. Motivation and Applicability 114 It may not be immediate obvious, however introduction of Remote LFA 115 [I-D.ietf-rtgwg-remote-lfa] technology has implied important changes 116 for an IGP implementation. Previously the IGP had a one-way 117 communication path with the LDP module. The IGP supplies tracking 118 routes and LDP selects the best neighbor based upon FEC to tracking 119 routes exact matching results. Remote LFA changes that relationship 120 such that there is a bi-directional communication path between the 121 IGP and LDP. Now the IGP needs to learn about if a label switched 122 path to a given destination prefix has been established and what the 123 ingress label for getting there is. The IGP needs to push that label 124 for the tracking routes of destinations beyond a remote LFA neighbor. 126 Since the IGP is now aware of label switched paths and it does create 127 forwarding state based on label information it makes sense to 128 distribute label switched paths by the IGP as well. 130 3. Use cases for IGP label distribution 132 This section lists example use cases which illustrate IGP 133 distribution of MPLS label switched paths. 135 3.1. Increase LFA backup coverage using 'Directed Forwarding' 137 Deployment of Loop free alternate backup technology [RFC5286] results 138 in backup graphs whose coverage is highly dependent on the underlying 139 Layer-3 topology. Typical network deployments provide backup 140 coverage less than 100 percent (see RFC 6571 Section 4.3 for Results 141 [RFC6571]) for IGP destination prefixes. 143 By closer examining the coverage gaps from the referenced production 144 network topologies, it becomes obvious that most topologies lacking 145 backup coverage are close to ring shaped topologies (Figure 1). 147 Remote LFA [I-D.ietf-rtgwg-remote-lfa] has introduced the notion of a 148 "remote" LFA neighbor. This helper router which is both in P and Q 149 space could forward the traffic to the final destination. Router 'H' 150 is in P space, however due to the actual metric allocation router 'H' 151 is not in Q space. 153 +-----+ 154 | D | 155 +-----+ 156 / \ 157 / M1 \ M4 >= (M1 + M2 + M3) 158 / \ 159 +-----+ +-----+ 160 | PLR | | H | 161 +-----+ +-----+ 162 \ / 163 \ M2 / M3 164 \ / 165 +-----+ 166 | E | 167 +-----+ 169 The protection router (PLR) evaluates for a primary path to 170 destination 'D' if {E -> H -> D} is a viable backup path. Because 171 the metric M4 {H -> D} is higher than the sum of the original primary 172 path and the path from router 'H' to the PLR, this particular path 173 would result in a loop and therefore is rejected. 175 Now consider that router 'H' would advertise a label for FEC 'D', 176 which has the semantics that H will POP the label and forward to the 177 destination node 'D'. This is done irrespective of the underlying IGP 178 metric 'M4' it is a 'strict forwarding' label. The PLR router can 179 now construct a label stack where the outermost label provides 180 transport to router 'H'. The next label on the MPLS stack is the IGP 181 learned 'strict forwarding label' label. Note that the label 'strict 182 forwarding' semantics are similar to a 1-hop ERO (Explicit route 183 object). The Remote 'LFA' calculation would need to get changed, such 184 that even if a node is not in PQ space, but rather in P space, it may 185 get used as a backup neighbor if it advertises a strict forwarding 186 label to the final destination. A recursive version of the algorithm 187 is applicable as well as long a node in P space has some non looping 188 LSP path to the final destination. The PLR router can now program a 189 backup path irrespective of the undesirable underlying layer-3 190 topology. 192 Using existing tunnels for backup routing has been previously 193 described in [I-D.bryant-ipfrr-tunnels]. Section 5.2.3 'Directed 194 forwarding' describes an option to insert a single MPLS label between 195 the tunnel and the payload. Traffic may thereby be directed to a 196 particular neighbor. The mechanism described in this document, is an 197 MPLS specific manifestation of 'Directed forwarding'. 199 3.2. Egress ASBR Link Selection 201 In the topology described in Figure 2. router 'S' is facing a 202 dilemma. Router S receives a BGP route from all of its 4 upstream 203 routers. Using existing mechanism the provider owning AS1 can 204 control the loading of its direct links *to* its ASBR1 and ASBR2, 205 however it cannot control the load of the links beyond the ASBRs, 206 except manually tweaking the eBGP import policy and filtering out a 207 certain prefix. It would be more desirable to have visibility of all 208 four BGP paths and be able to control the loading of those four paths 209 using Weighted ECMP. Note that the computation of the 'Weight' 210 percentage and the component doing this computation (Router embedded 211 or SDN) is outside the scope of this document. 213 If all the ASes would be under one common administrative control then 214 the network operator could deploy a forwarding hierarchy by using 215 [RFC3107] to learn about the remote-AS BGP nexthop addresses and 216 associated labels. An ingress router 'S' would then stack the 217 transport label to its local egress ASBR and the remote ASBR supplied 218 label. In reality it is hard to convince a peering AS to deploy 219 another protocol just in order to easier control the egress load on 220 the WAN links for the ingress AS. 222 A 'strict forwarding' paradigm would solve this problem: An Egress 223 ASBR (e.g. ASBR 1 and 2) allocates a strict forwarding label toward 224 all of its peering ASes and advertises it into its local IGP. The 225 forwarding state of all those labels is to POP off the label and 226 forward to the respective interface. The ingress router 'S' then 227 builds a MPLS label stack by combining its local transport label to 228 ASBR1 or ASBR2 with the IGP learned label pointing to the remote-AS 229 ASBR. 231 -------------traffic-flow---------> 232 <-----------signaling-flow--------- 234 : 235 : AS3 236 : +-------+ 237 AS1 _:___+ ASBR3 | 238 / : +-------+ 239 +-------+ : 240 | ASBR1 | : AS4 241 +-------+ : +-------+ 242 / \_:___+ ASBR4 | 243 / : +-------+ 244 / : 245 +-----+ : 246 | S | : 247 +-----+ : AS5 248 \ : +-------+ 249 \ _:___+ ASBR5 | 250 \ / : +-------+ 251 +-------+ : 252 | ASBR2 | : AS6 253 +-------+ : +-------+ 254 \_:___+ ASBR6 | 255 : +-------+ 256 : 258 ASBR {1,2} may want to periodically check the liveliness state to the 259 endpoint of the label (ASBR {3,4,5,6}) which they are advertising. 260 BFD Echo mode [RFC5880] is suitable technology to ensure liveliness 261 state of undirectional links. 263 3.3. Tail end protection of BGP service routes 265 [I-D.minto-2547-egress-node-fast-protection] describes how PE routers 266 advertising their labeled routes could get protected from node- 267 failures. This is a local repair technology being dependent upon 268 successful construction of a LFA path from any PLR to the 'protector 269 PE' in a network. 271 >>>>>>>>CTX-label>>>>>> 272 // \\ 273 // \\ 274 +------+ +------+ +------+ +------+ +------+ +------+ 275 | CE1 +---+PEingr+---+PEprot+---+ P +---+ PLR +-X-+PEegr + 276 +------+ +------+ +------+ +------+ +------+ +------+ 277 \\ \ / // 278 >>>>>>>>>>>>>>>>>>>>>>primary-LSP>>>>>>>> 279 \ / 280 \ +------+ / 281 \___+ CE2 +____/ 282 +------+ 284 Assume a primary LDP LSP from the 'ingress PE' router to the 'egress 285 PE' router. Now consider the FRR calculation from the 'PLR' router 286 if its direct link to the 'egress PE' router fails (X) or the entire 287 'egress PE' goes down. The 'PLR' cannot find a LFA path to local- 288 repair the traffic to the 'protector PE'. This is because the 289 'protector PE' router has not yet converged, and hence would want to 290 forward the traffic to the original PE egress router, such that a 291 temporal forwarding loop would be established. 293 Using IGP advertisement of MPLS Labels the 'protector PE' router can 294 advertise a Label which identifies backup traffic such that arriving 295 traffic, can be forwarded using a context specific forwarding table, 296 rather than the main LSP transit table. The advertised context label 297 is a unidirectional pointer to the 'egress PE' router. The LFA 298 calculation of the PLR gets augmented such that it considers 299 advertised labels pointing to the original tail-end of the LSP. The 300 network learns thereby an egress LSP point which is is as good as the 301 original egress LSP point. 303 3.4. Explicit Path Routing through Label Stacking 305 IGP advertised strict forwarding labels can be utilized for 306 constructing simple EROs via virtue of the MPLS label stack. In a 307 classical traffic engineering problem (Figure 4) is illustrated. The 308 best IGP path between {S,D} is {S, R3, R4, D}. Unfortunately this 309 path is congested. It turns out that the links {S, R1}, {R1, R4} and 310 {R2, R4} do have some spare capacity. In the past a C-SPF 311 calculation would have passed the ERO {S, R1, R4, R2, D} down to RSVP 312 for signaling. The conceptional problem with RSVP signaled paths is 313 that they cannot by shared with other nodes in the network. Hence 314 all potential ingress routers need to setup their "private" ERO path 315 and allocate network signaling resources and forwarding state. 317 +----+ +----+ 318 | R1 +---------+ R2 | 319 +----+ 2 +----+ 320 / \ | \ 321 / 2 \ | \ 2 322 / \ | \ 323 +-----+ \ | +-----+ 324 | S | \ 5 | 5 | D | 325 +-----+ \ | +-----+ 326 \ \ | / 327 \ 1 \ | / 1 328 \ \ | / 329 +----+ +----+ 330 | R3 +---------+ R4 | 331 +----+ 1 +----+ 333 Consider now every router along the path does advertise a strict 334 forwarding label for its direct neighbor. Router S could now 335 construct a couple of paths for avoiding the hot links without 336 explicitly signaling them. 338 o {S, R1, R2, D} 340 o {S, R1, R4, D} 342 o {S, R1, R4, R2, D} 344 Note that not every hop in the ERO needs to be unique label in the 345 label stack. This is undesired as existing forwarding hardware 346 technology has got upper limits how much labels can get pushed on the 347 label stack. In fact an existing tunnel (for example LDP tunnel {S, 348 R1, R2} can be reused for certain path segments. 350 3.5. Stitching MPLS Label Switched Path Segments 352 One of the shortcomings of existing traffic-engineering solutions is 353 that existing label switched paths cannot get advertised and shared 354 by many ingress routers in the network. In the example network 355 (Figure 5) a LSP with an ERO of {R4, R2, R6} has been established in 356 order to utilize two unused north / south links. The only way to 357 attract traffic to that LSP is to advertise the LSP as a forwarding 358 adjacency. This causes loss of the original path information which 359 might be interesting for a potential router which might wants to use 360 this LSP for backup purposes. A computing router would need to have 361 all underlying fate-sharing and bandwidth utilization information. 363 +----+ +----+ +----+ 364 | R1 +---------+ R2 +---------+ R5 | 365 +----+ 2 +----+ 2 +----+ 366 / \ | \ \ 367 / 2 \ | \ \ 2 368 / \ | \ \ 369 +----+ \ | \ +----+ 370 | S | \ 5 | 5 \ 5 | D | 371 -----+ \ | \ +----+ 372 \ \ | \ / 373 \ 1 \ | \ / 1 374 \ \ | \ / 375 +----+ +----+ +----+ 376 | R3 +---------+ R4 |---------+ R6 | 377 +----+ 1 +----+ 1 +----+ 379 The IGP on R4 can now advertise the LSP segment by advertising its 380 ingress label and optionally pass the original ERO, such that any 381 upstream router can do their fate-sharing computations. Potential 382 ingress routers now can use this LSP as a segment of the overall LSP. 383 Furthermore ingress routers can combine label advertisements from 384 different routers along the path. For example router S could stacks 385 its LDP path to R2 {S, R1, R2} plus the IGP learned RSVP LSP {R4, R5, 386 R6} plus a strict forwarding label {R6, D}. 388 4. Acknowledgements 390 Many thanks to Yakov Rehkter, Ina Minei, Stephane Likowski and Bruno 391 Decraene for their useful comments. 393 5. IANA Considerations 395 This memo includes no request to IANA. 397 6. Security Considerations 399 This document does not introduce any change in terms of IGP security. 400 It simply proposes to flood existing information gathered from other 401 protocols via the IGP. 403 7. References 405 7.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 411 BGP-4", RFC 3107, May 2001. 413 [RFC5036] Andersson, L., Minei, I. and B. Thomas, "LDP 414 Specification", RFC 5036, October 2007. 416 [RFC5151] Farrel, A., Ayyangar, A. and JP. Vasseur, "Inter-Domain 417 MPLS and GMPLS Traffic Engineering -- Resource Reservation 418 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 419 5151, February 2008. 421 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 422 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 424 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 425 (BFD)", RFC 5880, June 2010. 427 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 428 Uttaro, J., Leymann, N. and M. Horneffer, "Loop-Free 429 Alternate (LFA) Applicability in Service Provider (SP) 430 Networks", RFC 6571, June 2012. 432 7.2. Informative References 434 [I-D.bryant-ipfrr-tunnels] 435 Bryant, S., Filsfils, C., Previdi, S. and M. Shand, "IP 436 Fast Reroute using tunnels", Internet-Draft draft-bryant- 437 ipfrr-tunnels-03, November 2007. 439 [I-D.ietf-rtgwg-remote-lfa] 440 Bryant, S., Filsfils, C., Previdi, S., Shand, M. and S. 441 Ning, "Remote LFA FRR", Internet-Draft draft-ietf-rtgwg- 442 remote-lfa-01, December 2012. 444 [I-D.minto-2547-egress-node-fast-protection] 445 Jeganathan, J. and H. Gredler, "2547 egress PE Fast 446 Failure Protection", Internet-Draft draft-minto-2547 447 -egress-node-fast-protection-01, October 2012. 449 [NNHOP] Chen, E., Shen, N. and A. Tian, "Discovering LDP Next- 450 Nexthop Labels", November 2005, . 453 Authors' Addresses 455 Hannes Gredler, editor 456 Juniper Networks, Inc. 457 1194 N. Mathilda Ave. 458 Sunnyvale, CA 94089 459 US 461 Email: hannes@juniper.net 462 Shane Amante 463 Level 3 Communications, Inc. 464 1025 Eldorado Blvd 465 Broomfield, CO 80021 466 US 468 Email: shane@level3.net 470 Tom Scholl 471 Amazon 472 Seattle, WA 473 US 475 Email: tscholl@amazon.com 477 Luay Jalil 478 Verizon 479 1201 E Arapaho Rd. 480 Richardson, TX 75081 481 US 483 Email: luay.jalil@verizon.com