draft-ietf-mpls-seamless-mcast-15.txt   draft-ietf-mpls-seamless-mcast-16.txt 
Network Working Group Y. Rekhter Network Working Group Y. Rekhter
Internet Draft Juniper Networks Internet Draft E. Rosen
Intended status: Standards Track Intended status: Standards Track Juniper Networks
Expiration Date: July 2015 Expiration Date: August 2015 R. Aggarwal
R. Aggarwal Arktan
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
E. Rosen February 2015
Juniper Networks
January 9, 2015
Inter-Area P2MP Segmented LSPs Inter-Area P2MP Segmented LSPs
draft-ietf-mpls-seamless-mcast-15.txt draft-ietf-mpls-seamless-mcast-16.txt
Abstract Abstract
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, using P2MP LSP segments are either carried over intra-area P2MP LSPs, using P2MP LSP
hierarchy, or instantiated using ingress replication. The intra-area hierarchy, or instantiated using ingress replication. The intra-area
P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
skipping to change at page 2, line 27 skipping to change at page 2, line 18
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) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1 Introduction .......................................... 4 1 Introduction .......................................... 4
2 Specification of requirements ......................... 5 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 ... 8 5 Discovering P2MP FEC of Inter-Area P2MP Service LSP ... 7
5.1 BGP MVPN .............................................. 8 5.1 BGP MVPN .............................................. 8
5.1.1 Routes originated by PE or ASBR ....................... 8 5.1.1 Routes originated by PE or ASBR ....................... 8
5.1.2 Routes re-avertise by PE or ASBR ...................... 9 5.1.2 Routes Re-Advertised by PE or ASBR .................... 8
5.1.3 Inter-area routes ..................................... 9 5.1.3 Inter-area routes ..................................... 9
5.2 LDP VPLS with BGP auto-discovery or BGP VPLS .......... 10 5.2 LDP VPLS with BGP auto-discovery or BGP VPLS .......... 10
5.2.1 Routes originated by PE or ASBR ....................... 10 5.2.1 Routes originated by PE or ASBR ....................... 10
5.2.2 Routes re-avertise by PE or ASBR ...................... 10 5.2.2 Routes Re-Advertised by PE or ASBR .................... 10
5.2.3 Inter-area routes ..................................... 11 5.2.3 Inter-area routes ..................................... 11
5.3 Global Table Multicast over MPLS ...................... 12 5.3 Global Table Multicast over MPLS ...................... 11
6 Egress PE/ASBR Signaling Procedures ................... 12 6 Egress PE/ASBR Signaling Procedures ................... 12
6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 13 6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 12
6.1.1 Upstream Node for MVPN or VPLS ........................ 13 6.1.1 Upstream Node for MVPN or VPLS ........................ 13
6.1.2 Upstream Node for Global Table Multicast .............. 13 6.1.2 Upstream Node for Global Table Multicast .............. 13
6.2 Originating a Leaf A-D Route .......................... 14 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 ............. 15 6.2.2 Leaf A-D Route for Global Table Multicast ............. 14
6.2.3 Constructing the Rest of the Leaf A-D Route ........... 17 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 16
6.3 PIM-SM in ASM mode for Global Table Multicast ......... 17 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 .................. 18 6.3.1.1 Originating Source Active A-D Routes .................. 17
6.3.1.2 Receiving BGP Source Active A-D Route by PE ........... 18 6.3.1.2 Receiving BGP Source Active A-D Route by PE ........... 18
6.3.1.3 Handling (S, G, rpt) state ............................ 19 6.3.1.3 Handling (S, G, rpt) state ............................ 18
6.3.2 Option 2 .............................................. 19 6.3.2 Option 2 .............................................. 19
6.3.2.1 Originating Source Active A-D Routes .................. 19 6.3.2.1 Originating Source Active A-D Routes .................. 19
6.3.2.2 Receiving BGP Source Active A-D Route ................. 20 6.3.2.2 Receiving BGP Source Active A-D Route ................. 19
6.3.2.3 Pruning Sources off the Shared Tree ................... 20 6.3.2.3 Pruning Sources off the Shared Tree ................... 20
6.3.2.4 More on handling (S, G, rpt) state .................... 21 6.3.2.4 More on handling (S, G, rpt) state .................... 20
7 Egress ABR Procedures ................................. 21 7 Egress ABR Procedures ................................. 21
7.1 Handling Leaf A-D route on Egress ABR ................. 21 7.1 Handling Leaf A-D route on Egress ABR ................. 21
7.2 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 23 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 ........... 23 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 . 24 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 .......... 24 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 ............... 26 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 ........... 26 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 ................................ 27 8 Ingress ABR Procedures ................................ 27
8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 27 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 ............................ 28 9 Ingress PE/ASBR Procedures ............................ 28
skipping to change at page 4, line 30 skipping to change at page 4, line 25
14 Support for Inter-Area Transport LSPs ................. 33 14 Support for Inter-Area Transport LSPs ................. 33
14.1 Transport Tunnel Tunnel Type .......................... 34 14.1 Transport Tunnel Tunnel Type .......................... 34
14.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 34 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 ........... 35 14.4 Egress PE Procedures for P2MP Transport LSP ........... 35
14.5 ABRs and Ingress PE procedures for P2MP Transport LSP . 36 14.5 ABRs and Ingress PE procedures for P2MP Transport LSP . 36
14.6 Discussion ............................................ 37 14.6 Discussion ............................................ 37
15 IANA Considerations ................................... 39 15 IANA Considerations ................................... 39
16 Security Considerations ............................... 39 16 Security Considerations ............................... 39
17 Acknowledgements ...................................... 39 17 Acknowledgements ...................................... 39
18 References ............................................ 39 18 References ............................................ 40
18.1 Normative References .................................. 39 18.1 Normative References .................................. 40
18.2 Informative References ................................ 41 18.2 Informative References ................................ 41
19 Author's Address ...................................... 41 19 Author's Address ...................................... 41
1. 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
skipping to change at page 5, line 36 skipping to change at page 5, line 31
as specified in this document. as specified in this document.
2. Specification of requirements 2. 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].
3. General Assumptions and Terminology 3. General Assumptions and Terminology
The reader is suppose to be familiar with MVPN procedures and The reader is assumed to be familiar with MVPN procedures and
terminology [RFC6513, RFC6514] and VPLS procedures and terminology terminology [RFC6513, RFC6514] and VPLS procedures and terminology
[RFC7117]. [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-
skipping to change at page 9, line 5 skipping to change at page 8, line 37
policy (provisioned on the ingress PEs or ASBRs) there is no policy (provisioned on the ingress PEs or ASBRs) there is no
aggregation of ingress area segments of the service LSPs, and (b) aggregation of ingress 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 ingress area. Before any Leaf A-D route is advertised by a PE in the ingress area. Before any Leaf A-D route is advertised by a PE
or ABR in the same area, as described in the following sections, an or ABR in the same area, as described in the following sections, an
I-PMSI/S-PMSI A-D route is advertised either with an explicit Tunnel I-PMSI/S-PMSI A-D route is advertised either with an explicit Tunnel
Type and Tunnel Identifier in the PMSI Tunnel Attribute, if the Type and Tunnel Identifier in the PMSI Tunnel Attribute, if the
Tunnel Identifier has already been assigned, or with a special Tunnel Tunnel Identifier has already been assigned, or with a special Tunnel
Type of "No tunnel information present" otherwise. Type of "No tunnel information present" otherwise.
5.1.2. Routes re-avertise by PE or ASBR 5.1.2. Routes Re-Advertised 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
skipping to change at page 10, line 7 skipping to change at page 9, line 40
Community, then before re-advertising this route to an EBGP peer the Community, then before re-advertising this route to an EBGP peer the
ASBR SHOULD remove this Community from the route. ASBR SHOULD remove this Community from the route.
If an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP peer, and If an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP peer, and
this route does carry the Inter-area P2MP Segmented Next-Hop Extended this route does carry the Inter-area P2MP Segmented Next-Hop Extended
Community, if the inter-area P2MP service LSP signalled by this route Community, if the inter-area P2MP service LSP signalled by this route
should not be segmented, then before re-advertising this route to its should not be segmented, then before re-advertising this route to its
IBGP peers the ASBR MUST remove this community from the route. 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 that ABRs MUST NOT modify
Hop when re-advertising Inter-AS I-PMSI A-D routes. For consistency BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. For
this document requires ABRs to NOT modify BGP Next Hop when re- consistency this document requires that ABRs MUST NOT modify BGP Next
advertising both Intra-AS and Inter-AS I-PMSI/S-PMSI A-D routes. The Hop when re-advertising either Intra-AS or Inter-AS I-PMSI/S-PMSI A-D
egress PEs may advertise the C-multicast routes to RRs that are routes. The egress PEs may advertise the C-multicast routes to RRs
different than the ABRs. However ABRs still can be configured to be that are different than the ABRs. However ABRs still can be
the Route Reflectors for C-multicast routes, in which case they will configured to be the Route Reflectors for C-multicast routes, in
participate in the propagation of C-multicast routes. which case they will participate in the propagation of C-multicast
routes.
5.2. LDP VPLS with BGP auto-discovery or BGP VPLS 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 [RFC7117]. 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 5.2.1. Routes originated by PE or ASBR
skipping to change at page 10, line 40 skipping to change at page 10, line 29
ASBRs) there is no aggregation of ingress area segments of the ASBRs) there is no aggregation of ingress 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 ingress area. Before any Leaf A-D intra-area transport LSPs in the ingress area. Before any Leaf A-D
route is advertised by a PE or ABR in the same area, as described in route is advertised by a PE or ABR in the same area, as described in
the following sections, an VPLS/S-PMSI A-D route is advertised either the following sections, an VPLS/S-PMSI A-D route is advertised either
with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel
Attribute, if the Tunnel Identifier has already been assigned, or Attribute, if the Tunnel Identifier has already been assigned, or
with a special Tunnel Type of "No tunnel information present" with a special Tunnel Type of "No tunnel information present"
otherwise. otherwise.
5.2.2. Routes re-avertise by PE or ASBR 5.2.2. Routes Re-Advertised 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
skipping to change at page 24, line 14 skipping to change at page 24, line 7
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
When the RD of the received Leaf A-D route is set to all 0s or all When the RD of the received Leaf A-D route is set to all 0s or all
1s, then this is the case of inter-area P2MP service LSP being 1s, then this is the case of inter-area P2MP service LSP being
associated with the global table multicast service. The procedures associated with the global table multicast service. The procedures
for this are described below. for this are described below.
7.2.2.1. Global Table Multicast and S-PMSI A-D Routes 7.2.2.1. Global Table Multicast and S-PMSI A-D Routes
This section applies only if it is desirable to send a particular (S, This section applies only if it is desired to send a particular (S,
G) or (*, G) global table multicast flow only to those egress PEs G) or (*, G) global table multicast flow to only those egress PEs
that have receivers for that multicast flow. that have receivers for that multicast flow.
If the egress ABR have not previously received (and re-advertised) an If the egress ABR have not previously received (and re-advertised) an
S-PMSI A-D route for (S, G) or (*, G) that has been originated by an S-PMSI A-D route for (S, G) or (*, G) that has been originated by an
ingress PE/ASBR (see section "P2MP LSP as the Intra-Area LSP in the ingress PE/ASBR (see section "P2MP LSP as the Intra-Area LSP in the
Ingress Area"), then the egress ABR MUST originate a S-PMSI A-D Ingress Area"), then the egress ABR MUST originate a S-PMSI A-D
route. The PMSI Tunnel attribute of the route MUST contain the route. The PMSI Tunnel attribute of the route MUST contain the
identity of the intra-area P2MP LSP and an upstream assigned MPLS identity of the intra-area P2MP LSP and an upstream assigned MPLS
label (although this label may be an Implicit NULL - see section label (although this label may be an Implicit NULL - see section
"General Assumptions and Terminology"). The RD, Multicast Source "General Assumptions and Terminology"). The RD, Multicast Source
skipping to change at page 25, line 44 skipping to change at page 25, line 36
7.2.3. Global Table Multicast and the Expected Upstream Node 7.2.3. Global Table Multicast and the Expected Upstream Node
If the mapping between the inter-area P2MP service LSP for global If the mapping between the inter-area P2MP service LSP for global
table multicast service and the intra-area P2MP LSP is many-to-one table multicast service and the intra-area P2MP LSP is many-to-one
then an egress PE must be able to determine whether a given multicast then an egress PE must be able to determine whether a given multicast
packet for a particular (S, G) is received from the "expected" packet for a particular (S, G) is received from the "expected"
upstream node. The expected node is the node towards which the Leaf upstream node. The expected node is the node towards which the Leaf
A-D route is sent by the egress PE. Packets received from another A-D route is sent by the egress PE. Packets received from another
upstream node for that (S, G) MUST be dropped. To allow the egress PE upstream node for that (S, G) MUST be dropped. To allow the egress PE
to determine the sender upstream node, the intra-area P2MP LSP must to determine the sender upstream node, the intra-area P2MP LSP MUST
be signaled with no PHP, when the mapping between the inter-area P2MP be signaled with no PHP, when the mapping between the inter-area P2MP
service LSP for global table multicast service and the intra-area service LSP for global table multicast service and the intra-area
P2MP LSP is many-to-one. P2MP LSP is many-to-one.
Further the egress ABR MUST first push onto the label stack the Further the egress ABR MUST first push onto the label stack the
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
skipping to change at page 33, line 37 skipping to change at page 33, line 37
label stack of the P2P or MP2P LSP to the leaf. label stack of the P2P or MP2P LSP to the leaf.
13.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.
14. 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 multiple
multiple (inter-area) P2MP service LSPs into a single inter-area P2MP (inter-area) P2MP LSPs to be aggregated into a single inter-area P2MP
transport LSP, and then apply the segmentation procedures, as "transport LSP". The segmentation procedures, as specified in this
specified in this document, to these inter-area P2MP transport LSPs document, are then applied to these inter-area P2MP transport LSPs,
(rather than applying these procedures directly to the inter-area rather than being applied directly to the individual LSPs that are
P2MP service LSPs). aggregated into the transport). In the following, the individual
LSPs that are aggregated into a single transport LSP will be known as
"service LSPs".
14.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
skipping to change at page 39, line 23 skipping to change at page 39, line 23
Sub-Types registry, and IANA has assigned the value 0x0012 in the Sub-Types registry, and IANA has assigned the value 0x0012 in the
Transitive IPv6-Address-Specific Extended Community Types registry. Transitive IPv6-Address-Specific Extended Community Types registry.
This document is the reference for both codepoints. IANA is This document is the reference for both codepoints. IANA is
requested to change in these registries the reference to the RFC requested to change in these registries the reference to the RFC
number as soon as this document is published as an RFC. number as soon as this document is published as an RFC.
IANA is requested to assign a value from the PMSI Tunnel Types IANA is requested to assign a value from the PMSI Tunnel Types
registry [pmsi-registry] for "Transport Tunnel" (see section registry [pmsi-registry] for "Transport Tunnel" (see section
"Transport Tunnel Type"). The value 0x08 is requested. "Transport Tunnel Type"). The value 0x08 is requested.
This document makes use of a Route Distinguisher whose value is all
1's. The two-octet type field of this Route Distinguisher thus has
the value 65535. IANA is therefore requested to assign the value
65535 from the "Route Distinguisher Type Field" registry to "For Use
Only in Certain Leaf A-D Routes", with this document as the
reference.
16. Security Considerations 16. Security Considerations
Procedures described in this document are subject to similar security Procedures described in this document are subject to similar security
threats as any MPLS deployment. It is recommended that baseline threats as any MPLS deployment. It is recommended that baseline
security measures are considered as described in Security Framework security measures are considered as described in Security Framework
for MPLS and GMPLS networks [RFC5920], in the mLDP specification for MPLS and GMPLS networks [RFC5920], in the mLDP specification
[RFC6388] and in P2MP RSVP-TE specification [RFC3209]. [RFC6388] and in P2MP RSVP-TE specification [RFC3209].
17. Acknowledgements 17. Acknowledgements
We would like to thank Loa Andersson and Qin Wu for their review and We would like to thank Eric Rosen for his comments. We also would
comments. like to thank Loa Andersson and Qin Wu for their review and comments.
18. References 18. References
18.1. Normative References 18.1. Normative References
[RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC [RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC
1997, 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, RFC 2119, March 1997 Levels.", Bradner, RFC 2119, March 1997
skipping to change at page 41, line 33 skipping to change at page 41, line 47
[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., RFC 7024, 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
United States
Email: yakov@juniper.net Email: yakov@juniper.net
Rahul Aggarwal Rahul Aggarwal
Email: raggarwa_1@yahoo.com Email: raggarwa_1@yahoo.com
Thomas Morin Thomas Morin
France Telecom R & D France Telecom R & D
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
skipping to change at page 42, line 10 skipping to change at page 42, line 24
France Telecom R & D France Telecom R & D
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
Email: irene.grosclaude@orange-ftgroup.com Email: irene.grosclaude@orange-ftgroup.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom AG Deutsche Telekom AG
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
DE Germany
Email: n.leymann@telekom.de Email: n.leymann@telekom.de
Samir Saad Samir Saad
AT&T AT&T
Email: samirsaad1@outlook.com Email: samirsaad1@outlook.com
Eric Rosen Eric C Rosen
Juniper Networks Juniper Networks
10 Technology Park Drive
Westford, MA 01886
Email: erosen@juniper.net Email: erosen@juniper.net
 End of changes. 34 change blocks. 
65 lines changed or deleted 59 lines changed or added

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