idnits 2.17.1 draft-gredler-spring-mpls-06.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 386 has weird spacing: '...3), and pushe...' == Line 491 has weird spacing: '...4), and pushe...' -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC1142' is mentioned on line 159, but not defined ** Obsolete undefined reference: RFC 1142 (Obsoleted by RFC 7142) == Missing Reference: 'RFC1583' is mentioned on line 160, but not defined ** Obsolete undefined reference: RFC 1583 (Obsoleted by RFC 2178) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hannes Gredler 3 Internet Draft Juniper Networks 4 Intended status: Standards Track 5 Expires: November 2014 Yakov Rekhter 6 Juniper Networks 8 Luay Jalil 9 Verizon 11 Sriganesh Kini 12 Ericsson 14 Xiaohu Xu 15 Huawei 17 May 21 2014 19 Supporting Source/Explicitly Routed Tunnels via Stacked LSPs 21 draft-gredler-spring-mpls-06.txt 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that other 30 groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Abstract 60 This document describes how source/explicitly routed tunnels could be 61 realized using stacked Label Switched Paths (LSPs). 63 This document also describes how use of IS-IS/OSPF as a label 64 distribution protocol fits into the MPLS architecture. 66 Table of Contents 68 1 Specification of Requirements ......................... 3 69 2 Terminology ........................................... 3 70 3 Introduction .......................................... 4 71 4 Constructing Explicitly Routed Tunnels by using Stacked LSPs 5 72 4.1 Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 8 73 4.1.1 Explicitly Routed Tunnel with Single Hops ............. 8 74 4.1.2 Explicitly Routed Tunnel with Multi-Hops .............. 11 75 5 IS-IS or OSPF as Label Distribution Protocol .......... 13 76 5.1 Example of IS-IS/OSPF as Label Distribution Protocols . 15 77 6 IANA Considerations ................................... 16 78 7 Security Considerations ............................... 16 79 8 Acknowledgements ...................................... 16 80 9 Normative References .................................. 16 81 10 Informative References ................................ 16 82 11 Authors' Addresses .................................... 17 84 1. Specification of Requirements 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Terminology 92 We use the term "explicitly routed tunnels" as a synonym for such 93 terms as "source routed tunnels" and "source-initiated routed 94 tunnels". 96 Note that the term "source routed tunnel", or "source-initiated 97 routed tunnel" does not imply that intermediate nodes of such a 98 tunnel forward packets traversing the tunnel based upon source 99 addresses of these packets. In the context of "source routed tunnels" 100 and "source-initiated routed tunnels" the term "source" refers to the 101 tunnels' ingress. 103 This document assumes that a reader is familiar with the MPLS 104 architecture [RFC3031] terminology. 106 For a given Label Switched Path (LSP) of level m, as defined in 107 section 3.15 of [RFC3031]: 109 + the ingress node/router is the LSR that pushes the level m label, 111 + intermediate nodes/routers are the LSRs making their forwarding 112 decision on a level m label 114 3. Introduction 116 MPLS architecture [RFC3031] defines the concept of explicitly routed 117 tunnel as follows: 119 If a Tunneled Packet travels from Ru to Rd over a path other 120 than the Hop-by-hop path, we say that it is in an "Explicitly 121 Routed Tunnel" 123 where Ru and Rd are Label Switch Routers (LSRs). 125 To realize explicitly routed tunnels [RFC3031] proposes to use 126 explicitly routed Label Switched Paths (LSPs): 128 An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an 129 Explicitly Routed LSP 131 Up until now there have been two possible protocols to instantiate/signal 132 such explicitly routed LSPs - RSVP-TE ([RFC3209]) and CR-LDP 133 ([RFC3212]). 135 MPLS architecture ([RFC3031]) defines the notion of LSP hierarchy, 136 as LSP tunnels within LSPs. Use of MPLS label stack mechanism allows 137 LSP hierarchy to nest to any depth. 139 In this document we specify the procedures to realize explicitly 140 routed point-to-point tunnels by using LSP hierarchy, thus defining 141 yet another possible mechanism to realize such tunnels. (Note though 142 that the idea of using LSP hierarchy to realize explicitly routed 143 tunnels is not new - e.g., Remote LFA [R-LFA] uses explicitly routed 144 tunnels constructed by LSP hierarchy.) 145 An essential part of MPLS is the notion of label distribution 146 protocol. On the subject of whether it should be one, or more then 147 one label distribution protocol, MPLS architecture ([RFC3031]) said 148 the following: 150 THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE 151 LABEL DISTRIBUTION PROTOCOL. In fact, a number of different 152 label distribution protocols are being standardized. 154 Up until now IETF standardized the following label distribution 155 protocols for unicast: LDP ([RFC5036]), CR-LDP ([RFC3212]), RSVP-TE 156 [RFC3209] and BGP ([RFC3107], [RFC4364], [RFC4761]). 158 Recently there have been proposals ([gredler-isis], [gredler-ospf], 159 [previdi-isis], [psenak-ospf]) to extend IS-IS [RFC1142] and OSPF 160 [RFC1583] to make them yet another label distribution protocols. 162 This document describes how use of IS-IS or OSPF as label 163 distribution protocols fits into the MPLS architecture. This document 164 also describes the benefits of using IS-IS/OSPF as label distribution 165 protocols for the purpose of constructing explicitly routed tunnels 166 with stacked LSPs. 168 4. Constructing Explicitly Routed Tunnels by using Stacked LSPs 170 Instead of explicitly routed LSPs, one can use LSP hierarchy (stack 171 of LSPs) to construct explicitly routed point-to-point tunnels as 172 follows. 174 Consider an explicitly routed point-to-point tunnel with an explicit 175 route , where R(0) is the ingress of the 176 tunnel and R(n) is the egress of the tunnel. Denote the LSPs needed 177 to realize such a tunnel via an LSP stack as , where LSP(1) is the topmost and LSP(n) is the bottommost LSP 179 in the stack. These LSPs are constructed as follows: 181 + All the LSPs in the stack are constructed with the same ingress - 182 R(0). (See further down on why this is needed.) 184 + LSP(i) is constructed with R(i) as its egress (e.g., LSP(1) is 185 constructed with R(1) as its egress, LSP(2) with R(2) as its 186 egress, etc... LSP(n) with R(n) as its egress). 188 + For every 0 < i < n, the first intermediate router of LSP(i+1). 189 is constructed to be the same as the egress router of LSP(i). 191 + The first intermediate router of LSP(1) is constructed to be one 192 hop away from R(0). If R(1) is one hop away from R(0), then this 193 intermediate router is also the egress of LSP(1) (in which case 194 LSP(1) is a one-hop LSP). If R(1) is more than one hop away from 195 R(0), then this intermediate router is some router other than 196 R(1), and R(1) is still the egress of that LSP. 198 + The first intermediate router of any LSP in the stack, could be 199 either single or multi-hop away from the egress of that LSP. 201 + All the LSPs in the stack are constructed with the penultimate 202 hop popping. That is, for each LSP in the stack the penultimate 203 router of that LSP pops the label corresponding to that LSP off 204 the label stack before sending data to the egress router of that 205 LSP. 207 When R(i) and R(i+1) are single hop away from each other, the first 208 intermediate router of LSP(i+1) is one hop away from the egress of 209 that LSP. When R(i) and R(i+1) are multi-hop away from each other, 210 the first intermediate router of LSP(i+1) is multi-hop away from the 211 egress of that LSP. 213 Following the above procedures, the LSPs in the stack satisfy the 214 following properties: 216 + All LSPs in the stack have the same ingress. 218 + The egress of a given LSP in the stack is the first intermediate 219 router of the next LSP in the stack. 221 + The first intermediate router of the LSP at the top of the stack 222 is one hop away from the ingress. 224 + The first intermediate router of any LSP in the stack could be 225 either single or multi-hop away from the egress of that LSP. 226 (Thus the egress of a given LSP in the stack could be either 227 single or multi-hop away from the egress of the next LSP in the 228 stack.) 230 Such stack of LSPs provides the functionality to forward a packet 231 through a sequence of egresses of the LSPs on the stack - the 232 sequence of these egresses represents the explicit route of the 233 explicitly routed point-to-point tunnel constructed by using these 234 stacked LSPs. The ingress of all these LSPs is the ingress of the 235 tunnel. 237 When the first intermediate router of a given LSP in the stack is 238 multi-hop away from the egress of that LSP, the existing label 239 distribution protocols (LDP, RSVP-TE, etc. ) can be used to establish 240 a multi-hop LSP fragment for this LSP. When IS-IS or OSPF, in 241 addition to being a routing protocol, is also used as a label 242 distribution protocol (see section "IS-IS or OSPF as Label 243 Distribution Protocol"), it can also be used to establish such multi- 244 hop LSP fragment. 246 To construct the label stack associated with the stack of LSPs the 247 ingress of all these LSPs, R0, uses the following procedures: 249 + For (n > i > 0) R(0) obtains from R(i) label binding for LSP(i+1) 250 and places the label onto the stack, starting from the bottommost 251 label (the label that corresponds to LSP(n). 253 In section "IS-IS or OSPF as Label Distribution Protocol" we 254 describe how IS-IS or OSPF with appropriate extensions could be 255 used as a label distribution protocol to obtain such label 256 bindings. 258 If the first intermediate router of LSP(i+1) is either (a) a 259 single hop away from the egress of that LSP, or (b) multi-hop 260 away, and LDP is used as a label distribution protocol to 261 establish a multi-hop LSP fragment between the first intermediate 262 router and the egress of that LSP, then R(0) can use targeted LDP 263 session with R(i) to obtain such label bindings. 265 + For LSP(1) if R(1) is one hop away from R(0), then no label is 266 needed (as LSP(1), just like all other LSPs in the stack, is 267 constructed with the penultimate hop popping), and the label 268 stack construction terminates with the topmost label that R(0) 269 obtains from R(1) for LSP(2). 271 + Otherwise, if R(1) is more than one hop away from R(0), then R(0) 272 obtains label binding for LSP(1) from the first intermediate 273 router of LSP(1), and places this label at the top of the stack. 275 Note that the above procedures require all the LSPs in the stack to 276 have the same ingress - R(0). This requirement comes from the 277 observation that (a) R(0) is the router that constructs the whole 278 label stack needed to realize the explicitly routed tunnel, and (b) 279 according to MPLS architecture [RFC3031] when a router wants to 280 create a label stack, the router has to be the head-end of all the 281 LSPs corresponding to the labels in the stack. 283 Since the MPLS label stack mechanism allows stack of LSPs to nest to 284 any depth, use of LSP hierarchy for explicitly routed tunnels does 285 not place any protocol restrictions on the number of entries in the 286 explicit route of an explicitly routed tunnel. Note though that there 287 may be some other restrictions (e.g., due to MTU, or hardware) that 288 would place an upper bound on the depth of the label stack, and thus 289 on the number of entries in the explicit route. Also, the depth of 290 the label stack may have implications on ECMP, and specifically on 291 the use of the Entropy label (see [kini] for more). 293 4.1. Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 295 In this section we illustrate how to construct an explicitly routed 296 tunnel by using stacked LSPs. The first example illustrates this for 297 an explicitly routed tunnel where consecutive hops that define the 298 tunnel are one hop away from each other. The second example 299 illustrates this when these hops are more than one hop away from each 300 other. 302 4.1.1. Explicitly Routed Tunnel with Single Hops 304 Consider a network topology shown below: 306 R0-----R4 307 | /| 308 | / | 309 | / | 310 | / | 311 | / | 312 R1 R3 313 \ / 314 \ / 315 R2 317 Assume that R0 wants to construct an explicitly routed tunnel with 318 (R0, R1, R2, R3, R4). The consecutive hops that define the tunnel are 319 one hop away from each other. That is, R0 is one hop away from R1, R2 320 is one hop away from R1, R3 is one hop away from R2, and R4 is one 321 hop away from R3. 323 R0 constructs this tunnel using the following stack of LSPs: 325 LSP1: (R0, R1) - top of the stack 326 LSP2: (R0, R1, R2) 327 LSP3: (R0, R2, R3) 328 LSP4: (R0, R3, R4) - bottom of the stack 330 Note that this stack of LSPs meets the requirements specified in 331 section "Constructing Explicitly Routed Tunnels by using Stacked 332 LSPs". Specifically, 334 + All four LSPs in the stack have the same ingress - R0, which is 335 also the ingress of the explicitly routed tunnel. 337 + The egress of LSP1, R1, is the first intermediate router of the 338 next LSP in the stack, LSP2. The egress of LSP2, R2, is the first 339 intermediate router of the next LSP in the stack, LSP3. Likewise, 340 the egress of LSP3, R3, is the first intermediate router of the 341 next (and the last) LSP in the stack, LSP4. 343 + The LSP at the top of the stack, LSP1, has its first intermediate 344 router, R1, one hop away from its ingress, R0. Because of that, 345 this intermediate router is also the egress of that LSP, and that 346 LSP is a one-hop LSP. 348 + In that particular example the first intermediate router of every 349 LSP in the stack is one hop away from the egress of that LSP. 350 That is, the first intermediate router of LSP2, R1, is one hop 351 away from the egress of that LSP, R2; the first intermediate 352 router of LSP3, R2, is one hop away from the egress of that LSP, 353 R3; and the first intermediate router of LSP4, R3, is one hop 354 away from the egress of that LSP, R4. As a result, the egress of 355 a given LSP in the stack is one hop away from the egress of the 356 next LSP in the stack. 358 The first intermediate router of each of these LSPs creates label 359 bindings for these LSPs as follows. R3 creates label binding for LSP4 360 by binding a particular label, L1, to the address of R4, creating a 361 Next Hop Label Forwarding Entry (NHLFE) whose next hop is the link 362 from R3 to R4, and setting the Incoming Label Map (ILM) so that L1 363 maps to that NHLFE. Likewise, R2 creates label binding for LSP3 by 364 binding a particular label, L2, to the address of R3, creating an 365 NHLFE whose next hop is the link from R2 to R3, and setting the ILM 366 so that L2 maps to that NHLFE. Finally, R1 creates label binding for 367 LSP2 by binding a particular label, L3, to the address of R2, 368 creating an NHLFE whose next hop is the link from R1 to R2, and 369 setting the ILM so that L3 maps to that NHLFE. 371 To get from the first hop of LSP4, R0, to the second hop of LSP4, R3, 372 the packet has to go through the LSP tunnel provided by LSP3. To get 373 from the first hop of LSP3, R0, to the second hop of LSP3, R2, a 374 packet has to go through the LSP tunnel provided by LSP2. To get from 375 the first hop of LSP2, R0, to the second hop of LSP2, R1, a packet 376 has to go through the LSP tunnel provided by LSP1. 378 In order to accomplish this R0 constructs the label stack for the 379 explicitly routed tunnel as follows: 381 + Step 1: R0 obtains label binding L1 created by R3 for LSP4 (R0, 382 R3, R4), and starts building the label stack by pushing L1 onto 383 the label stack. 385 + Step 2: R0 obtains label binding L2 created by R2 for LSP3 (R0, 386 R2, R3), and pushes L2 into the stack. At this point the stack 387 contains (L2, L1). 389 + Step 3: R0 obtains label binding L3 created by R1 for LSP2 (R0, 390 R1, R2), and pushes L3 into the stack. At this point the stack 391 contains (L3, L2, L1). 393 + Step 4: Since R0 and R1 are one hop away from each other the 394 label stack construction is completed (R0 does not need a label 395 for one-hop LSP1, as all the LSPs use penultimate hop popping). 397 So far we did not say anything about how R0 obtains from R3 label 398 binding for LSP4, from R2 label binding for LSP3, and from R1 label 399 binding for LSP2. 401 At least in principle, these label bindings could be obtain by such 402 already defined label distribution protocols as LDP (to be more 403 precise, targeted LDP if the two routers are more than one hop away 404 from each other). E.g., if one uses targeted LDP, then R0 would need 405 to dynamically establish and maintain a targeted LDP session with R3 406 and another targeted LDP session with R2 (R0 would maintain a 407 "vanilla" LDP session with R1). Using these LDP sessions R0 would 408 obtain from R3 label binding for LSP4, from R2 label binding for 409 LSP3, and from R1 label binding for LSP2. Note that obtaining such 410 labels bindings with targeted LDP may also require defining a new FEC 411 to be used by targeted LDP. 413 In section "IS-IS or OSPF as Label Distribution Protocol" we describe 414 how IS-IS or OSPF with appropriate extensions could be used as a 415 label distribution protocol to obtain such label bindings. 417 When R0 wants to forward a packet along the explicitly constructed 418 tunnel (R0, R1, R2, R3, R4), R0 pushes (L3, L2, L1) onto the label 419 stack of the packet, and forwards the packet to R1. R1 performs the 420 lookup on the topmost label, L3, and based on this lookup forwards 421 the packet to R2. Prior to forwarding the packet to R2, R1 (acting as 422 a penultimate hop for LSP2) pops the topmost label, L3. When R2 423 receives the packet, R2 performs the lookup on the topmost label, L2, 424 and based on this lookup forwards the packet to R3. Prior to 425 forwarding the packet to R3, R2 (acting as a penultimate hop for 426 LSP3) pops the topmost label, L2. When R3 receives the packet, R3 427 performs the lookup on the topmost label, L1, and based on this 428 lookup forwards the packet to R4. Prior to forwarding the packet to 429 R4, R3 (acting as a penultimate hop for LSP4) pops the topmost label, 430 L1. 432 4.1.2. Explicitly Routed Tunnel with Multi-Hops 434 Consider a network topology shown below: 436 R0---R1 437 / \ 438 R2 R5---R6 439 \ / 440 R3---R4 442 Assume that R0 wants to construct an explicitly routed tunnel with 443 (R0, R4, R6) as hops. Note that R4 is multi-hop away from R0, and R6 444 is multi-hop away from R4. 446 R0 constructs this tunnel using the following stack of LSPs: 448 LSP1: (R0, R2, R3, R4) - top of the stack 449 LSP2: (R0, R4, R5, R6) - bottom of the stack 451 Note that this stack of LSPs meets the requirements specified in 452 section "Constructing Explicitly Routed Tunnels by using Stacked 453 LSPs". Specifically, 455 + Both LSPs in the stack have the same ingress - R0, which is also 456 the ingress of the explicitly routed tunnel. 458 + The egress of LSP1, R4, is the first intermediate router of the 459 next LSP in the stack, LSP2. 461 + The LSP at the top of the stack, LSP1, has its first intermediate 462 router, R2, one hop away from its ingress, R0. However, this 463 intermediate router is not the egress of that LSP, and therefore 464 this LSP is a multi-hop LSP. 466 + In that particular example the first intermediate router of every 467 LSP in the stack is multi-hop away from the egress of that LSP. 468 That is, the first intermediate router of LSP1, R2, is multi-hop 469 away from the egress of that LSP, R4; the first intermediate 470 router of LSP2, R4, is multi-hop away from the egress of that 471 LSP, R6. As a result, the egress of a given LSP in the stack is 472 multi-hop away from the egress of the next LSP in the stack. 474 In this example we assume that LDP is used as a label distribution 475 protocol for both LSP1 and LSP2. Since R0 and R4 are not IGP 476 neighbors, they are remote label distribution peers. Thus R0 and R4 477 use targeted LDP for label distribution. All other routers use 478 "vanilla" LDP procedures. 480 To get from the first hop of LSP2, R0, to its second hop, R4, the 481 packet has to go through the LSP tunnel provided by LSP1. 483 In order to accomplish this R0 constructs the label stack for the 484 explicitly routed tunnel as follows: 486 + Step 1: R0 (using targeted LDP) obtains label binding L1 created 487 by R4 for LSP2 (R0, R4, R5, R6), and starts building the label 488 stack by pushing L1 onto the label stack. 490 + Step 2: R0 (using "vanilla" LDP procedures) obtains label binding 491 L2 created by R2 for LSP1 (R0, R2, R3, R4), and pushes L2 into 492 the stack. At this point the stack contains (L2, L1). 494 + Step 3: Since R0 and R1 are one hop away from each other the 495 label stack construction is completed (R0 does not need a label 496 for one-hop LSP1). 498 A reader familiar with Remote LFA FRR [R-LFA] should be able to 499 notice that the example described in this section is nothing more 500 than an instance of Remote LFA FRR, where Remote LFA FRR provides 501 fast reroute to the traffic going from R0 to R6 in the presence of 502 the (R0, R2) link failure, with R0 being the Point of Local Repair 503 (PLR), R4 being the PQ-node, and R6 being the ultimate destination. 504 The explicitly routed tunnel (R0, R4, R6) consists of the PLR as the 505 head-node, the PQ-node as the next hop, and the ultimate destination 506 as yet another hop. 508 5. IS-IS or OSPF as Label Distribution Protocol 510 When OSPF or IS-IS, in addition to being a routing protocol, is also 511 used as a label distribution protocol (as proposed in [gredler-isis], 512 [gredler-ospf], [previdi-isis], [psenak-ospf), the OSPF/IS-IS Link 513 State Advertisements originated by a router carry label bindings for 514 LSPs that either transit or originated by the router. Doing this 515 allows to extend such LSPs. The criteria for selecting among all 516 these LSPs a subset for which the router would originate label 517 binding advertisements in IS-IS/OSPF are purely local to the router. 518 The router could be either single or multi-hop away from the egresses 519 of the LSPs in the subset. Existing label distribution protocols 520 (LDP, RSVP-TE, etc.) can be used to establish multi-hop LSP fragments 521 if the router is multi-hop away from the egress of a particular LSP 522 in the subset. When IS-IS or OSPF, in addition to being a routing 523 protocol, is also used as a label distribution protocol, it can also 524 be used to establish such multi-hop LSP fragments. 526 Use of IS-IS or OSPF as a label distribution protocol supports 527 advertisements of label mappings for such FECs as: 529 + IPv4/IPv6 prefix FEC via a hop-by-hop LSP established using IS- 530 IS/OSPF as a label distribution protocol. 532 + IPv4/IPv6 prefix FEC via a hop-by-hop LSP established using LDP 533 as a label distribution protocol. 535 + IPv4/IPv6 address FEC where the address identifies the remote end 536 of one of the advertising router's links via an LSP that 537 traverses the link and terminates on the remote end of the link. 539 + IPv4/IPv6 address FEC where the address identifies the remote end 540 of one of the advertising router's point-to-point links via an 541 LSP that traverses the link and terminates on the remote end of 542 the link. 544 + IPv4/IPv6 address FEC where the address identifies a (remote) 545 router connected to the advertising router by a broadcast link 546 via an LSP that traverses the link and terminates on the remote 547 router identified by its node-id. 549 + IPv4/IPv6 prefix FEC via an explicitly routed LSP established 550 using RSVP-TE, where path computation for such LSP is done by 551 either distributed CSPF, or by PCE. 553 When a router obtains label binding for a given FEC from more than 554 one label distribution protocol (e.g., one binding from targeted LDP 555 and another from IS-IS/OSPF), deciding which label binding to use is 556 a matter of policy local to the router. In the scenario where a 557 router obtains label binding for a given FEC from both (targeted) LDP 558 and IS-IS/OSPF, the default behavior RECOMMENDED in this document is 559 to prefer the one obtained from (targeted) LDP. An implementation 560 MUST support the ability to override the default behavior via 561 configuration. 563 MPLS architecture [RFC3031] defines the notion of local/remote label 564 distribution peers as follows: 566 When two LSRs are IGP neighbors, we will refer to them as "local 567 label distribution peers". When two LSRs may be label distribution 568 peers, but are not IGP neighbors, we will refer to them as "remote 569 label distribution peers." 571 Following OSPF/IS-IS procedures each router passes Link State 572 Advertisements originated by other routers unmodified. When these 573 advertisements carry label binding information, this information is 574 also passed unmodified. Therefore, the router that originates label 575 bindings advertisements in IS-IS/OSPF can be either single or multi- 576 hop away from the routers that receive and use these bindings. In 577 the former case the IGP neighbors of the router that originates the 578 advertisements will be the local label distribution peers of the 579 router. In the latter case other routers in the same IGP domain will 580 be the remote label distribution peers of the router. 582 Use of OSPF or IS-IS as a label distribution protocol provides 583 scalable support for remote label distribution peering in terms of 584 the number of label distribution peers a given router has to 585 maintain. This is because label distribution protocol messages (Link 586 State Advertisements) are exchanged only between IGP neighbors, 587 without requiring control plane peering between a router that 588 originates Link State Advertisements and each of its remote label 589 distribution peers. 591 It is important to note that the existing MPLS control plane already 592 has mechanisms/protocols to support remote label distribution peering 593 (using BGP or targeted LDP [RFC5036]). Thus the practical relevance 594 of the ability to provide scalable support for remote label 595 distribution peering with IS-IS or OSPF as a label distribution 596 protocol depends on a particular use case. 598 If for a given subset of routers within an MPLS network each router 599 within the subset is assigned a distinct index, then one could 600 compress announcements of labels bound to the LSPs whose FECs are the 601 IP addresses of these routers by (a) advertising these indices in IS- 602 IS/OSPF, and (b) making each router advertise a label block in IS- 603 IS/OSPF as well. A router R1 that advertises a given label block 604 algorithmically binds a FEC associated with an IP address of some 605 other router R2 to the label from that block that is identified by 606 the index that R2 advertises in IGP. A router R1 that receives label 607 block originated by some other router R2 can determine the label 608 bound to a FEC associated with an IP address of some other router R3 609 by using the index advertised by R3 as an offset into the label block 610 advertised by R2. Note that to avoid wasting labels this scheme 611 requires a fairly dense assignment of indices. Also note that to 612 expand the number of labels that a router advertises using label 613 blocks, the router may advertise more than one label block. 615 Note though, that the benefits of scaling improvements in terms of 616 label distribution peering come at a cost, as every router in the 617 domain ends up keeping all the labels assigned/bounded by every other 618 router in the domain, whether it really needs to know them or not. 619 Whether this cost is of practical significance depends on (a) the 620 number of label bindings being advertised, and (b) the encoding of 621 label bindings (e.g., use of label blocks vs enumerating each label 622 binding). 624 5.1. Example of IS-IS/OSPF as Label Distribution Protocols 626 In this section we illustrate how IS-IS/OSPF with extensions, as 627 defined in [gredler-isis], [gredler-ospf], [previdi-isis], [psenak- 628 ospf] could be used as a label distribution protocol to support 629 explicitly routed tunnels realized by stacked LSPs. For the purpose 630 of this illustration we assume the scenario described in section 631 "Example of Constructing Explicitly Routed Tunnels by Stacked LSPs". 632 In that example one of the key issues is the ability of R0 to obtain 633 from R3 label binding for LSP4, from R2 label binding for LSP3, and 634 from R1 label binding for LSP2. 636 To obtains such label bindings, the Link State Advertisement 637 originated by R3 carries label L1 (this is the label that R3 binds to 638 LSP4). Using IS-IS/OSPF procedures this Link State Advertisement is 639 propagated by R2 and R1 (as well as by R4) to R0. This is how R0 640 obtains from R3 label binding for LSP4. In a similar fashion, the 641 Link State Advertisement originated by R2 carries label L2 (which is 642 the label that R2 binds to LSP3). Using IS-IS/OSPF procedures this 643 Link State Advertisement is propagated by R1 (as well as by R3 and 644 R4) to R0. This is how R0 obtains from R2 label binding for LSP3. 645 Likewise, the Link State Advertisement originated by R1 carries label 646 L3 (which is the label that R1 binds to LSP2). Using IS-IS/OSPF 647 procedures this Link State Advertisement is delivered to R0. This is 648 how R0 obtains from R1 label binding for LSP2. 650 Note that while from R0's perspective both R2 and R3 are remote label 651 distribution peers, R0 does not maintain any control plane peering 652 (e.g., targeted LDP) with either R2 or R3. 654 6. IANA Considerations 656 This document introduces no new IANA Considerations. 658 7. Security Considerations 660 TBD 662 8. Acknowledgements 664 We would like to thank John Drake (Juniper Networks) and John Scudder 665 (Juniper Networks) for their review and comments. 667 We would also like to thank Bruno Decraene (Orange) and Robert Raszuk 668 for their review and comments. 670 9. Normative References 672 [RFC3031] Rosen, E., et. al., "Multiprotocol Label Switching 673 Architecture", RFC3031, January 2001 675 10. Informative References 677 [kini] Kini, S., et. al., "Entropy labels for source routed stacked 678 tunnels", draft-kini-mpls-entropy-label-src-stacked-tunnels, work in 679 progress 681 [gredler] Gredler, H., et. al., "Advertising MPLS labels in IGPs" 682 draft-gredler-rtgwg-igp-label-advertisement, work in progress 684 [gredler-isis] Gredler, H., et. al., "Advertising MPLS labels in IS- 685 IS" draft-gredler-isis-label-advertisement, work in progress 687 [gredler-ospf] Gredler, H., et. al., "Advertising MPLS labels in 688 OSPF" draft-gredler-ospf-label-advertisement, work in progress 690 [previdi-isis] Previdi, S., et. al., "IS-IS Extensions for Segment 691 Routing" draft-previdi-isis-segment-routing-extensions, work in 692 progress 694 [psenak-ospf] Psenak, P., et. al., "OSPF Extensions for Segment 695 Routing" draft-psenak-ospf-segment-routing-extensions, work in 696 progress 698 [R-LFA] Bryant, S., et. al., "Remote LFA FRR", draft-ietf-rtgwg- 699 remote-lfa, work in progress 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", RFC2119, March 1997 704 [RFC3107] Rekhter, Y., et. al., "Carrying Label Information in 705 BGP-4", RFC3107, May 2001 707 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 708 Tunnels", RFC3209, December 2001 710 [RFC3212] Jamoussi, B., et. al., "Constraint-Based LSP Setup using 711 LDP", RFC3212, January 2002 713 [RFC4364] Rosen E., et. al., "BGP/MPLS IP Virtual Private Networks 714 (VPNs)", RFC4364, February 2006 716 [RFC4761] Kompella, K., et. al., "Virtual Private LAN Service (VPLS) 717 Using BGP for Auto-Discovery and Signaling", RFC4761, January 2007 719 [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036, 720 October 2007 722 11. Authors' Addresses 724 Hannes Gredler 725 Juniper Networks 726 e-mail: hannes@juniper.net 728 Yakov Rekhter 729 Juniper Networks 730 e-mail: yakov@juniper.net 732 Luay Jalil 733 Verizon 734 e-mail: luay.jalil@verizon.com 736 Sriganesh Kini 737 Ericsson 738 Email: sriganesh.kini@ericsson.com 740 Xiaohu Xu 741 Huawei Technologies, 742 Email: xuxiaohu@huawei.com