idnits 2.17.1 draft-wijnands-mpls-mldp-recurs-fec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 16, 2010) is 5114 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) == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJsbrand Wijnands 3 Internet Draft Eric C. Rosen 4 Intended Status: Proposed Standard Cisco Systems, Inc. 5 Expires: October 16, 2010 6 Maria Napierala 7 AT&T 9 Nicolai Leymann 10 Deutsche Telekom 12 April 16, 2010 14 Using mLDP through a Backbone where there is no Route to the Root 16 draft-wijnands-mpls-mldp-recurs-fec-01.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright and License Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Abstract 56 The control protocol used for constructing Point-to-Multipoint and 57 Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a 58 field that identifies the address of a "root node". Intermediate 59 nodes are expected to be able to look up that address in their 60 routing tables. However, if the route to the root node is a BGP 61 route, and the intermediate nodes are part of a BGP-free core, this 62 is not possible. This document specifies procedures which enable a 63 MP LSP to be constructed through a BGP-free core. In these 64 procedures, the root node address is temporarily replaced by an 65 address which is known to the intermediate nodes. 67 Table of Contents 69 1 Introduction .......................................... 3 70 2 The Recursive Opaque Value Type ....................... 5 71 2.1 Encoding .............................................. 5 72 2.2 Procedures ............................................ 5 73 3 The VPN-Recursive MP FEC Element ...................... 6 74 3.1 Encoding .............................................. 6 75 3.2 Procedures ............................................ 7 76 3.2.1 Unsegmented 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 84 1. Introduction 86 [MLDP] defines several LDP FEC element encodings: P2MP, MP2MP 87 Upstream, and MP2MP Downstream. 89 The encoding for these three FEC elements is shown in Figure 1. 91 0 1 2 3 92 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 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Type | Address Family | Address Length| 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 ~ Root Node Address ~ 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Opaque Length | . | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 100 ~ ~ 101 | Opaque Value | 102 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 MLDP FEC Element Encoding 107 Figure 1 109 Note that a P2MP or MP2MP label switched path ("MP LSP") is 110 identified by the combination of a "root node" and a variable length 111 "opaque value". The root node also plays a special role in the MLDP 112 procedures - MLDP messages that are "about" a particular MP LSP are 113 forwarded to the LDP adjacency that is the next hop on the route to 114 the root node. 116 Sometimes it is desirable for a MP LSP to pass through a part of the 117 network in which there is no route to the root node. For instance, 118 consider the topology of Figure 2: 120 CE1----PE1---P1---- ...----P2 ----PE2----CE2----R 122 Figure 2 124 where CE1 and CE2 are "customer edge routers", PE1 and PE2 are 125 "provider edge routers", but the provider's core is "BGP-free". That 126 is, PE1 has a BGP-learned route for R, in which PE2 is the BGP next 127 hop. However, the provider's interior routers (such as P1 and P2) do 128 not have any BGP-learned routes, and in particular do not have any 129 routes to R. 131 In such an environment, data packets from CE1 address to R would get 132 encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and 133 forwarded to CE2. 135 Suppose now that CE1 is trying to set up a MP LSP whose root is R, 136 and the intention is that the provider's network will participate in 137 the construction of the LSP. Then the MLDP messages identifying the 138 LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to 139 PE2, from PE2 to CE2, and from CE2 to R. 141 To begin the process, CE1 creates a MP FEC element with the address 142 of R as the root node address, and passes that FEC element via MLDP 143 to PE1. However, PE1 cannot use this same FEC element to identify 144 the LSP in the LDP messages it sends to P1, because P1 does not have 145 a route to R. 147 However, PE1 does know that PE2 is the "BGP next hop" on the path to 148 R. What is needed is a method whereby: 150 - PE1 can tell P1 to set up an LSP as if the root node were PE2, 151 and 153 - PE2 can determine that the LSP in question is really rooted at R, 154 not at PE2 itself, 156 - PE2 can determine the original FEC element that CE1 passed to 157 PE1, so that PE2 can pass it on to CE2. 159 This document defines the procedures that allow CE1 to create an LSP 160 rooted at R. These procedures require PE1 to modify the MP FEC 161 element before sending an MLDP message to P1. The modified FEC 162 element has PE2 as the root, and the original FEC element as the 163 opaque value. This requires a new type of opaque value. Since the 164 opaque value contains a FEC element, we call this a "Recursive Opaque 165 Value". When PE2 sends an mLDP message to CE2, it replaces the FEC 166 element with the opaque value, thus undoing the recursion. Details 167 are in section 2. 169 Section 3 defines a "VPN Recursive Opaque Value". Whereas the 170 "Recursive Opaque Value" carries the original FEC, the "VPN Recursive 171 Opaque Value" carries the original FEC plus a Route Distinguisher 172 (RD). This has several possible uses in an L3VPN context. Details 173 are in section 3. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 2. The Recursive Opaque Value Type 181 2.1. Encoding 183 We define a new Opaque Value Type, the Recursive Opaque Value Type. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type = 6 | Length | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 190 ~ ~ 191 | P2MP or MP2MP FEC Element | 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Recursive Opaque Value Type 197 Figure 3 199 The "opaque value" itself is a P2MP or MP2MP FEC element, encoded 200 exactly as specified in [MLDP], with a type field, a length field, 201 and value field of is own. The length field of the Recursive Opaque 202 Value Type thus includes the type and length fields of the FEC 203 element that is the value field. 205 2.2. Procedures 207 In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP 208 FEC element whose root node is R, and whose opaque value is Q. We 209 will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC 210 as an ordered pair, as follows: 212 CE1-FEC = . 214 PE1 determines that the root node R matches a BGP route, with a BGP 215 next hop of PE2. PE1 also knows by its configuration that the 216 interior routers on the path to PE2 are "BGP-free", and thus have no 217 route to R. 219 PE1 therefore MUST create a new MP FEC element, whose root node 220 address is the address of PE2, and whose opaque value is a Recursive 221 (type 6) Opaque Value whose value field contains CE1-FEC. We refer 222 to this FEC element as PE2-FEC. PE1 then MUST send this FEC element 223 to P1. 225 PE2-FEC = , or 227 PE2-FEC = > 230 As far as the interior routers are concerned, they are being 231 requested to build a MP LSP whose root node is PE2. They MUST NOT 232 interpret the opaque value at all. 234 When PE2-FEC arrives at PE2, PE2 notes that it is the identified root 235 node, and that the opaque value is a Recursive (type 6) opaque value. 236 Therefore it MUST replace PE2-FEC with the contents of the type 6 237 opaque value (i.e., with CE1-FEC) before doing any further 238 processing. This will result in CE1-FEC being sent on to CE2, and 239 presumably further from CE2 to R. Note that CE1-FEC will contain the 240 LSP root node specified by CE1; the presumption is that PE2 has a 241 route to this root node. 243 3. The VPN-Recursive MP FEC Element 245 3.1. Encoding 247 We define a new Opaque Value Type, the VPN-Recursive Opaque Value 248 Type. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type = 7 | Length | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | | 256 | Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ 257 | | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 259 ~ ~ 260 | P2MP or MP2MP FEC Element | 261 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 VPN-Recursive Opaque Value Type 266 Figure 3 268 The "opaque value" consists of an eight-octet Route Distinguisher 269 (RD), followed by a P2MP or MP2MP FEC element, encoded exactly as 270 specified in [MLDP], with a type field, a length field, and value 271 field of is own. The length field of the Recursive Opaque Value Type 272 thus includes the 8 octets of RD plus the type and length fields of 273 the FEC element that is the value field. 275 3.2. Procedures 277 3.2.1. Unsegmented Inter-AS P-tunnels 279 Consider the Inter-AS VPN scenario depicted in Figure 4. 281 PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2 283 Figure 4 285 Suppose this is an "option B" VPN interconnect ([VPN] section 10). 286 This means that the Autonomous System Border Router (ASBR) in the 287 first Autonomous System (i.e., ASBR1) does not have a route to PE 288 routers in other ASes (such as PE2). Suppose also that the MVPN 289 policy is to instantiate PMSIs [MVPN] using mLDP, and that 290 "unsegmented inter-AS P-tunnels" [MVPN] are being used. 292 In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root 293 is PE2. P1 has no route to PE2, and all PE1 knows about the route to 294 PE2 is that ASBR1 is the BGP next hop. Since P1 has no root to PE2, 295 PE1 needs to originate an mLDP message with a FEC element that 296 identifies ASBR1 as the root. This FEC element must contain enough 297 information to enable ASBR1 to find the next hop towards PE2 even 298 though ASBR1 does not have a route to PE2. 300 Although ASBR1 does not have a route to PE2, it does have a BGP 301 Intra-AS I-PMSI A-D route [MVPN] whose NLRI contains PE2's IP address 302 together with a particular RD. PE1 also has this Inter-AS I-PMSI A-D 303 route. The LSP needs to be set up along the path established by the 304 Intra-AS I-PMSI A-D routes. Therefore one must use a Recursive FEC 305 element that contains the RD as well as the as well as the address of 306 PE2. The "VPN-Recursive FEC Element" defined herein is used for this 307 purpose. 309 This enables us to provide the same functionality, for mLDP P-tunnels 310 that is provided for PIM P-tunnels in section 8.1.3.2 of [MVPN] 311 though the use of the MVPN Join Attribute. 313 At PE1 in Figure 4, the LSP to be created is associated with a 314 particular VRF. PE1 looks up in that VRF the Intra-AS I-PMSI A-D 315 route originated by PE2. It finds that the BGP next hop of that 316 route is ASBR1. So it creates a P2MP or MP2MP FEC element whose root 317 is ASBR1, and whose opaque value is a VPN-Recursive FEC element. The 318 VPN-Recursive FEC element itself consists of a root, an RD, and an 319 opaque value, set as follows: 321 - The root is PE2 323 - The RD is the RD from the NLRI of the Intra-AS A-D route 324 originated by PE2. 326 - The opaque value is chosen (by some method outside the scope of 327 this document) so as to be unique in the context of PE2. (E.g., 328 it may have been specified in a PMSI tunnel attribute originated 329 by PE2.) We will refer to this opaque value as "Q". 331 The resulting FEC element can be informally represented as 333 >. 335 PE1 can now begin setting up the LSP by using this FEC element in an 336 LDP label mapping message sent towards ASBR1. 338 When ASBR1 receives, over a non-VRF interface, an mLDP label mapping 339 message containing this FEC element, it sees that it is the root, and 340 that the opaque value is a VPN-Recursive (type 7) FEC element. It 341 parses the VPN-Recursive FEC element and extracts the root value, 342 PE2. 344 If ASBR1 has a route to PE2, it continues setting up the LSP by using 345 the following FEC element: 347 349 However, if ASBR1 does not have a route to PE2, it looks for an 350 Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along 351 with the specified RD value. Say the BGP next hop of that route is 352 ASBR2. Then ASBR1 continues setting up the LSP by using the 353 following FEC element: 355 >. 357 Note that in this case, the root has changed from ASBR1 to ASBR2, but 358 the opaque value is the unchanged VPN-Recursive FEC element. 360 3.2.2. Limited Carrier's Carrier Function 362 Another possible use of the VPN recursive FEC is to provide a limited 363 version of "Carrier's Carrier Service". Referring again to the 364 topology of Figure 2, suppose that PE1/PE2 are offering "Carrier's 365 Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC 366 element whose root node is R, and whose opaque value is Q. We will 367 refer to this FEC element as "CE1-FEC". However, PE1's route to R 368 will be in a VRF ("Virtual Routing and Forwarding Table"). Therefore 369 the FEC-element created by PE1 must contain some identifier that PE2 370 can use to find the proper VRF in which to look up the address of R. 372 When PE1 looks up the address of R in a VRF, it will find a route in 373 the VPN-IP address family. The next hop will be PE2, but there will 374 also be a Route Distinguisher (RD) as part of that NLRI of the 375 matching route. In this case, the new FEC element created by PE1 376 MUST have the address of PE2 as the root node address, and MUST have 377 a VPN-Recursive (type 7) opaque value. The value field of the type 7 378 opaque value MUST consist of the 8-octet RD followed by CE1-FEC. 380 As far as the interior routers are concerned, they are being 381 requested to build a MP LSP whose root node is PE2. They MUST NOT 382 interpret the opaque value at all. 384 When an mLDP label mapping message containing PE2-FEC arrives at PE2 385 over a VRF interface, PE2 notes that it is the identified root node, 386 and that the opaque value is a VPN-recursive (type 7) opaque value. 387 Therefore it MUST replace PE2-FEC with the contents of the VPN- 388 recursive opaque value (i.e., with CE1-FEC) before doing any further 389 processing. It uses the VRF to lookup up the path to R. This will 390 result in CE1-FEC being sent on to CE2, and presumably further from 391 CE2 to R. 393 In this scenario, the RD in the VPN-Recursive Opaque Value also 394 ensures uniqueness of the FEC Element within the inner carrier's 395 network. 397 This way of providing Carrier's Carrier service has limited 398 applicability, as it only works under the following conditions: 400 - Both the inner carrier and the outer carrier are using 401 unsegmented mLDP P-tunnels 403 - The inner carrier is not aggregating the P-tunnels of the outer 404 carrier, but is content to carry each such P-tunnel in a single 405 P-tunnel of its own. 407 The carrier's carrier scenario can be distinguished from the inter-AS 408 scenario by the fact that in the former, the mLDP messages are being 409 exchanged on VRF interfaces. 411 4. IANA Considerations 413 [MLDP] defines a registry for "The LDP MP Opaque Value Element Type". 414 This document requires the assignment of two new code points in this 415 registry: 417 - Type 6. 419 An opaque value of this type is itself a TLV that encodes an mLDP 420 FEC type, as defined in [MLDP]. 422 - Type 7 424 An opaque value of this type consists of an eight-octet Route 425 Distinguisher as defined in [VPN], followed by a TLV that encodes 426 an mLDP FEC type, as defined in [MLDP]. 428 5. Security Considerations 430 TBD 432 6. Acknowledgments 434 The authors wish to thank Toerless Eckert for his contribution to 435 this work. 437 7. Authors' Addresses 439 IJsbrand Wijnands 440 Cisco Systems, Inc. 441 De kleetlaan 6a Diegem 1831 442 Belgium 443 E-mail: ice@cisco.com 445 Eric C. Rosen 446 Cisco Systems, Inc. 447 1414 Massachusetts Avenue 448 Boxborough, MA, 01719 449 E-mail: erosen@cisco.com 451 Maria Napierala 452 AT&T Labs 453 200 Laurel Avenue, Middletown, NJ 07748 454 E-mail: mnapierala@att.com 456 Nicolai Leymann 457 Deutsche Telekom 458 Winterfeldtstrasse 21 459 Berlin 10781 460 Germany 461 E-mail: n.leymann@telekom.de 463 8. Normative References 465 [MLDP] "Label Distribution Protocol Extensions for Point-to- 466 Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei, 467 Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-08.txt, October 468 2009 470 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 471 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2009 473 [RFC2119] "Key words for use in RFCs to Indicate Requirement 474 Levels.", Bradner, March 1997 476 [VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, Rekhter, 477 RFC 4364, February 2006