idnits 2.17.1 draft-ietf-mpls-pim-sm-over-mldp-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 (November 28, 2014) is 3437 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) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: May 2015 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 November 28, 2014 22 Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs 24 draft-ietf-mpls-pim-sm-over-mldp-03.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) 2014 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 Label 68 Distribution Protocol Extensions for Point-to-Multipoint and 69 Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP). 71 Table of Contents 73 1 Introduction ................................................. 3 74 1.1 Specification of Requirements ................................ 5 75 2 Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 5 76 2.1 Originating Source Active Auto-Discovery Routes (Mechanism 1) .. 5 77 2.2 Receiving Source Active Auto-Discovery Route by LSR .......... 6 78 2.3 Handling (S, G, RPT-bit) State ............................... 6 79 3 Mechanism 2 - Transitive Mapping of IP Multicast Shared Tree ... 6 80 3.1 In-band Signaling for IP Multicast Shared Trees .............. 7 81 3.2 Originating Source Active Auto-Discovery Routes (Mechanism 2) .. 8 82 3.3 Receiving Source Active Auto-Discovery Route ................. 9 83 3.4 Pruning Sources Off the Shared Tree .......................... 9 84 3.5 More on Handling (S,G,RPT-bit) State ......................... 10 85 4 IANA Considerations .......................................... 10 86 5 Security Considerations ...................................... 10 87 6 Acknowledgements ............................................. 10 88 7 Normative References ......................................... 11 89 8 Informative References ....................................... 11 90 9 Authors' Addresses ........................................... 11 92 1. Introduction 94 [RFC6826] describes how to map Point-to-Multipoint Label Switched 95 Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees 96 created by PIM-SM in Source-Specific Multicast (SSM) mode [RFC4607]. 97 This document describes how to map mLDP P2MP trees to multicast trees 98 created by PIM-SM in Any-Source Multicast (ASM) mode. It describes 99 two possible mechanisms for doing this. 101 The first mechanism, described in Section 2, is OPTIONAL for 102 implementations, but the second mechanism, described in Section 3, is 103 REQUIRED for all implementations claiming conformance to this 104 specification. 106 Note that from a deployment point of view these two mechanisms are 107 mutually exclusive. That is on the same network one could deploy 108 either one of the mechanisms, but not both. 110 The reader of this document is expected to be familiar with PIM-SM 111 [RFC4601] and mLDP [RFC6388]. 113 This document relies on the procedures in [RFC6826] to support Source 114 Trees. E.g., following these procedures a Label Switching Router 115 (LSR) may initiate an mLDP Label Map with the Transit IPv4/IPv6 116 Source TLV for (S, G) when receiving a PIM (S,G) Join. 118 This document uses BGP Source Active auto-discovery routes, as 119 defined in [RFC6514]. For the sake of brevity in the rest of the 120 document we'll refer to these routes as just "Source Active auto- 121 discovery routes". 123 Consider a deployment scenario where the service provider has 124 provisioned the network in such a way that the Rendezvous Point (RP) 125 for a particular ASM group G is always between the receivers and the 126 sources. If the network is provisioned in this manner, the ingress PE 127 for (S,G) is always the same as the ingress PE for the RP, and thus 128 the Source Active auto-discovery (A-D) routes are never needed. If it 129 is known a priori that the network is provisioned in this manner, 130 mLDP in-band signaling can be supported using a different set of 131 procedures, as specified in [draft-wijnands]. A service provider will 132 provision the PE routers either to use [draft-wijnands] procedures or 133 to use the procedures of this 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 is known 139 to be limited. 141 It is to be noted that the existing BGP Multicast VPN (MVPN) 142 procedures [RFC6514] can be used to map Internet IP multicast trees 143 to P2MP LSPs. These procedures would accomplish this for IP 144 multicast trees created by PIM-SM in SSM mode as well as for IP 145 multicast trees created by PIM-SM in ASM mode. Furthermore, these 146 procedures would also support the ability to aggregate multiple IP 147 multicast trees to one P2MP LSP in the MPLS network. The details of 148 this particular approach are out of 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 1.1. Specification of Requirements 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 162 This mechanism does not transit IP multicast shared trees over the 163 MPLS network. Therefore, when an LSR creates (*, G) state (as a 164 result of receiving PIM messages on one of its IP multicast 165 interfaces), the LSR does not propagate this state in mLDP. 167 2.1. Originating Source Active Auto-Discovery Routes (Mechanism 1) 169 Whenever (as a result of receiving either PIM Register or MSDP 170 messages) an RP discovers a new multicast source, the RP SHOULD 171 originate a Source Active auto-discovery route. The route carries a 172 single MCAST-VPN Network Layer Reachability Information (NLRI) 173 [RFC6514] constructed as follows: 175 + The Route Distinguisher (RD) in this NLRI is set to 0. 177 + The Multicast Source field is set to S. This could be either an 178 IPv4 or an IPv6 address. The Multicast Source Length field is set 179 appropriately to reflect the address type. 181 + The Multicast Group field is set to G. This could be either an 182 IPv4 or an IPv6 address. The Multicast Group Length field is set 183 appropriately to reflect this address type. 185 To constrain distribution of the Source Active auto-discovery route 186 to the AS of the advertising RP this route SHOULD carry the NO_EXPORT 187 Community ([RFC1997]). 189 Using the normal BGP procedures the Source Active auto-discovery 190 route is propagated to all other LSRs within the AS. 192 Whenever the RP discovers that the source is no longer active, the RP 193 MUST withdraw the Source Active auto-discovery route if such a route 194 was previously advertised by the RP. 196 2.2. Receiving Source Active Auto-Discovery Route by LSR 198 Consider an LSR that has some of its interfaces capable of IP 199 multicast and some capable of MPLS multicast. 201 When as a result of receiving PIM messages on one of its IP multicast 202 interfaces an LSR creates in its Tree Information Base (TIB) a new 203 (*, G) entry with a non-empty outgoing interface list that contains 204 one or more IP multicast interfaces, the LSR MUST check if it has any 205 Source Active auto-discovery routes for that G. If there is such a 206 route, S of that route is reachable via an MPLS interface, and the 207 LSR does not have (S, G) state in its TIB for (S, G) carried in the 208 route, then the LSR originates the mLDP Label Map with the Transit 209 IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826]. 211 When an LSR receives a new Source Active auto-discovery route, the 212 LSR MUST check if its TIB contains a (*, G) entry with the same G as 213 carried in the Source Active auto-discovery route. If such an entry 214 is found, S is reachable via an MPLS interface, and the LSR does not 215 have (S, G) state in its TIB for (S, G) carried in the route, then 216 the LSR originates an mLDP Label Map with the Transit IPv4/IPv6 217 Source TLV carrying (S,G), as specified in [RFC6826]. 219 2.3. Handling (S, G, RPT-bit) State 221 Creation and deletion of (S, G, RPT-bit) PIM state ([RFC4601]) on an 222 LSR that resulted from receiving PIM messages on one of its IP 223 multicast interfaces does not result in any mLDP and/or BGP actions 224 by the LSR. 226 3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Tree 228 This mechanism enables transit of IP multicast shared trees over the 229 MPLS network. Therefore, when an LSR creates (*, G) state as a result 230 of receiving PIM messages on one of its IP multicast interfaces, the 231 LSR propagates this state in mLDP, as described below. 233 Note that in the deployment scenarios where for a given G none of the 234 PEs originate an (S, G) mLDP Label Map with the Transit IPv4/IPv6 235 Source TLV, no Source Active auto-discovery routes will be used. One 236 other scenario where no Source Active auto-discovery routes will be 237 used is described in section "Originating Source Active Auto- 238 Discovery Routes (Mechanism 2)". In all these scenarios the only part 239 of Mechanism 2 that is used is the in-band signaling for IP Multicast 240 Shared Trees, as described in the next section. 242 3.1. In-band Signaling for IP Multicast Shared Trees 244 To provide support for in-band mLDP signaling of IP multicast shared 245 trees this document defines two new mLDP TLVs: Transit IPv4 Shared 246 Tree TLV, and Transit IPv6 Shared Tree TLV. 248 These two TLVs have exactly the same encoding/format as the IPv4/IPv6 249 Source Tree TLVs defined in [RFC6826], except that instead of the 250 Source field they have an RP field that carries the address of the 251 RP, as follows: 253 Transit IPv4 Shared Tree TLV: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | RP | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | Group | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Type: TBD1 (to be assigned by IANA). 267 Length: 8 269 RP: IPv4 RP address, 4 octets. 271 Group: IPv4 multicast group address, 4 octets. 273 Transit IPv6 Shared Tree TLV: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | RP ~ 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 ~ | Group ~ 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 ~ | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Type: TBD2 (to be assigned by IANA). 287 Length: 32 289 RP: IPv6 RP address, 16 octets. 291 Group: IPv6 multicast group address, 16 octets. 293 Procedures for in-band signaling for IP multicast shared trees with 294 mLDP follow the same procedures as for in-band signaling for IP 295 multicast source trees specified in [RFC6826], except that while the 296 latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the 297 former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs. 299 3.2. Originating Source Active Auto-Discovery Routes (Mechanism 2) 301 Consider an LSR that has some of its interfaces capable of IP 302 multicast and some capable of MPLS multicast. 304 Whenever such an LSR creates an (S, G) state as a result of receiving 305 an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G) 306 the LSR MUST originate a Source Active auto-discovery route if all of 307 the following are true: 309 + S is reachable via one of the IP multicast capable interfaces, 311 + the LSR determines that G is in the PIM-SM in ASM mode range, and 313 + the LSR does not have an (*, G) state with one of the IP 314 multicast capable interfaces as an incoming interface (iif) for 315 that state. 317 The route carries a single MCAST-VPN NLRI constructed as follows: 319 + The RD in this NLRI is set to 0. 321 + The Multicast Source field is set to S. The Multicast Source 322 Length field is set appropriately to reflect this address type. 324 + The Multicast Group field is set to G. The Multicast Group Length 325 field is set appropriately to reflect this address type. 327 To constrain distribution of the Source Active auto-discovery route 328 to the AS of the advertising LSR this route SHOULD carry the 329 NO_EXPORT Community ([RFC1997]). 331 Using the normal BGP procedures the Source Active auto-discovery 332 route is propagated to all other LSRs within the AS. 334 Whenever the LSR receiving an mLDP Label Map with the Transit 335 IPv4/IPv6 Source TLV for (S,G) deletes the (S,G) state that was 336 previously created, the LSR that deletes the state MUST also withdraw 337 the Source Active auto-discovery route, if such a route was 338 advertised when the state was created. 340 Note that whenever an LSR creates an (S,G) state as a result of 341 receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for 342 (S,G) with S reachable via one of the IP multicast capable 343 interfaces, and the LSR already has a (*,G) state with RP reachable 344 via one of the IP multicast capable interfaces as a result of 345 receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree 346 TLV for (*,G), the LSR does not originate a Source Active auto- 347 discovery route. 349 3.3. Receiving Source Active Auto-Discovery Route 351 Procedures for receiving Source Active Auto-Discovery routes are the 352 same as with Mechanism 1. 354 3.4. Pruning Sources Off the Shared Tree 356 If after receiving a new Source Active auto-discovery route for (S,G) 357 the LSR determines that (a) it has the (*, G) entry in its TIB, (b) 358 the incoming interface list (iif) for that entry contains one of the 359 IP interfaces, (c) at least one of the MPLS interfaces is in the 360 outgoing interface list (oif) for that entry, and (d) the LSR does 361 not originate an mLDP Label Mapping message for (S,G) with the 362 Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the 363 (S,G,RPT-bit) downstream state to the Prune state. (Conceptually the 364 PIM state machine on the LSR will act "as if" it had received 365 Prune(S,G,rpt) on one of its MPLS interfaces, without actually having 366 received one.) Depending on the (S,G,RPT-bit) state on the iif, this 367 may result in the LSR using PIM procedures to prune S off the Shared 368 (*,G) tree. 370 The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the 371 Prune state for as long as (a) the outgoing interface list (oif) for 372 (*, G) contains one of the MPLS interfaces, and (b) the LSR has at 373 least one Source Active auto-discovery route for (S,G), and (c) the 374 LSR does not originate the mLDP Label Mapping message for (S,G) with 375 the Transit IPv4/IPv6 Source TLV. Once either of these conditions 376 become no longer valid, the LSR MUST transition the (S,G,RPT-bit) 377 downstream state machine to the NoInfo state. 379 Note that except for the scenario described in the first paragraph of 380 this section, it is sufficient to rely solely on the PIM procedures 381 on the LSR to ensure the correct behavior when pruning sources off 382 the shared tree. 384 3.5. More on Handling (S,G,RPT-bit) State 386 Creation and deletion of (S,G,RPT-bit) state on a LSR that resulted 387 from receiving PIM messages on one of its IP multicast interfaces 388 does not result in any mLDP and/or BGP actions by the LSR. 390 4. IANA Considerations 392 IANA maintains a registry called "Label Distribution Protocol (LDP) 393 Parameters" with a subregistry called "LDP MP Opaque Value Element 394 basic type". IANA is requested to allocate two new values as follows: 396 Value | Name | Reference 397 ------+------------------------------+------------ 398 TBD1 | Transit IPv4 Shared Tree TLV | [This.I-D] 399 TBD2 | Transit IPv6 Shared Tree TLV | [This.I-D] 401 IANA is requested to assign consecutive values. 403 5. Security Considerations 405 All the security considerations for mLDP ([RFC6388]) apply here. 407 From the security considerations point of view use of Shared Tree 408 TLVs is no different than use of Source TLVs [RFC6826]. 410 6. Acknowledgements 412 Use of Source Active auto-discovery routes was borrowed from 413 [RFC6514]. Some text in this document was borrowed from [RFC6514]. 415 Some of the text in this document was borrowed from [RFC6826]. 417 We would like to acknowledge Arkadiy Gulko for his review and 418 comments. 420 We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati, 421 and Adrian Farrell for their review and comments. 423 7. Normative References 425 [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", 426 RFC1997, August 1996. 428 [RFC2119] "Key words for use in RFCs to Indicate Requirement 429 Levels.", Bradner, RFC2119, March 1997. 431 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 432 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 433 Specification (Revised)", RFC 4601, August 2006. 435 [RFC6388] Minei, I., "Label Distribution Protocol Extensions for 436 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 437 Paths", RFC6388, November 2011. 439 [RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 440 VPNs", R. Aggarwal et al., RFC6514, February 2012 442 [RFC6826] "In-band signaling for Point-to-Multipoint and Multipoint- 443 to-Multipoint Label Switched Paths", I. Wijnands et al., RFC6826, 444 January 2013 446 8. Informative References 448 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 449 IP", RFC 4607, August 2006. 451 [draft-wijnands] Wijnands IJ, et. al., "mLDP In-Band Signaling with 452 Wildcards", draft-ietf-mpls-mldp-in-band-wildcard-encoding, work in 453 progress 455 9. Authors' Addresses 457 Yakov Rekhter 458 Juniper Networks, Inc. 459 e-mail: yakov@juniper.net 461 Rahul Aggarwal 462 e-mail: raggarwa_1@yahoo.com 464 Nicolai Leymann 465 Deutsche Telekom 466 Winterfeldtstrasse 21 467 Berlin 10781 468 Germany 469 e-mail: nicolai.leymann@t-systems.com 471 Wim Henderickx 472 Alcatel-Lucent 473 Email: wim.henderickx@alcatel-lucent.com 475 Quintin Zhao 476 Huawei 477 Email: quintin.zhao@huawei.com 479 Richard Li 480 Huawei 481 Email: renwei.li@huawei.com