idnits 2.17.1 draft-gredler-spring-mpls-02.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 5 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 384 has weird spacing: '...3), and pushe...' == Line 489 has weird spacing: '...4), and pushe...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 157, but not defined ** Obsolete undefined reference: RFC 1142 (Obsoleted by RFC 7142) == Missing Reference: 'RFC1583' is mentioned on line 158, 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 (~~), 6 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: April 2014 Yakov Rekhter 6 Juniper Networks 8 Luay Jalil 9 Verizon 11 Sriganesh Kini 12 Ericsson 14 October 21 2013 16 Supporting Source/Explicitly Routed Tunnels via Stacked LSPs 18 draft-gredler-spring-mpls-02.txt 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Abstract 57 This document describes how source/explicitly routed tunnels could be 58 realized using stacked Label Switched Paths (LSPs). 60 This document also describes how use of IS-IS/OSPF as a label 61 distribution protocol fits into the MPLS architecture. 63 Table of Contents 65 1 Specification of Requirements ......................... 3 66 2 Terminology ........................................... 3 67 3 Introduction .......................................... 4 68 4 Constructing Explicitly Routed Tunnels by using Stacked LSPs 5 69 4.1 Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 8 70 4.1.1 Explicitly Routed Tunnel with Single Hops ............. 8 71 4.1.2 Explicitly Routed Tunnel with Multi-Hops .............. 11 72 5 IS-IS or OSPF as Label Distribution Protocol .......... 13 73 5.1 Example of IS-IS/OSPF as Label Distribution Protocols . 14 74 6 IANA Considerations ................................... 15 75 7 Security Considerations ............................... 15 76 8 Acknowledgements ...................................... 15 77 9 Normative References .................................. 15 78 10 Informative References ................................ 16 79 11 Authors' Addresses .................................... 17 81 1. Specification of Requirements 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Terminology 89 We use the term "explicitly routed tunnels" as a synonym for such 90 terms as "source routed tunnels" and "source-initiated routed 91 tunnels". 93 Note that the term "source routed tunnel", or "source-initiated 94 routed tunnel" does not imply that intermediate nodes of such a 95 tunnel forward packets traversing the tunnel based upon source 96 addresses of these packets. In the context of "source routed tunnels" 97 and "source-initiated routed tunnels" the term "source" refers to the 98 tunnels' ingress. 100 This document assumes that a reader is familiar with the MPLS 101 architecture [RFC3031] terminology. 103 For a given Label Switched Path (LSP) of level m, as defined in 104 section 3.15 of [RFC3031]: 106 + the ingress node/router is the LSR that pushes the level m label, 108 + intermediate nodes/routers are the LSRs making their forwarding 109 decision on a level m label 111 3. Introduction 113 MPLS architecture [RFC3031] defines the concept of explicitly routed 114 tunnel as follows: 116 If a Tunneled Packet travels from Ru to Rd over a path other 117 than the Hop-by-hop path, we say that it is in an "Explicitly 118 Routed Tunnel" 120 where Ru and Rd are Label Switch Routers (LSRs). 122 To realize explicitly routed tunnels [RFC3031] proposes to use 123 explicitly routed Label Switched Paths (LSPs): 125 An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an 126 Explicitly Routed LSP 128 Up until now there have been two possible protocols to instantiate/signal 129 such explicitly routed LSPs - RSVP-TE ([RFC3209]) and CR-LDP 130 ([RFC3212]). 132 MPLS architecture ([RFC3031]) defines the notion of LSP hierarchy, 133 as LSP tunnels within LSPs. Use of MPLS label stack mechanism allows 134 LSP hierarchy to nest to any depth. 136 In this document we specify the procedures to realize explicitly 137 routed point-to-point tunnels by using LSP hierarchy, thus defining 138 yet another possible mechanism to realize such tunnels. (Note though 139 that the idea of using LSP hierarchy to realize explicitly routed 140 tunnels is not new - e.g., Remote LFA [R-LFA] uses explicitly routed 141 tunnels constructed by LSP hierarchy.) 143 An essential part of MPLS is the notion of label distribution 144 protocol. On the subject of whether it should be one, or more then 145 one label distribution protocol, MPLS architecture ([RFC3031]) said 146 the following: 148 THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE 149 LABEL DISTRIBUTION PROTOCOL. In fact, a number of different 150 label distribution protocols are being standardized. 152 Up until now IETF standardized the following label distribution 153 protocols for unicast: LDP ([RFC5036]), CR-LDP ([RFC3212]), RSVP-TE 154 [RFC3209] and BGP ([RFC3107], [RFC4364], [RFC4761]). 156 Recently there have been proposals ([gredler-isis], [gredler-ospf], 157 [previdi-isis], [psenak-ospf]) to extend IS-IS [RFC1142] and OSPF 158 [RFC1583] to make them yet another label distribution protocols. 160 This document describes how use of IS-IS or OSPF as label 161 distribution protocols fits into the MPLS architecture. This document 162 also describes the benefits of using IS-IS/OSPF as label distribution 163 protocols for the purpose of constructing explicitly routed tunnels 164 with stacked LSPs. 166 4. Constructing Explicitly Routed Tunnels by using Stacked LSPs 168 Instead of explicitly routed LSPs, one can use LSP hierarchy (stack 169 of LSPs) to construct explicitly routed point-to-point tunnels as 170 follows. 172 Consider an explicitly routed point-to-point tunnel with an explicit 173 route , where R(0) is the ingress of the 174 tunnel and R(n) is the egress of the tunnel. Denote the LSPs needed 175 to realize such a tunnel via an LSP stack as , where LSP(1) is the topmost and LSP(n) is the bottommost LSP 177 in the stack. These LSPs are constructed as follows: 179 + All the LSPs in the stack are constructed with the same ingress - 180 R(0). (See further down on why this is needed.) 182 + LSP(i) is constructed with R(i) as its egress (e.g., LSP(1) is 183 constructed with R(1) as its egress, LSP(2) with R(2) as its 184 egress, etc... LSP(n) with R(n) as its egress). 186 + For every 0 < i < n, the first intermediate router of LSP(i+1). 187 is constructed to be the same as the egress router of LSP(i). 189 + The first intermediate router of LSP(1) is constructed to be one 190 hop away from R(0). If R(1) is one hop away from R(0), then this 191 intermediate router is also the egress of LSP(1) (in which case 192 LSP(1) is a one-hop LSP). If R(1) is more than one hop away from 193 R(0), then this intermediate router is some router other than 194 R(1), and R(1) is still the egress of that LSP. 196 + The first intermediate router of any LSP in the stack, could be 197 either single or multi-hop away from the egress of that LSP. 199 + All the LSPs in the stack are constructed with the penultimate 200 hop popping. That is, for each LSP in the stack the penultimate 201 router of that LSP pops the label corresponding to that LSP off 202 the label stack before sending data to the egress router of that 203 LSP. 205 When R(i) and R(i+1) are single hop away from each other, the first 206 intermediate router of LSP(i+1) is one hop away from the egress of 207 that LSP. When R(i) and R(i+1) are multi-hop away from each other, 208 the first intermediate router of LSP(i+1) is multi-hop away from the 209 egress of that LSP. 211 Following the above procedures, the LSPs in the stack satisfy the 212 following properties: 214 + All LSPs in the stack have the same ingress. 216 + The egress of a given LSP in the stack is the first intermediate 217 router of the next LSP in the stack. 219 + The first intermediate router of the LSP at the top of the stack 220 is one hop away from the ingress. 222 + The first intermediate router of any LSP in the stack could be 223 either single or multi-hop away from the egress of that LSP. 224 (Thus the egress of a given LSP in the stack could be either 225 single or multi-hop away from the egress of the next LSP in the 226 stack.) 228 Such stack of LSPs provides the functionality to forward a packet 229 through a sequence of egresses of the LSPs on the stack - the 230 sequence of these egresses represents the explicit route of the 231 explicitly routed point-to-point tunnel constructed by using these 232 stacked LSPs. The ingress of all these LSPs is the ingress of the 233 tunnel. 235 When the first intermediate router of a given LSP in the stack is 236 multi-hop away from the egress of that LSP, the existing label 237 distribution protocols (LDP, RSVP-TE, etc. ) can be used to establish 238 a multi-hop LSP fragment for this LSP. When IS-IS or OSPF, in 239 addition to being a routing protocol, is also used as a label 240 distribution protocol (see section "IS-IS or OSPF as Label 241 Distribution Protocol"), it can also be used to establish such multi- 242 hop LSP fragment. 244 To construct the label stack associated with the stack of LSPs the 245 ingress of all these LSPs, R0, uses the following procedures: 247 + For (n > i > 0) R(0) obtains from R(i) label binding for LSP(i+1) 248 and places the label onto the stack, starting from the bottommost 249 label (the label that corresponds to LSP(n). 251 In section "IS-IS or OSPF as Label Distribution Protocol" we 252 describe how IS-IS or OSPF with appropriate extensions could be 253 used as a label distribution protocol to obtain such label 254 bindings. 256 If the first intermediate router of LSP(i+1) is either (a) a 257 single hop away from the egress of that LSP, or (b) multi-hop 258 away, and LDP is used as a label distribution protocol to 259 establish a multi-hop LSP fragment between the first intermediate 260 router and the egress of that LSP, then R(0) can use targeted LDP 261 session with R(i) to obtain such label bindings. 263 + For LSP(1) if R(1) is one hop away from R(0), then no label is 264 needed (as LSP(1), just like all other LSPs in the stack, is 265 constructed with the penultimate hop popping), and the label 266 stack construction terminates with the topmost label that R(0) 267 obtains from R(1) for LSP(2). 269 + Otherwise, if R(1) is more than one hop away from R(0), then R(0) 270 obtains label binding for LSP(1) from the first intermediate 271 router of LSP(1), and places this label at the top of the stack. 273 Note that the above procedures require all the LSPs in the stack to 274 have the same ingress - R(0). This requirement comes from the 275 observation that (a) R(0) is the router that constructs the whole 276 label stack needed to realize the explicitly routed tunnel, and (b) 277 according to MPLS architecture [RFC3031] when a router wants to 278 create a label stack, the router has to be the head-end of all the 279 LSPs corresponding to the labels in the stack. 281 Since the MPLS label stack mechanism allows stack of LSPs to nest to 282 any depth, use of LSP hierarchy for explicitly routed tunnels does 283 not place any protocol restrictions on the number of entries in the 284 explicit route of an explicitly routed tunnel. Note though that there 285 may be some other restrictions (e.g., due to MTU, or hardware) that 286 would place an upper bound on the depth of the label stack, and thus 287 on the number of entries in the explicit route. Also, the depth of 288 the label stack may have implications on ECMP, and specifically on 289 the use of the Entropy label (see [kini] for more). 291 4.1. Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 293 In this section we illustrate how to construct an explicitly routed 294 tunnel by using stacked LSPs. The first example illustrates this for 295 an explicitly routed tunnel where consecutive hops that define the 296 tunnel are one hop away from each other. The second example 297 illustrates this when these hops are more than one hop away from each 298 other. 300 4.1.1. Explicitly Routed Tunnel with Single Hops 302 Consider a network topology shown below: 304 R0-----R4 305 | /| 306 | / | 307 | / | 308 | / | 309 | / | 310 R1 R3 311 \ / 312 \ / 313 R2 315 Assume that R0 wants to construct an explicitly routed tunnel with 316 (R0, R1, R2, R3, R4). The consecutive hops that define the tunnel are 317 one hop away from each other. That is, R0 is one hop away from R1, R2 318 is one hop away from R1, R3 is one hop away from R2, and R4 is one 319 hop away from R3. 321 R0 constructs this tunnel using the following stack of LSPs: 323 LSP1: (R0, R1) - top of the stack 324 LSP2: (R0, R1, R2) 325 LSP3: (R0, R2, R3) 326 LSP4: (R0, R3, R4) - bottom of the stack 328 Note that this stack of LSPs meets the requirements specified in 329 section "Constructing Explicitly Routed Tunnels by using Stacked 330 LSPs". Specifically, 332 + All four LSPs in the stack have the same ingress - R0, which is 333 also the ingress of the explicitly routed tunnel. 335 + The egress of LSP1, R1, is the first intermediate router of the 336 next LSP in the stack, LSP2. The egress of LSP2, R2, is the first 337 intermediate router of the next LSP in the stack, LSP3. Likewise, 338 the egress of LSP3, R3, is the first intermediate router of the 339 next (and the last) LSP in the stack, LSP4. 341 + The LSP at the top of the stack, LSP1, has its first intermediate 342 router, R1, one hop away from its ingress, R0. Because of that, 343 this intermediate router is also the egress of that LSP, and that 344 LSP is a one-hop LSP. 346 + In that particular example the first intermediate router of every 347 LSP in the stack is one hop away from the egress of that LSP. 348 That is, the first intermediate router of LSP2, R1, is one hop 349 away from the egress of that LSP, R2; the first intermediate 350 router of LSP3, R2, is one hop away from the egress of that LSP, 351 R3; and the first intermediate router of LSP4, R3, is one hop 352 away from the egress of that LSP, R4. As a result, the egress of 353 a given LSP in the stack is one hop away from the egress of the 354 next LSP in the stack. 356 The first intermediate router of each of these LSPs creates label 357 bindings for these LSPs as follows. R3 creates label binding for LSP4 358 by binding a particular label, L1, to the address of R4, creating a 359 Next Hop Label Forwarding Entry (NHLFE) whose next hop is the link 360 from R3 to R4, and setting the Incoming Label Map (ILM) so that L1 361 maps to that NHLFE. Likewise, R2 creates label binding for LSP3 by 362 binding a particular label, L2, to the address of R3, creating an 363 NHLFE whose next hop is the link from R2 to R3, and setting the ILM 364 so that L2 maps to that NHLFE. Finally, R1 creates label binding for 365 LSP2 by binding a particular label, L3, to the address of R2, 366 creating an NHLFE whose next hop is the link from R1 to R2, and 367 setting the ILM so that L3 maps to that NHLFE. 369 To get from the first hop of LSP4, R0, to the second hop of LSP4, R3, 370 the packet has to go through the LSP tunnel provided by LSP3. To get 371 from the first hop of LSP3, R0, to the second hop of LSP3, R2, a 372 packet has to go through the LSP tunnel provided by LSP2. To get from 373 the first hop of LSP2, R0, to the second hop of LSP2, R1, a packet 374 has to go through the LSP tunnel provided by LSP1. 376 In order to accomplish this R0 constructs the label stack for the 377 explicitly routed tunnel as follows: 379 + Step 1: R0 obtains label binding L1 created by R3 for LSP4 (R0, 380 R3, R4), and starts building the label stack by pushing L1 onto 381 the label stack. 383 + Step 2: R0 obtains label binding L2 created by R2 for LSP3 (R0, 384 R2, R3), and pushes L2 into the stack. At this point the stack 385 contains (L2, L1). 387 + Step 3: R0 obtains label binding L3 created by R1 for LSP2 (R0, 388 R1, R2), and pushes L3 into the stack. At this point the stack 389 contains (L3, L2, L1). 391 + Step 4: Since R0 and R1 are one hop away from each other the 392 label stack construction is completed (R0 does not need a label 393 for one-hop LSP1, as all the LSPs use penultimate hop popping). 395 So far we did not say anything about how R0 obtains from R3 label 396 binding for LSP4, from R2 label binding for LSP3, and from R1 label 397 binding for LSP2. 399 At least in principle, these label bindings could be obtain by such 400 already defined label distribution protocols as LDP (to be more 401 precise, targeted LDP if the two routers are more than one hop away 402 from each other). E.g., if one uses targeted LDP, then R0 would need 403 to dynamically establish and maintain a targeted LDP session with R3 404 and another targeted LDP session with R2 (R0 would maintain a 405 "vanilla" LDP session with R1). Using these LDP sessions R0 would 406 obtain from R3 label binding for LSP4, from R2 label binding for 407 LSP3, and from R1 label binding for LSP2. Note that obtaining such 408 labels bindings with targeted LDP may also require defining a new FEC 409 to be used by targeted LDP. 411 In section "IS-IS or OSPF as Label Distribution Protocol" we describe 412 how IS-IS or OSPF with appropriate extensions could be used as a 413 label distribution protocol to obtain such label bindings. 415 When R0 wants to forward a packet along the explicitly constructed 416 tunnel (R0, R1, R2, R3, R4), R0 pushes (L3, L2, L1) onto the label 417 stack of the packet, and forwards the packet to R1. R1 performs the 418 lookup on the topmost label, L3, and based on this lookup forwards 419 the packet to R2. Prior to forwarding the packet to R2, R1 (acting as 420 a penultimate hop for LSP2) pops the topmost label, L3. When R2 421 receives the packet, R2 performs the lookup on the topmost label, L2, 422 and based on this lookup forwards the packet to R3. Prior to 423 forwarding the packet to R3, R2 (acting as a penultimate hop for 424 LSP3) pops the topmost label, L2. When R3 receives the packet, R3 425 performs the lookup on the topmost label, L1, and based on this 426 lookup forwards the packet to R4. Prior to forwarding the packet to 427 R4, R3 (acting as a penultimate hop for LSP4) pops the topmost label, 428 L1. 430 4.1.2. Explicitly Routed Tunnel with Multi-Hops 432 Consider a network topology shown below: 434 R0---R1 435 / \ 436 R2 R5---R6 437 \ / 438 R3---R4 440 Assume that R0 wants to construct an explicitly routed tunnel with 441 (R0, R4, R6) as hops. Note that R4 is multi-hop away from R0, and R6 442 is multi-hop away from R4. 444 R0 constructs this tunnel using the following stack of LSPs: 446 LSP1: (R0, R2, R3, R4) - top of the stack 447 LSP2: (R0, R4, R5, R6) - bottom of the stack 449 Note that this stack of LSPs meets the requirements specified in 450 section "Constructing Explicitly Routed Tunnels by using Stacked 451 LSPs". Specifically, 453 + Both LSPs in the stack have the same ingress - R0, which is also 454 the ingress of the explicitly routed tunnel. 456 + The egress of LSP1, R4, is the first intermediate router of the 457 next LSP in the stack, LSP2. 459 + The LSP at the top of the stack, LSP1, has its first intermediate 460 router, R2, one hop away from its ingress, R0. However, this 461 intermediate router is not the egress of that LSP, and therefore 462 this LSP is a multi-hop LSP. 464 + In that particular example the first intermediate router of every 465 LSP in the stack is multi-hop away from the egress of that LSP. 466 That is, the first intermediate router of LSP1, R2, is multi-hop 467 away from the egress of that LSP, R4; the first intermediate 468 router of LSP2, R4, is multi-hop away from the egress of that 469 LSP, R6. As a result, the egress of a given LSP in the stack is 470 multi-hop away from the egress of the next LSP in the stack. 472 In this example we assume that LDP is used as a label distribution 473 protocol for both LSP1 and LSP2. Since R0 and R4 are not IGP 474 neighbors, they are remote label distribution peers. Thus R0 and R4 475 use targeted LDP for label distribution. All other routers use 476 "vanilla" LDP procedures. 478 To get from the first hop of LSP2, R0, to its second hop, R4, the 479 packet has to go through the LSP tunnel provided by LSP1. 481 In order to accomplish this R0 constructs the label stack for the 482 explicitly routed tunnel as follows: 484 + Step 1: R0 (using targeted LDP) obtains label binding L1 created 485 by R4 for LSP2 (R0, R4, R5, R6), and starts building the label 486 stack by pushing L1 onto the label stack. 488 + Step 2: R0 (using "vanilla" LDP procedures) obtains label binding 489 L2 created by R2 for LSP1 (R0, R2, R3, R4), and pushes L2 into 490 the stack. At this point the stack contains (L2, L1). 492 + Step 3: Since R0 and R1 are one hop away from each other the 493 label stack construction is completed (R0 does not need a label 494 for one-hop LSP1). 496 A reader familiar with Remote LFA FRR [R-LFA] should be able to 497 notice that the example described in this section is nothing more 498 than an instance of Remote LFA FRR, where Remote LFA FRR provides 499 fast reroute to the traffic going from R0 to R6 in the presence of 500 the (R0, R2) link failure, with R0 being the Point of Local Repair 501 (PLR), R4 being the PQ-node, and R6 being the ultimate destination. 502 The explicitly routed tunnel (R0, R4, R6) consists of the PLR as the 503 head-node, the PQ-node as the next hop, and the ultimate destination 504 as yet another hop. 506 5. IS-IS or OSPF as Label Distribution Protocol 508 When OSPF or IS-IS, in addition to being a routing protocol, is also 509 used as a label distribution protocol (as proposed in [gredler-isis], 510 [gredler-ospf], [previdi-isis], [psenak-ospf), the OSPF/IS-IS Link 511 State Advertisements originated by a router carry label bindings for 512 LSPs that either transit or originated by the router. Doing this 513 allows to extend such LSPs. The criteria for selecting among all 514 these LSPs a subset for which the router would originate label 515 binding advertisements in IS-IS/OSPF are purely local to the router. 516 The router could be either single or multi-hop away from the egresses 517 of the LSPs in the subset. Existing label distribution protocols 518 (LDP, RSVP-TE, etc.) can be used to establish multi-hop LSP fragments 519 if the router is multi-hop away from the egress of a particular LSP 520 in the subset. When IS-IS or OSPF, in addition to being a routing 521 protocol, is also used as a label distribution protocol, it can also 522 be used to establish such multi-hop LSP fragments. 524 MPLS architecture [RFC3031] defines the notion of local/remote label 525 distribution peers as follows: 527 When two LSRs are IGP neighbors, we will refer to them as "local 528 label distribution peers". When two LSRs may be label distribution 529 peers, but are not IGP neighbors, we will refer to them as "remote 530 label distribution peers." 532 Following OSPF/IS-IS procedures each router passes Link State 533 Advertisements originated by other routers unmodified. When these 534 advertisements carry label binding information, this information is 535 also passed unmodified. Therefore, the router that originates label 536 bindings advertisements in IS-IS/OSPF can be either single or multi- 537 hop away from the routers that receive and use these bindings. In 538 the former case the IGP neighbors of the router that originates the 539 advertisements will be the local label distribution peers of the 540 router. In the latter case other routers in the same IGP domain will 541 be the remote label distribution peers of the router. 543 Use of OSPF or IS-IS as a label distribution protocol provides 544 scalable support for remote label distribution peering in terms of 545 the number of label distribution peers a given router has to 546 maintain. This is because label distribution protocol messages (Link 547 State Advertisements) are exchanged only between IGP neighbors, 548 without requiring control plane peering between a router that 549 originates Link State Advertisements and each of its remote label 550 distribution peers. 552 It is important to note that the existing MPLS control plane already 553 has mechanisms/protocols to support remote label distribution peering 554 (using BGP or targeted LDP [RFC5036]). Thus the practical relevance 555 of the ability to provide scalable support for remote label 556 distribution peering with IS-IS or OSPF as a label distribution 557 protocol depends on a particular use case. 559 If for a given subset of routers within an MPLS network each router 560 within the subset is assigned a distinct index, then one could 561 compress announcements of labels bound to the LSPs whose FECs are the 562 IP addresses of these routers by (a) advertising these indices in IS- 563 IS/OSPF, and (b) making each router advertise a label block in IS- 564 IS/OSPF as well. A router R1 that advertises a given label block 565 algorithmically binds a FEC associated with an IP address of some 566 other router R2 to the label from that block that is identified by 567 the index that R2 advertises in IGP. A router R1 that receives label 568 block originated by some other router R2 can determine the label 569 bound to a FEC associated with an IP address of some other router R3 570 by using the index advertised by R3 as an offset into the label block 571 advertised by R2. Note that to avoid wasting labels this scheme 572 requires a fairly dense assignment of indices. Also note that to 573 expand the number of labels that a router advertises using label 574 blocks, the router may advertise more than one label block. 576 Note though, that the benefits of scaling improvements in terms of 577 label distribution peering come at a cost, as every router in the 578 domain ends up keeping all the labels assigned/bounded by every other 579 router in the domain, whether it really needs to know them or not. 580 Whether this cost is of practical significance depends on (a) the 581 number of label bindings being advertised, and (b) the encoding of 582 label bindings (e.g., use of label blocks vs enumerating each label 583 binding). 585 5.1. Example of IS-IS/OSPF as Label Distribution Protocols 587 In this section we illustrate how IS-IS/OSPF with extensions, as 588 defined in [gredler-isis], [gredler-ospf], [previdi-isis], [psenak- 589 ospf] could be used as a label distribution protocol to support 590 explicitly routed tunnels realized by stacked LSPs. For the purpose 591 of this illustration we assume the scenario described in section 592 "Example of Constructing Explicitly Routed Tunnels by Stacked LSPs". 593 In that example one of the key issues is the ability of R0 to obtain 594 from R3 label binding for LSP4, from R2 label binding for LSP3, and 595 from R1 label binding for LSP2. 597 To obtains such label bindings, the Link State Advertisement 598 originated by R3 carries label L1 (this is the label that R3 binds to 599 LSP4). Using IS-IS/OSPF procedures this Link State Advertisement is 600 propagated by R2 and R1 (as well as by R4) to R0. This is how R0 601 obtains from R3 label binding for LSP4. In a similar fashion, the 602 Link State Advertisement originated by R2 carries label L2 (which is 603 the label that R2 binds to LSP3). Using IS-IS/OSPF procedures this 604 Link State Advertisement is propagated by R1 (as well as by R3 and 605 R4) to R0. This is how R0 obtains from R2 label binding for LSP3. 606 Likewise, the Link State Advertisement originated by R1 carries label 607 L3 (which is the label that R1 binds to LSP2). Using IS-IS/OSPF 608 procedures this Link State Advertisement is delivered to R0. This is 609 how R0 obtains from R1 label binding for LSP2. 611 Note that while from R0's perspective both R2 and R3 are remote label 612 distribution peers, R0 does not maintain any control plane peering 613 (e.g., targeted LDP) with either R2 or R3. 615 6. IANA Considerations 617 This document introduces no new IANA Considerations. 619 7. Security Considerations 621 TBD 623 8. Acknowledgements 625 We would like to thank John Drake (Juniper Networks) and John Scudder 626 (Juniper Networks) for their review and comments. 628 We would also like to thank Bruno Decraene (Orange) for his review 629 and comments. 631 9. Normative References 633 [RFC3031] Rosen, E., et. al., "Multiprotocol Label Switching 634 Architecture", RFC3031, January 2001 636 10. Informative References 638 [kini] Kini, S., et. al., "Entropy labels for source routed stacked 639 tunnels", draft-kini-mpls-entropy-label-src-stacked-tunnels, work in 640 progress 642 [gredler] Gredler, H., et. al., "Advertising MPLS labels in IGPs" 643 draft-gredler-rtgwg-igp-label-advertisement, work in progress 645 [gredler-isis] Gredler, H., et. al., "Advertising MPLS labels in IS- 646 IS" draft-gredler-isis-label-advertisement, work in progress 648 [gredler-ospf] Gredler, H., et. al., "Advertising MPLS labels in 649 OSPF" draft-gredler-ospf-label-advertisement, work in progress 651 [previdi-isis] Previdi, S., et. al., "IS-IS Extensions for Segment 652 Routing" draft-previdi-isis-segment-routing-extensions, work in 653 progress 655 [psenak-ospf] Psenak, P., et. al., "OSPF Extensions for Segment 656 Routing" draft-psenak-ospf-segment-routing-extensions, work in 657 progress 659 [R-LFA] Bryant, S., et. al., "Remote LFA FRR", draft-ietf-rtgwg- 660 remote-lfa, work in progress 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", RFC2119, March 1997 665 [RFC3107] Rekhter, Y., et. al., "Carrying Label Information in 666 BGP-4", RFC3107, May 2001 668 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 669 Tunnels", RFC3209, December 2001 671 [RFC3212] Jamoussi, B., et. al., "Constraint-Based LSP Setup using 672 LDP", RFC3212, January 2002 674 [RFC4364] Rosen E., et. al., "BGP/MPLS IP Virtual Private Networks 675 (VPNs)", RFC4364, February 2006 677 [RFC4761] Kompella, K., et. al., "Virtual Private LAN Service (VPLS) 678 Using BGP for Auto-Discovery and Signaling", RFC4761, January 2007 680 [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036, 681 October 2007 683 11. Authors' Addresses 685 Hannes Gredler 686 Juniper Networks 687 e-mail: hannes@juniper.net 689 Yakov Rekhter 690 Juniper Networks 691 e-mail: yakov@juniper.net 693 Luay Jalil 694 Verizon 695 e-mail: luay.jalil@verizon.com 697 Sriganesh Kini 698 Ericsson 699 Email: sriganesh.kini@ericsson.com