--- 1/draft-rekhter-mpls-pim-sm-over-mldp-03.txt 2013-08-21 10:14:23.381211008 -0700 +++ 2/draft-rekhter-mpls-pim-sm-over-mldp-04.txt 2013-08-21 10:14:23.401211532 -0700 @@ -1,19 +1,19 @@ Network Working Group Yakov Rekhter (Juniper Networks) Internet Draft Rahul Aggarwal Intended Status: Proposed Standard Nicolai Leymann (Deutsche Telekom) -Expiration Date: February 2014 July 29, 2013 +Expiration Date: March 2014 August 2, 2013 Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs - draft-rekhter-mpls-pim-sm-over-mldp-03.txt + draft-rekhter-mpls-pim-sm-over-mldp-04.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. @@ -65,48 +65,41 @@ IN-BAND-SIGNALLING] describes how to accomplish this when the trees are created by PIM-SM in SSM mode [RFC4607], but does not describe how to accomplish this when the trees are created by PIM-SM in ASM mode [RFC4601]. This document describes how a combination of mLDP and BGP can be used to accomplish this for multicast trees created by PIM-SM in ASM mode, and P2MP LSPs created by mLDP. It describes two possible options for doing this. - An implementation MUST support Option 1, as described in Section 2 of - this document. An implementation MAY support Option 2, as described + An implementation MAY support Option 1, as described in Section 2 of + this document. An implementation MUST support Option 2, as described in Section 3 of this document. - A deployment of the procedures specified in this document MAY use - neither Option 1, nor Option 2 if all the Last Hop Routers and RPs - are provisioned to return FALSE in the SwitchToSPTDesired [RFC4601]. - This document uses BGP Source Active auto-discovery routes, as defined in [MVPN-BGP]. Like [MLDP-IN-BAND-SIGNALLING], each IP multicast tree is mapped one- to-one to a P2MP LSP in the MPLS network. This type of service works well if the number of LSPs that are created is under control of the MPLS network operator, or if the number of LSPs for a particular service are known to be limited in number. It is to be noted that the existing BGP MVPN [MVPN-BGP] procedures may be used to map Internet IP multicast trees to P2MP LSPs. These procedures would accomplish this for IP multicast trees created by PIM-SM in SSM mode as well as for IP multicast trees created by PIM- SM in ASM mode. Furthermore, these procedures would also support the ability to aggregate multiple IP multicast trees to one P2MP LSP in the MPLS network. The details of this particular approach are out of - scope of this document. The approach specified in this document can - be viewed as an optimization, compared to the reuse of the entire BGP - MVPN procedures, and may be beneficial in certain deployment - scenarios. + scope of this document. 2. Option 1 This option 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 @@ -164,20 +157,29 @@ from receiving PIM messages on one of its IP multicast interfaces does not result in any mLDP and/or BGP actions by the LSR. 3. Option 2 This option enables transit of 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 propagate this state in mLDP, as described below. + Note that in the deployment scenarios where for a given G none of the + PEs originate an (S, G) mLDP Label Map with the Transit IPv4/IPv6 + Source TLV, no Source Active auto-discovery routes will be used. One + other scenario where no Source Active auto-discovery route will be + used is described in section "Originating Source Active auto- + discovery routes". In all these scenarios the only part of Option 2 + that will be used is the in-band signaling for IP Multicast Shared + Tree, as described in the next section. + 3.1. In-band signaling for IP Multicast Shared Tree To provide support for in-band mLDP signaling of IP multicast shared trees this document defines two new mLDP TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared Tree TLV. These two TLVs have exactly the same encoding/format as the IPv4/IPv6 Source Tree TLVs defined in [MLDP-IN-BAND-SIGNALLING], except that instead of the Source field they have the RP field, and this field carries the address of the RP. @@ -188,47 +190,65 @@ that while the 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 Consider an LSR that has some of its interfaces capable of IP multicast and some capable of MPLS multicast. Whenever such 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), S is - reachable via one of the IP multicast capable interfaces, and the LSR - determines that G is in the PIM-SM in ASM mode range, the LSR MUST - originate a BGP Source Active auto-discovery route. The route carries - a single MCAST-VPN NLRI constructed as follows: + mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G), 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 LSR MUST originate a BGP Source Active auto-discovery route. + + The route carries a single MCAST-VPN NLRI constructed as follows: + The RD in this NLRI is set to 0. - + The Multicast Source field MUST be set to S. The Multicast - Source Length field is set appropriately to reflect this. + + The Multicast Source field MUST be set to S. The Multicast Source + Length field is set appropriately to reflect this. + The Multicast Group field MUST be set to G. The Multicast Group Length field is set appropriately to reflect this. To constrain distribution of the Source Active auto-discovery route to the AS of the advertising LSR 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 LSR deletes the (S, G) state that was previously created as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G), the LSR that deletes the state MUST also withdraw the Source Active auto-discovery route, if such a route was advertised when the state was created. + 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, as a result of receiving an mLDP Label Map with the + Transit IPv4/IPv6 Shared Tree TLV for (*, G), the LSR already has a + (*, G) state with RP reachable via one of the IP multicast capable + interfaces, the LSR does not originate a Source Active auto-discovery + route. + 3.3. Receiving BGP Source Active auto-discovery route Procedures for receiving BGP Source Active auto-discovery routes are the same as with Option 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