idnits 2.17.1 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03.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 (January 17, 2014) is 3750 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 Network Working Group IJ. Wijnands, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track P. Hitchen 5 Expires: July 21, 2014 BT 6 N. Leymann 7 Deutsche Telekom 8 W. Henderickx 9 Alcatel-Lucent 10 A. Gulko 11 Thomson Reuters 12 J. Tantsura 13 Ericsson 14 January 17, 2014 16 Multipoint Label Distribution Protocol 17 In-Band Signaling in a VRF Context 18 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 20 Abstract 22 An IP Multicast Distribution Tree (MDT) may traverse both label 23 switching (i.e. - Multi-Protocol Label Switching, or MPLS) and non- 24 label switching regions of a network. Typically the MDT begins and 25 ends in non-MPLS regions, but travels through an MPLS region. In 26 such cases, it can be useful to begin building the MDT as a pure IP 27 MDT, then convert it to an MPLS Multipoint Label Switched Path (MP- 28 LSP) when it enters an MPLS-enabled region, and then convert it back 29 to a pure IP MDT when it enters a non-MPLS-enabled region. Other 30 documents specify the procedures for building such a hybrid MDT, 31 using Protocol Independent Multicast (PIM) in the non-MPLS region of 32 the network, and using Multipoint Extensions to Label Distribution 33 Protocol (mLDP) in the MPLS region. This document extends those 34 procedures to handle the case where the link connecting the two 35 regions is a "Virtual Routing and Forwarding Table" (VRF) link, as 36 defined in the "BGP IP/MPLS VPN" specifications. However, this 37 document is primarily aimed at particular use cases where VRFs are 38 used to support multicast applications other than Multicast VPN. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on July 21, 2014. 57 Copyright Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Conventions used in this document . . . . . . . . . . . . 5 76 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. VRF In-band signaling for MP LSPs . . . . . . . . . . . . . . 6 78 3. Encoding the Opaque Value of an LDP MP FEC . . . . . . . . . . 7 79 3.1. Transit VPNv4 Source TLV . . . . . . . . . . . . . . . . . 7 80 3.2. Transit VPNv6 Source TLV . . . . . . . . . . . . . . . . . 8 81 3.3. Transit VPNv4 bidir TLV . . . . . . . . . . . . . . . . . 9 82 3.4. Transit VPNv6 bidir TLV . . . . . . . . . . . . . . . . . 10 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 85 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 Sometimes an IP multicast distribution tree (MDT) traverses both 94 MPLS-enabled and non-MPLS-enabled regions of a network. Typically 95 the MDT begins and ends in non-MPLS regions, but travels through an 96 MPLS region. In such cases, it can be useful to begin building the 97 MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP 98 (Label Switched Path) when it enters an MPLS-enabled region, and then 99 convert it back to a pure IP MDT when it enters a non-MPLS-enabled 100 region. Other documents specify the procedures for building such a 101 hybrid MDT, using Protocol Independent Multicast (PIM) in the non- 102 MPLS region of the network, and using Multipoint Extensions to Label 103 Distribution Protocol (mLDP) in the MPLS region. This document 104 extends the procedures from [RFC6826] to handle the case where the 105 link connecting the two regions is a "Virtual Routing and Forwarding 106 Table" (VRF) link, as defined in the "BGP IP/MPLS VPN" specifications 107 [RFC6513]. However, this document is primarily aimed at particular 108 use cases where VRFs are used to support multicast applications other 109 than Multicast VPN. 111 In PIM, a tree is identified by a source address (or in the case of 112 bidirectional trees [RFC5015], a rendezvous point address or "RPA") 113 and a group address. The tree is built from the leaves up, by 114 sending PIM control messages in the direction of the source address 115 or the RPA. In mLDP, a tree is identified by a root address and an 116 "opaque value", and is built by sending mLDP control messages in the 117 direction of the root. The procedures of [RFC6826] explain how to 118 convert a PIM pair into an 119 mLDP pair and how to convert the mLDP pair back into the original PIM pair. 123 However, the procedures in [RFC6826] assume that the routers doing 124 the PIM/mLDP conversion have routes to the source address or RPA in 125 their global routing tables. Thus the procedures cannot be applied 126 exactly as specified when the interfaces connecting the non-MPLS- 127 enabled region to the MPLS-enabled region are interfaces that belong 128 to a VRF as described in [RFC4364]. This specification extends the 129 procedures of [RFC6826] so that they may be applied in the VRF 130 context. 132 As in [RFC6826], the scope of this document is limited to the case 133 where the multicast content is distributed in the non-MPLS-enabled 134 regions via PIM-created Source-Specific or Bidirectional trees. 135 Bidirectional trees are always mapped onto Multipoint-to-Multipoint 136 LSPs, and source-specific trees are always mapped onto Point-to- 137 Multipoint LSPs. 139 Note that the procedures described herein do not support non- 140 bidirectional PIM ASM groups, do not support the use of multicast 141 trees other than mLDP multipoint LSPs in the core, and do not provide 142 the capability to aggregate multiple PIM trees onto a single 143 multipoint LSP. If any of those features are needed, they can be 144 provided by the procedures of [RFC6513] and [RFC6514]. However, 145 there are cases where multicast services are offered through 146 interfaces associated with a VRF, and where mLDP is used in the core, 147 but where aggregation is not desired. For example, some service 148 providers offer multicast content to their customers, but have chosen 149 to use VRFs to isolate the various customers and services. This is a 150 simpler scenario than one in which the customers provide their own 151 multicast content, out of the control of the service provider, and 152 can be handled with a simpler solution. Also, when PIM trees are 153 mapped one-to-one to multipoint LSPs, it is helpful for 154 troubleshooting purposes to have the PIM source/group addresses 155 encoded into the mLDP FEC element. 157 In order to use the mLDP in-band signaling procedures for a 158 particular group address in the context of a particular set of VRFs, 159 those VRFs MUST be configured with a range of multicast group 160 addresses for which mLDP in-band signaling is to be enabled. This 161 configuration is per VRF ("Virtual Routing and Forwarding table", 162 defined in [RFC4364]). For those groups, and those groups only, the 163 procedures of this document are used. For other groups the general 164 purpose Multicast VPN procedures MAY be used, although it is more 165 likely this VRF is dedicated to mLDP in-band signaling procedures and 166 all other groups are discarded. The configuration MUST be present in 167 all PE routers that attach to sites containing senders or receivers 168 for the given set of group addresses. Note, since the provider most 169 likely owns the multicast content and how it is transported across 170 the network is transparent to the end-user, no co-oordination needs 171 to happen between the end-user and the provider. 173 1.1. Conventions used in this document 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 RFC 2119 [RFC2119]. 179 1.2. Terminology 181 IP multicast tree: An IP multicast distribution tree identified by a 182 source IP address and/or IP multicast destination address, also 183 referred to as (S,G) and (*,G). 185 mLDP : Multicast LDP. 187 In-band signaling: Using the opaque value of a mLDP FEC element to 188 encode the (S,G) or (*,G) identifying a particular IP multicast 189 tree. 191 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 192 LSRs (see [RFC6388]). 194 MP2MP LSP: An LSP that connects a set of leaf nodes, acting 195 indifferently as ingress or egress (see [RFC6388]). 197 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 199 Ingress LSR: Source of a P2MP LSP, also referred to as root node. 201 VRF: Virtual Routing and Forwarding table. 203 2. VRF In-band signaling for MP LSPs 205 Suppose that a PE router, PE1, receives a PIM Join(S,G) message over 206 one of its interfaces that is associated with a VRF. Following the 207 procedure of section 5.1 of [RFC6513], PE1 determines the "upstream 208 RD", the "upstream PE", and the "upstream multicast hop" (UMH) for 209 the source address S. 211 In order to transport the multicast tree via an MP LSP using VRF in- 212 band signaling, an mLDP Label Mapping Message is sent by PE1. This 213 message will contain either a P2MP FEC or an MP2MP FEC (see 214 [RFC6388]), depending upon whether the PIM tree being transported is 215 a source-specific tree, or a bidirectional tree, respectively. The 216 FEC contains a "root" and an "opaque value". 218 If the UMH and the upstream PE have the same IP address (i.e., the 219 Upstream PE is the UMH), then the root of the Multipoint FEC is set 220 to the IP address of the Upstream PE. If, in the context of this 221 VPN, (S,G) refers to a source-specific MDT, then the values of S, G, 222 and the upstream RD are encoded into the opaque value. If, in the 223 context of this VPN, G is a bidirectional group address, then S is 224 replaced with the value of the RPA associated with G. 226 The encoding details are specified in Section 3. Conceptually, the 227 Multipoint FEC can be thought of as an ordered pair: 228 {root=; opaque_value=}. The 229 mLDP Label Mapping Message is then sent by PE1 on its LDP session to 230 the "next hop" on the message's path to the upstream PE. The "next 231 hop" is usually the directly connected next hop, but see [RFC7060] 232 for cases in which the next hop is not directly connected. 234 If the UMH and the upstream PE do not have the same IP address, the 235 procedures of section 2 of [RFC6512] should be applied. The root 236 node of the multipoint FEC is set to the UMH. The recursive opaque 237 value is then set as follows: the root node is set to the upstream 238 PE, and the opaque value is set to the multipoint FEC described in 239 the previous paragraph. That is, the multipoint FEC can be thought 240 of as the following recursive ordered pair: {root=; 241 opaque_value=>}. 244 The encoding of the multipoint FEC also specifies the "type" of PIM 245 MDT being spliced onto the multipoint LSP. Four types of MDT are 246 defined in [RFC6826]: IPv4 source-specific tree, IPv6 source-specific 247 tree, IPv4 bidirectional tree, and IPv6 bidirectional tree. 249 When a PE router receives an mLDP message with a P2MP or MP2MP FEC, 250 where the PE router itself is the root node, and the opaque value is 251 one of the types defined in Section 3, then it uses the RD encoded in 252 the opaque value field to determine the VRF context. (This RD will 253 be associated with one of the PEs VRFs.) Then, in the context of 254 that VRF, the PE follows the procedure specified in section 2 of 255 [RFC6826]. 257 3. Encoding the Opaque Value of an LDP MP FEC 259 This section documents the different transit opaque encodings. 261 3.1. Transit VPNv4 Source TLV 263 This opaque value type is used when transporting a source-specific 264 mode multicast tree whose source and group addresses are IPv4 265 addresses. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Length | Source 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Group 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 ~ RD | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type: (to be assigned by IANA). 281 Length: 16 283 Source: IPv4 multicast source address, 4 octets. 285 Group: IPv4 multicast group address, 4 octets. 287 RD: Route Distinguisher, 8 octets. 289 3.2. Transit VPNv6 Source TLV 291 This opaque value type is used when transporting a source-specific 292 mode multicast tree whose source and group addresses are IPv6 293 addresses. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Length | Source ~ 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ | Group ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ~ | ~ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 ~ RD | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Type: (to be assigned by IANA). 309 Length: 40 311 Source: IPv6 multicast source address, 16 octets. 313 Group: IPv6 multicast group address, 16 octets. 315 RD: Route Distinguisher, 8 octets. 317 3.3. Transit VPNv4 bidir TLV 319 This opaque value type is used when transporting a bidirectional 320 multicast tree whose group address is an IPv4 address. The RP 321 address is also an IPv4 address in this case. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length | Mask Len | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | RP | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Group | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 ~ RD | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Type: (to be assigned by IANA). 337 Length: 17 339 Mask Len: The number of contiguous one bits that are left justified 340 and used as a mask, 1 octet. 342 RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4 343 octets. 345 Group: IPv4 multicast group address, 4 octets. 347 RD: Route Distinguisher, 8 octets. 349 3.4. Transit VPNv6 bidir TLV 351 This opaque value type is used when transporting a bidirectional 352 multicast tree whose group address is an IPv6 address. The RP 353 address is also an IPv6 address in this case. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type | Length | Mask Len | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | RP ~ 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 ~ | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Group ~ 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 ~ | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ~ RD | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Type: (to be assigned by IANA). 373 Length: 41 375 Mask Len: The number of contiguous one bits that are left justified 376 and used as a mask, 1 octet. 378 RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 379 octets. 381 Group: IPv6 multicast group address, 16 octets. 383 RD: Route Distinguisher, 8 octets. 385 4. Security Considerations 387 The same security considerations apply as for the base LDP 388 specification, described in [RFC5036], and the base mLDP 389 specification, described in [RFC6388] 391 5. IANA considerations 393 [RFC6388] defines a registry for the "LDP MP Opaque Value Element 394 Basic Type". This document requires the assignment of four new code 395 points in this registry: 397 Transit VPNv4 Source TLV type - requested 250 399 Transit VPNv6 Source TLV type - requested 251 401 Transit VPNv4 Bidir TLV type - requested TBD-1 403 Transit VPNv6 Bidir TLV type - requested TBD-2 405 6. Acknowledgments 407 Thanks to Eric Rosen, Andy Green, Yakov Rekhter and Eric Gray for 408 their comments on the draft. 410 7. References 412 7.1. Normative References 414 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 415 Networks (VPNs)", RFC 4364, February 2006. 417 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 418 "Bidirectional Protocol Independent Multicast (BIDIR- 419 PIM)", RFC 5015, October 2007. 421 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 422 Specification", RFC 5036, October 2007. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 428 "Label Distribution Protocol Extensions for Point-to- 429 Multipoint and Multipoint-to-Multipoint Label Switched 430 Paths", RFC 6388, November 2011. 432 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 433 "Using Multipoint LDP When the Backbone Has No Route to 434 the Root", RFC 6512, February 2012. 436 [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, 437 "Multipoint LDP In-Band Signaling for Point-to-Multipoint 438 and Multipoint-to-Multipoint Label Switched Paths", 439 RFC 6826, January 2013. 441 7.2. Informative References 443 [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP 444 Multipoint Extensions on Targeted LDP Sessions", RFC 7060, 445 November 2013. 447 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 448 VPNs", RFC 6513, February 2012. 450 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 451 Encodings and Procedures for Multicast in MPLS/BGP IP 452 VPNs", RFC 6514, February 2012. 454 Authors' Addresses 456 IJsbrand Wijnands (editor) 457 Cisco Systems 458 De kleetlaan 6a 459 Diegem 1831 460 Belgium 462 Email: ice@cisco.com 463 Paul Hitchen 464 BT 465 BT Adastral Park 466 Ipswich IP53RE 467 UK 469 Email: paul.hitchen@bt.com 471 Nicolai Leymann 472 Deutsche Telekom 473 Winterfeldtstrasse 21 474 Berlin 10781 475 Germany 477 Email: n.leymann@telekom.de 479 Wim Henderickx 480 Alcatel-Lucent 481 Copernicuslaan 50 482 Antwerp 2018 483 Belgium 485 Email: wim.henderickx@alcatel-lucent.com 487 Arkadiy Gulko 488 Thomson Reuters 489 195 Broadway 490 New York NY 10007 491 USA 493 Email: arkadiy.gulko@thomsonreuters.com 495 Jeff Tantsura 496 Ericsson 497 300 Holger Way 498 San Jose, california 95134 499 usa 501 Email: jeff.tantsura@ericsson.com