draft-ietf-mpls-seamless-mcast-06.txt   draft-ietf-mpls-seamless-mcast-07.txt 
Network Working Group Y. Rekhter Network Working Group Y. Rekhter
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: July 2013 Expiration Date: October 2013
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
January 22 2013 May 14 2013
Inter-Area P2MP Segmented LSPs Inter-Area P2MP Segmented LSPs
draft-ietf-mpls-seamless-mcast-06.txt draft-ietf-mpls-seamless-mcast-07.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 3, line 12 skipping to change at page 3, line 12
that use such inter-area service LSPs may be BGP MVPN, VPLS that use such inter-area service LSPs may be BGP MVPN, VPLS
multicast, or global table multicast over MPLS. multicast, or global table multicast over MPLS.
Table of Contents Table of Contents
1 Specification of requirements ......................... 4 1 Specification of requirements ......................... 4
2 Introduction .......................................... 4 2 Introduction .......................................... 4
3 General Assumptions and Terminology ................... 5 3 General Assumptions and Terminology ................... 5
4 Inter-area P2MP Segmented Next-Hop Extended Community . 7 4 Inter-area P2MP Segmented Next-Hop Extended Community . 7
5 Discovering P2MP FEC of Inter-Area P2MP Service LSP ... 7 5 Discovering P2MP FEC of Inter-Area P2MP Service LSP ... 7
5.1 BGP MVPN .............................................. 7 5.1 BGP MVPN .............................................. 8
5.2 BGP VPLS or LDP VPLS with BGP auto-discovery .......... 9 5.2 BGP VPLS or LDP VPLS with BGP auto-discovery .......... 9
5.3 Global Table Multicast over MPLS ...................... 10 5.3 Global Table Multicast over MPLS ...................... 11
6 Egress PE Procedures .................................. 11 6 Egress PE/ASBR Procedures ............................. 11
6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 11 6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 12
6.1.1 Upstream Node for MVPN or VPLS ........................ 11 6.1.1 Upstream Node for MVPN or VPLS ........................ 12
6.1.2 Upstream Node for Global Table Multicast .............. 12 6.1.2 Upstream Node for Global Table Multicast .............. 12
6.2 Originating a Leaf A-D Route .......................... 13 6.2 Originating a Leaf A-D Route .......................... 13
6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 13 6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 13
6.2.2 Leaf A-D Route for Global Table Multicast ............. 13 6.2.2 Leaf A-D Route for Global Table Multicast ............. 14
6.2.3 Constructing the Rest of the Leaf A-D Route ........... 15 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 16
6.3 PIM-SM in ASM mode for Global Table Multicast ......... 16 6.3 PIM-SM in ASM mode for Global Table Multicast ......... 16
6.3.1 Option 1 .............................................. 16 6.3.1 Option 1 .............................................. 16
6.3.1.1 Originating Source Active A-D Routes .................. 16 6.3.1.1 Originating Source Active A-D Routes .................. 17
6.3.1.2 Receiving BGP Source Active A-D Route by PE ........... 17 6.3.1.2 Receiving BGP Source Active A-D Route by PE ........... 17
6.3.1.3 Handling (S, G, RPTbit) state ......................... 17 6.3.1.3 Handling (S, G, RPTbit) state ......................... 18
6.3.2 Option 2 .............................................. 17 6.3.2 Option 2 .............................................. 18
6.3.2.1 Originating Source Active A-D Routes .................. 17 6.3.2.1 Originating Source Active A-D Routes .................. 18
6.3.2.2 Receiving BGP Source Active A-D Route ................. 18 6.3.2.2 Receiving BGP Source Active A-D Route ................. 19
6.3.2.3 Pruning Sources off the Shared Tree ................... 18 6.3.2.3 Pruning Sources off the Shared Tree ................... 19
6.3.2.4 More on handling (S, G, RPTbit) state ................. 19 6.3.2.4 More on handling (S, G, RPTbit) state ................. 20
7 Egress ABR Procedures ................................. 19 7 Egress ABR Procedures ................................. 20
7.1 Handling Leaf A-D route on Egress ABR ................. 19 7.1 Handling Leaf A-D route on Egress ABR ................. 20
7.2 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 21 7.2 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 22
7.2.1 Received Leaf A-D route is for MVPN or VPLS ........... 21 7.2.1 Received Leaf A-D route is for MVPN or VPLS ........... 22
7.2.2 Received Leaf A-D route is for global table multicast . 22 7.2.2 Received Leaf A-D route is for global table multicast . 23
7.2.2.1 Global Table Multicast and S-PMSI A-D Routes .......... 22 7.2.2.1 Global Table Multicast and S-PMSI A-D Routes .......... 23
7.2.2.2 Global Table Multicast and Wildcard S-PMSI A-D Routes . 23 7.2.2.2 Global Table Multicast and Wildcard S-PMSI A-D Routes . 24
7.2.3 Global Table Multicast and the Expected Upstream Node . 24 7.2.3 Global Table Multicast and the Expected Upstream Node . 24
7.2.4 P2MP LDP LSP as the Intra-Area P2MP LSP ............... 24 7.2.4 P2MP LDP LSP as the Intra-Area P2MP LSP ............... 25
7.2.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........... 24 7.2.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........... 25
7.3 Ingress Replication in the Egress Area ................ 25 7.3 Ingress Replication in the Egress Area ................ 25
8 Ingress ABR Procedures ................................ 25 8 Ingress ABR Procedures ................................ 26
8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 25 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 26
8.2 Ingress Replication in the Backbone Area .............. 26 8.2 Ingress Replication in the Backbone Area .............. 26
9 Ingress PE/ASBR Procedures ............................ 26 9 Ingress PE/ASBR Procedures ............................ 27
9.1 P2MP LSP as the Intra-Area LSP in the Ingress Area .... 27 9.1 P2MP LSP as the Intra-Area LSP in the Ingress Area .... 28
9.2 Ingress Replication in the Ingress Area ............... 28 9.2 Ingress Replication in the Ingress Area ............... 28
10 Common Tunnel Type in the Ingress and Egress Areas .... 28 10 Common Tunnel Type in the Ingress and Egress Areas .... 29
11 Placement of Ingress and Egress PEs ................... 29 11 Placement of Ingress and Egress PEs ................... 30
12 Data Plane ............................................ 29 12 MVPN with Virtual Hub-and-Spoke ....................... 30
12.1 Data Plane Procedures on ABRs ......................... 29 13 Data Plane ............................................ 31
12.2 Data Plane Procedures on Egress PEs ................... 30 13.1 Data Plane Procedures on ABRs ......................... 31
12.3 Data Plane Procedures on Ingress PEs .................. 31 13.2 Data Plane Procedures on Egress PEs ................... 31
12.4 Data Plane Procedures on Transit Routers .............. 31 13.3 Data Plane Procedures on Ingress PEs .................. 32
13 Support for Inter-Area Transport LSPs ................. 31 13.4 Data Plane Procedures on Transit Routers .............. 33
13.1 Transport Tunnel Tunnel Type .......................... 31 14 Support for Inter-Area Transport LSPs ................. 33
13.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 32 14.1 Transport Tunnel Tunnel Type .......................... 33
13.3 Discovering P2MP FEC of P2MP Transport LSP ............ 32 14.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 33
13.4 Egress PE Procedures for P2MP Transport LSP ........... 33 14.3 Discovering P2MP FEC of P2MP Transport LSP ............ 34
13.5 Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP 34 14.4 Egress PE Procedures for P2MP Transport LSP ........... 34
13.6 Discussion ............................................ 35 14.5 Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP 35
14 IANA Considerations ................................... 36 14.6 Discussion ............................................ 36
15 Security Considerations ............................... 37 15 IANA Considerations ................................... 38
16 Acknowledgements ...................................... 37 16 Security Considerations ............................... 38
17 References ............................................ 37 17 Acknowledgements ...................................... 38
17.1 Normative References .................................. 37 18 References ............................................ 38
17.2 Informative References ................................ 38 18.1 Normative References .................................. 38
18 Author's Address ...................................... 38 18.2 Informative References ................................ 39
19 Author's Address ...................................... 40
1. Specification of requirements 1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document describes procedures for building inter-area point-to- This document describes procedures for building inter-area point-to-
skipping to change at page 8, line 41 skipping to change at page 8, line 51
Note that the procedures in the above paragraph apply when intra-area Note that the procedures in the above paragraph apply when intra-area
segments are realized by either intra-area P2MP LSPs or by ingress segments are realized by either intra-area P2MP LSPs or by ingress
replication. replication.
When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or
propagated to signal Inter-area P2MP service LSPs, to indicate that propagated to signal Inter-area P2MP service LSPs, to indicate that
these LSPs should be segmented using the procedures specified in this these LSPs should be segmented using the procedures specified in this
document, these routes MUST carry the Inter-area P2MP Segmented Next- document, these routes MUST carry the Inter-area P2MP Segmented Next-
Hop Extended Community. This Extended Community MUST be included in Hop Extended Community. This Extended Community MUST be included in
the I-PMSI/S-PMSI A-D route by the PE or ASBR that originates such a the I-PMSI/S-PMSI A-D route by the PE that originates such a route,
route, and the Global Administrator field MUST be set to the or an ASBR that re-advertises such a route into its own AS. The
advertising PE or ASBR's IP address. This Extended Community MUST Global Administrator field in this Extended Community MUST be set to
the advertising PE or ASBR's IP address. This Extended Community MUST
also be included by ABRs as they re-advertise such routes. An ABR also be included by ABRs as they re-advertise such routes. An ABR
MUST set the Global Administrator field of the P2MP Segmented Next- MUST set the Global Administrator field of the P2MP Segmented Next-
Hop Extended Community to its own IP address. Presence of this Hop Extended Community to its own IP address. Presence of this
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
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.
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.
skipping to change at page 11, line 5 skipping to change at page 11, line 32
This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP. This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP.
For each such P2MP FEC there MAY exist a distinct inter-area P2MP For each such P2MP FEC there MAY exist a distinct inter-area P2MP
service LSP, or multiple such FECs MAY be carried over a single P2MP service LSP, or multiple such FECs MAY be carried over a single P2MP
service LSP using a wildcard (*, *) S-PMSI [RFC6625]. service LSP using a wildcard (*, *) S-PMSI [RFC6625].
Note that this document does not require the use of (*, G) Inter-area Note that this document does not require the use of (*, G) Inter-area
P2MP service LSPs when global table multicast uses PIM-SM in ASM P2MP service LSPs when global table multicast uses PIM-SM in ASM
mode. In fact, PIM-SM in ASM mode may be supported entirely by using mode. In fact, PIM-SM in ASM mode may be supported entirely by using
only (S, G) inter-area P2MP service LSPs. only (S, G) inter-area P2MP service LSPs.
6. Egress PE Procedures 6. Egress PE/ASBR Procedures
This section describes egress PE procedures for constructing This section describes egress PE/ASBR procedures for constructing
segmented inter-area P2MP LSP. The procedures in this section apply segmented inter-area P2MP LSP. The procedures in this section apply
irrespective of whether the egress PE is in a leaf IGP area, or the irrespective of whether the egress PE/ASBR is in a leaf IGP area, or
backbone area, or even in the same IGP area as the ingress PE/ASBR. the backbone area, or even in the same IGP area as the ingress
PE/ASBR.
An egress PE applies procedures specified in this section to MVPN I- An egress PE/ASBR applies procedures specified in this section to
PMSI or S-PMSI A-D routes only if these routes carry the Inter-area MVPN I-PMSI or S-PMSI A-D routes only if these routes carry the
P2MP Segmented Next-Hop Extended Community. An egress PE applies Inter-area P2MP Segmented Next-Hop Extended Community. An egress PE
procedures specified in this section to VPLS A-D routes or VPLS S- applies procedures specified in this section to VPLS A-D routes or
PMSI A-D routes only if these routes carry the Inter-area P2MP VPLS S-PMSI A-D routes only if these routes carry the Inter-area P2MP
Segmented Next-Hop Extended Community. Segmented Next-Hop Extended Community.
In order to support global table multicast an egress PE MUST auto- In order to support global table multicast an egress PE MUST auto-
configure an import AS-specific Route Target Extended Community configure an import AS-specific Route Target Extended Community
([RFC4360]) with the Global Administrator field set to the AS of the ([RFC4360]) with the Global Administrator field set to the AS of the
PE and the Local Administrator field set to 0. PE and the Local Administrator field set to 0.
Once an egress PE discovers the P2MP FEC of an inter-area segmented Once an egress PE/ASBR discovers the P2MP FEC of an inter-area
P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in
construct the segmented inter-area P2MP service LSP. This propagation order to construct the segmented inter-area P2MP service LSP. This
uses BGP Leaf A-D routes. propagation uses BGP Leaf A-D routes.
6.1. Determining the Upstream ABR/PE/ASBR (Upstream Node) 6.1. Determining the Upstream ABR/PE/ASBR (Upstream Node)
An egress PE discovers the P2MP FEC of an inter-area P2MP Segmented An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP
Service LSP as described in section 5 ("Discovering P2MP FEC of the Segmented Service LSP as described in section 5 ("Discovering P2MP
Inter-Area P2MP Service LSP"). Once the egress PE discovers this P2MP FEC of the Inter-Area P2MP Service LSP"). Once the egress PE/ASBR
FEC, it MUST determine the upstream node to reach such a FEC. If the discovers this P2MP FEC, it MUST determine the upstream node to reach
egress PE is in the egress area, and the ingress PE is not in the such a FEC. If the egress PE/ASBR and the ingress PE/ASBR are not in
that egress area, then this upstream node would be an egress ABR. If the same area, and the egress PE/ASBR is not in the backbone IGP
the egress PE is in the backbone area and the ingress PE is not in area, then this upstream node would be an egress ABR. If the egress
the backbone area, then this upstream node would be an ingress ABR. PE/ASBR is in the backbone area and the ingress PE/ASBR is not in the
If the egress PE is in the same area as the ingress PE, then this backbone area, then this upstream node would be an ingress ABR. If
upstream node would be the ingress PE. 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 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.
skipping to change at page 16, line 39 skipping to change at page 17, line 23
route carries a single MCAST-VPN NLRI constructed as follows: route carries a single MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to 0. + The RD in this NLRI is set to 0.
+ The Multicast Source field MUST be set to S. The Multicast + The Multicast Source field MUST be set to S. The Multicast
Source Length field is set appropriately to reflect this. Source Length field is set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. The Multicast Group + The Multicast Group field MUST be set to G. The Multicast Group
Length field is set appropriately to reflect this. Length field is set appropriately to reflect this.
The Route Target of this Source Active A-D route is an AS-specific
Route Target Extended Community with the Global Administrator field
set to the AS of the advertising RP/PE, and the Local Administrator
field is set to 0.
To constrain distribution of the Source Active A-D route to the AS of To constrain distribution of the Source Active A-D route to the AS of
the advertising RP this route SHOULD carry the NO_EXPORT Community the advertising RP this route SHOULD carry the NO_EXPORT Community
([RFC1997]). ([RFC1997]).
Using the normal BGP procedures the Source Active A-D route is Using the normal BGP procedures the Source Active A-D route is
propagated to all other PEs within the AS. propagated to all other PEs within the AS.
Whenever the RP/PE discovers that the source is no longer active, the Whenever the RP/PE discovers that the source is no longer active, the
RP MUST withdraw the Source Active A-D route, if such a route was RP MUST withdraw the Source Active A-D route, if such a route was
previously advertised by the RP. previously advertised by the RP.
skipping to change at page 18, line 11 skipping to change at page 18, line 43
MCAST-VPN NLRI constructed as follows: MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to 0. + The RD in this NLRI is set to 0.
+ The Multicast Source field MUST be set to S. The Multicast + The Multicast Source field MUST be set to S. The Multicast
Source Length field is set appropriately to reflect this. Source Length field is set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. The Multicast Group + The Multicast Group field MUST be set to G. The Multicast Group
Length field is set appropriately to reflect this. Length field is set appropriately to reflect this.
The Route Target of this Source Active A-D route is an AS-specific
Route Target Extended Community with the Global Administrator field
set to the AS of the advertising PE, and the Local Administrator
field is set to 0.
To constrain distribution of the Source Active A-D route to the AS of To constrain distribution of the Source Active A-D route to the AS of
the advertising PE this route SHOULD carry the NO_EXPORT Community the advertising PE this route SHOULD carry the NO_EXPORT Community
([RFC1997]). ([RFC1997]).
Using the normal BGP procedures the Source Active A-D route is Using the normal BGP procedures the Source Active A-D route is
propagated to all other PEs within the AS. propagated to all other PEs within the AS.
Whenever the PE deletes the (S, G) state that was previously created Whenever the PE deletes the (S, G) state that was previously created
as a result of receiving a Leaf A-D route for (S, G), the PE that as a result of receiving a Leaf A-D route for (S, G), the PE that
deletes the state MUST also withdraw the Source Active A-D route, if deletes the state MUST also withdraw the Source Active A-D route, if
skipping to change at page 19, line 39 skipping to change at page 20, line 31
this ABR, then the following procedures will be executed. this ABR, then the following procedures will be executed.
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, else it MUST be discarded. If the Leaf A-D route MUST be accepted, else it MUST be discarded. If the Leaf A-D route
is accepted and if its the first Leaf A-D route update for the Route is accepted and if it is the first Leaf A-D route update for the
Key field in the route, or the withdrawl of the last Leaf A-D route Route Key field in the route, or the withdrawl of the last Leaf A-D
for the Route Key field then the following procedures will be route for the Route Key field then the following procedures will be
executed. 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 24, line 38 skipping to change at page 25, line 26
7.2.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP 7.2.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP
If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress
area, then the egress ABR can either (a) graft the leaf (whose IP area, then the egress ABR can either (a) graft the leaf (whose IP
address is specified in the received Leaf A-D route) into an existing address is specified in the received Leaf A-D route) into an existing
P2MP LSP rooted at the egress ABR, and use that LSP for carrying P2MP LSP rooted at the egress ABR, and use that LSP for carrying
traffic for the inter-area segmented P2MP service LSP, or (b) traffic for the inter-area segmented P2MP service LSP, or (b)
originate a new P2MP LSP to be used for carrying (S,G). originate a new P2MP LSP to be used for carrying (S,G).
When the RD of the received Leaf A-D route is all 0s or all 1s, then When the RD of the received Leaf A-D route is all 0s or all 1s, then
the procedures are as described in section 7.1.2 ("RD of the received the procedures are as described in section "Received Leaf A-D route
Leaf A-D route is all 0s or all 1s"). is for global table multicast".
Note also that the SESSION object that the egress ABR would use for Note also that the SESSION object that the egress ABR would use for
the intra-area P2MP LSP need not encode the P2MP FEC from the the intra-area P2MP LSP need not encode the P2MP FEC from the
received Leaf A-D route. received Leaf A-D route.
7.3. Ingress Replication in the Egress Area 7.3. Ingress Replication in the Egress Area
When Ingress Replication is used to instantiate the egress area When Ingress Replication is used to instantiate the egress area
segment then the Leaf A-D route advertised by the egress PE MUST segment then the Leaf A-D route advertised by the egress PE 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
skipping to change at page 25, line 43 skipping to change at page 26, line 26
In order to support global table multicast the ingress ABR MUST be In order to support global table multicast the ingress ABR MUST be
auto-configured with an import AS-based Route Target Extended auto-configured with an import AS-based Route Target Extended
Community whose Global Administrator field is set to the AS of the Community whose Global Administrator field is set to the AS of the
ABR and the Local Administrator field is set to 0. ABR and the Local Administrator field is set to 0.
8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area 8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area
The procedures for binding the backbone area segment of an inter-area The procedures for binding the backbone area segment of an inter-area
P2MP LSP to the intra-area P2MP LSP in the backbone area are the same P2MP LSP to the intra-area P2MP LSP in the backbone area are the same
as in section 7 ("Egress ABR Procedures") and sub-section 7.1 ("P2MP as in section "Egress ABR Procedures" and sub-section "P2MP LSP as
LSP as the Intra-Area LSP in the Egress Area"), with egress PE being the Intra-Area LSP in the Egress Area", with egress PE being replace
replace by egress ABR, egress ABR being replaced by ingress ABR, and by egress ABR, egress ABR being replaced by ingress ABR, and egress
egress area being replaced by backbone area. This applies to the area being replaced by backbone area. This applies to the inter-area
inter-area P2MP LSPs associated with either MVPN, or VPLS, or global P2MP LSPs associated with either MVPN, or VPLS, or global table
table multicast. multicast.
It is to be noted that in the case of global table multicast, if the It is to be noted that in the case of global table multicast, if the
backbone area uses wildcard S-PMSI, then the egress area also SHOULD backbone area uses wildcard S-PMSI, then the egress area also SHOULD
use wildcard S-PMSI for global table multicast, or the egress ABRs use wildcard S-PMSI for global table multicast, or the egress ABRs
MUST be able to disaggregate traffic carried over the wildcard S-PMSI MUST be able to disaggregate traffic carried over the wildcard S-PMSI
onto the egress area (S, G) or (*, G) S-PMSIs. The procedures for onto the egress area (S, G) or (*, G) S-PMSIs. The procedures for
such disaggregation require IP processing on the egress ABRs. such disaggregation require IP processing on the egress ABRs.
8.2. Ingress Replication in the Backbone Area 8.2. Ingress Replication in the Backbone Area
skipping to change at page 27, line 21 skipping to change at page 28, line 13
machine to Pruned state for the (S/RP, G). machine to Pruned state for the (S/RP, G).
9.1. P2MP LSP as the Intra-Area LSP in the Ingress Area 9.1. P2MP LSP as the Intra-Area LSP in the Ingress Area
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 (which indicates that Leaf A-D route is either 0x01, or 0x02, or 0x03 (which 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), and P2MP LSP is used as the the intra-area LSP in the A-D route), and P2MP LSP is used as the the intra-area LSP in the
ingress area, then the procedures for binding the ingress area ingress area, then the procedures for binding the ingress area
segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the
ingress area, are the same as in section 7 ("Egress ABR Procedures") ingress area, are the same as in section "Egress ABR Procedures" and
and sub-section 7.1.1 ("P2MP LSP as the Intra-Area LSP in the Egress sub-section "P2MP LSP as the Intra-Area LSP in the Egress Area".
Area").
When the RD of the received Leaf A-D route is all 0s or all 1s, as is When the RD of the received Leaf A-D route is all 0s or all 1s, as is
the case where the inter-area service P2MP LSP is associated with the the case where the inter-area service P2MP LSP is associated with the
global table multicast service, then the ingress PE MAY originate a global table multicast service, then the ingress PE MAY originate a
S-PMSI A-D route with the RD, multicast source, multicast group S-PMSI A-D route with the RD, multicast source, multicast group
fields being the same as those in the received Leaf A-D route. fields being the same as those in the received Leaf A-D route.
Further in the case of global table multicast an ingress PE MAY Further in the case of global table multicast an ingress PE MAY
originate a wildcard S-PMSI A-D route as per the procedures in originate a wildcard S-PMSI A-D route as per the procedures in
[RFC6625] with the RD set to 0. This route may be originated by the [RFC6625] with the RD set to 0. This route may be originated by the
skipping to change at page 29, line 26 skipping to change at page 30, line 26
ingress and egress areas and its desirable to carry global table ingress and egress areas and its desirable to carry global table
multicast over MPLS in the backbone area. This may also be the case multicast over MPLS in the backbone area. This may also be the case
if the service is MVPN and the P-tunnel technology in the ingress and if the service is MVPN and the P-tunnel technology in the ingress and
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. Data Plane 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].
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
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 This section describes the data plane procedures on the ABRs, ingress
PEs, egress PEs and transit routers. PEs, egress PEs and transit routers.
12.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
P2MP Segmented LSPs, then ABRs are required to perform only MPLS P2MP Segmented LSPs, then ABRs are required to perform only MPLS
switching. When an ABR receives a MPLS packet from an "incoming" switching. When an ABR receives a MPLS packet from an "incoming"
intra-area segment of the inter-area P2MP Segmented LSP, it forwards intra-area segment of the inter-area P2MP Segmented LSP, it forwards
the packet, based on MPLS switching, onto another "outgoing" intra- the packet, based on MPLS switching, onto another "outgoing" intra-
area segment of the inter-area P2MP Segmented LSP. area segment of the inter-area P2MP Segmented LSP.
If the outgoing intra-area segment is instantiated using a P2MP LSP, If the outgoing intra-area segment is instantiated using a P2MP LSP,
and if there is a one-to-one mapping between the outgoing intra-area and if there is a one-to-one mapping between the outgoing intra-area
skipping to change at page 30, line 13 skipping to change at page 31, line 38
LSP. LSP.
If the outgoing intra-area segment is instantiated using ingress If the outgoing intra-area segment is instantiated using ingress
replication then the ABR must pop the incoming segment's label stack replication then the ABR must pop the incoming segment's label stack
and replicate the packet once to each leaf ABR or PE of the outgoing and replicate the packet once to each leaf ABR or PE of the outgoing
intra-area segment. The label stack of the packet sent to each such intra-area segment. The label stack of the packet sent to each such
leaf MUST first include a downstream assigned label assigned by the leaf MUST first include a downstream assigned label assigned by the
leaf to the segment, followed by the label stack of the P2P or MP2P leaf to the segment, followed by the label stack of the P2P or MP2P
LSP to the leaf. LSP to the leaf.
12.2. Data Plane Procedures on Egress PEs 13.2. Data Plane Procedures on Egress PEs
An egress PE must first identify the inter-area P2MP segmented LSP An egress PE must first identify the inter-area P2MP segmented LSP
based on the incoming label stack. After this identification the based on the incoming label stack. After this identification the
egress PE must forward the packet using the application that is bound egress PE must forward the packet using the application that is bound
to the inter-area P2MP segmented LSP. to the inter-area P2MP segmented LSP.
Note that the application specific forwarding for MVPN service may Note that the application specific forwarding for MVPN service may
require the egress PE to determine whether the packets were received require the egress PE to determine whether the packets were received
from the expected sender PE. When the application is MVPN then the from the expected sender PE. When the application is MVPN then the
FEC of an inter-area P2MP Segmented LSP is at the granularity of the FEC of an inter-area P2MP Segmented LSP is at the granularity of the
skipping to change at page 31, line 5 skipping to change at page 32, line 27
VE-ID. VE-ID.
When the application is global table multicast it is sufficient for When the application is global table multicast it is sufficient for
the label stack to include identification of the sender upstream the label stack to include identification of the sender upstream
node. When P2MP LSPs are used this requires that PHP MUST be turned node. When P2MP LSPs are used this requires that PHP MUST be turned
off. When Ingress Replication is used the egress PE knows the off. When Ingress Replication is used the egress PE knows the
incoming downstream assigned label to which it has bound a particular incoming downstream assigned label to which it has bound a particular
(S/*, G) and must accept packets with only that label for that (S/*, (S/*, G) and must accept packets with only that label for that (S/*,
G). G).
12.3. Data Plane Procedures on Ingress PEs 13.3. Data Plane Procedures on Ingress PEs
An Ingress PE must perform application specific forwarding procedures An Ingress PE must perform application specific forwarding procedures
to identify the outgoing inta-area segment of an incoming packet. to identify the outgoing inta-area segment of an incoming packet.
If the outgoing intra-area segment is instantiated using a P2MP LSP, If the outgoing intra-area segment is instantiated using a P2MP LSP,
and if there is a one-to-one mapping between the outgoing intra-area and if there is a one-to-one mapping between the outgoing intra-area
segment and the P2MP LSP, then the ingress PE MUST encapsulate the segment and the P2MP LSP, then the ingress PE MUST encapsulate the
packet in the label stack of the outgoing P2MP LSP. If there is a packet in the label stack of the outgoing P2MP LSP. If there is a
many-to-one mapping between outgoing intra-area segments and the P2MP many-to-one mapping between outgoing intra-area segments and the P2MP
LSP then the PE MUST first push the upstream assigned label LSP then the PE MUST first push the upstream assigned label
skipping to change at page 31, line 27 skipping to change at page 33, line 5
been assigned, and then push the label stack of the outgoing P2MP been assigned, and then push the label stack of the outgoing P2MP
LSP. LSP.
If the outgoing intra-area segment is instantiated using ingress If the outgoing intra-area segment is instantiated using ingress
replication then the PE must replicate the packet once to each leaf replication then the PE must replicate the packet once to each leaf
ABR or PE of the outgoing intra-area segment. The label stack of the ABR or PE of the outgoing intra-area segment. The label stack of the
packet sent to each such leaf MUST first include a downstream packet sent to each such leaf MUST first include a downstream
assigned label assigned by the leaf to the segment, followed by the assigned label assigned by the leaf to the segment, followed by the
label stack of the P2P or MP2P LSP to the leaf. label stack of the P2P or MP2P LSP to the leaf.
12.4. Data Plane Procedures on Transit Routers 13.4. Data Plane Procedures on Transit Routers
When procedures in this document are followed to signal inter-area When procedures in this document are followed to signal inter-area
P2MP Segmented LSPs then transit routers in each area perform only P2MP Segmented LSPs then transit routers in each area perform only
MPLS switching. MPLS switching.
13. Support for Inter-Area Transport LSPs 14. Support for Inter-Area Transport LSPs
This section describes OPTIONAL procedures that allow to aggregate This section describes OPTIONAL procedures that allow to aggregate
multiple (inter-area) P2MP service LSPs into a single inter-area P2MP multiple (inter-area) P2MP service LSPs into a single inter-area P2MP
transport LSPs, and then apply the segmentation procedures, as transport LSP, and then apply the segmentation procedures, as
specified in this document, to these inter-area P2MP transport LSPs specified in this document, to these inter-area P2MP transport LSPs
(rather than applying these procedures directly to the inter-area (rather than applying these procedures directly to the inter-area
P2MP service LSPs). P2MP service LSPs).
13.1. Transport Tunnel Tunnel Type 14.1. Transport Tunnel Tunnel Type
For the PMSI Tunnel Attribute we define a new Tunnel type, called For the PMSI Tunnel Attribute we define a new Tunnel type, called
"Transport Tunnel", whose Tunnel Identifier is a tuple <Source PE "Transport Tunnel", whose Tunnel Identifier is a tuple <Source PE
Address, Local Number>. This Tunnel type is assigned a value of 8. Address, Local Number>. This Tunnel type is assigned a value of 8.
The Source PE Address is the address of the PE that originates the The Source PE Address is the address of the PE that originates the
(service) A-D route that carries this attribute, and the Local Number (service) A-D route that carries this attribute, and the Local Number
is a number that is unique to the Source PE. The length of the Local is a number that is unique to the Source PE. The length of the Local
Number part is the same as the length of the Source PE Address. Thus Number part is the same as the length of the Source PE Address. Thus
if the Source PE Address is an IPv4 address, then the Local Number if the Source PE Address is an IPv4 address, then the Local Number
part is 4 octets, and if the Source PE Address is an IPv6 address, part is 4 octets, and if the Source PE Address is an IPv6 address,
then the Local Number part is 16 octets. then the Local Number part is 16 octets.
13.2. Discovering Leaves of the Inter-Area P2MP Service LSP 14.2. Discovering Leaves of the Inter-Area P2MP Service LSP
When aggregating multiple P2MP LSPs using P2MP LSP hierarchy, When aggregating multiple P2MP LSPs using P2MP LSP hierarchy,
determining the leaf nodes of the LSPs being aggregated is essential determining the leaf nodes of the LSPs being aggregated is essential
for being able to tradeoff the overhead due to the P2MP LSPs vs for being able to tradeoff the overhead due to the P2MP LSPs vs
suboptimal use of bandwidth due to the partial congruency of the LSPs suboptimal use of bandwidth due to the partial congruency of the LSPs
being aggregated. being aggregated.
Therefore, if a PE that is a root of a given service P2MP LSP wants Therefore, if a PE that is a root of a given service P2MP LSP wants
to aggregate this LSP with other (service) P2MP LSPs rooted at the to aggregate this LSP with other (service) P2MP LSPs rooted at the
same PE into an inter-area P2MP transport LSP, the PE should first same PE into an inter-area P2MP transport LSP, the PE should first
skipping to change at page 32, line 32 skipping to change at page 34, line 10
To accomplish this the PE sets the PMSI Tunnel attribute of the To accomplish this the PE sets the PMSI Tunnel attribute of the
service A-D route (an I-PMSI or S-PMSI A-D route for MVPN or VPLS service A-D route (an I-PMSI or S-PMSI A-D route for MVPN or VPLS
service) associated with that LSP as follows. The Tunnel Type is set service) associated with that LSP as follows. The Tunnel Type is set
to "No tunnel information present", Leaf Information Required flag is to "No tunnel information present", Leaf Information Required flag is
set to 1, the route MUST NOT carry the P2MP Segmented Next-Hop set to 1, the route MUST NOT carry the P2MP Segmented Next-Hop
Extended Community. In contrast to the procedures for the MVPN and Extended Community. In contrast to the procedures for the MVPN and
VPLS A-D routes described so far, the Route Reflectors that VPLS A-D routes described so far, the Route Reflectors that
participate in the distribution of this route need not be ABRs. participate in the distribution of this route need not be ABRs.
13.3. Discovering P2MP FEC of P2MP Transport LSP 14.3. Discovering P2MP FEC of P2MP Transport LSP
Once the ingress PE determines all the leaves of a given P2MP service Once the ingress PE determines all the leaves of a given P2MP service
LSP, the PE (using some local to the PE criteria) selects a LSP, the PE (using some local to the PE criteria) selects a
particular inter-area transport P2MP LSP to be used for carrying the particular inter-area transport P2MP LSP to be used for carrying the
(inter-area) service P2MP LSP. (inter-area) service P2MP LSP.
Once the PE selects the transport P2MP LSP, the PE (re)originates the Once the PE selects the transport P2MP LSP, the PE (re)originates the
service A-D route. The PMSI Tunnel attribute of this route now service A-D route. The PMSI Tunnel attribute of this route now
carries the Tunnel Identifier of the selected transport LSP, with the carries the Tunnel Identifier of the selected transport LSP, with the
Tunnel Type set to "Transport Tunnel". If the transport LSP carries Tunnel Type set to "Transport Tunnel". If the transport LSP carries
multiple P2MP service LSPs, then the MPLS Label field in the multiple P2MP service LSPs, then the MPLS Label field in the
attribute carries an upstream-assigned label assigned by the PE that attribute carries an upstream-assigned label assigned by the PE that
is bound to the P2MP FEC of the inter-area P2MP service LSP. is bound to the P2MP FEC of the inter-area P2MP service LSP.
Otherwise, this field is set to Implicit NULL. Otherwise, this field is set to Implicit NULL.
Just as described earlier, this service A-D route MUST NOT carry the Just as described earlier, this service A-D route MUST NOT carry the
P2MP Segmented Next-Hop Extended Community. Just as described P2MP Segmented Next-Hop Extended Community. Just as described
earlier, the Route Reflectors that participate in the distribution of earlier, the Route Reflectors that participate in the distribution of
this route need not be ABRs. this route need not be ABRs.
13.4. Egress PE Procedures for P2MP Transport LSP 14.4. Egress PE Procedures for P2MP Transport LSP
When an egress PE receives and accepts an MVPN or VPLS service A-D When an egress PE receives and accepts an MVPN or VPLS service A-D
route, if the Leaf Information Required flag in the PMSI Tunnel route, if the Leaf Information Required flag in the PMSI Tunnel
attribute of the received A-D route is set to 1, and the route does attribute of the received A-D route is set to 1, and the route does
not carry the P2MP Segmented Next-Hop Extended Community, then the not carry the P2MP Segmented Next-Hop Extended Community, then the
egress PE, following the "regular" MVPN or VPLS procedures associated egress PE, following the "regular" MVPN or VPLS procedures associated
with the received A-D route (as specified in [RFC6514] and [VPLS- with the received A-D route (as specified in [RFC6514] and [VPLS-
P2MP]), originates a Leaf A-D route. P2MP]), originates a Leaf A-D route.
In addition, if the Tunnel Type in the PMSI Tunnel attribute of the In addition, if the Tunnel Type in the PMSI Tunnel attribute of the
skipping to change at page 34, line 8 skipping to change at page 35, line 32
procedures specified in section 6.1 ("Determining the Upstream procedures specified in section 6.1 ("Determining the Upstream
ABR/PE/ASBR (Upstream Node)") for global table multicast. ABR/PE/ASBR (Upstream Node)") for global table multicast.
The egress PE constructs the rest of the Leaf A-D route following the The egress PE constructs the rest of the Leaf A-D route following the
procedures specified in section 6.2.3 ("Constructing the Rest of the procedures specified in section 6.2.3 ("Constructing the Rest of the
Leaf A-D Route"). Leaf A-D Route").
From that point on we follow the procedures used for the Leaf A-D From that point on we follow the procedures used for the Leaf A-D
routes for global table multicast, as outlined below. routes for global table multicast, as outlined below.
13.5. Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP 14.5. Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP
When an egress ABR receives the Leaf A-D route, and P2MP LSP is used When an egress ABR receives the Leaf A-D route, and P2MP LSP is used
to instantiate the egress area segment of the inter-area transport to instantiate the egress area segment of the inter-area transport
LSP, the egress ABR will advertise into the egress area an S-PMSI A-D LSP, the egress ABR will advertise into the egress area an S-PMSI A-D
route. This route is constructed following the procedures in section route. This route is constructed following the procedures in section
7.1.2.1 ("Global Table Multicast and S-PMSI A-D Routes"). The egress "Global Table Multicast and S-PMSI A-D Routes". The egress PE(s) will
PE(s) will import this route. import this route.
The egress ABR will also propagate, with appropriate modifications, The egress ABR will also propagate, with appropriate modifications,
the received Leaf A-D route into the backbone area. This is the received Leaf A-D route into the backbone area. This is
irrespective of whether the egress area segment is instantiated using irrespective of whether the egress area segment is instantiated using
P2MP LSP or ingress replication. P2MP LSP or ingress replication.
If P2MP LSP is used to instantiate the backbone area segment of the If P2MP LSP is used to instantiate the backbone area segment of the
inter-area transport LSP, then an ingress ABR will advertise into the inter-area transport LSP, then an ingress ABR will advertise into the
backbone area an S-PMSI A-D route. This route is constructed backbone area an S-PMSI A-D route. This route is constructed
following the procedures in section 7.1.2.1 ("Global Table Multicast following the procedures in section 7.1.2.1 ("Global Table Multicast
skipping to change at page 34, line 37 skipping to change at page 36, line 14
The ingress ABR will also propagate, with appropriate modifications, The ingress ABR will also propagate, with appropriate modifications,
the received Leaf A-D route into the ingress area towards the the received Leaf A-D route into the ingress area towards the
ingress/root PE. This is irrespective of whether the backbone area ingress/root PE. This is irrespective of whether the backbone area
segment is instantiated using P2MP LSP or ingress replication. segment is instantiated using P2MP LSP or ingress replication.
Finally, if P2MP LSP is used to instantiate the ingress area segment, Finally, if P2MP LSP is used to instantiate the ingress area segment,
the ingress PE will advertise into the ingress area an S-PMSI A-D the ingress PE will advertise into the ingress area an S-PMSI A-D
route with the RD, multicast source, and multicast group fields being route with the RD, multicast source, and multicast group fields being
the same as those in the received Leaf A-D route. The PMSI Tunnel the same as those in the received Leaf A-D route. The PMSI Tunnel
attribute of this route contains the identity of a the intra-area attribute of this route contains the identity of the intra-area P2MP
P2MP LSP used to instantiate the ingress area segment, and an LSP used to instantiate the ingress area segment, and an upstream-
upstream-assigned MPLS label. The ingress ABR(s) and other PE(s) in assigned MPLS label. The ingress ABR(s) and other PE(s) in the
the ingress area, if any, will import this route. The ingress PE will ingress area, if any, will import this route. The ingress PE will use
use the (intra-area) P2MP LSP advertised in this route for carrying the (intra-area) P2MP LSP advertised in this route for carrying
traffic associated with the original service A-D route advertised by traffic associated with the original service A-D route advertised by
the PE. the PE.
13.6. Discussion 14.6. Discussion
Use of inter-area transport P2MP LSPs, as described in this section, Use of inter-area transport P2MP LSPs, as described in this section,
creates a level of indirection between (inter-area) P2MP service creates a level of indirection between (inter-area) P2MP service
LSPs, and intra-area transport LSPs that carry the service LSPs. LSPs, and intra-area transport LSPs that carry the service LSPs.
Rather than segmenting (inter-area) service P2MP LSPs, and then Rather than segmenting (inter-area) service P2MP LSPs, and then
aggregating (intra-area) segments of these service LSPs into intra- aggregating (intra-area) segments of these service LSPs into intra-
area transport LSPs, this approach first aggregates multiple (inter- area transport LSPs, this approach first aggregates multiple (inter-
area) service P2MP LSPs into a single inter-area transport P2MP LSP, area) service P2MP LSPs into a single inter-area transport P2MP LSP,
then segments such inter-area transport P2MP LSPs, and then then segments such inter-area transport P2MP LSPs, and then
aggregates (intra-area) segments of these inter-area transport LSPs aggregates (intra-area) segments of these inter-area transport LSPs
skipping to change at page 36, line 37 skipping to change at page 38, line 8
overhead on the routers within each of the egress areas (except for overhead on the routers within each of the egress areas (except for
egress ABRs), PE1 would need to aggregate the P2MP service LSP for egress ABRs), PE1 would need to aggregate the P2MP service LSP for
(C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same
inter-area P2MP transport LSP. While such aggregation would reduce inter-area P2MP transport LSP. While such aggregation would reduce
state on ABRs, it would also result in bandwidth inefficiency, as (C- state on ABRs, it would also result in bandwidth inefficiency, as (C-
S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also
to PE5, which has no receivers for this stream. Likewise, (C-S2, C- to PE5, which has no receivers for this stream. Likewise, (C-S2, C-
G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2, G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2,
which has no receivers for this stream. which has no receivers for this stream.
14. IANA Considerations 15. IANA Considerations
This document defines a new BGP Extended Community called "Inter-area This document defines a new BGP Extended Community called "Inter-area
P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented
Next-Hop Extended Community"). This community is IP Address Specific, Next-Hop Extended Community"). This community is IP Address Specific,
of an extended type, and is transitive. A codepoint for this of an extended type, and is transitive. A codepoint for this
community should be assigned both from the IPv4 Address Specific community should be assigned both from the IPv4 Address Specific
Extended Community registry, and from the IPv6 Address Specific Extended Community registry, and from the IPv6 Address Specific
Extended Community registry. The same code point should be assigned Extended Community registry. The same code point should be assigned
from both registries. from both registries.
This document also assigns a new Tunnel Type in the PMSI Tunnel This document also assigns a new Tunnel Type in the PMSI Tunnel
Attribute, called the "Transport Tunnel" (see section "Transport Attribute, called the "Transport Tunnel" (see section "Transport
Tunnel Type"). This Tunnel Type is assigned a value of 8. Tunnel Type"). This Tunnel Type is assigned a value of 8.
15. Security Considerations 16. Security Considerations
These will be spelled out in a future revision. These will be spelled out in a future revision.
16. Acknowledgements 17. Acknowledgements
We would like to thank Eric Rosen for his comments. We would like to thank Eric Rosen for his comments.
17. References 18. References
17.1. Normative References 18.1. Normative References
[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 [RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC1997,
August 1996
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997 Levels.", Bradner, March 1997
[RFC4360] S. Sangle et. al., "BGP Extended Communities Attribute", [RFC4360] S. Sangle et. al., "BGP Extended Communities Attribute",
RFC4360, February 2006 RFC4360, February 2006
[RFC4684] P. Marques et. al., "Constrained Route Distribution for [RFC4684] P. Marques et. al., "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
November 2006 November 2006
[RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4761] Kompella, K., Rekhter, Y., "Virtual Private LAN Service [RFC4761] Kompella, K., Rekhter, Y., "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January
2007 2007
[RFC6468] "Internal BGP as PE-CE protocol", Pedro Marques, et al., [RFC6368] "Internal BGP as PE-CE protocol", Pedro Marques, et al.,
RFC6368, September 2011 RFC6368, September 2011
[RFC5331] "MPLS Upstream Label Assignment and Context-Specific Label
Space", Rahul Aggarwal, et al., RFC5331, August 2008
[RFC5332] "MPLS Multicast Encapsulations", T. Eckert, E. Rosen, R.
Aggarwal, Y. Rekhter, RFC5332, August 2008
[RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP [RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, RFC6514, February VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, RFC6514, February
2012 2012
[RFC6074] "Provisioning, Auto-Discovery, and Signaling in Layer 2 [RFC6074] "Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", E. Rosen, B. Davie, V. Radoaca, Virtual Private Networks (L2VPNs)", E. Rosen, B. Davie, V. Radoaca,
W. Luo, RFC6074, January 2011 W. Luo, RFC6074, January 2011
[RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric [RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric
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
17.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 draft-ietf-mpls-seamless-mpls, work in progress
18. Author's Address [virtual-hub-and-spoke] "Virtual Hub-and-Spoke in BGP/MPLS VPNs",
Huajin Jeng et. al., draft-ietf-l3vpn-virtual-hub, work in progress
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
Email: raggarwa_1@yahoo.com Email: raggarwa_1@yahoo.com
 End of changes. 52 change blocks. 
121 lines changed or deleted 178 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/