draft-ietf-mpls-seamless-mcast-11.txt   draft-ietf-mpls-seamless-mcast-12.txt 
skipping to change at page 1, line 21 skipping to change at page 1, line 21
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 3 2014 June 6 2014
Inter-Area P2MP Segmented LSPs Inter-Area P2MP Segmented LSPs
draft-ietf-mpls-seamless-mcast-11.txt draft-ietf-mpls-seamless-mcast-12.txt
Abstract
This document describes procedures for building inter-area point-to-
multipoint (P2MP) segmented service LSPs by partitioning such LSPs
into intra-area segments and using BGP as the inter-area routing and
label distribution protocol. Within each IGP area the intra-area
segments are either carried over intra-area P2MP LSPs, using P2MP LSP
hierarchy, or instantiated using ingress replication. The intra-area
P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
replication is used within an IGP area, then (multipoint-to-point)
LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP
area. The applications/services that use such inter-area service LSPs
may be BGP Multicast VPN, VPLS multicast, or global table multicast
over MPLS.
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 2, line 7 skipping to change at page 2, line 27
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 3, line 5
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract
This document describes procedures for building inter-area point-to-
multipoint (P2MP) segmented service LSPs by partitioning such LSPs
into intra-area segments and using BGP as the inter-area routing and
label distribution protocol. Within each IGP area the intra-area
segments are either carried over intra-area P2MP LSPs, using P2MP LSP
hierarchy, or instantiated using ingress replication. The intra-area
P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
replication is used within an IGP area, then MP2P LDP LSPs or P2P
RSVP-TE LSPs may be used in the IGP area. The applications/services
that use such inter-area service LSPs may be BGP MVPN, VPLS
multicast, or global table multicast over MPLS.
Table of Contents Table of Contents
1 Specification of requirements ......................... 4 1 Introduction .......................................... 4
2 Introduction .......................................... 4 2 Specification of requirements ......................... 5
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 ... 8
5.1 BGP MVPN .............................................. 8 5.1 BGP MVPN .............................................. 8
5.2 BGP VPLS or LDP VPLS with BGP auto-discovery .......... 9 5.1.1 Routes originated by PE or ASBR ....................... 8
5.3 Global Table Multicast over MPLS ...................... 11 5.1.2 Routes re-avertise by PE or ASBR ...................... 9
6 Egress PE/ASBR Procedures ............................. 11 5.1.3 Inter-area routes ..................................... 9
6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 12 5.2 LDP VPLS with BGP auto-discovery or BGP VPLS .......... 10
6.1.1 Upstream Node for MVPN or VPLS ........................ 12 5.2.1 Routes originated by PE or ASBR ....................... 10
6.1.2 Upstream Node for Global Table Multicast .............. 12 5.2.2 Routes re-avertise by PE or ASBR ...................... 10
6.2 Originating a Leaf A-D Route .......................... 13 5.2.3 Inter-area routes ..................................... 11
5.3 Global Table Multicast over MPLS ...................... 12
6 Egress PE/ASBR Signaling Procedures ................... 12
6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 13
6.1.1 Upstream Node for MVPN or VPLS ........................ 13
6.1.2 Upstream Node for Global Table Multicast .............. 13
6.2 Originating a Leaf A-D Route .......................... 14
6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 14 6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 14
6.2.2 Leaf A-D Route for Global Table Multicast ............. 14 6.2.2 Leaf A-D Route for Global Table Multicast ............. 15
6.2.3 Constructing the Rest of the Leaf A-D Route ........... 16 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 17
6.3 PIM-SM in ASM mode for Global Table Multicast ......... 16 6.3 PIM-SM in ASM mode for Global Table Multicast ......... 17
6.3.1 Option 1 .............................................. 17 6.3.1 Option 1 .............................................. 17
6.3.1.1 Originating Source Active A-D Routes .................. 17 6.3.1.1 Originating Source Active A-D Routes .................. 18
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 ........... 18
6.3.1.3 Handling (S, G, RPTbit) state ......................... 18 6.3.1.3 Handling (S, G, rpt) state ............................ 19
6.3.2 Option 2 .............................................. 18 6.3.2 Option 2 .............................................. 19
6.3.2.1 Originating Source Active A-D Routes .................. 18 6.3.2.1 Originating Source Active A-D Routes .................. 19
6.3.2.2 Receiving BGP Source Active A-D Route ................. 19 6.3.2.2 Receiving BGP Source Active A-D Route ................. 20
6.3.2.3 Pruning Sources off the Shared Tree ................... 19 6.3.2.3 Pruning Sources off the Shared Tree ................... 20
6.3.2.4 More on handling (S, G, RPTbit) state ................. 20 6.3.2.4 More on handling (S, G, rpt) state .................... 21
7 Egress ABR Procedures ................................. 20 7 Egress ABR Procedures ................................. 21
7.1 Handling Leaf A-D route on Egress ABR ................. 20 7.1 Handling Leaf A-D route on Egress ABR ................. 21
7.2 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 22 7.2 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 23
7.2.1 Received Leaf A-D route is for MVPN or VPLS ........... 22 7.2.1 Received Leaf A-D route is for MVPN or VPLS ........... 23
7.2.2 Received Leaf A-D route is for global table multicast . 23 7.2.2 Received Leaf A-D route is for global table multicast . 24
7.2.2.1 Global Table Multicast and S-PMSI A-D Routes .......... 23 7.2.2.1 Global Table Multicast and S-PMSI A-D Routes .......... 24
7.2.2.2 Global Table Multicast and Wildcard S-PMSI A-D Routes . 24 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 . 25 7.2.3 Global Table Multicast and the Expected Upstream Node . 25
7.2.4 P2MP LDP LSP as the Intra-Area P2MP LSP ............... 25 7.2.4 P2MP LDP LSP as the Intra-Area P2MP LSP ............... 26
7.2.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........... 25 7.2.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........... 26
7.3 Ingress Replication in the Egress Area ................ 26 7.3 Ingress Replication in the Egress Area ................ 26
8 Ingress ABR Procedures ................................ 26 8 Ingress ABR Procedures ................................ 27
8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 26 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 27
8.2 Ingress Replication in the Backbone Area .............. 27 8.2 Ingress Replication in the Backbone Area .............. 27
9 Ingress PE/ASBR Procedures ............................ 27 9 Ingress PE/ASBR Procedures ............................ 28
9.1 P2MP LSP as the Intra-Area LSP in the Ingress Area .... 28 9.1 P2MP LSP as the Intra-Area LSP in the Ingress Area .... 28
9.2 Ingress Replication in the Ingress Area ............... 29 9.2 Ingress Replication in the Ingress Area ............... 29
10 Common Tunnel Type in the Ingress and Egress Areas .... 29 10 Common Tunnel Type in the Ingress and Egress Areas .... 30
11 Placement of Ingress and Egress PEs ................... 30 11 Placement of Ingress and Egress PEs ................... 30
12 MVPN with Virtual Hub-and-Spoke ....................... 30 12 MVPN with Virtual Hub-and-Spoke ....................... 31
13 Data Plane ............................................ 31 13 Data Plane ............................................ 31
13.1 Data Plane Procedures on ABRs ......................... 31 13.1 Data Plane Procedures on ABRs ......................... 31
13.2 Data Plane Procedures on Egress PEs ................... 31 13.2 Data Plane Procedures on Egress PEs ................... 32
13.3 Data Plane Procedures on Ingress PEs .................. 32 13.3 Data Plane Procedures on Ingress PEs .................. 33
13.4 Data Plane Procedures on Transit Routers .............. 33 13.4 Data Plane Procedures on Transit Routers .............. 33
14 Support for Inter-Area Transport LSPs ................. 33 14 Support for Inter-Area Transport LSPs ................. 33
14.1 Transport Tunnel Tunnel Type .......................... 33 14.1 Transport Tunnel Tunnel Type .......................... 34
14.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 33 14.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 34
14.3 Discovering P2MP FEC of P2MP Transport LSP ............ 34 14.3 Discovering P2MP FEC of P2MP Transport LSP ............ 34
14.4 Egress PE Procedures for P2MP Transport LSP ........... 34 14.4 Egress PE Procedures for P2MP Transport LSP ........... 35
14.5 Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP 35 14.5 ABRs and Ingress PE procedures for P2MP Transport LSP . 36
14.6 Discussion ............................................ 36 14.6 Discussion ............................................ 37
15 IANA Considerations ................................... 38 15 IANA Considerations ................................... 39
16 Security Considerations ............................... 38 16 Security Considerations ............................... 39
17 Acknowledgements ...................................... 38 17 Acknowledgements ...................................... 39
18 References ............................................ 38 18 References ............................................ 40
18.1 Normative References .................................. 38 18.1 Normative References .................................. 40
18.2 Informative References ................................ 39 18.2 Informative References ................................ 41
19 Author's Address ...................................... 40 19 Author's Address ...................................... 41
1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction 1. Introduction
This document describes procedures for building inter-area point-to- This document describes procedures for building inter-area point-to-
multipoint (P2MP) segmented service LSPs by partitioning such LSPs multipoint (P2MP) segmented service LSPs by partitioning such LSPs
into intra-area segments and using BGP as the inter-area routing and into intra-area segments and using BGP as the inter-area routing and
label distribution protocol. Within each IGP area the intra-area label distribution protocol. Within each IGP area the intra-area
segments are either carried over intra-area P2MP LSPs, potentially segments are either carried over intra-area P2MP LSPs, potentially
using P2MP LSP hierarchy, or instantiated using ingress replication. using P2MP LSP hierarchy, or instantiated using ingress replication.
The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE [RFC4875]
mLDP. If ingress replication is used in an IGP area then MP2P LDP or or P2MP mLDP [RFC6388]. If ingress replication is used in an IGP area
P2P RSVP-TE LSPs may be used within the IGP area. The then (multipoint-to-point) LDP LSPs [RFC5036] or (point-to-point)
RSVP-TE LSPs [RFC3209] may be used within the IGP area. The
applications/services that use such inter-area service LSPs may be applications/services that use such inter-area service LSPs may be
BGP MVPN, VPLS multicast, or global table multicast over MPLS. BGP Multicast VPN (BGP MVPN), VPLS multicast, or global table
multicast over MPLS.
The primary use case of such segmented P2MP service LSPs is when the The primary use case of such segmented P2MP service LSPs is when the
PEs are in different areas but in the same AS and thousands or more PEs are in different areas but in the same AS and thousands or more
of PEs require P2MP connectivity. For instance this may be the case of PEs require P2MP connectivity. For instance this may be the case
when MPLS is pushed further to the metro edge and the metros are in when MPLS is pushed further to the metro edge and the metros are in
different IGP areas. This may also be the case when a Service different IGP areas. This may also be the case when a Service
Provider's network comprises multiple IGP areas in a single Provider's network comprises multiple IGP areas in a single
Autonomous System, with a large number of PEs. Seamless MPLS is the Autonomous System, with a large number of PEs. Seamless MPLS is the
industry term to address this case [SEAMLESS-MPLS]. Thus one of the industry term to address this case [SEAMLESS-MPLS]. Thus one of the
applicabilities of this document is that it describes the multicast applicabilities of this document is that it describes the multicast
procedures for seamless MPLS. procedures for seamless MPLS.
It is to be noted that [RFC6514], [VPLS-P2MP] already specify It is to be noted that [RFC6514] and [RFC7117] already specify
procedures for building segmented inter-AS P2MP service LSPs. This procedures for building segmented inter-AS P2MP service LSPs. This
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. In fact 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, RFC7117] 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.
2. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. General Assumptions and Terminology 3. General Assumptions and Terminology
The reader is suppose to be familiar with MVPN procedures and
terminology [RFC6513, RFC6514] and VPLS procedures and terminology
[RFC7117].
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
skipping to change at page 8, line 22 skipping to change at page 8, line 34
The procedures in this document require that at least one ABR in a The procedures in this document require that at least one ABR in a
given IGP area acts as a Route Reflector for MVPN A-D routes. Such a given IGP area acts as a Route Reflector for MVPN A-D routes. Such a
Router Reflector is responsible for re-advertising MVPN A-D routes Router Reflector is responsible for re-advertising MVPN A-D routes
across area's boundaries. When re-advertising these routes across across area's boundaries. When re-advertising these routes across
area's boundaries, this Route Reflector MUST follow the procedures in area's boundaries, this Route Reflector MUST follow the procedures in
this document. Note that such a Route Reflector may also re-advertise this document. Note that such a Route Reflector may also re-advertise
MVPN A-D routes within the same area, in which case it follows the MVPN A-D routes within the same area, in which case it follows the
plain BGP Route Reflector procedures [RFC4456]. plain BGP Route Reflector procedures [RFC4456].
The "Leaf Information Required" flag MUST be set in the P-Tunnel 5.1.1. Routes originated by PE or ASBR
attribute carried in such routes, when originated by the ingress PEs
or ASBRs, except for the case where (a) as a matter of policy The "Leaf Information Required" flag MUST be set in the PMSI Tunnel
(provisioned on the ingress PEs or ASBRs) there is no aggregation of attribute carried in the MVPN A-D routes, when originated by the
ingress area segments of the service LSPs, and (b) mLDP is used as ingress PEs or ASBRs, except for the case where (a) as a matter of
the protocol to establish intra-area transport LSPs in the ingress policy (provisioned on the ingress PEs or ASBRs) there is no
area. Before any Leaf A-D route is advertised by a PE or ABR in the aggregation of ingress area segments of the service LSPs, and (b)
same area, as described in the following sections, an I-PMSI/S-PMSI mLDP is used as the protocol to establish intra-area transport LSPs
A-D route is advertised either with an explicit Tunnel Type and in the ingress area. Before any Leaf A-D route is advertised by a PE
Tunnel Identifier in the PMSI Tunnel Attribute, if the Tunnel or ABR in the same area, as described in the following sections, an
Identifier has already been assigned, or with a special Tunnel Type I-PMSI/S-PMSI A-D route is advertised either with an explicit Tunnel
of "No tunnel information present" otherwise. Type and Tunnel Identifier in the PMSI Tunnel Attribute, if the
Tunnel Identifier has already been assigned, or with a special Tunnel
Type of "No tunnel information present" otherwise.
5.1.2. Routes re-avertise by PE or ASBR
When the I-PMSI/S-PMSI A-D routes are re-advertised by an ingress When the I-PMSI/S-PMSI A-D routes are re-advertised by an ingress
ABR, the "Leaf Information Required" flag MUST be set in the P-Tunnel ABR, the "Leaf Information Required" flag MUST be set in the P-Tunnel
attribute present in the routes, except for the case where (a) as a attribute present in the routes, except for the case where (a) as a
matter of policy (provisioned on the ingress ABR) there is no matter of policy (provisioned on the ingress ABR) there is no
aggregation of backbone area segments of the service LSPs, and (b) aggregation of backbone area segments of the service LSPs, and (b)
mLDP is used as the protocol to establish intra-area transport LSPs mLDP is used as the protocol to establish intra-area transport LSPs
in the backbone area. Likewise, when the I-PMSI/S-PMSI A-D routes are in the backbone area. Likewise, when the I-PMSI/S-PMSI A-D routes are
re-advertised by an egress ABR, the "Leaf Information Required" flag re-advertised by an egress ABR, the "Leaf Information Required" flag
MUST be set in the P-Tunnel attribute present in the routes, except MUST be set in the P-Tunnel attribute present in the routes, except
for the case where (a) as a matter of policy (provisioned on the for the case where (a) as a matter of policy (provisioned on the
egress ABR) there is no aggregation of egress area segments of the egress ABR) there is no aggregation of egress area segments of the
service LSPs, and (b) mLDP is used as the protocol to establish service LSPs, and (b) mLDP is used as the protocol to establish
intra-area transport LSPs in the egress area. intra-area transport LSPs in the egress area.
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.
5.1.3. Inter-area routes
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 that originates such a route, the I-PMSI/S-PMSI A-D route by the PE that originates such a route,
or an ASBR that re-advertises such a route into its own AS. The or an ASBR that re-advertises such a route into its own AS. The
Global Administrator field in this Extended Community MUST be set to Global Administrator field in this Extended Community MUST be set to
the advertising PE or ASBR's IP address. This Extended Community MUST 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
skipping to change at page 9, line 42 skipping to change at page 10, line 16
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. LDP VPLS with BGP auto-discovery or BGP VPLS
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
[RFC4761, RFC6074], or VPLS S-PMSI A-D routes that are originated by [RFC4761, RFC6074], or VPLS S-PMSI A-D routes that are originated by
the ingress PEs [VPLS-P2MP]. The NLRI of such routes encodes the P2MP the ingress PEs [RFC7117]. The NLRI of such routes encodes the P2MP
FEC. FEC.
5.2.1. Routes originated by PE or ASBR
The "Leaf Information Required" flag MUST be set in the P-Tunnel The "Leaf Information Required" flag MUST be set in the P-Tunnel
attribute carried in such routes, when originated by the ingress PEs attribute carried in the VPLS A-D routes or VPLS S-PMSI A-D routes,
or ASBRs, except for the case where (a) as a matter of policy when originated by the ingress PEs or ASBRs, except for the case
(provisioned on the ingress PEs or ASBRs) there is no aggregation of where (a) as a matter of policy (provisioned on the ingress PEs or
ingress area segments of the service LSPs, and (b) mLDP is used as ASBRs) there is no aggregation of ingress area segments of the
the protocol to establish intra-area transport LSPs in the ingress service LSPs, and (b) mLDP is used as the protocol to establish
area. Before any Leaf A-D route is advertised by a PE or ABR in the intra-area transport LSPs in the ingress area. Before any Leaf A-D
same area, as described in the following sections, an VPLS/S-PMSI A-D route is advertised by a PE or ABR in the same area, as described in
route is advertised either with an explicit Tunnel Type and Tunnel the following sections, an VPLS/S-PMSI A-D route is advertised either
Identifier in the PMSI Tunnel Attribute, if the Tunnel Identifier has with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel
already been assigned, or with a special Tunnel Type of "No tunnel Attribute, if the Tunnel Identifier has already been assigned, or
information present" otherwise. with a special Tunnel Type of "No tunnel information present"
otherwise.
5.2.2. Routes re-avertise by PE or ASBR
When the VPLS/S-PMSI A-D routes are re-advertised by an ingress ABR, When the VPLS/S-PMSI A-D routes are re-advertised by an ingress ABR,
the "Leaf Information Required" flag MUST be set in the P-Tunnel the "Leaf Information Required" flag MUST be set in the P-Tunnel
attribute present in the routes, except for the case where (a) as a attribute present in the routes, except for the case where (a) as a
matter of policy (provisioned on the ingress ABR) there is no matter of policy (provisioned on the ingress ABR) there is no
aggregation of backbone area segments of the service LSPs, and (b) aggregation of backbone area segments of the service LSPs, and (b)
mLDP is used as the protocol to establish intra-area transport LSPs mLDP is used as the protocol to establish intra-area transport LSPs
in the backbone area. Likewise, when the VPLS/S-PMSI A-D routes are in the backbone area. Likewise, when the VPLS/S-PMSI A-D routes are
re-advertised by an egress ABR, the "Leaf Information Required" flag re-advertised by an egress ABR, the "Leaf Information Required" flag
MUST be set in the P-Tunnel attribute present in the routes, except MUST be set in the P-Tunnel attribute present in the routes, except
for the case where (a) as a matter of policy (provisioned on the for the case where (a) as a matter of policy (provisioned on the
egress ABR) there is no aggregation of egress area segments of the egress ABR) there is no aggregation of egress area segments of the
service LSPs, and (b) mLDP is used as the protocol to establish service LSPs, and (b) mLDP is used as the protocol to establish
intra-area transport LSPs in the egress area. intra-area transport LSPs in the egress area.
5.2.3. Inter-area routes
When VPLS A-D routes or S-PMSI A-D routes are advertised or When VPLS A-D routes 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 A-D route by the PE or ASBR that originates such a route and the the A-D route by the PE or ASBR that originates such a route and the
Global Administrator field MUST be set to the advertising PE or Global Administrator field MUST be set to the advertising PE or
ASBR's IP address. This Extended Community MUST also be included by ASBR's IP address. This Extended Community MUST also be included by
ABRs as they re-advertise such routes. An ABR MUST set the Global ABRs as they re-advertise such routes. An ABR MUST set the Global
Administrator field of the P2MP Segmented Next-Hop Extended Community Administrator field of the P2MP Segmented Next-Hop Extended Community
to its own IP address. Presence of this community in the I-PMSI/S- to its own IP address. Presence of this community in the I-PMSI/S-
PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to
follow the procedures in this document when these procedures differ follow the procedures in this document when these procedures differ
from those in [VPLS-P2MP]. from those in [RFC7117].
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.
The procedures in this document require that at least one ABR in a The procedures in this document require that at least one ABR in a
given area acts as a Route Reflector for VPLS A-D routes. Such a given area acts as a Route Reflector for VPLS A-D routes. Such a
Router Reflector is responsible for re-advertising VPLS A-D routes Router Reflector is responsible for re-advertising VPLS A-D routes
across area's boundaries. When re-advertising these routes across across area's boundaries. When re-advertising these routes across
area's boundaries, this Route Reflector MUST follow the procedures in area's boundaries, this Route Reflector MUST follow the procedures in
skipping to change at page 11, line 39 skipping to change at page 12, 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/ASBR Procedures 6. Egress PE/ASBR Signaling Procedures
This section describes egress PE/ASBR 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/ASBR is in a leaf IGP area, or irrespective of whether the egress PE/ASBR is in a leaf IGP area, or
the backbone area, or even in the same IGP area as the ingress the backbone area, or even in the same IGP area as the ingress
PE/ASBR. PE/ASBR.
An egress PE/ASBR applies procedures specified in this section to An egress PE/ASBR applies procedures specified in this section to
MVPN I-PMSI or S-PMSI A-D routes only if these routes carry the MVPN I-PMSI or S-PMSI A-D routes only if these routes carry the
Inter-area P2MP Segmented Next-Hop Extended Community. An egress PE Inter-area P2MP Segmented Next-Hop Extended Community. An egress PE
applies procedures specified in this section to VPLS A-D routes or applies procedures specified in this section to VPLS A-D routes or
VPLS S-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 be auto-
configure an import AS-specific Route Target Extended Community configured to import routes that carry AS-specific Route Target
([RFC4360]) with the Global Administrator field set to the AS of the Extended Community ([RFC4360]) with the Global Administrator field
PE and the Local Administrator field set to 0. set to the AS of the PE and the Local Administrator field set to 0.
Once an egress PE/ASBR discovers the P2MP FEC of an inter-area Once an egress PE/ASBR discovers the P2MP FEC of an inter-area
segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in
order to construct the segmented inter-area P2MP service LSP. This order to construct the segmented inter-area P2MP service LSP. This
propagation 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/ASBR discovers the P2MP FEC of an inter-area P2MP An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP
Segmented Service LSP as described in section 5 ("Discovering P2MP Segmented Service LSP as described in section 5 ("Discovering P2MP
skipping to change at page 12, line 45 skipping to change at page 13, line 37
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
field is set to the IP address of the PE or ASBR advertising the field is set to the IP address of the PE or ASBR advertising the
unicast route. The Local Administrator field of this community MUST unicast route. The Local Administrator field of this community MUST
be set to 0 (note, that this is in contrast to the case of MVPN, be set to 0 (note, that this is in contrast to the case of MVPN,
where the Global Administrator field carries a non-zero value that where the Global Administrator field carries a non-zero value that
identifies a particular VRF on a PE that originates VPN-IP routes). identifies a particular VRF on a PE that originates VPN-IP routes).
If it is not desirable to advertise the VRF Route Import Extended If it is not desirable to advertise the VRF Route Import Extended
Community in unicast routes, then unicast routes to multicast Community in unicast routes, then unicast routes to multicast
sources/RPs MUST be advertised using the multicast SAFI i.e. SAFI 2, sources/RPs MUST be advertised using the multicast SAFI i.e. SAFI 2,
and such routes MUST carry the VRF Route Import Extended Community. and such routes MUST carry the VRF Route Import Extended Community.
skipping to change at page 14, line 10 skipping to change at page 14, line 45
If the P2MP FEC was derived from a global table multicast (S/*, G), If the P2MP FEC was derived from a global table multicast (S/*, G),
and the upstream node's address is not the same as the egress PE, and the upstream node's address is not the same as the egress PE,
then the egress PE MUST originate a Leaf A-D route. then the egress PE MUST originate a Leaf A-D route.
6.2.1. Leaf A-D Route for MVPN and VPLS 6.2.1. Leaf A-D Route for MVPN and VPLS
If the P2MP FEC was derived from MVPN or VPLS A-D routes then the If the P2MP FEC was derived from MVPN or VPLS A-D routes then the
Route Key field of the Leaf A-D route contains the NLRI of the A-D Route Key field of the Leaf A-D route contains the NLRI of the A-D
route from which the P2MP FEC was derived. This follows procedures route from which the P2MP FEC was derived. This follows procedures
for constructing Leaf A-D routes described in [RFC6514, VPLS-P2MP]. for constructing Leaf A-D routes described in [RFC6514, RFC7117].
6.2.2. Leaf A-D Route for Global Table Multicast 6.2.2. Leaf A-D Route for Global Table Multicast
If the application is global table multicast, then the MCAST-VPN NLRI If the application is global table multicast, then the MCAST-VPN NLRI
of the Leaf A-D route is constructed as follows: of the Leaf A-D route is constructed as follows:
The Route Key field of MCAST-VPN NLRI has the following format: The Route Key field of MCAST-VPN NLRI has the following format:
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
skipping to change at page 17, line 28 skipping to change at page 18, line 20
whenever as a result of receiving MSDP messages a PE, that is not whenever as a result of receiving MSDP messages a PE, that is not
configured as a RP, discovers a new multicast source the PE SHOULD configured as a RP, discovers a new multicast source the PE SHOULD
originate a BGP Source Active A-D route. The BGP Source Active A-D originate a BGP Source Active A-D route. The BGP Source Active A-D
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
Length field is set appropriately to reflect this. Group Length field is set appropriately to reflect this.
The Route Target of this Source Active A-D route is an AS-specific The Route Target of this Source Active A-D route is an AS-specific
Route Target Extended Community with the Global Administrator field Route Target Extended Community with the Global Administrator field
set to the AS of the advertising RP/PE, and the Local Administrator set to the AS of the advertising RP/PE, and the Local Administrator
field is set to 0. 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]).
skipping to change at page 18, line 21 skipping to change at page 19, line 13
Multicast"). Multicast").
When an (egress) PE receives a new Source Active A-D route, the PE When an (egress) PE receives a new Source Active A-D route, the PE
MUST check if its TIB contains an (*, G) entry with the same G as MUST check if its TIB contains an (*, G) entry with the same G as
carried in the Source Active A-D route. If such an entry is found, S carried in the Source Active A-D route. If such an entry is found, S
is reachable via an MPLS interface, and the PE does not have (S, G) is reachable via an MPLS interface, and the PE does not have (S, G)
state in its TIB for (S, G) carried in the route, then the PE state in its TIB for (S, G) carried in the route, then the PE
originates a Leaf A-D route carrying that (S, G), as specified in originates a Leaf A-D route carrying that (S, G), as specified in
section 6.2.2 ("Leaf A-D Route for Global Table Multicast"). section 6.2.2 ("Leaf A-D Route for Global Table Multicast").
6.3.1.3. Handling (S, G, RPTbit) state 6.3.1.3. Handling (S, G, rpt) state
Creation and deletion of (S, G, RPTbit) state on a PE that resulted Creation and deletion of (S, G, rpt) state on a PE that resulted from
from receiving PIM messages on one of its IP multicast interfaces receiving PIM messages on one of its IP multicast interfaces does not
does not result in any BGP actions by the PE. result in any BGP actions by the PE.
6.3.2. Option 2 6.3.2. Option 2
This option does transit IP multicast shared trees over the MPLS This option does transit IP multicast shared trees over the MPLS
network. Therefore, when an (egress) PE creates (*, G) state (as a network. Therefore, when an (egress) PE creates (*, G) state (as a
result of receiving PIM or IGMP messages on one of its IP multicast result of receiving PIM or IGMP messages on one of its IP multicast
interfaces), the PE does propagate this state using Leaf A-D routes. interfaces), the PE does propagate this state using Leaf A-D routes.
6.3.2.1. Originating Source Active A-D Routes 6.3.2.1. Originating Source Active A-D Routes
skipping to change at page 18, line 48 skipping to change at page 19, line 40
is reachable via one of the IP multicast capable interfaces, and the is reachable via one of the IP multicast capable interfaces, and the
PE determines that G is in the PIM-SM in ASM mode range, the PE MUST PE determines that G is in the PIM-SM in ASM mode range, the PE MUST
originate a BGP Source Active A-D route. The route carries a single originate a BGP Source Active A-D route. The route carries a single
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
Length field is set appropriately to reflect this. Group Length field is set appropriately to reflect this.
The Route Target of this Source Active A-D route is an AS-specific The Route Target of this Source Active A-D route is an AS-specific
Route Target Extended Community with the Global Administrator field Route Target Extended Community with the Global Administrator field
set to the AS of the advertising PE, and the Local Administrator set to the AS of the advertising PE, and the Local Administrator
field is set to 0. 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]).
skipping to change at page 20, line 15 skipping to change at page 21, line 6
D route for (S,G), and (c) the PE does not originate the Leaf A-D D route for (S,G), and (c) the PE does not originate the Leaf A-D
route for (S,G). Once either of these conditions become no longer route for (S,G). Once either of these conditions become no longer
valid, the PE MUST transition the (S,G,rpt) downstream state machine valid, the PE MUST transition the (S,G,rpt) downstream state machine
to the NoInfo state. to the NoInfo state.
Note that except for the scenario described in the first paragraph of Note that except for the scenario described in the first paragraph of
this section, in all other scenarios relying solely on PIM procedures this section, in all other scenarios relying solely on PIM procedures
on the PE is sufficient to ensure the correct behavior when pruning on the PE is sufficient to ensure the correct behavior when pruning
sources off the shared tree. sources off the shared tree.
6.3.2.4. More on handling (S, G, RPTbit) state 6.3.2.4. More on handling (S, G, rpt) state
Creation and deletion of (S, G, RPTbit) state on a PE that resulted Creation and deletion of (S, G, rpt) state on a PE that resulted from
from receiving PIM messages on one of its IP multicast interfaces receiving PIM messages on one of its IP multicast interfaces does not
does not result in any BGP actions by the PE. result in any BGP actions by the PE.
7. Egress ABR Procedures 7. Egress ABR Procedures
This section describes Egress ABR Procedures for constructing This section describes Egress ABR Procedures for constructing
segmented inter-area P2MP LSP. segmented inter-area P2MP LSP.
7.1. Handling Leaf A-D route on Egress ABR 7.1. Handling Leaf A-D route on Egress ABR
When an egress ABR receives a Leaf A-D route and the Route Target When an egress ABR receives a Leaf A-D route and the Route Target
Extended Community carried by the route contains the IP address of Extended Community carried by the route contains the IP address of
skipping to change at page 23, line 6 skipping to change at page 23, line 44
The PMSI Tunnel attribute of the re-advertised route specifies either The PMSI Tunnel attribute of the re-advertised route specifies either
an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted
at the ABR and MUST also carry an upstream assigned MPLS label. The at the ABR and MUST also carry an upstream assigned MPLS label. The
upstream-assigned MPLS label MUST be set to implicit NULL if the upstream-assigned MPLS label MUST be set to implicit NULL if the
mapping between the inter-area P2MP service LSP and the intra-area mapping between the inter-area P2MP service LSP and the intra-area
P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area
segment of the inter-area P2MP service LSP (referred to as the segment of the inter-area P2MP service LSP (referred to as the
"inner" P2MP LSP) is constructed by nesting the inter-area P2MP "inner" P2MP LSP) is constructed by nesting the inter-area P2MP
service LSP in an intra-area P2MP LSP (referred to as the "outer" service LSP in an intra-area P2MP LSP (referred to as the "outer"
intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream- intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream-
assigned MPLS labels [RFC 5332]. assigned MPLS labels [RFC5332].
If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried
over a given intra-area P2MP LSP, each of these segments MUST carry a over a given intra-area P2MP LSP, each of these segments MUST carry a
distinct upstream-assigned label, even if all these service LSPs are distinct upstream-assigned label, even if all these service LSPs are
for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR
maintains an LFIB state for each such S-PMSI traversing the ABR (that maintains an LFIB state for each such S-PMSI traversing the ABR (that
applies to both the ingress and the egress ABRs). applies to both the ingress and the egress ABRs).
7.2.2. Received Leaf A-D route is for global table multicast 7.2.2. Received Leaf A-D route is for global table multicast
skipping to change at page 25, line 30 skipping to change at page 26, line 13
upstream assigned label advertised in the S-PMSI A-D route, if the upstream assigned label advertised in the S-PMSI A-D route, if the
label is not the Implicit NULL. label is not the Implicit NULL.
7.2.4. P2MP LDP LSP as the Intra-Area P2MP LSP 7.2.4. P2MP LDP LSP as the Intra-Area P2MP LSP
The above procedures are sufficient if P2MP LDP LSPs are used as the The above procedures are sufficient if P2MP LDP LSPs are used as the
Intra-area P2MP LSP in the Egress area. Intra-area P2MP LSP in the Egress area.
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 intra-area LSP in the egress area,
area, then the egress ABR can either (a) graft the leaf (whose IP then the egress ABR can either (a) graft the leaf (whose IP address
address is specified in the received Leaf A-D route) into an existing is specified in the received Leaf A-D route) into an existing P2MP
P2MP LSP rooted at the egress ABR, and use that LSP for carrying LSP rooted at the egress ABR, and use that LSP for carrying traffic
traffic for the inter-area segmented P2MP service LSP, or (b) for the inter-area segmented P2MP service LSP, or (b) originate a new
originate a new P2MP LSP to be used for carrying (S,G). 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 "Received Leaf A-D route the procedures are as described in section "Received Leaf A-D route
is for global table multicast". 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
skipping to change at page 28, line 18 skipping to change at page 28, line 44
a Leaf A-D route update. Likewise, if this is the withdrawal of the a Leaf A-D route update. Likewise, if this is the withdrawal of the
last Leaf A-D route whose Route Key matches a particular (S/RP, G) last Leaf A-D route whose Route Key matches a particular (S/RP, G)
state, the PIM implementation MUST set its upstream (S/RP, G) state state, the PIM implementation MUST set its upstream (S/RP, G) state
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 intra-area LSP in the ingress
ingress area, then the procedures for binding the ingress area area, then the procedures for binding the ingress area segment of the
segment of the inter-area P2MP LSP to the intra-area P2MP LSP in the inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area,
ingress area, are the same as in section "Egress ABR Procedures" and are the same as in section "Egress ABR Procedures" and sub-section
sub-section "P2MP LSP as the Intra-Area LSP in the Egress Area". "P2MP LSP as the Intra-Area LSP in the Egress 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 34, line 38 skipping to change at page 35, line 22
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.
14.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
P2MP]), originates a Leaf A-D route. [RFC7117]), 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
received service A-D route is set to "Transport Tunnel", the egress received service A-D route is set to "Transport Tunnel", the egress
PE originates yet another Leaf A-D route. PE originates yet another Leaf A-D route.
The format of the Route Key field of MCAST-VPN NLRI of this The format of the Route Key field of MCAST-VPN NLRI of this
additional Leaf A-D route is the same as defined in section 6.2.2 additional Leaf A-D route is the same as defined in section 6.2.2
("Leaf A-D Route for Global Table Multicast"). The Route Key field of ("Leaf A-D Route for Global Table Multicast"). The Route Key field of
MCAST-VPN NLRI of this route is constructed as follows: MCAST-VPN NLRI of this route is constructed as follows:
skipping to change at page 35, line 32 skipping to change at page 36, line 16
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.
14.5. Egress/Ingress ABR, Ingress PE procedures for P2MP Transport LSP 14.5. ABRs and Ingress PE procedures for P2MP Transport LSP
In this section we specify ingress and egress ABRs, as well as
ingress PE procedures for P2MP transport LSPs.
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
"Global Table Multicast and S-PMSI A-D Routes". The egress PE(s) will "Global Table Multicast and S-PMSI A-D Routes". The egress 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
skipping to change at page 38, line 19 skipping to change at page 39, line 16
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.
IANA is requested to assign one code point from the range for
transitive communities in the IPv4 Address Specific Extended
Community register within the Border Gateway Protocol (BGP) Extended
Communities namespace.
IANA is requested to assign one code point from the range for
transitive communities in the IPv6 Address Specific Extended
Community register within the Border Gateway Protocol (BGP) Extended
Communities namespace.
Further, the lowest value that is available in both registries should
be allocated.
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.
16. Security Considerations 16. Security Considerations
These will be spelled out in a future revision. Procedures described in this document are subject to similar security
threats as any MPLS deployment. It is recommended that baseline
security measures are considered as described in Security Framework
for MPLS and GMPLS networks [RFC5920], in the mLDP specification
[RFC6388] and in P2MP RSVP-TE specification [RFC3209].
17. Acknowledgements 17. Acknowledgements
We would like to thank Eric Rosen for his comments. We would like to thank Eric Rosen for his comments. We also would
like to thank Loa Andersson for his review and comments.
18. References 18. References
18.1. Normative References 18.1. Normative References
[RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC1997, [RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC
August 1996 1997, 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, RFC 2119, March 1997
[RFC3209] "RSVP-TE: Extensions to RSVP for LSP Tunnels", D. Awduche,
et al., RFC 3209, December 2001
[RFC4360] S. Sangle et. al., "BGP Extended Communities Attribute", [RFC4360] S. Sangle et. al., "BGP Extended Communities Attribute",
RFC4360, February 2006 RFC 4360, February 2006
[RFC4456] T. Bates et. al., "BGP Route Reflection: An Alternative to [RFC4456] T. Bates et. al., "BGP Route Reflection: An Alternative to
Full Mesh Internal BGP (IBGP)", RFC4456, April 2006 Full Mesh Internal BGP (IBGP)", RFC 4456, April 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
[RFC6368] "Internal BGP as PE-CE protocol", Pedro Marques, et al., [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
RFC6368, September 2011 Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 4875, May 2007
[RFC5036] "LDP Specification", Loa Andersson, et al., RFC 5036,
October 2007
[RFC5331] "MPLS Upstream Label Assignment and Context-Specific Label [RFC5331] "MPLS Upstream Label Assignment and Context-Specific Label
Space", Rahul Aggarwal, et al., RFC5331, August 2008 Space", Rahul Aggarwal, et al., RFC 5331, August 2008
[RFC5332] "MPLS Multicast Encapsulations", T. Eckert, E. Rosen, R. [RFC5332] "MPLS Multicast Encapsulations", T. Eckert, E. Rosen, R.
Aggarwal, Y. Rekhter, RFC5332, August 2008 Aggarwal, Y. Rekhter, RFC 5332, August 2008
[RFC6368] "Internal BGP as PE-CE protocol", Pedro Marques, et al.,
RFC 6368, September 2011
[RFC6513] "Multicast in MPLS/BGP IP VPNs", Eric Rosen, et al., RFC
6513, February 2012
[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, RFC 6514,
2012 February 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, RFC 6074, January 2011
[RFC6388] "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths",
Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, RFC
6388, November 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., RFC 6625, May 2012
[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, [RFC7117] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, RFC
draft-ietf-l2vpn-vpls-mcast, work in progress 7117, February 2014
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
[RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang,
et al., RFC 5920, July 2010
[RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et. [RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et.
al., RFC7024, October 2013 al., RFC 7024, 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
 End of changes. 63 change blocks. 
157 lines changed or deleted 226 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/