idnits 2.17.1 draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-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 (October 17, 2012) is 4181 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 (-08) exists of draft-ietf-mpls-mldp-in-band-signaling-06 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-targeted-mldp-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJ. Wijnands, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track P. Hitchen 5 Expires: April 20, 2013 BT 6 N. Leymann 7 Deutsche Telekom 8 W. Henderickx 9 Alcatel-Lucent 10 A. Gulko 11 Thomson Reuters 12 October 17, 2012 14 Multipoint Label Distribution Protocol 15 In-Band Signaling in a VRF Context 16 draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01 18 Abstract 20 Sometimes an IP multicast distribution tree (MDT) traverses both 21 MPLS-enabled and non-MPLS-enabled regions of a network. Typically 22 the MDT begins and ends in non-MPLS regions, but travels through an 23 MPLS region. In such cases, it can be useful to begin building the 24 MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP 25 (Label Switched Path) when it enters an MPLS-enabled region, and then 26 convert it back to a pure IP MDT when it enters a non-MPLS-enabled 27 region. Other documents specify the procedures for building such a 28 hybrid MDT, using Protocol Independent Multicast (PIM) in the non- 29 MPLS region of the network, and using Multipoint Extensions to Label 30 Distribution Protocol (mLDP) in the MPLS region. This document 31 extends those procedures to handle the case where the link connecting 32 the two regions is a "Virtual Routing and Forwarding Table" (VRF) 33 link, as defined in the "BGP IP/MPLS VPN" specifications. However, 34 this document is primarily aimed at particular use cases where VRFs 35 are used to support multicast applications other than Multicast VPN. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 20, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Conventions used in this document . . . . . . . . . . . . 5 73 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. VRF In-band signaling for MP LSPs . . . . . . . . . . . . . . 6 75 3. Encoding the Opaque Value of an LDP MP FEC . . . . . . . . . . 7 76 3.1. Transit VPNv4 Source TLV . . . . . . . . . . . . . . . . . 7 77 3.2. Transit VPNv6 Source TLV . . . . . . . . . . . . . . . . . 8 78 3.3. Transit VPNv4 bidir TLV . . . . . . . . . . . . . . . . . 9 79 3.4. Transit VPNv6 bidir TLV . . . . . . . . . . . . . . . . . 10 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 Sometimes an IP multicast distribution tree (MDT) traverses both 91 MPLS-enabled and non-MPLS-enabled regions of a network. Typically 92 the MDT begins and ends in non-MPLS regions, but travels through an 93 MPLS region. In such cases, it can be useful to begin building the 94 MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP 95 (Label Switched Path) when it enters an MPLS-enabled region, and then 96 convert it back to a pure IP MDT when it enters a non-MPLS-enabled 97 region. Other documents specify the procedures for building such a 98 hybrid MDT, using Protocol Independent Multicast (PIM) in the non- 99 MPLS region of the network, and using Multipoint Extensions to Label 100 Distribution Protocol (mLDP) in the MPLS region. This document 101 extends those procedures to handle the case where the link connecting 102 the two regions is a "Virtual Routing and Forwarding Table" (VRF) 103 link, as defined in the "BGP IP/MPLS VPN" specifications. However, 104 this document is primarily aimed at particular use cases where VRFs 105 are used to support multicast applications other than Multicast VPN. 107 In PIM, a tree is identified by a source address (or in the case of 108 bidirectional trees [RFC5015], a rendezvous point address or "RPA") 109 and a group address. The tree is built from the leaves up, by 110 sending PIM control messages in the direction of the source address 111 or the RPA. In mLDP, a tree is identified by a root address and an 112 "opaque value", and is built by sending mLDP control messages in the 113 direction of the root. The procedures of 114 [I-D.ietf-mpls-mldp-in-band-signaling] explain how to convert a PIM 115 pair into an mLDP pair;, and how to convert the mLDP pair back into the original PIM pair. 120 However, those procedures assume that the routers doing the PIM/mLDP 121 conversion have routes to the source address or RPA in their global 122 routing tables. Thus the procedures cannot be applied exactly as 123 specified when the interfaces connecting the non-MPLS-enabled region 124 to the MPLS-enabled region are interfaces that belong to a VRF as 125 described in [RFC4364]. This specification extends the procedures of 126 [I-D.ietf-mpls-mldp-in-band-signaling] so that they may be applied in 127 the VRF context. 129 As in [I-D.ietf-mpls-mldp-in-band-signaling], the scope of this 130 document is limited to the case where the multicast content is 131 distributed in the non-MPLS-enabled regions via PIM-created Source- 132 Specific or Bidirectional trees. Bidirectional trees are always 133 mapped onto Multipoint-to-Multipoint LSPs, and source-specific trees 134 are always mapped onto Point-to-Multipoint LSPs. 136 Note that the procedures described herein do not support non- 137 bidirectional PIM ASM groups, do not support the use of multicast 138 trees other than mLDP multipoint LSPs in the core, and do not provide 139 the capability to aggregate multiple PIM trees onto a single 140 multipoint LSP. If any of those features are needed, they can be 141 provided by the procedures of [RFC6513] and [RFC6514]. However, 142 there are cases where multicast services are offered through VRF 143 interfaces, and where mLDP is used in the core, but where aggregation 144 is not desired. For example, some service providers offer multicast 145 content to their customers, but have chosen to use VRFs to isolate 146 the various customers and services. This is a simpler scenario that 147 one in which the customers provide their own multicast content, out 148 of the control of the service provider, and can be handled with a 149 simpler solution. Also, when PIM trees are mapped one-to-one to 150 multipoint LSPs, it is helpful for troubleshooting purposes to have 151 the PIM source/group addresses encoded into the mLDP FEC element. 153 In order to use the mLDP in-band signaling procedures for a 154 particular group address in the context of a particular set of VRFs, 155 those VRFs MUST be configured with a range of multicast group 156 addresses for which mLDP in-band signaling is to be enabled. This 157 configuration is per VRF ("Virtual Routing and Forwarding table", 158 defined in [RFC4364]). For those groups, and those groups only, the 159 procedures of this document are used. For other groups the general 160 purpose Multicast VPN procedures MAY be used, although it is more 161 likely this VRF is dedicated to mLDP in-band signaling procedures and 162 all other groups are discarded. The configuration must be present in 163 all PE routers that attach to sites containing senders or receivers 164 for the given set of group addresses. Note, since the provider most 165 likely owns the multicast content and how it is transported across 166 the network is transparent to the end-user, no co-oordination needs 167 to happen between the end-user and the provider. 169 1.1. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 1.2. Terminology 177 IP multicast tree : An IP multicast distribution tree identified by 178 an source IP address and/or IP multicast destination address, also 179 referred to as (S,G) and (*,G). 181 mLDP : Multicast LDP. 183 In-band signaling : Using the opaque value of a mLDP FEC element to 184 encode the (S,G) or (*,G) identifying a particular IP multicast 185 tree. 187 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 188 LSRs (see [RFC6388]). 190 MP2MP LSP: An LSP that connects a set of leaf nodes, acting 191 indifferently as ingress or egress (see [RFC6388]). 193 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 195 Ingress LSR: Source of a P2MP LSP, also referred to as root node. 197 VRF: Virtual Routing and Forwarding table. 199 2. VRF In-band signaling for MP LSPs 201 Suppose that a PE router, PE1, receives a PIM Join(S,G) message over 202 one of its VRF interfaces. Following the procedure of section 5.1 of 203 [RFC6513], PE1 determines the "upstream RD", the "upstream PE", and 204 the "upstream multicast hop" (UMH) for the source address S. Please 205 note that sections 5.1.1 and 5.1.2 of [RFC6513] are applicable. 207 In order to transport the multicast tree via a MP LSP using VRF in- 208 band signaling, an mLDP Label Mapping Message is sent by PE1. This 209 message will contain either a P2MP FEC or an MP2MP FEC (see 210 [RFC6388], depending upon whether the PIM tree being transported is a 211 source-specific tree, or a bidirectional tree, respectively. The FEC 212 contains a "root" and an "opaque value". 214 If the UMH and the upstream PE have the same IP address (i.e., the 215 Upstream PE is the UMH), then the root of the Multipoint FEC is set 216 to the IP address of the Upstream PE. If, in the context of this 217 VPN, (S,G) refers to a source-specific MDT, then the values of S, G, 218 and the upstream RD are encoded into the opaque value. If, in the 219 context of this VPN, G is a bidirectional group address, then S is 220 replaced with the value of the RPA associated with G. The coding 221 details are specified in Section 3. Conceptually, the Multipoint FEC 222 can be thought of as an ordered pair: . The mLDP Label Mapping 224 Message is then sent by PE1 on its LDP session to the "next hop" on 225 its path to the upstream PE. The "next hop" is usually the IGP next 226 hop, but see [I-D.ietf-mpls-targeted-mldp] for cases in which the 227 next hop is not the IGP next hop. 229 If the UMH and the upstream PE do not have the same IP address, the 230 procedures of section 2 of [RFC6512] should be applied. The root 231 node of the multipoint FEC is set to the UMH. The recursive opaque 232 value is then set as follows: the root node is set to the upstream 233 PE, and the opaque value is set to the multipoint FEC described in 234 the previous paragraph. That is, the multipoint FEC can be thought 235 of as the following recursive ordered pair: >. 239 The encoding of the multipoint FEC also specifies the "type" of PIM 240 MDT being spliced onto the multipoint LSP. Four types of MDT are 241 defined: IPv4 source-specific tree, IPv6 source-specific tree, IPv4 242 bidirectional tree, and IPv6 bidirectional tree. 244 When a PE router receives an mLDP message with a P2MP or MP2MP FEC, 245 where the PE router itself is the root node, and the opaque value is 246 one of the types defined in Section 3, then it uses the RD encoded in 247 the opaque value field to determine the VRF context. (This RD will 248 be associated with one of the PEs VRFs.) Then, in the context of 249 that VRF, the PE follows the procedure specified in section 2 of 250 [I-D.ietf-mpls-mldp-in-band-signaling]. 252 3. Encoding the Opaque Value of an LDP MP FEC 254 This section documents the different transit opaque encodings. 256 3.1. Transit VPNv4 Source TLV 258 This opaque value type is used when transporting a source-specific 259 mode multicast tree whose source and group addresses are IPv4 260 addresses. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length | Source 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Group 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | ~ 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 ~ RD | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Type: (to be assigned by IANA). 276 Length: 16 278 Source: IPv4 multicast source address, 4 octets. 280 Group: IPv4 multicast group address, 4 octets. 282 RD: Route Distinguisher, 8 octets. 284 3.2. Transit VPNv6 Source TLV 286 This opaque value type is used when transporting a source-specific 287 mode multicast tree whose source and group addresses are IPv6 288 addresses. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | Source ~ 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ~ | Group ~ 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ~ | ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ RD | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Type: (to be assigned by IANA). 304 Length: 40 306 Source: IPv6 multicast source address, 16 octets. 308 Group: IPv6 multicast group address, 16 octets. 310 RD: Route Distinguisher, 8 octets. 312 3.3. Transit VPNv4 bidir TLV 314 This opaque value type is used when transporting a bidirectional 315 multicast tree whose group address is an IPv4 address. The RP 316 address is also an IPv4 address in this case. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Length | Mask Len | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | RP | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Group | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 ~ RD | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type: (to be assigned by IANA). 332 Length: 17 334 Mask Len: The number of contiguous one bits that are left justified 335 and used as a mask, 1 octet. 337 RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4 338 octets. 340 Group: IPv4 multicast group address, 4 octets. 342 RD: Route Distinguisher, 8 octets. 344 3.4. Transit VPNv6 bidir TLV 346 This opaque value type is used when transporting a bidirectional 347 multicast tree whose group address is an IPv6 address. The RP 348 address is also an IPv6 address in this case. 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type | Length | Mask Len | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | RP ~ 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 ~ | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Group ~ 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 ~ | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 ~ RD | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Type: (to be assigned by IANA). 368 Length: 41 370 Mask Len: The number of contiguous one bits that are left justified 371 and used as a mask, 1 octet. 373 RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 374 octets. 376 Group: IPv6 multicast group address, 16 octets. 378 RD: Route Distinguisher, 8 octets. 380 4. Security Considerations 382 The same security considerations apply as for the base LDP 383 specification, described in [RFC5036], and the base mLDP 384 specification, described in [RFC6388] 386 5. IANA considerations 388 [RFC6388] defines a registry for "The LDP MP Opaque Value Element 389 Basic Type". This document requires the assignment of four new code 390 points in this registry: 392 Transit VPNv4 Source TLV type 394 Transit VPNv6 Source TLV type 396 Transit VPNv4 Bidir TLV type 398 Transit VPNv6 Bidir TLV type 400 6. Acknowledgments 402 Thanks to Eric Rosen, Andy Green and Yakov Rekhter for their comments 403 on the draft. 405 7. References 407 7.1. Normative References 409 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 410 Networks (VPNs)", RFC 4364, February 2006. 412 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 413 "Bidirectional Protocol Independent Multicast (BIDIR- 414 PIM)", RFC 5015, October 2007. 416 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 417 Specification", RFC 5036, October 2007. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 423 "Label Distribution Protocol Extensions for Point-to- 424 Multipoint and Multipoint-to-Multipoint Label Switched 425 Paths", RFC 6388, November 2011. 427 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 428 "Using Multipoint LDP When the Backbone Has No Route to 429 the Root", RFC 6512, February 2012. 431 [I-D.ietf-mpls-mldp-in-band-signaling] 432 Wijnands, I., Eckert, T., Leymann, N., and M. Napierala, 433 "Multipoint LDP in-band signaling for Point-to-Multipoint 434 and Multipoint- to-Multipoint Label Switched Paths", 435 draft-ietf-mpls-mldp-in-band-signaling-06 (work in 436 progress), June 2012. 438 7.2. Informative References 440 [I-D.ietf-mpls-targeted-mldp] 441 Napierala, M. and E. Rosen, "Using LDP Multipoint 442 Extensions on Targeted LDP Sessions", 443 draft-ietf-mpls-targeted-mldp-00 (work in progress), 444 August 2012. 446 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 447 VPNs", RFC 6513, February 2012. 449 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 450 Encodings and Procedures for Multicast in MPLS/BGP IP 451 VPNs", RFC 6514, February 2012. 453 Authors' Addresses 455 IJsbrand Wijnands (editor) 456 Cisco Systems 457 De kleetlaan 6a 458 Diegem 1831 459 Belgium 461 Email: ice@cisco.com 462 Paul Hitchen 463 BT 464 BT Adastral Park 465 Ipswich IP53RE 466 UK 468 Email: paul.hitchen@bt.com 470 Nicolai Leymann 471 Deutsche Telekom 472 Winterfeldtstrasse 21 473 Berlin 10781 474 Germany 476 Email: n.leymann@telekom.de 478 Wim Henderickx 479 Alcatel-Lucent 480 Copernicuslaan 50 481 Antwerp 2018 482 Belgium 484 Email: wim.henderickx@alcatel-lucent.com 486 Arkadiy Gulko 487 Thomson Reuters 488 195 Broadway 489 New York NY 10007 490 USA 492 Email: arkadiy.gulko@thomsonreuters.com