--- 1/draft-ietf-mpls-pim-sm-over-mldp-02.txt 2014-11-28 07:15:02.493814589 -0800 +++ 2/draft-ietf-mpls-pim-sm-over-mldp-03.txt 2014-11-28 07:15:02.517815179 -0800 @@ -1,34 +1,34 @@ Network Working Group Yakov Rekhter Internet Draft Juniper Networks Intended status: Standards Track -Expires: April 2015 Rahul Aggarwal +Expires: May 2015 Rahul Aggarwal Arktan Nicolai Leymann Deutsche Telekom Wim Henderickx Alcatel-Lucent Quintin Zhao Huawei Richard Li Huawei - October 20, 2014 + November 28, 2014 Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs - draft-ietf-mpls-pim-sm-over-mldp-02.txt + draft-ietf-mpls-pim-sm-over-mldp-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -67,67 +67,69 @@ Point-to-Multipoint Label Switched Paths are established using Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP). Table of Contents 1 Introduction ................................................. 3 1.1 Specification of Requirements ................................ 5 2 Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 5 2.1 Originating Source Active Auto-Discovery Routes (Mechanism 1) .. 5 - 2.2 Receiving BGP Source Active Auto-Discovery Route by LSR ....... 6 + 2.2 Receiving Source Active Auto-Discovery Route by LSR .......... 6 2.3 Handling (S, G, RPT-bit) State ............................... 6 3 Mechanism 2 - Transitive Mapping of IP Multicast Shared Tree ... 6 3.1 In-band Signaling for IP Multicast Shared Trees .............. 7 3.2 Originating Source Active Auto-Discovery Routes (Mechanism 2) .. 8 - 3.3 Receiving BGP Source Active Auto-Discovery Route ............. 9 + 3.3 Receiving Source Active Auto-Discovery Route ................. 9 3.4 Pruning Sources Off the Shared Tree .......................... 9 3.5 More on Handling (S,G,RPT-bit) State ......................... 10 4 IANA Considerations .......................................... 10 5 Security Considerations ...................................... 10 6 Acknowledgements ............................................. 10 7 Normative References ......................................... 11 8 Informative References ....................................... 11 9 Authors' Addresses ........................................... 11 1. Introduction [RFC6826] describes how to map Point-to-Multipoint Label Switched Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees created by PIM-SM in Source-Specific Multicast (SSM) mode [RFC4607]. This document describes how to map mLDP P2MP trees to multicast trees created by PIM-SM in Any-Source Multicast (ASM) mode. It describes two possible mechanisms for doing this. - The first mechanism, described in Section 3, is optional for - implementations, but the second mechanism, described in Section 4, is - mandatory for all implementations claiming conformance to this + The first mechanism, described in Section 2, is OPTIONAL for + implementations, but the second mechanism, described in Section 3, is + REQUIRED for all implementations claiming conformance to this specification. Note that from a deployment point of view these two mechanisms are mutually exclusive. That is on the same network one could deploy either one of the mechanisms, but not both. The reader of this document is expected to be familiar with PIM-SM [RFC4601] and mLDP [RFC6388]. This document relies on the procedures in [RFC6826] to support Source Trees. E.g., following these procedures a Label Switching Router (LSR) may initiate an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G) when receiving a PIM (S,G) Join. This document uses BGP Source Active auto-discovery routes, as - defined in [RFC6514]. + defined in [RFC6514]. For the sake of brevity in the rest of the + document we'll refer to these routes as just "Source Active auto- + discovery routes". - In a deployment scenario where the service provider has provisioned - the network in such a way that the Rendezvous Point (RP) for a - particular ASM group G is always between the receivers and the + Consider a deployment scenario where the service provider has + provisioned the network in such a way that the Rendezvous Point (RP) + for a particular ASM group G is always between the receivers and the sources. If the network is provisioned in this manner, the ingress PE for (S,G) is always the same as the ingress PE for the RP, and thus the Source Active auto-discovery (A-D) routes are never needed. If it is known a priori that the network is provisioned in this manner, mLDP in-band signaling can be supported using a different set of procedures, as specified in [draft-wijnands]. A service provider will provision the PE routers either to use [draft-wijnands] procedures or to use the procedures of this document. Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP @@ -159,22 +161,22 @@ This mechanism does not transit IP multicast shared trees over the MPLS network. Therefore, when an LSR creates (*, G) state (as a result of receiving PIM messages on one of its IP multicast interfaces), the LSR does not propagate this state in mLDP. 2.1. Originating Source Active Auto-Discovery Routes (Mechanism 1) Whenever (as a result of receiving either PIM Register or MSDP messages) an RP discovers a new multicast source, the RP SHOULD - originate a BGP Source Active auto-discovery route. The route carries - a single MCAST-VPN Network Layer Reachability Information (NLRI) + originate a Source Active auto-discovery route. The route carries a + single MCAST-VPN Network Layer Reachability Information (NLRI) [RFC6514] constructed as follows: + The Route Distinguisher (RD) in this NLRI is set to 0. + The Multicast Source field is set to S. This could be either an IPv4 or an IPv6 address. The Multicast Source Length field is set appropriately to reflect the address type. + The Multicast Group field is set to G. This could be either an IPv4 or an IPv6 address. The Multicast Group Length field is set @@ -184,21 +186,21 @@ to the AS of the advertising RP this route SHOULD carry the NO_EXPORT Community ([RFC1997]). Using the normal BGP procedures the Source Active auto-discovery route is propagated to all other LSRs within the AS. Whenever the RP discovers that the source is no longer active, the RP MUST withdraw the Source Active auto-discovery route if such a route was previously advertised by the RP. -2.2. Receiving BGP Source Active Auto-Discovery Route by LSR +2.2. Receiving Source Active Auto-Discovery Route by LSR Consider an LSR that has some of its interfaces capable of IP multicast and some capable of MPLS multicast. When as a result of receiving PIM messages on one of its IP multicast interfaces an LSR creates in its Tree Information Base (TIB) a new (*, G) entry with a non-empty outgoing interface list that contains one or more IP multicast interfaces, the LSR MUST check if it has any Source Active auto-discovery routes for that G. If there is such a route, S of that route is reachable via an MPLS interface, and the @@ -294,22 +296,22 @@ latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs. 3.2. Originating Source Active Auto-Discovery Routes (Mechanism 2) Consider an LSR that has some of its interfaces capable of IP multicast and some capable of MPLS multicast. Whenever such an LSR creates an (S, G) state as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G) - the LSR MUST originate a BGP Source Active auto-discovery route if - all of the following are true: + the LSR MUST originate a Source Active auto-discovery route if all of + the following are true: + S is reachable via one of the IP multicast capable interfaces, + the LSR determines that G is in the PIM-SM in ASM mode range, and + the LSR does not have an (*, G) state with one of the IP multicast capable interfaces as an incoming interface (iif) for that state. The route carries a single MCAST-VPN NLRI constructed as follows: @@ -337,24 +339,24 @@ Note that whenever an LSR creates an (S,G) state as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G) with S reachable via one of the IP multicast capable interfaces, and the LSR already has a (*,G) state with RP reachable via one of the IP multicast capable interfaces as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree TLV for (*,G), the LSR does not originate a Source Active auto- discovery route. -3.3. Receiving BGP Source Active Auto-Discovery Route +3.3. Receiving Source Active Auto-Discovery Route - Procedures for receiving BGP Source Active Auto-Discovery routes are - the same as with Mechanism 1. + Procedures for receiving Source Active Auto-Discovery routes are the + same as with Mechanism 1. 3.4. Pruning Sources Off the Shared Tree If after receiving a new Source Active auto-discovery route for (S,G) the LSR determines that (a) it has the (*, G) entry in its TIB, (b) the incoming interface list (iif) for that entry contains one of the IP interfaces, (c) at least one of the MPLS interfaces is in the outgoing interface list (oif) for that entry, and (d) the LSR does not originate an mLDP Label Mapping message for (S,G) with the Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the @@ -395,20 +397,23 @@ ------+------------------------------+------------ TBD1 | Transit IPv4 Shared Tree TLV | [This.I-D] TBD2 | Transit IPv6 Shared Tree TLV | [This.I-D] IANA is requested to assign consecutive values. 5. Security Considerations All the security considerations for mLDP ([RFC6388]) apply here. + From the security considerations point of view use of Shared Tree + TLVs is no different than use of Source TLVs [RFC6826]. + 6. Acknowledgements Use of Source Active auto-discovery routes was borrowed from [RFC6514]. Some text in this document was borrowed from [RFC6514]. Some of the text in this document was borrowed from [RFC6826]. We would like to acknowledge Arkadiy Gulko for his review and comments. @@ -416,37 +421,37 @@ and Adrian Farrell for their review and comments. 7. Normative References [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", RFC1997, August 1996. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, RFC2119, March 1997. + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol + Specification (Revised)", RFC 4601, August 2006. + [RFC6388] Minei, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC6388, November 2011. [RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", R. Aggarwal et al., RFC6514, February 2012 [RFC6826] "In-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths", I. Wijnands et al., RFC6826, January 2013 8. Informative References - [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, - "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol - Specification (Revised)", RFC 4601, August 2006. - [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [draft-wijnands] Wijnands IJ, et. al., "mLDP In-Band Signaling with Wildcards", draft-ietf-mpls-mldp-in-band-wildcard-encoding, work in progress 9. Authors' Addresses Yakov Rekhter