idnits 2.17.1 draft-rekhter-mpls-pim-sm-over-mldp-08.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 13 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft Juniper Networks 4 Intended status: Standards Track 5 Expires: August 2014 Rahul Aggarwal 6 Arktan 8 Nicolai Leymann 9 Deutsche Telekom 11 Wim Henderickx 12 Alcatel-Lucent 14 Quintin Zhao 15 Huawei 17 Richard Li 18 Huawei 20 February 7 2014 22 Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs 24 draft-rekhter-mpls-pim-sm-over-mldp-08.txt 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Abstract 63 When IP multicast trees created by PIM-SM in Any Source Multicast 64 (ASM) mode need to pass through an MPLS domain, it may be desirable 65 to map such trees to Point-to-Multipoint Label Switched Paths. This 66 document describes how to accomplish this in the case where such 67 Point-to-Multipoint Label Switched Paths are established using mLDP. 69 Table of Contents 71 1 Specification of Requirements ......................... 3 72 2 Introduction .......................................... 3 73 3 Option 1 - Non-transitive mapping of IP multicast shared tree 5 74 3.1 Originating Source Active auto-discovery routes (Option 1) 5 75 3.2 Receiving BGP Source Active auto-discovery route by LSR ...6 76 3.3 Handling (S, G, RPT-bit) state ........................ 6 77 4 Option 2 - Transitive mapping of IP multicast shared tree .6 78 4.1 In-band signaling for IP Multicast Shared Tree ........ 7 79 4.2 Originating Source Active auto-discovery routes (Option 2) 8 80 4.3 Receiving BGP Source Active auto-discovery route ...... 9 81 4.4 Pruning Sources off the Shared Tree ................... 9 82 4.5 More on handling (S,G,RPT-bit) state .................. 10 83 5 IANA Considerations ................................... 10 84 6 Security Considerations ............................... 10 85 7 Acknowledgements ...................................... 10 86 8 Normative References .................................. 11 87 9 Informative References ................................ 11 88 10 Authors' Addresses .................................... 11 90 1. Specification of Requirements 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. Introduction 98 [RFC6826] describes how to map Point-to-Multipoint Label Switched 99 Paths (P2MP LSPs) created by mLDP [mLDP] to multicast trees created 100 by PIM-SM in SSM mode [RFC4607]. This document describes how to map 101 mLDP P2MP trees to multicast trees created by PIM-SM in ASM mode. It 102 describes two possible options for doing this. 104 An implementation MAY support Option 1, as described in Section 3 of 105 this document. An implementation MUST support Option 2, as described 106 in Section 4 of this document. 108 Note that from a deployment point of view these two options are 109 mutually exclusive. That is on the same network one could either 110 deploy Option 1, or Option 2, but not both. 112 The reader of this document is expected to be familiar with PIM-SM 113 [RFC4601] and mLDP [mLDP]. 115 This document relies on the procedures in [RFC6826] to support Source 116 Trees. E.g., following these procedures an LSR may initiate a mLDP 117 Label Map with the Transit IPv4/IPv6 Source TLV for (S, G) when 118 receiving PIM (S,G) Join. 120 This document uses BGP Source Active auto-discovery routes, as 121 defined in [MVPN-BGP]. 123 In a deployment scenario where the service provider has provisioned 124 the network in such a way that the RP for a particular ASM group G is 125 always between the receivers and the sources. If the network is 126 provisioned in this manner, the ingress PE for (S,G) is always the 127 same as the ingress PE for the RP, and thus the Source Active A-D 128 routes are never needed. If it is known a priori that the network is 129 provisioned in this manner, mLDP in-band signaling can be supported 130 using a different set of procedures, as specified in [draft- 131 wijnands]. A service provider will provision the PE routers either 132 to use [draft-wijnands] procedures or to use the procedures of this 133 document. 135 Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP 136 LSP in the MPLS network. This type of service works well if the 137 number of LSPs that are created is under control of the MPLS network 138 operator, or if the number of LSPs for a particular service are known 139 to be limited in number. 141 It is to be noted that the existing BGP MVPN [MVPN-BGP] procedures 142 may be used to map Internet IP multicast trees to P2MP LSPs. These 143 procedures would accomplish this for IP multicast trees created by 144 PIM-SM in SSM mode as well as for IP multicast trees created by PIM- 145 SM in ASM mode. Furthermore, these procedures would also support the 146 ability to aggregate multiple IP multicast trees to one P2MP LSP in 147 the MPLS network. The details of this particular approach are out of 148 scope of this document. 150 This document assumes that a given LSR may have some of its 151 interfaces IP multicast capable, while other interfaces being MPLS 152 capable. 154 3. Option 1 - Non-transitive mapping of IP multicast shared tree 156 This option does not transit IP multicast shared trees over the MPLS 157 network. Therefore, when an LSR creates (*, G) state (as a result of 158 receiving PIM messages on one of its IP multicast interfaces), the 159 LSR does not propagate this state in mLDP. 161 3.1. Originating Source Active auto-discovery routes (Option 1) 163 Whenever (as a result of receiving either PIM Register or MSDP 164 messages) a Rendezvous Point (RP) discovers a new multicast source, 165 the RP SHOULD originate a BGP Source Active auto-discovery route. 166 The route carries a single MCAST-VPN NLRI [MVPN-BGP] constructed as 167 follows: 169 + The Route Distinguisher (RD) in this NLRI is set to 0. 171 + The Multicast Source field MUST be set to S. This could be either 172 an IPv4 or an IPv6 address. The Multicast Source Length field is 173 set appropriately to reflect this. 175 + The Multicast Group field MUST be set to G. This could be either 176 an IPv4 or an IPv6 address. The Multicast Group Length field is 177 set appropriately to reflect this. 179 To constrain distribution of the Source Active auto-discovery route 180 to the AS of the advertising RP this route SHOULD carry the NO_EXPORT 181 Community ([RFC1997]). 183 Using the normal BGP procedures the Source Active auto-discovery 184 route is propagated to all other LSRs within the AS. 186 Whenever the RP discovers that the source is no longer active, the RP 187 MUST withdraw the Source Active auto-discovery route, if such a route 188 was previously advertised by the RP. 190 3.2. Receiving BGP Source Active auto-discovery route by LSR 192 Consider an LSR that has some of its interfaces capable of IP 193 multicast and some capable of MPLS multicast. 195 When as a result of receiving PIM messages on one of its IP multicast 196 interfaces such LSR creates in its Tree Information Base (TIB) a new 197 (*, G) entry with a non-empty outgoing interface list that contains 198 one or more IP multicast interfaces, the LSR MUST check if it has any 199 Source Active auto-discovery routes for that G. If there is such a 200 route, S of that route is reachable via an MPLS interface, and the 201 LSR does not have (S, G) state in its TIB for (S, G) carried in the 202 route, then the LSR originates the mLDP Label Map with the Transit 203 IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826]. 205 When an LSR receives a new Source Active auto-discovery route, the 206 LSR MUST check if its TIB contains an (*, G) entry with the same G as 207 carried in the Source Active auto-discovery route. If such an entry 208 is found, S is reachable via an MPLS interface, and the LSR does not 209 have (S, G) state in its TIB for (S, G) carried in the route, then 210 the LSR originates an mLDP Label Map with the Transit IPv4/IPv6 211 Source TLV carrying (S,G), as specified in [RFC6826]. 213 3.3. Handling (S, G, RPT-bit) state 215 Creation and deletion of (S, G, RPT-bit) PIM state ([RFC4601]) on a 216 LSR that resulted from receiving PIM messages on one of its IP 217 multicast interfaces does not result in any mLDP and/or BGP actions 218 by the LSR. 220 4. Option 2 - Transitive mapping of IP multicast shared tree 222 This option enables transit of IP multicast shared trees over the 223 MPLS network. Therefore, when an LSR creates (*, G) state as a result 224 of receiving PIM messages on one of its IP multicast interfaces, the 225 LSR does propagate this state in mLDP, as described below. 227 Note that in the deployment scenarios where for a given G none of the 228 PEs originate an (S, G) mLDP Label Map with the Transit IPv4/IPv6 229 Source TLV, no Source Active auto-discovery routes will be used. One 230 other scenario where no Source Active auto-discovery routes will be 231 used is described in section "Originating Source Active auto- 232 discovery routes (Option 2)". In all these scenarios the only part of 233 Option 2 that will be used is the in-band signaling for IP Multicast 234 Shared Tree, as described in the next section. 236 4.1. In-band signaling for IP Multicast Shared Tree 238 To provide support for in-band mLDP signaling of IP multicast shared 239 trees this document defines two new mLDP TLVs: Transit IPv4 Shared 240 Tree TLV, and Transit IPv6 Shared Tree TLV. 242 These two TLVs have exactly the same encoding/format as the IPv4/IPv6 243 Source Tree TLVs defined in [RFC6826], except that instead of the 244 Source field they have the RP field, and this field carries the 245 address of the RP, as follows: 247 Transit IPv4 Shared Tree TLV: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Length | RP 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Group 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Type: TBD (to be assigned by IANA). 261 Length: 8 263 RP: IPv4 RP address, 4 octets. 265 Group: IPv4 multicast group address, 4 octets. 267 Transit IPv6 Shared Tree TLV: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | RP ~ 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 ~ | Group ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 ~ | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type: TBD (to be assigned by IANA). 281 Length: 32 283 RP: IPv6 RP address, 16 octets. 285 Group: IPv6 multicast group address, 16 octets. 287 Procedures for in-band signaling for IP multicast shared trees with 288 mLDP follow the same procedures as for in-band signaling for IP 289 multicast source trees specified in [RFC6826], except that while the 290 latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the 291 former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs. 293 4.2. Originating Source Active auto-discovery routes (Option 2) 295 Consider an LSR that has some of its interfaces capable of IP 296 multicast and some capable of MPLS multicast. 298 Whenever such LSR creates an (S, G) state as a result of receiving an 299 mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G), if 300 all of the following are true: 302 + S is reachable via one of the IP multicast capable interfaces, 304 + the LSR determines that G is in the PIM-SM in ASM mode range, and 306 + the LSR does not have an (*, G) state with one of the IP 307 multicast capable interfaces as an incoming interface (iif) for 308 that state 310 the LSR MUST originate a BGP Source Active auto-discovery route. 312 The route carries a single MCAST-VPN NLRI constructed as follows: 314 + The RD in this NLRI is set to 0. 316 + The Multicast Source field MUST be set to S. The Multicast Source 317 Length field is set appropriately to reflect this. 319 + The Multicast Group field MUST be set to G. The Multicast Group 320 Length field is set appropriately to reflect this. 322 To constrain distribution of the Source Active auto-discovery route 323 to the AS of the advertising LSR this route SHOULD carry the 324 NO_EXPORT Community ([RFC1997]). 326 Using the normal BGP procedures the Source Active auto-discovery 327 route is propagated to all other LSRs within the AS. 329 Whenever the LSR deletes the (S,G) state that was previously created 330 as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 331 Source TLV for (S,G), the LSR that deletes the state MUST also 332 withdraw the Source Active auto-discovery route, if such a route was 333 advertised when the state was created. 335 Note that whenever an LSR creates an (S,G) state as a result of 336 receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for 337 (S,G) with S reachable via one of the IP multicast capable 338 interfaces, and the LSR already has a (*,G) state with RP reachable 339 via one of the IP multicast capable interfaces as a result of 340 receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree 341 TLV for (*,G), the LSR does not originate a Source Active auto- 342 discovery route. 344 4.3. Receiving BGP Source Active auto-discovery route 346 Procedures for receiving BGP Source Active auto-discovery routes are 347 the same as with Option 1. 349 4.4. Pruning Sources off the Shared Tree 351 If after receiving a new Source Active auto-discovery route for (S,G) 352 the LSR determines that (a) it has the (*, G) entry in its TIB, (b) 353 the incoming interface list (iif) for that entry contains one of the 354 IP interfaces, (c) at least one of the MPLS interfaces is in the 355 outgoing interface list (oif) for that entry, and (d) the LSR does 356 not originate an mLDP Label Mapping message for (S,G) with the 357 Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the 358 (S,G,RPT-bit) downstream state to the Prune state. [Conceptually the 359 PIM state machine on the LSR will act "as if" it had received 360 Prune(S,G,rpt) on one of its MPLS interfaces, without actually having 361 received one.] Depending on the (S,G,RPT-bit) state on the iif, this 362 may result in the LSR using PIM procedures to prune S off the Shared 363 (*,G) tree. 365 The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the 366 Prune state for as long as (a) the outgoing interface list (oif) for 367 (*, G) contains one of the MPLS interfaces, and (b) the LSR has at 368 least one Source Active auto-discovery route for (S,G), and (c) the 369 LSR does not originate the mLDP Label Mapping message for (S,G) with 370 the Transit IPv4/IPv6 Source TLV. Once either of these conditions 371 become no longer valid, the LSR MUST transition the (S,G,RPT-bit) 372 downstream state machine to the NoInfo state. 374 Note that except for the scenario described in the first paragraph of 375 this section, in all other scenarios relying solely on PIM procedures 376 on the LSR is sufficient to ensure the correct behavior when pruning 377 sources off the shared tree. 379 4.5. More on handling (S,G,RPT-bit) state 381 Creation and deletion of (S,G,RPT-bit) state on a LSR that resulted 382 from receiving PIM messages on one of its IP multicast interfaces 383 does not result in any mLDP and/or BGP actions by the LSR. 385 5. IANA Considerations 387 This document requires allocation from the LDP MP Opaque Value 388 Element type name space managed by IANA the following two new mLDP 389 TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared Tree TLV. 391 6. Security Considerations 393 All the security considerations for mLDP ([mLDP]) apply here. 395 7. Acknowledgements 397 Use of Source Active auto-discovery routes was borrowed from [MVPN- 398 BGP]. Some text in this document was borrowed from [MVPN-BGP]. 400 Some of the text in this document was borrowed from [RFC6826]. 402 We would like to acknowledge Arkadiy Gulko for his review and 403 comments. 405 We would also like to thank Xuxiaohu, Gregory Mirsky, and Rajiv Asati 406 for their review and comments. 408 8. Normative References 410 [mLDP] Minei, I., "Label Distribution Protocol Extensions for Point- 411 to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", 412 RFC6388, November 2011. 414 [RFC6826] "In-band signaling for Point-to-Multipoint and Multipoint- 415 to-Multipoint Label Switched Paths", I. Wijnands et al., RFC6826, 416 January 2013 418 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 419 VPNs", R. Aggarwal et al., RFC6514, February 2012 421 [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", 422 RFC1997, August 1996. 424 [RFC2119] "Key words for use in RFCs to Indicate Requirement 425 Levels.", Bradner, RFC2119, March 1997. 427 9. Informative References 429 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 430 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 431 Specification (Revised)", RFC 4601, August 2006. 433 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 434 IP", RFC 4607, August 2006. 436 [draft-wijnands] Wijnands IJ, et. al., "mLDP In-Band Signaling with 437 Wildcards", draft-wijnands-mpls-mldp-in-band-wildcard-encoding, work 438 in progress 440 10. Authors' Addresses 442 Yakov Rekhter 443 Juniper Networks, Inc. 444 e-mail: yakov@juniper.net 446 Rahul Aggarwal 447 e-mail: raggarwa_1@yahoo.com 449 Nicolai Leymann 450 Deutsche Telekom 451 Winterfeldtstrasse 21 452 Berlin 10781 453 Germany 454 e-mail: nicolai.leymann@t-systems.com 456 Wim Henderickx 457 Alcatel-Lucent 458 Email: wim.henderickx@alcatel-lucent.com 460 Richard Li 461 Huawei 462 Email: renwei.li@huawei.com 464 Quintin Zhao 465 Huawei 466 Email: quintin.zhao@huawei.com