idnits 2.17.1 draft-ietf-mpls-mldp-recurs-fec-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 25, 2011) is 4658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group IJsbrand Wijnands 3 Internet Draft Eric C. Rosen 4 Intended Status: Proposed Standard Cisco Systems, Inc. 5 Expires: January 25, 2012 6 Maria Napierala 7 AT&T 9 Nicolai Leymann 10 Deutsche Telekom 12 July 25, 2011 14 Using Multipoint LDP when the Backbone has no Route to the Root 16 draft-ietf-mpls-mldp-recurs-fec-04.txt 18 Abstract 20 The control protocol used for constructing Point-to-Multipoint and 21 Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a 22 field that identifies the address of a "root node". Intermediate 23 nodes are expected to be able to look up that address in their 24 routing tables. However, if the route to the root node is a BGP 25 route, and the intermediate nodes are part of a BGP-free core, this 26 is not possible. This document specifies procedures which enable a 27 MP LSP to be constructed through a BGP-free core. In these 28 procedures, the root node address is temporarily replaced by an 29 address that is known to the intermediate nodes and is on the path to 30 the true root node. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Copyright and License Notice 54 Copyright (c) 2011 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction .......................................... 3 70 2 The Recursive Opaque Value ............................ 5 71 2.1 Encoding .............................................. 5 72 2.2 Procedures ............................................ 5 73 3 The VPN-Recursive Opaque Value ........................ 6 74 3.1 Encoding .............................................. 6 75 3.2 Procedures ............................................ 7 76 3.2.1 Non-segmented Inter-AS P-tunnels ...................... 7 77 3.2.2 Limited Carrier's Carrier Function .................... 9 78 4 IANA Considerations ................................... 10 79 5 Security Considerations ............................... 11 80 6 Acknowledgments ....................................... 11 81 7 Authors' Addresses .................................... 11 82 8 Normative References .................................. 12 83 9 Informative References ................................ 12 85 1. Introduction 87 The document [mLDP] extends LDP ("Label Distribution Protocol", 88 [LDP]) to support multipoint label-switched paths. These extensions 89 are known as "Multipoint LDP", or more simply as "mLDP". [mLDP] 90 defines several LDP "Forwarding Equivalence Class" (FEC) element 91 encodings: "Point-to-Multipoint" (P2MP), "Multipoint-to-Multipoint 92 (MP2MP) Upstream", and "MP2MP Downstream". 94 The encoding for these three FEC elements, as defined in [mLDP], is 95 shown in Figure 1. 97 0 1 2 3 98 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Type | Address Family | Address Length| 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 ~ Root Node Address ~ 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Opaque Length | . | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 106 ~ ~ 107 | Opaque Value | 108 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 mLDP FEC Element Encoding 113 Figure 1 115 Note that a P2MP or MP2MP label switched path ("MP LSP") is 116 identified by the combination of a "root node" and a variable length 117 "opaque value". The root node also plays a special role in the mLDP 118 procedures - mLDP messages that are "about" a particular MP LSP are 119 forwarded to the LDP adjacency that is the next hop on the route to 120 the root node. 122 Sometimes it is desirable for a MP LSP to pass through a part of the 123 network in which there is no route to the root node. For instance, 124 consider the topology of Figure 2. 126 CE1----PE1---P1---- ...----P2 ----PE2----CE2----R 128 Figure 2 130 In Figure 2, CE1 and CE2 are "customer edge routers", R is a customer 131 router at the same VPN site as CE2, PE1 and PE2 are "provider edge 132 routers". Suppose that the provider's core is "BGP-free". That is, 133 PE1 has a BGP-learned route for R, in which PE2 is the BGP next hop. 134 However, the provider's interior routers (such as P1 and P2) do not 135 have any BGP-learned routes, and in particular do not have any routes 136 to R. 138 In such an environment, unicast data packets from CE1 addressed to R 139 would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2, 140 and forwarded to CE2. 142 Suppose now that CE1 is trying to set up a MP LSP whose root is R, 143 and the intention is that the provider's network will participate in 144 the construction of the LSP. Then the mLDP messages identifying the 145 LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to 146 PE2, from PE2 to CE2, and from CE2 to R. 148 To begin the process, CE1 creates a MP FEC element with the address 149 of R as the root node address, and passes that FEC element via mLDP 150 to PE1. However, PE1 cannot use this same FEC element to identify 151 the LSP in the LDP messages it sends to P1, because P1 does not have 152 a route to R. 154 However, PE1 does know that PE2 is the "BGP next hop" on the path to 155 R. What is needed is a method whereby: 157 - PE1 can tell P1 to set up an LSP as if the root node were PE2, 158 and 160 - PE2 can determine that the LSP in question is really rooted at R, 161 not at PE2 itself, 163 - PE2 can determine the original FEC element that CE1 passed to 164 PE1, so that PE2 can pass it on to CE2. 166 This document defines the procedures that allow CE1 to create an LSP 167 rooted at R. These procedures require PE1 to modify the MP FEC 168 element before sending an mLDP message to P1. The modified FEC 169 element has PE2 as the root, and the original FEC element as the 170 opaque value. This requires a new type of opaque value. Since the 171 opaque value contains a FEC element, we call this a "Recursive Opaque 172 Value". When PE2 sends an mLDP message to CE2, it replaces the FEC 173 element with the opaque value, thus undoing the recursion. Details 174 are in section 2. 176 Section 3 defines a "Virtual Private Network (VPN) Recursive Opaque 177 Value". Whereas the "Recursive Opaque Value" carries the original 178 FEC, the "VPN Recursive Opaque Value" carries the original FEC plus a 179 Route Distinguisher (RD). This is applicable when MP LSPs are being 180 used to carry the multicast traffic of a VPN [MVPN]. Details are in 181 section 3. 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 2. The Recursive Opaque Value 189 2.1. Encoding 191 We define a new type of Opaque Value, the Recursive Opaque Value. 192 This is a "basic type", identified by a one-octet type field. 194 0 1 2 3 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type = TBD | Length | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 199 ~ ~ 200 | P2MP or MP2MP FEC Element | 201 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Recursive Opaque Value 206 Figure 3 208 The value field of the "Recursive Opaque Value" is itself is a P2MP 209 or MP2MP FEC element, encoded exactly as specified in [mLDP], with a 210 type field, a length field, and value field of its own. The length 211 of the Recursive Opaque Value thus includes the lengths of the type, 212 length, and value fields of the contained FEC element. 214 2.2. Procedures 216 In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP 217 FEC element whose root node is R, and whose opaque value is Q. We 218 will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC 219 as an ordered pair, as follows: 221 CE1-FEC = . 223 PE1 determines that the root node R matches a BGP route, with a BGP 224 next hop of PE2. PE1 also knows by its configuration that the 225 interior routers on the path to PE2 are "BGP-free", and thus have no 226 route to R. 228 PE1 therefore creates a new MP FEC element, whose root node address 229 is the address of PE2, and whose opaque value is a Recursive Opaque 230 Value whose value field contains CE1-FEC. We refer to this FEC 231 element as PE2-FEC: 233 PE2-FEC = , i.e., 235 PE2-FEC = > 238 PE1 then sends this FEC element to P1. 240 As far as the interior routers are concerned, they are being 241 requested to build a MP LSP whose root node is PE2. They MUST NOT 242 interpret the opaque value at all. 244 When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the 245 identified root node, and that the opaque value is a Recursive Opaque 246 Value. Therefore PE2 MUST replace PE2-FEC with the contents of the 247 Recursive Opaque Value (i.e., with CE1-FEC) before doing any further 248 processing. This will result in CE1-FEC being sent on to CE2, and 249 further from CE2 to R. Note that CE1-FEC will contain the LSP root 250 node specified by CE1; the presumption is that PE2 has a route to 251 this root node. 253 3. The VPN-Recursive Opaque Value 255 3.1. Encoding 257 We define a new type of Opaque Value, the VPN-Recursive Opaque Value. 258 This is a "basic type", identified by a one-octet type field. 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type = TBD | Length | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 265 | | 266 | Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ 267 | | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 269 ~ ~ 270 | P2MP or MP2MP FEC Element | 271 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 VPN-Recursive Opaque Value 276 Figure 4 278 The value field of the "VPN-Recursive Opaque Value" consists of an 279 eight-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC 280 element, encoded exactly as specified in [mLDP], with a type field, a 281 length field, and value field of is own. The length of the VPN- 282 Recursive Opaque Value thus includes the 8 octets of RD plus the 283 lengths of the type, length, and values fields of the contained FEC 284 element. 286 3.2. Procedures 288 3.2.1. Non-segmented Inter-AS P-tunnels 290 Consider the Inter-AS VPN scenario depicted in Figure 5. 292 PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2 294 Figure 5 296 Suppose this is an "option B" VPN interconnect ([VPN] section 10). 297 This means that the Autonomous System Border Router (ASBR) in the 298 first Autonomous System (i.e., ASBR1) does not have a route to PE 299 routers in other ASes (such as PE2). Suppose also that the MVPN 300 policy is to instantiate PMSIs [MVPN] using mLDP, and that 301 "non-segmented inter-AS P-tunnels" [MVPN] are being used. 303 In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root 304 is PE2. P1 has no route to PE2, and all PE1 knows about the route to 305 PE2 is that ASBR1 is the BGP next hop. Since P1 has no root to PE2, 306 PE1 needs to originate an mLDP message with a FEC element that 307 identifies ASBR1 as the root. This FEC element must contain enough 308 information to enable ASBR1 to find the next hop towards PE2 even 309 though ASBR1 does not have a route to PE2. 311 Although ASBR1 does not have a route to PE2, it does have a BGP 312 Intra-AS I-PMSI A-D route [MVPN] whose NLRI contains PE2's IP address 313 together with a particular RD. PE1 also has this Inter-AS I-PMSI A-D 314 route. The LSP needs to be set up along the path established by the 315 Intra-AS I-PMSI A-D routes. Therefore one must use a Recursive FEC 316 element that contains the RD as well as the as well as the address of 317 PE2. The "VPN-Recursive FEC Element" defined herein is used for this 318 purpose. 320 This enables us to provide the same functionality, for mLDP P-tunnels 321 that is provided for PIM P-tunnels in section 8.1.3.2 of [MVPN] 322 through the use of the MVPN Join Attribute. 324 At PE1 in Figure 4, the LSP to be created is associated with a 325 particular VPN Routing/Forwarding Table (VRF). PE1 looks up in that 326 VRF the Intra-AS I-PMSI A-D route originated by PE2. It finds that 327 the BGP next hop of that route is ASBR1. So it creates a P2MP or 328 MP2MP FEC element whose root is ASBR1, and whose opaque value is a 329 VPN-Recursive FEC element. The VPN-Recursive FEC element itself 330 consists of a root, an RD, and an opaque value, set as follows: 332 - The root is PE2 334 - The RD is the RD from the NLRI of the Intra-AS A-D route 335 originated by PE2. 337 - The opaque value is chosen (by some method outside the scope of 338 this document) so as to be unique in the context of PE2. (E.g., 339 it may have been specified in a PMSI tunnel attribute originated 340 by PE2.) We will refer to this opaque value as "Q". 342 The resulting FEC element can be informally represented as 344 >. 346 PE1 can now begin setting up the LSP by using this FEC element in an 347 LDP label mapping message sent towards ASBR1. 349 When ASBR1 receives, over a non-VRF interface, an mLDP label mapping 350 message containing this FEC element, it sees that it is the root, and 351 that the opaque value is a VPN-Recursive Opaque Value. It parses the 352 VPN-Recursive Opaque value and extracts the root value, PE2. 354 If ASBR1 has a route to PE2, it continues setting up the LSP by using 355 the following FEC element: 357 359 However, if ASBR1 does not have a route to PE2, it looks for an 360 Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along 361 with the specified RD value. Say the BGP next hop of that route is 362 ASBR2. Then ASBR1 continues setting up the LSP by using the 363 following FEC element: 365 >. 367 Note that in this case, the root has changed from ASBR1 to ASBR2, but 368 the opaque value is the unchanged VPN-Recursive FEC element. 370 3.2.2. Limited Carrier's Carrier Function 372 Another possible use of the VPN recursive FEC is to provide a limited 373 version of "Carrier's Carrier Service". Referring again to the 374 topology of Figure 2, suppose that PE1/PE2 are offering "Carrier's 375 Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC 376 element whose root node is R, and whose opaque value is Q. We will 377 refer to this FEC element as "CE1-FEC". However, PE1's route to R 378 will be in a VRF ("Virtual Routing and Forwarding Table"). Therefore 379 the FEC-element created by PE1 must contain some identifier that PE2 380 can use to find the proper VRF in which to look up the address of R. 382 When PE1 looks up the address of R in a VRF, it will find a route in 383 the VPN-IP address family. The next hop will be PE2, but there will 384 also be a Route Distinguisher (RD) as part of that NLRI of the 385 matching route. In this case, the new FEC element created by PE1 has 386 the address of PE2 as the root node address, and has a VPN-Recursive 387 Opaque Value. The value field of the VPN-Recursive Opaque Value 388 consists of the 8-octet RD followed by CE1-FEC. 390 As far as the interior routers are concerned, they are being 391 requested to build a MP LSP whose root node is PE2. They MUST NOT 392 interpret the opaque value at all. 394 When an mLDP label mapping message containing PE2-FEC arrives at PE2 395 over a VRF interface, PE2 notes that it is the identified root node, 396 and that the opaque value is a VPN-Recursive Opaque Value. Therefore 397 it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque 398 Value (i.e., with CE1-FEC) before doing any further processing. It 399 uses the VRF to lookup up the path to R. This will result in CE1-FEC 400 being sent on to CE2, and presumably further from CE2 to R. 402 In this scenario, the RD in the VPN-Recursive Opaque Value also 403 ensures uniqueness of the FEC Element within the inner carrier's 404 network. 406 This way of providing Carrier's Carrier service has limited 407 applicability, as it only works under the following conditions: 409 - Both the inner carrier and the outer carrier are using 410 non-segmented mLDP P-tunnels 412 - The inner carrier is not aggregating the P-tunnels of the outer 413 carrier, but is content to carry each such P-tunnel in a single 414 P-tunnel of its own. 416 The carrier's carrier scenario can be distinguished from the inter-AS 417 scenario by the fact that in the former, the mLDP messages are being 418 exchanged on VRF interfaces. 420 4. IANA Considerations 422 [mLDP] defines a registry for "The LDP MP Opaque Value Element Basic 423 Type". This document requires the assignment of two new code points 424 in this registry: 426 - Recursive Opaque Value: Type TBD (requested value: 7) 428 An opaque value of this type is itself a TLV that encodes an mLDP 429 FEC type, as defined in [mLDP]. 431 - VPN-Recursive Opaque Value: Type TBD (requested value: 8) 433 An opaque value of this type consists of an eight-octet Route 434 Distinguisher as defined in [VPN], followed by a TLV that encodes 435 an mLDP FEC type, as defined in [mLDP]. 437 5. Security Considerations 439 The security considerations of [LDP] and [mLDP] apply. 441 Unauthorized modification of the FEC elements defined in this 442 document can disrupt the creation of the multipoint LSPs, or can 443 cause the multipoint LSPs to pass through parts of the network where 444 they are not supposed to go. This could potentially be used as part 445 of an attack to illegitimately insert or intercept multicast traffic. 446 However, since the FEC elements defined in this document are not 447 inherently more vulnerable to this form of attack than are the 448 previously defined FEC elements, this document does not add new 449 security vulnerabilities. 451 A description of general security issues for MPLS can be found in 452 [RFC5920]. 454 6. Acknowledgments 456 The authors wish to thank Toerless Eckert for his contribution to 457 this work. 459 7. Authors' Addresses 461 IJsbrand Wijnands 462 Cisco Systems, Inc. 463 De kleetlaan 6a Diegem 1831 464 Belgium 465 E-mail: ice@cisco.com 467 Eric C. Rosen 468 Cisco Systems, Inc. 469 1414 Massachusetts Avenue 470 Boxborough, MA, 01719 471 E-mail: erosen@cisco.com 473 Maria Napierala 474 AT&T Labs 475 200 Laurel Avenue, Middletown, NJ 07748 476 E-mail: mnapierala@att.com 477 Nicolai Leymann 478 Deutsche Telekom 479 Winterfeldtstrasse 21 480 Berlin 10781 481 Germany 482 E-mail: n.leymann@telekom.de 484 8. Normative References 486 [LDP] "LDP Specification", RFC 5036, Andersson, Minei, Thomas, 487 October 2007 489 [mLDP] "Label Distribution Protocol Extensions for Point-to- 490 Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei, 491 Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-13.txt, April 492 2011 494 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 495 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2009 497 [RFC2119] "Key words for use in RFCs to Indicate Requirement 498 Levels.", Bradner, March 1997 500 [VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, Rekhter, 501 RFC 4364, February 2006 503 9. Informative References 505 [RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang, 506 RFC 5920, July 2010