idnits 2.17.1 draft-gredler-spring-mpls-00.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 344 has weird spacing: '...3), and pushe...' == Line 431 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 137, but not defined ** Obsolete undefined reference: RFC 1142 (Obsoleted by RFC 7142) == Missing Reference: 'RFC1583' is mentioned on line 138, 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 October 1 2013 10 Supporting Source/Explicitly Routed Tunnels via Stacked LSPs 12 draft-gredler-spring-mpls-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document describes how source/explicitly routed tunnels could be 52 realized using stacked Label Switched Paths (LSPs). 54 This document also describes how use of IS-IS/OSPF as a label 55 distribution protocol fits into the MPLS architecture. 57 Table of Contents 59 1 Specification of Requirements ......................... 3 60 2 Terminology ........................................... 4 61 3 Introduction .......................................... 4 62 4 Constructing Explicitly Routed Tunnels by using Stacked LSPs 5 63 4.1 Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 7 64 4.1.1 Explicitly Routed Tunnel with Strict Hops ............. 8 65 4.1.2 Explicitly Routed Tunnel with Loose Hops .............. 10 66 5 IS-IS or OSPF as Label Distribution Protocol .......... 12 67 5.1 Example of IS-IS/OSPF as Label Distribution Protocols . 13 68 6 IANA Considerations ................................... 14 69 7 Security Considerations ............................... 14 70 8 Acknowledgements ...................................... 14 71 9 Normative References .................................. 14 72 10 Informative References ................................ 14 73 11 Authors' Addresses .................................... 15 75 1. Specification of Requirements 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 2. Terminology 83 We use the term "explicitly routed tunnels" as a synonym for such 84 terms as "source routed tunnels" and "source-initiated routed 85 tunnels". 87 Note that the term "source routed tunnel", or "source-initiated 88 routed tunnel" does not imply that intermediate nodes of such a 89 tunnel forward packets traversing the tunnel based upon source 90 addresses of these packets. In the context of "source routed tunnels" 91 and "source-initiated routed tunnels" the term "source" refers to the 92 tunnels' ingress. 94 3. Introduction 96 MPLS architecture [RFC3031] defines the concept of explicitly routed 97 tunnel as follows: 99 If a Tunneled Packet travels from Ru to Rd over a path other 100 than the Hop-by-hop path, we say that it is in an "Explicitly 101 Routed Tunnel" 103 where Ru and Rd are Label Switch Routers (LSRs). 105 To realize explicitly routed tunnels [RFC3031] proposes to use 106 explicitly routed LSPs: 108 An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an 109 Explicitly Routed LSP 111 Up until now there have been two possible protocols to instantiate/signal 112 such explicitly routed LSPs - RSVP-TE ([RFC3209]) and CR-LDP 113 ([RFC3212]). 115 MPLS architecture ([RFC3031]) defines the notion of LSP hierarchy, 116 as LSP tunnels within LSPs. Use of MPLS label stack mechanism allows 117 LSP hierarchy to nest to any depth. 119 In this document we specify the procedures to realize explicitly 120 routed point-to-point tunnels by using LSP hierarchy, thus defining 121 yet another possible mechanism to realize such tunnels. 123 An essential part of MPLS is the notion of label distribution 124 protocol. On the subject of whether it should be one, or more then 125 one label distribution protocol, MPLS architecture ([RFC3031]) said 126 the following: 128 THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE 129 LABEL DISTRIBUTION PROTOCOL. In fact, a number of different 130 label distribution protocols are being standardized. 132 Up until now IETF standardized the following label distribution 133 protocols for unicast: LDP ([RFC5036]), CR-LDP ([RFC3212]), RSVP-TE 134 [RFC3209] and BGP ([RFC3107], [RFC4364], [RFC4761]). 136 Recently there have been proposals ([gredler-isis], [gredler-ospf], 137 [previdi-isis], [psenak-ospf]) to extend IS-IS [RFC1142] and OSPF 138 [RFC1583] to make them yet another label distribution protocols. 140 This document describes how use of IS-IS or OSPF as label 141 distribution protocols fits into the MPLS architecture. This document 142 also describes the benefits of using IS-IS/OSPF as label distribution 143 protocols for the purpose of constructing explicitly routed tunnels 144 with stacked LSPs. 146 4. Constructing Explicitly Routed Tunnels by using Stacked LSPs 148 Instead of explicitly routed LSPs, one can use LSP hierarchy (stack 149 of LSPs) to construct explicitly routed point-to-point tunnels as 150 follows. 152 Consider an explicitly routed point-to-point tunnel with an explicit 153 route , where R(0) is the ingress of the 154 tunnel and R(n) is the egress of the tunnel. Denote the LSPs needed 155 to realize such a tunnel via an LSP stack as , where LSP(1) is the topmost and LSP(n) is the bottommost LSP 157 in the stack. These LSPs are constructed as follows: 159 + All the LSPs in the stack are constructed with the same ingress - 160 R(0). 162 + LSP(i) is constructed with R(i) as its egress (e.g., LSP(1) is 163 constructed with R(1) as its egress, LSP(2) with R(2) as its 164 egress, etc... LSP(n) with R(n) as its egress). 166 + For every 0 < i < n, the first intermediate point of LSP(i+1). 167 is constructed to be the egress of LSP(i). 169 + The first intermediate point of LSP(1) is constructed to be one 170 hop away from R(0). If R(1) is one hop away from R(0), then this 171 intermediate point is also the egress of LSP(1) (in which case 172 LSP(1) is a one-hop LSP). If R(1) is more than one hop away from 173 R(0), then this intermediate point is some router other than 174 R(1), and R(1) is still the egress of that LSP. 176 + The first intermediate point of any LSP in the stack, could be 177 either single or multi-hop away from the egress of that LSP. 179 When R(i) and R(i+1) are single hop away from each other, this 180 corresponds to a strict hop for the explicitly routed tunnel, in 181 which case the first intermediate point of LSP(i+1) is one hop away 182 from the egress of that LSP. When R(i) and R(i+1) are multi-hop away 183 from each other, this corresponds to a loose hop for the explicitly 184 routed tunnel, in which case the first intermediate point of LSP(i+1) 185 is multi-hop away from the egress of that LSP. 187 Following the above procedures, the LSPs in the stack satisfy the 188 following properties: 190 + All LSPs in the stack have the same ingress. 192 + The egress of a given LSP in the stack is the first intermediate 193 point of the next LSP in the stack. 195 + The first intermediate point of the LSP at the top of the stack 196 is one hop away from the ingress. 198 + The first intermediate point of any LSP in the stack could be 199 either single or multi-hop away from the egress of that LSP. 200 (Thus the egress of a given LSP in the stack could be either 201 single or multi-hop away from the egress of the next LSP in the 202 stack.) 204 Such stack of LSPs provides the functionality to forward a packet 205 through a sequence of egresses of the LSPs on the stack - the 206 sequence of these egresses represents the explicit route of the 207 explicitly routed point-to-point tunnel constructed by using these 208 stacked LSPs. The ingress of all these LSPs is the ingress of the 209 tunnel. 211 When the first intermediate point of a given LSP in the stack is 212 multi-hop away from the egress of that LSP, the existing label 213 distribution protocols (LDP, RSVP-TE, etc. ) can be used to establish 214 a multi-hop LSP fragment for this LSP. When IS-IS or OSPF, in 215 addition to being a routing protocol, is also used as a label 216 distribution protocol (see section "IS-IS or OSPF as Label 217 Distribution Protocol"), it can also be used to establish such multi- 218 hop LSP fragment. 220 To construct the label stack associated with the stack of LSPs the 221 ingress uses the following procedures: 223 + For (n > i > 0) R(0) obtains from R(i) label binding for LSP(i+1) 224 and places the label onto the stack, starting from the bottommost 225 label (the label that corresponds to LSP(n). 227 In section "IS-IS or OSPF as Label Distribution Protocol" we 228 describe how IS-IS or OSPF with appropriate extensions could be 229 used as a label distribution protocol to obtain such label 230 bindings. 232 If the first intermediate point of LSP(i+1) is either (a) a 233 single hop away from the egress of that LSP, or (b) multi-hop 234 away, and LDP is used as a label distribution protocol to 235 establish a multi-hop LSP fragment between the first intermediate 236 point and the egress of that LSP, then R(0) can use targeted LDP 237 session with R(i) to obtain such label bindings. 239 + For LSP(1) if R(1) is one hop away from R(0), then no label is 240 needed, and the label stack construction terminates with the 241 topmost label that R(0) obtains from R(1) for LSP(2). 243 + Otherwise, if R(1) is more than one hop away from R(0), then R(0) 244 places the label it binds to LSP(1) at the top of the stack. 246 Since the MPLS label stack mechanism allows stack of LSPs to nest to 247 any depth, use of LSP hierarchy for explicitly routed tunnels does 248 not place any protocol restrictions on the number of entries in the 249 explicit route of an explicitly routed tunnel. Note though that there 250 may be some other restrictions (e.g., due to MTU, or hardware) that 251 would place an upper bound on the depth of the label stack, and thus 252 on the number of entries in the explicit route. Also, the depth of 253 the label stack may have implications on ECMP, and specifically on 254 the use of the Entropy label (see [kini] for more). 256 4.1. Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 258 In this section we illustrate how to construct an explicitly routed 259 tunnel by using stacked LSPs. The first example illustrates this for 260 an explicitly routed tunnel with strict hops. The second example 261 illustrates this for an explicitly routed tunnel with loose hops. 263 4.1.1. Explicitly Routed Tunnel with Strict Hops 265 Consider a network topology shown below: 267 R0-----R4 268 | /| 269 | / | 270 | / | 271 | / | 272 | / | 273 R1 R3 274 \ / 275 \ / 276 R2 278 Assume that R0 wants to construct an explicitly routed tunnel with 279 (R0, R1, R2, R3, R4) as strict hops. R0 constructs this tunnel using 280 the following stack of LSPs: 282 LSP1: (R0, R1) - top of the stack 283 LSP2: (R0, R1, R2) 284 LSP3: (R0, R2, R3) 285 LSP4: (R0, R3, R4) - bottom of the stack 287 Note that this stack of LSPs meets the requirements specified in 288 section "Constructing Explicitly Routed Tunnels by using Stacked 289 LSPs". Specifically, 291 + All four LSPs in the stack have the same ingress - R0, which is 292 also the ingress of the explicitly routed tunnel. 294 + The egress of LSP1, R1, is the first intermediate point of the 295 next LSP in the stack, LSP2. The egress of LSP2, R2, is the first 296 intermediate point of the next LSP in the stack, LSP3. Likewise, 297 the egress of LSP3, R3, is the first intermediate point of the 298 next (and the last) LSP in the stack, LSP4. 300 + The LSP at the top of the stack, LSP1, has its first intermediate 301 point, R1, one hop away from its ingress, R0. Because of that, 302 this intermediate point is also the egress of that LSP, and that 303 LSP is a one-hop LSP. 305 + In that particular example the first intermediate point of every 306 LSP in the stack is one hop away from the egress of that LSP. 307 That is, the first intermediate point of LSP2, R1, is one hop 308 away from the egress of that LSP, R2; the first intermediate 309 point of LSP3, R2, is one hop away from the egress of that LSP, 310 R3; and the first intermediate point of LSP4, R3, is one hop away 311 from the egress of that LSP, R4. As a result, the egress of a 312 given LSP in the stack is one hop away from the egress of the 313 next LSP in the stack, which makes all the hops of the explicitly 314 routed tunnel strict. 316 The first intermediate point of each of these LSPs creates label 317 bindings for these LSPs as follows. R3 creates label binding for LSP4 318 by binding a particular label, L1, to the address of R4, creating a 319 Next Hop Label Forwarding Entry (NHLFE) whose next hop is the link 320 from R3 to R4, and setting the Incoming Label Map (ILM) so that L1 321 maps to that NHLFE. Likewise, R2 creates label binding for LSP3 by 322 binding a particular label, L2, to the address of R3, creating an 323 NHLFE whose next hop is the link from R2 to R3, and setting the ILM 324 so that L2 maps to that NHLFE. Finally, R1 creates label binding for 325 LSP2 by binding a particular label, L3, to the address of R2, 326 creating an NHLFE whose next hop is the link from R1 to R2, and 327 setting the ILM so that L3 maps to that NHLFE. 329 To get from the first hop of LSP4, R0, to the second hop of LSP4, R3, 330 the packet has to go through the LSP tunnel provided by LSP3. To get 331 from the first hop of LSP3, R0, to the second hop of LSP3, R2, a 332 packet has to go through the LSP tunnel provided by LSP2. To get from 333 the first hop of LSP2, R0, to the second hop of LSP2, R1, a packet 334 has to go through the LSP tunnel provided by LSP1. 336 In order to accomplish this R0 constructs the label stack for the 337 explicitly routed tunnel as follows: 339 + Step 1: R0 obtains label binding L1 created by R3 for LSP4 (R0, 340 R3, R4), and starts building the label stack by pushing L1 onto 341 the label stack. 343 + Step 2: R0 obtains label binding L2 created by R2 for LSP3 (R0, 344 R2, R3), and pushes L2 into the stack. At this point the stack 345 contains (L2, L1). 347 + Step 3: R0 obtains label binding L3 created by R1 for LSP2 (R0, 348 R1, R2), and pushes L3 into the stack. At this point the stack 349 contains (L3, L2, L1). 351 + Step 4: Since R0 and R1 are one hop away from each other the 352 label stack construction is completed (R0 does not need a label 353 for one-hop LSP1). 355 So far we did not say anything about how R0 obtains from R3 label 356 binding for LSP4, from R2 label binding for LSP3, and from R1 label 357 binding for LSP2. 359 At least in principle, these label bindings could be obtain by such 360 already defined label distribution protocols as LDP (to be more 361 precise, targeted LDP if the two routers are more than one hop away 362 from each other). E.g., if one uses targeted LDP, then R0 would need 363 to maintain a targeted LDP session with R3 and another targeted LDP 364 session with R2 (R0 would maintain a "vanilla" LDP session with R1). 365 Using these LDP sessions R0 would obtain from R3 label binding for 366 LSP4, from R2 label binding for LSP3, and from R1 label binding for 367 LSP2. 369 In section "IS-IS or OSPF as Label Distribution Protocol" we describe 370 how IS-IS or OSPF with appropriate extensions could be used as a 371 label distribution protocol to obtain such label bindings. 373 4.1.2. Explicitly Routed Tunnel with Loose Hops 375 Consider a network topology shown below: 377 R0---R1 378 / \ 379 R2 R5---R6 380 \ / 381 R3---R4 383 Assume that R0 wants to construct an explicitly routed tunnel with 384 (R0, R4, R6) as loose hops. R0 constructs this tunnel using the 385 following stack of LSPs: 387 LSP1: (R0, R2, R3, R4) - top of the stack 388 LSP2: (R0, R4, R5, R6) - bottom of the stack 390 Note that this stack of LSPs meets the requirements specified in 391 section "Constructing Explicitly Routed Tunnels by using Stacked 392 LSPs". Specifically, 394 + Both LSPs in the stack have the same ingress - R0, which is also 395 the ingress of the explicitly routed tunnel. 397 + The egress of LSP1, R4, is the first intermediate point of the 398 next LSP in the stack, LSP2. 400 + The LSP at the top of the stack, LSP1, has its first intermediate 401 point, R2, one hop away from its ingress, R0. However, this 402 intermediate point is not the egress of that LSP, and therefore 403 this LSP is a multi-hop LSP. 405 + In that particular example the first intermediate point of every 406 LSP in the stack is multi-hop away from the egress of that LSP 407 That is, the first intermediate point of LSP1, R2, is multi-hop 408 away from the egress of that LSP, R4; the first intermediate 409 point of LSP2, R4, is multi-hop away from the egress of that LSP, 410 R6. As a result, the egress of a given LSP in the stack is 411 multi-hop away from the egress of the next LSP in the stack, 412 which makes the hops of the explicitly routed tunnel loose. 414 In this example we assume that LDP is used as a label distribution 415 protocol for both LSP1 and LSP2. Since R0 and R4 are not IGP 416 neighbors, they are remote label distribution peers. Thus R0 and R4 417 use targeted LDP for label distribution. All other routers use 418 "vanilla" LDP procedures. 420 To get from the first hop of LSP2, R0, to its second hop, R4, the 421 packet has to go through the LSP tunnel provided by LSP1. 423 In order to accomplish this R0 constructs the label stack for the 424 explicitly routed tunnel as follows: 426 + Step 1: R0 (using targeted LDP) obtains label binding L1 created 427 by R4 for LSP2 (R0, R4, R5, R6), and starts building the label 428 stack by pushing L1 onto the label stack. 430 + Step 2: R0 (using "vanilla" LDP procedures) obtains label binding 431 L2 created by R2 for LSP1 (R0, R3, R4), and pushes L2 into the 432 stack. At this point the stack contains (L2, L1). 434 + Step 3: Since R0 and R1 are one hop away from each other the 435 label stack construction is completed (R0 does not need a label 436 for one-hop LSP1). 438 A reader familiar with Remote LFA FRR [R-LFA] should be able to 439 notice that the example described in this section is nothing more 440 than an instance of Remote LFA FRR, where Remote LFA FRR provides 441 fast reroute to the traffic going from R0 to R6 in the presence of 442 the (R0, R2) link failure, with R0 being the Point of Local Repair 443 (PLR), R4 being the PQ-node, and R6 being the ultimate destination. 444 The explicitly routed tunnel (R0, R4, R6) consists of the PLR as the 445 head-node, the PQ-node as the next loose hop, and the ultimate 446 destination as yet another loose hop. 448 5. IS-IS or OSPF as Label Distribution Protocol 450 When OSPF or IS-IS, in addition to being a routing protocol, is also 451 used as a label distribution protocol (as proposed in [gredler-isis], 452 [gredler-ospf], [previdi-isis], [psenak-ospf), the OSPF/IS-IS Link 453 State Advertisements originated by a router carry label bindings for 454 LSPs that either transit or originated by the router. Doing this 455 allows to extend such LSPs. The criteria for selecting among all 456 these LSPs a subset for which the router would originate label 457 binding advertisements in IS-IS/OSPF are purely local to the router. 458 The router could be either single or multi-hop away from the egresses 459 of the LSPs in the subset. Existing label distribution protocols 460 (LDP, RSVP-TE, etc.) can be used to establish multi-hop LSP fragments 461 if the router is multi-hop away from the egress of a particular LSP 462 in the subset. When IS-IS or OSPF, in addition to being a routing 463 protocol, is also used as a label distribution protocol, it can also 464 be used to establish such multi-hop LSP fragments. 466 MPLS architecture [RFC3031] defines the notion of local/remote label 467 distribution peers as follows: 469 When two LSRs are IGP neighbors, we will refer to them as "local 470 label distribution peers". When two LSRs may be label distribution 471 peers, but are not IGP neighbors, we will refer to them as "remote 472 label distribution peers." 474 Following OSPF/IS-IS procedures each router passes Link State 475 Advertisements originated by other routers unmodified. When these 476 advertisements carry label binding information, this information is 477 also passed unmodified. Therefore, the router that originates label 478 bindings advertisements in IS-IS/OSPF can be either single or multi- 479 hop away from the routers that receive and use these bindings. In 480 the former case the IGP neighbors of the router that originates the 481 advertisements will be the local label distribution peers of the 482 router. In the latter case other routers in the same IGP domain will 483 be the remote label distribution peers of the router. 485 Use of OSPF or IS-IS as a label distribution protocol provides 486 scalable support for remote label distribution peering in terms of 487 the number of label distribution peers a given router has to 488 maintain. This is because label distribution protocol messages (Link 489 State Advertisements) are exchanged only between IGP neighbors, 490 without requiring control plane peering between a router that 491 originates Link State Advertisements and each of its remote label 492 distribution peers. 494 It is important to note that the existing MPLS control plane already 495 has mechanisms/protocols to support remote label distribution peering 496 (using BGP or targeted LDP [RFC5036]). Thus the practical relevance 497 of the ability to provide scalable support for remote label 498 distribution peering with IS-IS or OSPF as a label distribution 499 protocol depends on a particular use case. 501 If for a given subset of routers within an MPLS network each router 502 within the subset is assigned a distinct index, then one could 503 compress announcements of labels bound to the LSPs whose FECs are the 504 IP addresses of these routers by (a) advertising these indices in IS- 505 IS/OSPF, and (b) making each router advertise a label block in IS- 506 IS/OSPF as well. A router R1 that advertises a given label block 507 algorithmically binds a FEC associated with an IP address of some 508 other router R2 to the label from that block that is identified by 509 the index that R2 advertises in IGP. A router R1 that receives label 510 block originated by some other router R2 can determine the label 511 bound to a FEC associated with an IP address of some other router R3 512 by using the index advertised by R3 as an offset into the label block 513 advertised by R2. Note that to avoid wasting labels this scheme 514 requires a fairly dense assignment of indices. Also note that to 515 expand the number of labels that a router advertises using label 516 blocks, the router may advertise more than one label block. 518 Note though, that the benefits of scaling improvements in terms of 519 label distribution peering come at a cost, as every router in the 520 domain ends up keeping all the labels assigned/bounded by every other 521 router in the domain, whether it really needs to know them or not. 522 Whether this cost is of practical significance depends on the 523 encoding of label bindings (e.g., use of label blocks vs enumerating 524 each label binding). 526 5.1. Example of IS-IS/OSPF as Label Distribution Protocols 528 In this section we illustrate how IS-IS/OSPF with extensions, as 529 defined in [gredler-isis], [gredler-ospf], [previdi-isis], [psenak- 530 ospf] could be used as a label distribution protocol to support 531 explicitly routed tunnels realized by stacked LSPs. For the purpose 532 of this illustration we assume the scenario described in section 533 "Example of Constructing Explicitly Routed Tunnels by Stacked LSPs". 534 In that example one of the key issues is the ability of R0 to obtain 535 from R3 label binding for LSP4, from R2 label binding for LSP3, and 536 from R1 label binding for LSP2. 538 To obtains such label bindings, the Link State Advertisement 539 originated by R3 carries label L1 (this is the label that R3 binds to 540 LSP4). Using IS-IS/OSPF procedures this Link State Advertisement is 541 propagated by R2 and R1 (as well as by R4) to R0. This is how R0 542 obtains from R3 label binding for LSP4. In a similar fashion, the 543 Link State Advertisement originated by R2 carries label L2 (which is 544 the label that R2 binds to LSP3). Using IS-IS/OSPF procedures this 545 Link State Advertisement is propagated by R1 (as well as by R3 and 546 R4) to R0. This is how R0 obtains from R2 label binding for LSP3. 547 Likewise, the Link State Advertisement originated by R1 carries label 548 L3 (which is the label that R1 binds to LSP2). Using IS-IS/OSPF 549 procedures this Link State Advertisement is delivered to R0. This is 550 how R0 obtains from R1 label binding for LSP2. 552 Note that while from R0's perspective both R2 and R3 are remote label 553 distribution peers, R0 does not maintain any control plane peering 554 (e.g., targeted LDP) with either R2 or R3. 556 6. IANA Considerations 558 This document introduces no new IANA Considerations. 560 7. Security Considerations 562 TBD 564 8. Acknowledgements 566 We would like to thank John Drake and John Scudder for their review 567 and comments. 569 9. Normative References 571 [RFC3031] Rosen, E., et. al., "Multiprotocol Label Switching 572 Architecture", RFC3031, January 2001 574 10. Informative References 576 [kini] Kini, S., et. al., "Entropy labels for source routed stacked 577 tunnels", draft-kini-mpls-entropy-label-src-stacked-tunnels, work in 578 progress 580 [gredler] Gredler, H., et. al., "Advertising MPLS labels in IGPs" 581 draft-gredler-rtgwg-igp-label-advertisement, work in progress 583 [gredler-isis] Gredler, H., et. al., "Advertising MPLS labels in IS- 584 IS" draft-gredler-isis-label-advertisement, work in progress 586 [gredler-ospf] Gredler, H., et. al., "Advertising MPLS labels in 587 OSPF" draft-gredler-ospf-label-advertisement, work in progress 589 [previdi-isis] Previdi, S., et. al., "IS-IS Extensions for Segment 590 Routing" draft-previdi-isis-segment-routing-extensions, work in 591 progress 593 [psenak-ospf] Psenak, P., et. al., "OSPF Extensions for Segment 594 Routing" draft-psenak-ospf-segment-routing-extensions, work in 595 progress 597 [R-LFA] Bryant, S., et. al., "Remote LFA FRR", draft-ietf-rtgwg- 598 remote-lfa, work in progress 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", RFC2119, March 1997 603 [RFC3107] Rekhter, Y., et. al., "Carrying Label Information in 604 BGP-4", RFC3107, May 2001 606 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 607 Tunnels", RFC3209, December 2001 609 [RFC3212] Jamoussi, B., et. al., "Constraint-Based LSP Setup using 610 LDP", RFC3212, January 2002 612 [RFC4364] Rosen E., et. al., "BGP/MPLS IP Virtual Private Networks 613 (VPNs)", RFC4364, February 2006 615 [RFC4761] Kompella, K., et. al., "Virtual Private LAN Service (VPLS) 616 Using BGP for Auto-Discovery and Signaling", RFC4761, January 2007 618 [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036, 619 October 2007 621 11. Authors' Addresses 623 Hannes Gredler 624 Juniper Networks 625 e-mail: hannes@juniper.net 627 Yakov Rekhter 628 Juniper Networks 629 e-mail: yakov@juniper.net