idnits 2.17.1 draft-gredler-rtgwg-igp-label-advertisement-01.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 (February 18, 2013) is 4083 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) == Missing Reference: 'NNHOP' is mentioned on line 385, but not defined ** 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 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 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track February 18, 2013 5 Expires: August 22, 2013 7 Advertising MPLS labels in IGPs 8 draft-gredler-rtgwg-igp-label-advertisement-01 10 Abstract 12 Historically MPLS label distribution was driven by session oriented 13 protocols. In order to obtain a particular routers label binding for 14 a given destination FEC one needs to have first an established 15 session with that node. 17 This document describes a mechanism to distribute FEC/label mappings 18 trough flooding protocols. Flooding protocols publish their objects 19 for an unknown set of receivers, therefore one can efficiently scale 20 label distribution for use cases where the receiver of label 21 information is not directly connected. 23 Application of this technique are found in the field of backup (LFA) 24 computation, Label switched path stitching, traffic engineering and 25 egress link load balancing. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 22, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 3 69 2.1. Explicit One hop tunnels . . . . . . . . . . . . . . . . . 4 70 2.2. Egress ASBR Link Selection . . . . . . . . . . . . . . . . 5 71 2.3. Explicit Path Routing through Label Stacking . . . . . . . 6 72 2.4. Stitching MPLS Label Switched Path Segments . . . . . . . . 7 73 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 79 6.3. References . . . . . . . . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 MPLS label allocations are predominantly distributed by using the LDP 85 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 86 those protocols have in common that they are session oriented, which 87 means that in order to learn the Label Information database of a 88 particular router one needs to have a direct control-plane session 89 using the given protocol. 91 There are a couple of interesting use cases where the consumer of a 92 MPLS label allocation may not be adjacent to the router having 93 allocated the label. Bringing up an explicit session using existing 94 label distribution protocols between the non-adjacent label allocator 95 and the label consumer is the existing remedy for this dilemma. 97 For LDP protection routingLDP next next hop labels [NNHOP] have been 98 proposed to provide the 2 hop neighborhood labels. While the 2 hop 99 neighborhood provides good backup coverage for the typical network 100 operator topology it is inadequate for some sparse for example ring 101 like topologies. 103 Depending on the application, retrieval and setup of forwarding state 104 of such >1 hop label allocations may only be transient. As such 105 configuring and un-configuring the explicit session is an operational 106 burden and therefore should be avoided. 108 2. Motivation and Applicability 110 It may not be immediate obvious, however introduction of Remote LFA 111 [I-D.ietf-rtgwg-remote-lfa] technology has implied important changes 112 for an IGP implementation. Previously the IGP had a one-way 113 communication path with the LDP module. The IGP supplies tracking 114 routes and LDP selects the best neighbor based upon FEC to tracking 115 routes exact matching results. Remote LFA changes that relationship 116 such that there is a bi-directional communication path between the 117 IGP and LDP. Now the IGP needs to learn about if a label switched 118 path to a given destination prefix has been established and what the 119 ingress label for getting there is. The IGP needs to push that label 120 for the tracking routes of destinations beyond a remote LFA neighbor. 122 Since the IGP now creates forwarding state based on label information 123 it may make sense to distribute label by the IGP as well. This 124 section lists example applications of IGP distribution of MPLS 125 labels. 127 2.1. Explicit One hop tunnels 129 Deployment of Loop free alternate backup technology RFC 5286 130 [RFC5286] results in backup graphs whose coverage is highly dependent 131 on the underlying Layer-3 topology. Typical network deployments 132 provide backup coverage less than 100 percent (see RFC 6571 Section 133 4.3 for Results [RFC6571]) for IGP destination prefixes. 135 By closer examining the coverage gaps from the referenced production 136 network topologies, it becomes obvious that most topologies lacking 137 backup coverage are close to ring shaped topologies (Figure 1). 139 +-----+ 140 | D | 141 +-----+ 142 / \ 143 / M1 \ M4 >= (M1 + M2 + M3) 144 / \ 145 +-----+ +-----+ 146 | PLR | | H | 147 +-----+ +-----+ 148 \ / 149 \ M2 / M3 150 \ / 151 +-----+ 152 | E | 153 +-----+ 155 Figure 1: Coverage gap analysis 157 The protection router (PLR) evaluates for a primary path to 158 destination 'D' if {E -> H -> D} is a viable backup path. Because 159 the metric M4 {H -> D} is higher than the sum of the original primary 160 path and the path from router 'H' to the PLR, this particular path 161 would result in a loop and therefore is rejected. 163 Remote LFA [I-D.ietf-rtgwg-remote-lfa] has introduced the notion of 164 "remote" LFA neighbor. A helper Router which is both in P and Q 165 space could forward the traffic to the final destination. Router 'H' 166 is in P space, however due to the actual metric allocation router 'H' 167 is not in Q space. 169 Now consider that router 'H' would advertise a label for FEC 'D', 170 which has the semantics that H will POP the label and forward to the 171 destination node 'D'. This is done irrespective of the underlying 172 IGP metric 'M4' it is a 'strict forwarding' label. The PLR router 173 can now construct a label stack where the outermost label provides 174 transport to router 'H'. The next label on the MPLS stack is the IGP 175 learned 'strict forwarding label' label. Note that the label 'strict 176 forwarding' semantics are similar to a 1-hop ERO (Explicit route 177 object). The Remote 'LFA' calculation would ned to get changed, such 178 that even if a node is not in PQ space, but rather in P space, it may 179 get used as a backup neighbor if it advertises a strict forwarding 180 label to the final destination. A recursive version of the algorithm 181 is applicable as well as long a node in P space has some non looping 182 LSP path to the final destination. The PLR router can now program a 183 backup path irrespective of the undesirable underlying layer-3 184 topology. 186 2.2. Egress ASBR Link Selection 188 In the ingress router 'S' is facing a dilemma (Figure 2). Router S 189 receives a BGP route from all of its 4 upstream routers. Using 190 existing mechanism the provider owning AS1 can control the loading of 191 its direct links *to* its ASBR3 and ASBR4, however it cannot control 192 the load of the links beyond the ASBRs, except manually tweaking the 193 BGP import policy and filtering out a certain prefix. It would be be 194 more desirable to have visibility of all four BGP paths and be able 195 to control the loading of those four paths using Weighted ECMP. Note 196 that the computation of the 'Weight' percentage and the component 197 doing this computation (Network embedded/SDN) is outside the scope of 198 this document. 200 If all the ASes would be under one common administrative control then 201 the network operator could deploy a forwarding hierarchy by using 202 [RFC3107] to learn about the remote-AS BGP nexthop addresses and 203 associated labels. An ingress router 'S' would then stack the 204 transport label to its local egress ASBR and the remote ASBR supplied 205 label. In reality it is hard to convince a peering AS to deploy 206 another protocol just in order to easier control the egress load on 207 the WAN links for the ingress AS. 209 A 'strict forwarding' paradigm would solve this problem: An Egress 210 ASBR (e.g. ASBR 3 and 4) allocates a strict forwarding label toward 211 all of its peering ASes and advertises it into its local IGP. The 212 forwarding state of all those labels is to POP off the label and 213 forward to the respective interface. The ingress router 'S' then 214 builds a MPLS label stack by combining its local transport label to 215 ASBR3 or ASBR4 with the IGP learned label pointing to the remote-AS 216 ASBR. 218 -------------traffic-flow---------> 219 <-----------signaling-flow--------- 221 : 222 : AS3 223 : +-------+ 224 AS1 _:___+ ASBR3 | 225 / : +-------+ 226 +-------+ : 227 | ASBR1 | : AS4 228 +-------+ : +-------+ 229 / \_:___+ ASBR4 | 230 / : +-------+ 231 / : 232 +-----+ : 233 | S | : 234 +-----+ : AS5 235 \ : +-------+ 236 \ _:___+ ASBR5 | 237 \ / : +-------+ 238 +-------+ : 239 | ASBR2 | : AS6 240 +-------+ : +-------+ 241 \_:___+ ASBR6 | 242 : +-------+ 243 : 245 Figure 2: Egress ASBR Link selection 247 2.3. Explicit Path Routing through Label Stacking 249 IGP advertised strict forwarding labels can be utilized for 250 constructing simple EROs via virtue of the MPLS label stack. In a 251 classical traffic engineering problem (Figure 3) is illustrated. The 252 best IGP path between {S,D} is {S, R3, R4, D}. Unfortunately this 253 path is congested. It turns out that the links {S, R1}, {R1, R4} and 254 {R2, R4} do have some spare capacity. In the past a C-SPF 255 calculation would have passed the ERO {S, R1, R4, R2, D} down to RSVP 256 for signaling. The conceptional problem with RSVP signaled paths is 257 that they cannot by shared with other nodes in the network. Hence 258 all potential ingress routers need to setup their "private" ERO path 259 and allocate network signaling resources and forwarding state. 261 +----+ +----+ 262 | R1 +---------+ R2 | 263 +----+ 2 +----+ 264 / \ | \ 265 / 2 \ | \ 2 266 / \ | \ 267 +-----+ \ | +-----+ 268 | S | \ 5 | 5 | D | 269 +-----+ \ | +-----+ 270 \ \ | / 271 \ 1 \ | / 1 272 \ \ | / 273 +----+ +----+ 274 | R3 +---------+ R4 | 275 +----+ 1 +----+ 277 Figure 3: Explicit Routing using Label stacking 279 Consider now every router along the path does advertise a strict 280 forwarding label for its direct neighbor. Router S could now 281 construct a couple of paths for avoiding the hot links without 282 explicitly signaling them. 284 o {S, R1, R2, D} 286 o {S, R1, R4, D} 288 o {S, R1, R4, R2, D} 290 Note that not every hop in the ERO needs to be unique label in the 291 label stack. This is undesired as existing forwarding hardware 292 technology has got upper limits how much labels can get pushed on the 293 label stack. In fact an existing tunnel (for example LDP tunnel {S, 294 R1, R2} can be reused for certain path segments. 296 2.4. Stitching MPLS Label Switched Path Segments 298 One of the shortcomings of existing traffic-engineering solutions is 299 that existing label switched paths cannot get advertised and shared 300 by many ingress routers in the network. In the example network 301 (Figure 4) a LSP with an ERO of {R4, R2, R6} has been established in 302 order to utilize two unused north / south links. The only way to 303 attract traffic to that LSP is to advertise the LSP as a forwarding 304 adjacency. This causes loss of the original path information which 305 might be interesting for a potential router which might wants to use 306 this LSP for backup purposes. A computing router would need to have 307 all underlying fate-sharing and bandwidth utilization information. 309 +----+ +----+ +----+ 310 | R1 +---------+ R2 +---------+ R5 | 311 +----+ 2 +----+ 2 +----+ 312 / \ | \ \ 313 / 2 \ | \ \ 2 314 / \ | \ \ 315 +----+ \ | \ +----+ 316 | S | \ 5 | 5 \ 5 | D | 317 -----+ \ | \ +----+ 318 \ \ | \ / 319 \ 1 \ | \ / 1 320 \ \ | \ / 321 +----+ +----+ +----+ 322 | R3 +---------+ R4 |---------+ R6 | 323 +----+ 1 +----+ 1 +----+ 325 Figure 4: Advertising path segments 327 The IGP on R4 can now advertise the LSP segment by advertising its 328 ingress label and optionally pass the original ERO, such that any 329 upstream router can do their fate-sharing computations. Potential 330 ingress routers now can use this LSP as a segment of the overall LSP. 331 Furthermore ingress routers can combine label advertisements from 332 different routers along the path. For example router S could stacks 333 its LDP path to R2 {S, R1, R2} plus the IGP learned RSVP LSP {R4, R5, 334 R6} plus a strict forwarding label {R6, D}. 336 3. Acknowledgements 338 Many thanks to Yakov Rehkter, Stephane Likowski and Bruno Decraene 339 for their useful comments. 341 4. IANA Considerations 343 This memo includes no request to IANA. 345 5. Security Considerations 347 This document does not introduce any change in terms of IGP security. 348 It simply proposes to flood existing information gathered from other 349 protocols via the IGP. 351 6. References 352 6.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 358 BGP-4", RFC 3107, May 2001. 360 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 361 Specification", RFC 5036, October 2007. 363 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 364 MPLS and GMPLS Traffic Engineering -- Resource Reservation 365 Protocol-Traffic Engineering (RSVP-TE) Extensions", 366 RFC 5151, February 2008. 368 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 369 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 371 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 372 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 373 Alternate (LFA) Applicability in Service Provider (SP) 374 Networks", RFC 6571, June 2012. 376 6.2. Informative References 378 [I-D.ietf-rtgwg-remote-lfa] 379 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 380 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01 381 (work in progress), December 2012. 383 6.3. References 385 [NNHOP] Chen, H., Shen, H., and H. Tian, "Discovering LDP Next- 386 Nexthop Labels", November 2005, . 389 Author's Address 391 Hannes Gredler 392 Juniper Networks, Inc. 393 1194 N. Mathilda Ave. 394 Sunnyvale, CA 94089 395 US 397 Email: hannes@juniper.net