--- 1/draft-ietf-mpls-seamless-mcast-10.txt 2014-06-02 11:14:27.487369920 -0700 +++ 2/draft-ietf-mpls-seamless-mcast-11.txt 2014-06-02 11:14:27.571371978 -0700 @@ -1,33 +1,34 @@ Network Working Group Y. Rekhter Internet Draft Juniper Networks +Intended status: Standards Track Expiration Date: December 2014 R. Aggarwal T. Morin France Telecom I. Grosclaude France Telecom N. Leymann Deutsche Telekom AG S. Saad AT&T - June 2 2014 + June 3 2014 Inter-Area P2MP Segmented LSPs - draft-ietf-mpls-seamless-mcast-10.txt + draft-ietf-mpls-seamless-mcast-11.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. @@ -187,26 +188,26 @@ document complements those procedures, as it extends the segmented P2MP LSP model such that it is applicable to inter-area P2MP service LSPs as well. Infact an inter-AS deployment could use inter-AS segmented P2MP LSPs as specified in [RFC6514, VPLS-P2MP] where each intra-AS segment is constructed using inter-area segmented P2MP LSPs as specified in this document. 3. General Assumptions and Terminology This document allows ABRs, acting as Route Reflectors, to follow the - procedures specified in [SEAMLESS-MPLS] when handling BGP Next-Hop of + procedures specified in [SEAMLESS-MPLS] when handling BGP Next Hop of the routes to the PEs. Specifically, when reflecting such routes from the non-backbone areas into the backbone area, the ABRs MUST set BGP - Next-Hop to their own loopback addresses (next-hop-self), while when + Next Hop to their own loopback addresses (next-hop-self), while when reflecting such routes from the backbone area into the non-backbone - areas, the ABRs SHOULD NOT change the BGP Next-Hop addresses (next- + areas, the ABRs SHOULD NOT change the BGP Next Hop addresses (next- hop-unchanged). While this document allows ABRs to follow the procedures specified in [SEAMLESS-MPLS], procedures specified in this document are applicable even when ABRs do not follow the procedures specified in [SEAMLESS- MPLS]. One possible way to support the global table multicast service is by relying on the MVPN procedures, as specified in [RFC6514], in which case the MVPN procedures specified in this document would be used to @@ -215,21 +216,21 @@ service. This document refers to this approach as "global table multicast" (although this by no means imply that this alternative approach is the only way to support the global table multicast service). This document assumes that in the context of global table multicast ABRs do not carry routes to the destinations external to their own AS. Furthermore, in the context of global table multicast this document assumes that an ASBR, when re-advertising into IBGP routes received from an external speaker (received via EBGP) may not change - BGP Next-Hop to self. + BGP Next Hop to self. Within an AS a P2MP service LSP is partitioned into 3 segments: ingress area segment, backbone area segment, and egress area segment. Within each area a segment is carried over an intra-area P2MP LSP or instantiated using ingress replication. When intra-area P2MP LSPs are used to instantiate the intra-area segments there could be either 1:1 or n:1 mapping between intra-area segments of the inter-area P2MP service LSP and a given intra-area P2MP LSP. The latter is realized using P2MP LSP hierarchy with @@ -363,30 +364,29 @@ community in the I-PMSI/S-PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to follow the procedures in this document when these procedures differ from those in [RFC6514]. If an ASBR receives from an IBGP peer an I-PMSI or S-PMSI A-D route that carries the Inter-area P2MP Segmented Next-Hop Extended Community, then before re-advertising this route to an EBGP peer the ASBR SHOULD remove this Community from the route. If an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP peer, and - this route does carry the Inter-area P2MP Segmented Next- Hop - Extended Community, if the inter-area P2MP service LSP signalled by - this route should not be segmented, then before re-advertising this - route to its IBGP peers the ASBR MUST remove this community from the - route. + this route does carry the Inter-area P2MP Segmented Next-Hop Extended + Community, if the inter-area P2MP service LSP signalled by this route + should not be segmented, then before re-advertising this route to its + IBGP peers the ASBR MUST remove this community from the route. To avoid requiring ABRs to participate in the propagation of C- multicast routes, this document requires ABRs NOT to modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. For consistency - this document requires ABRs to NOT modify BGP Next-Hop when re- + this document requires ABRs to NOT modify BGP Next Hop when re- advertising both Intra-AS and Inter-AS I-PMSI/S-PMSI A-D routes. The egress PEs may advertise the C-multicast routes to RRs that are different than the ABRs. However ABRs still can be configured to be the Route Reflectors for C-multicast routes, in which case they will participate in the propagation of C-multicast routes. 5.2. BGP VPLS or LDP VPLS with BGP auto-discovery Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, using the VPLS A-D routes that are originated by the ingress PEs @@ -515,21 +515,21 @@ area, then this upstream node would be an egress ABR. If the egress PE/ASBR is in the backbone area and the ingress PE/ASBR is not in the backbone area, then this upstream node would be an ingress ABR. If the egress PE/ASBR is in the same area as the ingress PE/ASBR, then this upstream node would be the ingress PE/ASBR. 6.1.1. Upstream Node for MVPN or VPLS If the application is MVPN or VPLS, then the upstream node's IP address is the IP address determined from the Global Administrator - field of the Inter-area P2MP Segmented Next-hop Extended Community. + field of the Inter-area P2MP Segmented Next-Hop Extended Community. As described in section 5 ("Discovering P2MP FEC of the Inter-Area P2MP Service LSP"), this Extended Community MUST be carried in the MVPN or VPLS A-D route from which the P2MP FEC of the inter-area P2MP Segmented Service LSP is determined. 6.1.2. Upstream Node for Global Table Multicast If the application is global table multicast, then the unicast routes to multicast sources/RPs SHOULD carry the VRF Route Import Extended Community [RFC6514] where the IP address in the Global Administrator @@ -546,22 +546,22 @@ Further, if the application is global table multicast, then the BGP unicast routes that advertise the routes to the IP addresses of PEs/ASBRs/ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended Community. The IP address in the Global Administrator field of this community MUST be set to the IP address of the PE or ASBR or ABR advertising the unicast route. The Local Administrator field of this community MUST be set to 0. If it is not desirable to advertise the P2MP Segmented Next-Hop Extended Community in BGP unicast routes, then the BGP unicast routes to the IP addresses of PEs/ASBRs/ABRs MUST be advertised using the multicast SAFI i.e. SAFI 2, and such - routes MUST carry the Inter-area P2MP Segmented Next-hop Extended - Community. The procedures for handling the BGP Next-Hop attribute of + routes MUST carry the Inter-area P2MP Segmented Next-Hop Extended + Community. The procedures for handling the BGP Next Hop attribute of SAFI 2 routes are the same as those of handling regular Unicast routes and MAY follow [SEAMLESS-MPLS]. If the application is global table multicast, then in order to determine the upstream node address the egress PE first determines the ingress PE. In order to determine the ingress PE, the egress PE determines the best route to reach S/RP. The ingress PE address is the IP address determined from the Global Administrator field of the VRF Route Import Extended Community that is carried in this route. The egress PE then finds the best unicast route to reach the ingress @@ -885,22 +885,22 @@ If the value of the third octet of the MCAST-VPN NLRI of the received Leaf A-D route is either 0x01, or 0x02, or 0x03, this indicates that the Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D route (see section "Leaf A-D Route for Global Table Multicast"). In this case the egress ABR MUST find a S-PMSI or I-PMSI route whose NLRI has the same value as the Route Key field of the received Leaf A-D route. If such a matching route is found then the Leaf A-D route MUST be accepted. If the Leaf A-D route is accepted and if it is the first Leaf A-D route update for the Route Key field in the route, or - the withdrawl of the last Leaf A-D route for the Route Key field then - the following procedures will be executed. + the withdrawal of the last Leaf A-D route for the Route Key field + then the following procedures will be executed. If the RD of the received Leaf A-D route is set to all 0s or all 1s then the received Leaf A-D route is for the global table multicast service. If the received Leaf A-D route is the first Leaf A-D route update for the Route Key field carried in the route, then the egress ABR originates a Leaf A-D route, whose MCAST-VPN NLRI is constructed as follows. @@ -914,21 +914,21 @@ Router's IP Address field of the route. To constrain distribution of this route the originating egress ABR constructs an IP-based Route Target Extended Community by placing the IP address of the upstream node in the Global Administrator field of the community, with the Local Administrator field of this community set to 0, and sets the Extended Communities attribute of this Leaf A- D route to that community. The upstream node's IP address is the IP address determined from the - Global Administrator field of the Inter-area P2MP Segmented Next-hop + Global Administrator field of the Inter-area P2MP Segmented Next-Hop Extended Community, where this Extended Community is obtained as follows. When the Leaf A-D route is for MVPN or VPLS, then this Extended Community is the one carried in the I-PMSI/S-PMSI A-D route that matches the Leaf A-D route. When the Leaf A-D route is for global table multicast, then this Extended Community is the one carried in the best unicast route to the Ingress PE. The Ingress PE address is determined from the received Leaf A-D route. The best unicast route MUST first be determined from multicast SAFI i.e., SAFI 2 routes, if present. @@ -943,21 +943,21 @@ segment then the Leaf A-D route originated by the egress ABR MUST carry a downstream assigned label in the P-Tunnel Attribute where the P-Tunnel type is set to Ingress Replication. The ABR MUST assign a distinct MPLS label for each Leaf A-D route that it originates. In order to support global table multicast an egress ABR MUST auto- configure an import AS-based Route Target Extended Community with the Global Administrator field set to the AS of the ABR and the Local Administrator field set to 0. - If the received Leaf A-D route is the withdrawl of the last Leaf A-D + If the received Leaf A-D route is the withdrawal of the last Leaf A-D route for the Route Key carried in the route, then the egress ABR must withdraw the Leaf A-D route associated with that Route Key that has been previously advertised by the egress ABR in the backbone area. 7.2. P2MP LSP as the Intra-Area LSP in the Egress Area This section describes procedures for using intra-area P2MP LSPs in the egress area. The procedures that are common to both P2MP RSVP-TE and P2MP LDP are described first, followed by procedures that are @@ -1010,43 +1010,43 @@ 1s, then this is the case of inter-area P2MP service LSP being associated with the global table multicast service. The procedures for this are described below. 7.2.2.1. Global Table Multicast and S-PMSI A-D Routes This section applies only if it is desirable to send a particular (S, G) or (*, G) global table multicast flow only to those egress PEs that have receivers for that multicast flow. - If the egress ABR have not previousely received (and re-advertised) - an S-PMSI A-D route for (S, G) or (*, G) that has been originated by - an ingress PE/ASBR (see section "P2MP LSP as the Intra-Area LSP in - the Ingress Area"), then the egress ABR MUST originate a S-PMSI A-D + If the egress ABR have not previously received (and re-advertised) an + S-PMSI A-D route for (S, G) or (*, G) that has been originated by an + ingress PE/ASBR (see section "P2MP LSP as the Intra-Area LSP in the + Ingress Area"), then the egress ABR MUST originate a S-PMSI A-D route. The PMSI Tunnel attribute of the route MUST contain the identity of the intra-area P2MP LSP and an upstream assigned MPLS label (although this label may be an Implicit NULL - see section "General Assumptions and Terminology"). The RD, Multicast Source Length, Multicast Source, Multicast Group Length (1 octet), and Multicast Group fields of the NLRI of this route are the same as of the received Leaf A-D route. The Originating Router's IP address field in the S-PMSI A-D route is the same as the Ingress PE's IP address field in the received Leaf A-D route. The Route Target of this route is an AS-specific Route Target Extended Community with the Global Administrator field set to the AS of the advertising ABR, and the Local Administrator field is set to 0. The route MUST carry the Inter-area P2MP Segmented Next-Hop Extended Community. This community is constructed following the procedures in section 4 ("Inter-area P2MP Segmented Next-Hop Extended Community"). The egress ABR MUST advertise this route into the egress area. PEs in the egress area that participate in the global table multicast will - import this route. + import this route based on the Route Target carried by the route. A PE in the egress area that originated the Leaf A-D route SHOULD join the P2MP LSP advertised in the PMSI Tunnel attribute of the S- PMSI A-D route. 7.2.2.2. Global Table Multicast and Wildcard S-PMSI A-D Routes It may be desirable for an ingress PE to carry multiple multicast flows associated with the global table multicast over the same inter- area P2MP service LSP. This can be achieved using wildcard, i.e., @@ -1323,37 +1323,37 @@ egress areas uses PIM based IP/GRE P-tunnels. As far as the ABRs are concerned PIM signaling for such P-Tunnels is handled as per the ingress/egress PE global table multicast procedures specified in this document. To facilitate this the ABRs may advertise their loopback addresses in BGP using multicast-SAFI i.e., SAFI 2, if non-congruence between unicast and multicast is desired. 12. MVPN with Virtual Hub-and-Spoke Procedures described in this document could be used in conjunction - with the Virtual Hub-and-Spoke procedures [virtual-hub-and-spoke]. + with the Virtual Hub-and-Spoke procedures [RFC7024]. This document does not place any restrictions on the placement of Virtual Hubs and Virtual Spokes. In addition to I-PMSI/S-PMSI A-D routes, the procedures described in this document are applicable to Associated-V-spoke-only I-PMSI A-D routes. In the scenario where a V-hub, as a result of importing an S-PMSI A-D route in its VRF, originates an S-PMSI A-D route targeted to its V- - spokes (as specified in section "Case 2" of [virtual-hub-and-spoke]), - the V-hub SHOULD be able to control via configuration whether the - Inter-area P2MP Segmented Next-Hop Extended Community, if present in - the received S-PMSI A-D route, be also carried in the originated S- - PMSI A-D route. By default if the received S-PMSI A-D route carries - the Inter-area P2MP Segmented Next-Hop Extended Community, then the + spokes (as specified in section "Case 2" of [RFC7024]), the V-hub + SHOULD be able to control via configuration whether the Inter-area + P2MP Segmented Next-Hop Extended Community, if present in the + received S-PMSI A-D route, be also carried in the originated S-PMSI + A-D route. By default if the received S-PMSI A-D route carries the + Inter-area P2MP Segmented Next-Hop Extended Community, then the originated S-PMSI A-D route SHOULD also carry this community. 13. Data Plane This section describes the data plane procedures on the ABRs, ingress PEs, egress PEs and transit routers. 13.1. Data Plane Procedures on ABRs When procedures in this document are followed to signal inter-area @@ -1748,22 +1748,22 @@ Rosen, et al., RFC6625, May 2012 [VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, draft-ietf-l2vpn-vpls-mcast, work in progress 18.2. Informative References [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., draft-ietf-mpls-seamless-mpls, work in progress - [virtual-hub-and-spoke] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", - Huajin Jeng et. al., draft-ietf-l3vpn-virtual-hub, work in progress + [RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et. + al., RFC7024, October 2013 19. Author's Address Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@juniper.net Rahul Aggarwal @@ -1785,11 +1785,11 @@ Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 DE Email: n.leymann@telekom.de Samir Saad AT&T - Email: ss2539@att.com + Email: samirsaad1@outlook.com