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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/