draft-ietf-mpls-seamless-mcast-00.txt   draft-ietf-mpls-seamless-mcast-01.txt 
Network Working Group Y. Rekhter Network Working Group Y. Rekhter
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: December 2011 Expiration Date: February 2012
R. Aggarwal R. Aggarwal
Juniper Networks Juniper Networks
T. Morin T. Morin
France Telecom France Telecom
I. Grosclaude I. Grosclaude
France Telecom France Telecom
N. Leymann N. Leymann
Deutsche Telekom AG Deutsche Telekom AG
S. Saad S. Saad
AT&T AT&T
June 5, 2011 August 18, 2011
Inter-Area P2MP Segmented LSPs Inter-Area P2MP Segmented LSPs
draft-ietf-mpls-seamless-mcast-00.txt draft-ietf-mpls-seamless-mcast-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 11 skipping to change at page 3, line 11
LSPs may be used in the IGP area. The applications/services that use LSPs may be used in the IGP area. The applications/services that use
such an inter-area service LSP may be BGP MVPN, VPLS multicast or such an inter-area service LSP may be BGP MVPN, VPLS multicast or
Internet multicast over MPLS. Internet multicast over MPLS.
Table of Contents Table of Contents
1 Specification of requirements ......................... 4 1 Specification of requirements ......................... 4
2 Introduction .......................................... 4 2 Introduction .......................................... 4
3 General Assumptions and Terminology ................... 5 3 General Assumptions and Terminology ................... 5
4 Inter-area P2MP Segmented Next-Hop Extended Community . 6 4 Inter-area P2MP Segmented Next-Hop Extended Community . 6
5 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 6 5 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 7
5.1 BGP MVPN .............................................. 6 5.1 BGP MVPN .............................................. 7
5.2 BGP VPLS or LDP VPLS with BGP A-D ..................... 7 5.2 BGP VPLS or LDP VPLS with BGP A-D ..................... 8
5.3 Internet Multicast .................................... 8 5.3 Internet Multicast .................................... 9
6 Egress PE Procedures .................................. 9 6 Egress PE Procedures .................................. 10
6.1 Determining the Upstream ABR/PE/ASBR .................. 9 6.1 Determining the Upstream ABR/PE/ASBR .................. 10
6.2 Originating a Leaf Auto-Discovery Route ............... 10 6.2 Originating a Leaf Auto-Discovery Route ............... 12
6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 10 6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 12
6.2.2 Leaf A-D Route for Internet Multicast ................. 11 6.2.2 Leaf A-D Route for Internet Multicast ................. 12
6.2.3 Constructing the Rest of the Leaf A-D Route ........... 12 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 14
6.3 PIM-SM in ASM mode for Internet Multicast ............. 12 6.3 PIM-SM in ASM mode for Internet Multicast ............. 14
6.3.1 Option 1 .............................................. 12 6.3.1 Option 1 .............................................. 15
6.3.1.1 Originating Source Active auto-discovery routes ....... 13 6.3.1.1 Originating Source Active auto-discovery routes ....... 15
6.3.1.2 Receiving BGP Source Active auto-discovery route by PE ....13 6.3.1.2 Receiving BGP Source Active auto-discovery route by PE ....15
6.3.1.3 Handling (S, G, RPTbit) state ......................... 14 6.3.1.3 Handling (S, G, RPTbit) state ......................... 16
6.3.2 Option 2 .............................................. 14 6.3.2 Option 2 .............................................. 16
6.3.2.1 Originating Source Active auto-discovery routes ....... 14 6.3.2.1 Originating Source Active auto-discovery routes ....... 16
6.3.2.2 Receiving BGP Source Active auto-discovery route ...... 15 6.3.2.2 Receiving BGP Source Active auto-discovery route ...... 17
6.3.2.3 Pruning Sources off the Shared Tree ................... 15 6.3.2.3 Pruning Sources off the Shared Tree ................... 17
6.3.2.4 More on handling (S, G, RPTbit) state ................. 15 6.3.2.4 More on handling (S, G, RPTbit) state ................. 18
7 Egress ABR Procedures ................................. 16 7 Egress ABR Procedures ................................. 18
7.1 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 18 7.1 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 20
7.1.1 RD of the received Leaf-AD route is not zero or all ones ..18 7.1.1 RD of the received Leaf-AD route is not zero or all ones ..20
7.1.2 RD of the received Leaf A-D route is zero or all ones . 19 7.1.2 RD of the received Leaf A-D route is zero or all ones . 21
7.1.2.1 Internet Multicast and S-PMSI A-D Routes .............. 19 7.1.2.1 Internet Multicast and S-PMSI A-D Routes .............. 21
7.1.2.2 Internet Multicast and Wildcard S-PMSI A-D Routes ..... 19 7.1.2.2 Internet Multicast and Wildcard S-PMSI A-D Routes ..... 21
7.1.3 Internet Multicast and the Expected Upstream Node ..... 19 7.1.3 Internet Multicast and the Expected Upstream Node ..... 22
7.1.4 P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 20 7.1.4 P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 22
7.1.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 20 7.1.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 22
7.2 Ingress Replication in the Egress Area ................ 20 7.2 Ingress Replication in the Egress Area ................ 23
8 Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 21 8 Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 23
8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 21 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 23
8.2 Ingress Replication in the Backbone Area .............. 22 8.2 Ingress Replication in the Backbone Area .............. 24
9 Ingress PE/ASBR Procedures ............................ 22 9 Ingress PE/ASBR Procedures ............................ 24
9.1 P2MP LSP as the intra-area LSP in the ingress area .... 23 9.1 P2MP LSP as the intra-area LSP in the ingress area .... 25
9.2 Ingress Replication in the Ingress Area ............... 23 9.2 Ingress Replication in the Ingress Area ............... 26
10 Common Tunnel Type in the Ingress and Egress Areas .... 24 10 Common Tunnel Type in the Ingress and Egress Areas .... 26
11 Placement of Ingress and Egress PEs ................... 24 11 Placement of Ingress and Egress PEs ................... 27
12 Data Plane ............................................ 25 12 Data Plane ............................................ 27
12.1 Data Plane Procedures on an ABR ....................... 25 12.1 Data Plane Procedures on an ABR ....................... 27
12.2 Data Plane Procedures on an Egress PE ................. 25 12.2 Data Plane Procedures on an Egress PE ................. 28
12.3 Data Plane Procedures on an Ingress PE ................ 26 12.3 Data Plane Procedures on an Ingress PE ................ 29
12.4 Data Plane Procedures on Transit Routers .............. 27 12.4 Data Plane Procedures on Transit Routers .............. 29
13 IANA Considerations ................................... 27 13 Support for Inter-Area Transport LSPs ................. 29
14 Security Considerations ............................... 27 13.1 Transport Tunnel Tunnel Type .......................... 30
15 References ............................................ 27 13.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 30
15.1 Normative References .................................. 27 13.3 Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP 30
15.2 Informative References ................................ 28 13.4 Egress PE Procedures for Inter-Area P2MP Transport LSP ....31
16 Author's Address ...................................... 28 13.5 Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area Transport LSP 32
13.6 Discussion ............................................ 32
14 IANA Considerations ................................... 34
15 Security Considerations ............................... 34
16 Acknowledgements ...................................... 35
17 References ............................................ 35
17.1 Normative References .................................. 35
17.2 Informative References ................................ 35
18 Author's Address ...................................... 35
1. Specification of requirements 1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document describes procedures for building inter-area point-to- This document describes procedures for building inter-area point-to-
skipping to change at page 5, line 22 skipping to change at page 5, line 30
intra-AS segment is constructed using inter-area segmented P2MP LSPs intra-AS segment is constructed using inter-area segmented P2MP LSPs
as specified in this document. as specified in this document.
3. General Assumptions and Terminology 3. General Assumptions and Terminology
This document assumes BGP is used as an inter-area routing and label This document assumes BGP is used as an inter-area routing and label
distribution protocol for the unicast IPv4 /32 or IPv6 /128 routes distribution protocol for the unicast IPv4 /32 or IPv6 /128 routes
for the PEs. This document also assumes ABRs act as Route Reflectors for the PEs. This document also assumes ABRs act as Route Reflectors
(RR) for these routes. (RR) for these routes.
When supporting segmentation of the inter-area P2MP MVPN service
LSPs, instead of assuming that BGP is used as an inter-area routing
and label distribution protocol for unicast IPv4 /32 or IPv6 /128
routes, it is sufficient to assume that BGP is used as an inter-area
routing protocol for unicast IPv4 /32 or IPv6 /128 routes used for
multicast forwarding (SAFI = 2).
Within an AS a P2MP service LSP is partitioned into 3 segments: Within an AS a P2MP service LSP is partitioned into 3 segments:
ingress area segment, backbone area segment, and egress area segment. ingress area segment, backbone area segment, and egress area segment.
Within each area a segment is carried over an intra-area P2MP LSP or Within each area a segment is carried over an intra-area P2MP LSP or
instantiated using ingress replication. instantiated using ingress replication.
When intra-area P2MP LSPs are used to instantiate the intra-area When intra-area P2MP LSPs are used to instantiate the intra-area
segments there could be either 1:1 or n:1 mapping between intra-area segments there could be either 1:1 or n:1 mapping between intra-area
segments of the inter-area P2MP service LSP and a given intra-area segments of the inter-area P2MP service LSP and a given intra-area
P2MP LSP. The latter is realized using P2MP LSP hierarchy with P2MP LSP. The latter is realized using P2MP LSP hierarchy with
upstream-assigned labels [RFC5331]. For simplicity we assume that upstream-assigned labels [RFC5331]. For simplicity we assume that
skipping to change at page 6, line 7 skipping to change at page 6, line 22
an ABR that is connected to the ingress area (ingress ABR), and has an ABR that is connected to the ingress area (ingress ABR), and has
as its leaves ABRs that are connected to the egress area(s) or PEs in as its leaves ABRs that are connected to the egress area(s) or PEs in
the backbone area. The egress area segment is rooted at an ABR in the backbone area. The egress area segment is rooted at an ABR in
the egress area (egress ABR), and has as its leaves PEs and ASBR in the egress area (egress ABR), and has as its leaves PEs and ASBR in
that egress area (the latter covers the case where the P2MP service that egress area (the latter covers the case where the P2MP service
LSP spans multiple ASes). Note that for a given P2MP service LSP LSP spans multiple ASes). Note that for a given P2MP service LSP
there may be more than one backbone segment, each rooted at its own there may be more than one backbone segment, each rooted at its own
ingress ABR, and more than one egress area segment, each rooted at ingress ABR, and more than one egress area segment, each rooted at
its own egress ABR. its own egress ABR.
An implementation that supports this document MUST implement the
procedures described in the following sections to support inter-area
point-to-multipoint (P2MP) segmented service LSPs.
4. Inter-area P2MP Segmented Next-Hop Extended Community 4. Inter-area P2MP Segmented Next-Hop Extended Community
This document defines a new BGP Extended Community "Inter-area P2MP This document defines a new BGP Extended Community "Inter-area P2MP
Next-Hop" extended community. This is an IP address specific Extended Next-Hop" extended community. This is an IP address specific Extended
Community, of an extended type and is transitive across AS boundaries Community, of an extended type and is transitive across AS boundaries
[RFC4360]. [RFC4360].
A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented
Next-Hop Extended Community as follows: Next-Hop Extended Community as follows:
skipping to change at page 7, line 7 skipping to change at page 7, line 28
Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN
using the I-PMSI or S-PMSI A-D routes that are originated by the using the I-PMSI or S-PMSI A-D routes that are originated by the
ingress PEs or ASBRs following the procedures of [BGP-MVPN], along ingress PEs or ASBRs following the procedures of [BGP-MVPN], along
with modifications as described in this document. The NLRI of such with modifications as described in this document. The NLRI of such
routes encodes the P2MP FEC. The procedures in this document require routes encodes the P2MP FEC. The procedures in this document require
that at least one ABR in a given IGP area act as Route Reflector for that at least one ABR in a given IGP area act as Route Reflector for
MVPN auto-discovery (A-D) routes. MVPN auto-discovery (A-D) routes.
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 such routes, when originated by the ingress PEs
or ASBRs. Before any Leaf auto discovery route is advertised by a PE or ASBRs, except for the case where (a) as a matter of policy
or ABR in the same area, as described in the following sections, an (provisioned on the ingress PEs or ASBRs) there is no aggregation of
ingress area segments of the service LSPs, and (b) mLDP is used as
the protocol to establish intra-area transport LSPs in the ingress
area. Before any Leaf auto discovery route is advertised by a PE or
ABR in the same area, as described in the following sections, an
I-/S-PMSI auto-discovery route is advertised either with an explicit I-/S-PMSI auto-discovery route is advertised either with an explicit
Tunnel Type and Tunnel Identifier in the PMSI Tunnel Attribute, if Tunnel Type and Tunnel Identifier in the PMSI Tunnel Attribute, if
the Tunnel Identifier has already been assigned, or with a special the Tunnel Identifier has already been assigned, or with a special
Tunnel Type of "No tunnel information present" otherwise. When the Tunnel Type of "No tunnel information present" otherwise.
I/S-PMSI routes are re-advertised by an ABR, "Leaf Information
Required" flag MUST be set in the P-Tunnel attribute present in the When the I/S-PMSI routes are re-advertised by an ingress ABR, the
routes. "Leaf Information Required" flag 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 ingress ABR) there is no
aggregation of backbone area segments of the service LSPs, and (b)
mLDP is used as the protocol to establish intra-area transport LSPs
in the backbone area. Likewise, when the I/S-PMSI routes are re-
advertised by an egress 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 matter of policy (provisioned on 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
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.
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, they MUST carry propagated to signal Inter-area P2MP service LSPs, to indicate that
the Inter-area P2MP Segmented Next-Hop Extended Community. This these LSPs should be segmented using the procedures specified in this
Extended Community MUST be included in the I/S-PMSI A-D route by the document, these routes MUST carry the Inter-area P2MP Segmented Next-
PE or ASBR that originates such a route and the Global Administrator Hop Extended Community. This Extended Community MUST be included in
field MUST be set to the advertising PE or ASBR's IP address. This the I/S-PMSI A-D route by the PE or ASBR that originates such a route
Extended Community MUST also be included by ABRs as they re-advertise and the Global Administrator field MUST be set to the advertising PE
such routes. An ABR MUST set the Global Administrator field of the or ASBR's IP address. This Extended Community MUST also be included
P2MP Segmented Next-Hop Extended Community to its own IP address. by ABRs as they re-advertise such routes. An ABR MUST set the Global
This allows ABRs and PEs/ASBRs to follow the procedures in this Administrator field of the P2MP Segmented Next-Hop Extended Community
document when these procedures differ from those in [BGP-MVPN]. to its own IP address. This allows ABRs and PEs/ASBRs to follow the
procedures in this document when these procedures differ from those
in [BGP-MVPN].
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 consitancy Hop when re-advertising Inter-AS I-PMSI A-D routes. For consitancy
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/S-PMSI A-D routes. The advertising both Intra-AS and Inter-AS I/S-PMSI A-D routes. The
egress PEs may advertise the C-multicast routes to RRs that are egress PEs may advertise the C-multicast routes to RRs that are
different than the ABRs. However ABRs still can be configured to be different than the ABRs. However ABRs still can be configured to be
the Route Reflectors for C-multicast routes, in which case they will the Route Reflectors for C-multicast routes, in which case they will
participate in the propagation of C-multicast routes. participate in the propagation of C-multicast routes.
skipping to change at page 7, line 49 skipping to change at page 8, line 39
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 A-D 5.2. BGP VPLS or LDP VPLS with BGP A-D
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
[BGP-VPLS, VPLS-AD] or S-PMSI A-D routes that are originated by the [BGP-VPLS, VPLS-AD] or S-PMSI A-D routes that are originated by the
ingress PE [VPLS-P2MP]. The NLRI of such routes encodes the P2MP FEC. ingress PE [VPLS-P2MP]. The NLRI of such routes encodes the P2MP FEC.
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. Before any Leaf auto discovery attribute carried in such routes, when originated by the ingress PEs
route is advertised by a PE or ABR in its own area, as described in or ASBRs, except for the case where (a) as a matter of policy
the following sections, an VPLS/S-PMSI autodiscovery route is (provisioned on the ingress PEs or ASBRs) there is no aggregation of
advertised either with an explicit Tunnel Type and Tunnel Identifier ingress area segments of the service LSPs, and (b) mLDP is used as
in the PMSI Tunnel Attribute, if the Tunnel Identifier has already the protocol to establish intra-area transport LSPs in the ingress
been assigned, or with a special Tunnel Type of "No tunnel area. Before any Leaf auto-discovery route is advertised by a PE or
information present" otherwise. ABR in the same area, as described in the following sections, an
VPLS/S-PMSI auto-discovery route is advertised either with an
explicit Tunnel 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.
When the VPLS/S-PMSI auto-discovery routes are re-advertised by an
ingress 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 matter of policy (provisioned on the ingress ABR) there is
no aggregation of backbone area segments of the service LSPs, and (b)
mLDP is used as the protocol to establish intra-area transport LSPs
in the backbone area. Likewise, when the VPLS/S-PMSI auto-discovery
routes are re-advertised by an egress 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 matter of policy
(provisioned on 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 intra-area transport LSPs in the egress area.
When VPLS A-D or S-PMSI A-D routes are advertised or propagated to When VPLS A-D or S-PMSI A-D routes are advertised or propagated to
signal Inter-area P2MP service LSPs, they MUST carry the Inter-area signal Inter-area P2MP service LSPs, to indicate that these LSPs
P2MP Segmented Next-Hop Extended Community. This Extended Community should be segmented using the procedures specified in this document,
MUST be included in the A-D route by the PE or ASBR that originates these routes MUST carry the Inter-area P2MP Segmented Next-Hop
such a route and the Global Administrator field MUST be set to the Extended Community. This Extended Community MUST be included in the
advertising PE or ASBR's IP address. This Extended Community MUST A-D route by the PE or ASBR that originates such a route and the
also be included by ABRs as they re-advertise such routes. An ABR Global Administrator field MUST be set to the advertising PE or
MUST set the Global Administrator field of the P2MP Segmented Next- ASBR's IP address. This Extended Community MUST also be included by
Hop Extended Community to its own IP address. This allows ABRs and ABRs as they re-advertise such routes. An ABR MUST set the Global
PEs/ASBRs to follow the procedures in this document when these Administrator field of the P2MP Segmented Next-Hop Extended Community
procedures differ from those in [VPLS-P2MP]. to its own IP address. This allows ABRs and PEs/ASBRs to follow the
procedures in this document when these procedures differ from those
in [VPLS-P2MP].
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 act as Route Reflector for MVPN auto-discovery (A-D) given area act as Route Reflector for MVPN auto-discovery (A-D)
routes. These ABRs/RRs MUST NOT modify BGP Next Hop when re- routes. These ABRs/RRs MUST NOT modify BGP Next Hop when re-
advertising these A-D routes. advertising these A-D routes.
skipping to change at page 9, line 13 skipping to change at page 10, line 25
Infact PIM-SM in ASM mode may be supported entirely by using (S, G) Infact PIM-SM in ASM mode may be supported entirely by using (S, G)
trees alone. trees alone.
6. Egress PE Procedures 6. Egress PE Procedures
This section describes egress PE procedures for constructing This section describes egress PE procedures for constructing
segmented inter-area P2MP LSP. The procedures in this section apply segmented inter-area P2MP LSP. The procedures in this section apply
irrespective of whether the egress PE is in a leaf IGP area, or the irrespective of whether the egress PE is in a leaf IGP area, or the
backbone area or even in the same IGP area as the ingress PE/ASBR. backbone area or even in the same IGP area as the ingress PE/ASBR.
An egress PE applies procedures specified in this section to MVPN I-
PMSI or S-PMSI A-D routes only if these routes carry the Inter-area
P2MP Segmented Next-Hop Extended Community. An egress PE applies
procedures specified in this section to VPLS A-D or S-PMSI A-D routes
only if these routes carry the Inter-area P2MP Segmented Next-Hop
Extended Community.
In order to support Internet Multicast an egress PE MUST auto- In order to support Internet Multicast an egress PE MUST auto-
configure an import Route Target with the global administrator field configure an import Route Target with the global administrator field
set to the AS of the 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 discovers the P2MP FEC of an inter-area segmented Once an egress PE discovers the P2MP FEC of an inter-area segmented
P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to
construct the segmented inter-area P2MP service LSP. This propagation construct the segmented inter-area P2MP service LSP. This propagation
uses BGP Leaf auto-discovery routes. uses BGP Leaf auto-discovery routes.
6.1. Determining the Upstream ABR/PE/ASBR 6.1. Determining the Upstream ABR/PE/ASBR
skipping to change at page 10, line 14 skipping to change at page 11, line 32
i.e. SAFI 2 and the VRF Route Import Extended Community MUST be i.e. SAFI 2 and the VRF Route Import Extended Community MUST be
carried in such routes. carried in such routes.
Further if the application is internet multicast then the BGP unicast Further if the application is internet multicast then the BGP unicast
routes that advertise the route to the IP address of PEs or ASBRs or routes that advertise the route to the IP address of PEs or ASBRs or
ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended
Community where the IP address in the Global Administrator field is Community where the IP address in the Global Administrator field is
set to the IP address of the PE or ASBR or ABR advertising the set to the IP address of the PE or ASBR or ABR 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. If it is not desirable to advertise the P2MP Segmented be set to 0. If it is not desirable to advertise the P2MP Segmented
Import Extended Community in BGP unicast routes, then unicast routes Next-Hop Extended Community in BGP unicast routes, then unicast
to ABRs, ASBRs or PEs MUST be advertised using the multicast SAFI routes to ABRs, ASBRs or PEs MUST be advertised using the multicast
i.e. SAFI 2 and the Inter-area P2MP Segmented Next-hop Extended SAFI i.e. SAFI 2 and the Inter-area P2MP Segmented Next-hop Extended
Community MUST be carried in such routes. The procedures for handling Community MUST be carried in such routes. The procedures for handling
the next-hop of SAFI 2 routes are the same as those of handling the next-hop of SAFI 2 routes are the same as those of handling
regular Unicast routes and follow [SEAMLESS-MPLS]. regular Unicast routes and follow [SEAMLESS-MPLS].
In order to determine the upstream node address the egress PE first In order to determine the upstream node address the egress PE first
determines the ingress PE. The egress PE determines the best route to determines the ingress PE. The egress PE determines the best route to
reach S/RP. The ingress PE address is the IP address determined from reach S/RP. The ingress PE address is the IP address determined from
the Global Administrator field of the VRF Route Import Extended the Global Administrator field of the VRF Route Import Extended
Community, that is present in this route. The egress PE now finds the Community, that is present in this route. The egress PE now finds the
best unicast route to reach the ingress PE. The upstream node address best unicast route to reach the ingress PE. The upstream node address
skipping to change at page 12, line 13 skipping to change at page 13, line 34
| Ingress PE's IP address | | Ingress PE's IP address |
+-----------------------------------+ +-----------------------------------+
| Originating Router's IP address | | Originating Router's IP address |
+-----------------------------------+ +-----------------------------------+
When the PE deletes (S,G)/(*,G) state that was created as a result of When the PE deletes (S,G)/(*,G) state that was created as a result of
receiving PIM or IGMP messages on one of its IP multicast interfaces, receiving PIM or IGMP messages on one of its IP multicast interfaces,
if the PE previousely originated a Leaf auto-discovery route for that if the PE previousely originated a Leaf auto-discovery route for that
state, then the PE SHOULD withdraw that route. state, then the PE SHOULD withdraw that route.
An Autonomous System with an IPv4 network may provide IP multicast
service for customers that use IPv6, and an Autonomous System with an
IPv6 network may provide IP multicast service for customers that use
IPv4. Therefore the address family of the Ingress PE's IP address and
Originating Router's IP address in the Leaf A-D routes used for
Internet multicast MUST NOT be inferred from the AFI field of the
associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute of these routes.
The address family is determined from the length of the address (a
length of 4 octets for IPv4 addresses, a length of 16 octets for IPv6
addresses).
For example if an Autonomous System with an IPv4 network is
providing IPv6 multicast service to a customer, the Ingress PE's IP
address and Originating Router's IP address in the Leaf A-D routes
used for IPv6 Internet multicast will be a four-octet IPv4 address,
even though the AFI of those routes will have the value 2.
Note that the Ingress PE's IP address and the Originating Router's IP
address must be either both IPv4 or both IPv6 addresses, and thus
must be of the same length. Since the two variable length fields
(Multicast Source and Multicast Group) in the Leaf A-D routes used
for Internet multicast have their own length field, from these two
length fields, and the Length field of the MCAST-VPN NLRI, one can
compute length of the Ingress PE's IP address and the Originating
Router's IP address fields. If the computed length of these fields
is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered
to be "incorrect", and MUST be handled as specified in section 7 of
[BGP-MP].
6.2.3. Constructing the Rest of the Leaf A-D Route 6.2.3. Constructing the Rest of the Leaf A-D Route
The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
be set to the same IP address as the one carried in the Originating be set to the same IP address as the one carried in the Originating
Router's IP Address field of the route. Router's IP Address field of the route.
When Ingress Replication is used to instantiate the egress area When Ingress Replication is used to instantiate the egress area
segment then the Leaf A-D route MUST carry a downstream assigned segment then the Leaf A-D route MUST carry a downstream assigned
label in the P-Tunnel Attribute where the P-Tunnel type is set to label in the P-Tunnel Attribute where the P-Tunnel type is set to
Ingress Replication. A PE MUST assign a distinct MPLS label for each Ingress Replication. A PE MUST assign a distinct MPLS label for each
skipping to change at page 19, line 25 skipping to change at page 21, line 32
This section applies only if it is desirable to send a particular This section applies only if it is desirable to send a particular
Internet Multicast flow to only those egress PEs that have receivers Internet Multicast flow to only those egress PEs that have receivers
in a particular (S, G) or a particular (*, G) multicast flow. in a particular (S, G) or a particular (*, G) multicast flow.
The egress ABR MUST originate a S-PMSI A-D route. The PMSI Tunnel The egress ABR MUST originate a S-PMSI A-D route. The PMSI Tunnel
attribute of the route MUST contain the identity of the intra-area attribute of the route MUST contain the identity of the intra-area
P2MP LSP and an upstream assigned MPLS label. The RD, Multicast P2MP LSP and an upstream assigned MPLS label. The RD, Multicast
Source Length, Multicast Source, Multicast Group Length (1 octet), Source Length, Multicast Source, Multicast Group Length (1 octet),
and Multicast Group fields of the NLRI of this route are the same as and Multicast Group fields of the NLRI of this route are the same as
of the Leaf A-D route. The egress ABR MUST advertise this route into of the Leaf A-D route. The egress ABR MUST advertise this route into
the backbone area. The Route Target of this route is an AS specific the egress area. The Route Target of this route is an AS specific
route-target with the AS set to the AS of the advertising ABR while route-target with the AS set to the AS of the advertising ABR while
the local administrator field is set to 0. the local administrator field is set to 0.
7.1.2.2. Internet Multicast and Wildcard S-PMSI A-D Routes 7.1.2.2. Internet Multicast and Wildcard S-PMSI A-D Routes
It may be desirable for an ingress PE to aggregate Internet Multicast It may be desirable for an ingress PE to aggregate Internet Multicast
routes over a single Inter-area P2MP LSP. This can be achieved using routes over a single Inter-area P2MP LSP. This can be achieved using
wildcard, i.e., (*,*) S-PMSI A-D routes. An ingress PE MAY advertise wildcard, i.e., (*,*) S-PMSI A-D routes. An ingress PE MAY advertise
a wildcard S-PMSI route as described in section "Ingress PE a wildcard S-PMSI route as described in section "Ingress PE
Procedures". If the ingress PE does indeed originate such a route the Procedures". If the ingress PE does indeed originate such a route the
skipping to change at page 27, line 13 skipping to change at page 29, line 34
packet sent to each such leaf MUST first include a downstream packet sent to each such leaf MUST first include a downstream
assigned label assigned by the leaf to the segment, followed by the assigned label assigned by the leaf to the segment, followed by the
label stack of the P2P or MP2P LSP to the leaf. label stack of the P2P or MP2P LSP to the leaf.
12.4. Data Plane Procedures on Transit Routers 12.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 tansit routers in each area perform only P2MP Segmented LSPs then tansit routers in each area perform only
MPLS switching. MPLS switching.
13. IANA Considerations 13. Support for Inter-Area Transport LSPs
This section describes OPTIONAL procedures that allow to aggregate
multiple (inter-area) P2MP service LSPs into a single inter-area P2MP
transport LSPs, and then apply the segmentation procedures, as
specified in this document, to these inter-area P2MP transport LSPs
(rather than applying these procedures directly to the inter-area
P2MP service LSPs).
13.1. Transport Tunnel Tunnel Type
For the PMSI Tunnel Attribute we define a new Tunnel type, called
"Transport Tunnel", whose Tunnel Identifier is a tuple <Source PE
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
(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
Number part is the same as the length of the Source PE Address. Thus
if the Source PE Address is an IPv4 address, then the Local Number
part is 4 octets, and if the Source PE Address is an IPv6 address,
then the Local Number part is 16 octets.
13.2. Discovering Leaves of the Inter-Area P2MP Service LSP
When aggregating multiple P2MP LSPs using P2MP LSP hierarchy,
determining the leaf nodes of the LSPs being aggregated is essential
for being able to tradeoff the overhead due to the P2MP LSPs vs
suboptimal use of bandwidth due to the partial congruency of the LSPs
being aggregated.
Therefore, if a PE that is a root of a given service P2MP LSP wants
to aggregate this LSP with other (service) p2mp LSPs rooted at the
same PE into an inter-area P2MP transport LSP, the PE should first
determine all the leaf nodes of that service LSP, as well as those of
the other service LSPs being aggregated).
To accomplish this the PE sets the PMSI Tunnel attribute of the
service A-D route associated with that LSP as follows. The Tunnel
Type is set to "No tunnel information present", Leaf Information
Required flag is set to 1, the route MUST NOT carry the P2MP
Segmented Next-Hop extended community. In contrast to the procedures
for the MVPN and VPLS A-D routes described so far, the Route
Reflectors that participate in the distribution of this route need
not be ABRs
13.3. Discovering the P2MP FEC of the Inter-Area P2MP Transport LSP
Once the root PE determines all the leaves of a given P2MP service
LSP, the PE (using some local to the PE criteria) selects a
particular inter-area transport P2MP LSP to be used for carrying the
(inter-area) service P2MP LSP.
Once the PE selects the transport P2MP LSP, the PE (re)originates the
service A-D route. The PMSI Tunnel attribute of this route now
carries the Transport Tunnel ID of the selected transport tunnel,
with the Tunnel Type set to "Transport Tunnel". Just as described
earlier, this service A-D route MUST NOT carry the P2MP Segmented
Next-Hop extended community. Just as described earlier, the Route
Reflectors that participate in the distribution of this route need
not be ABRs.
13.4. Egress PE Procedures for Inter-Area P2MP Transport LSP
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
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
egress PE following the "regular" MVPN or VPLS procedures, as
specified in [MVPN-BGP] and [VPLS-P2MP], associated with the received
A-D route originates a Leaf A-D route.
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
PE originates yet another Leaf A-D route.
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 "Leaf A-D
Route for Internet Multicast". The Route Key field of MCAST-VPN NLRI
of this route is constructed as follows:
RD (8 octets) - set to 0
Multicast Source Length, Multicast Source - constructed from
the Source PE address part of the Tunnel Identifier carried
in the received S-PMSI A-D route.
Multicast Group Length, Multicast Group - constructed from
Local Number part of the Tunnel Identifier carried in the
received S-PMSI A-D route.
Ingress PE IP Address is constructed from the Source PE
address part of the Tunnel Identifier carried in the
received S-PMSI A-D route.
The egress PE, when determining the upstream ABR, follows the
procedures specified in Section 6.1 for Internet Multicast.
From that point on we follow the procedures used for the Leaf A-D
routes for Internet multicast, as outlined below.
13.5. Egress ABR, Ingress ABR, Ingress PE procedures for Inter-Area
Transport LSP
When an egress ABR receives the Leaf A-D route, the egress ABR will
advertise into the egress area an S-PMSI A-D route whose NLRI is the
same as the received Leaf A-D route, minus the Ingress PE IP address.
The PMSI Tunnel attribute of this route contains the identity of a
particular intra-area P2MP LSP and an upstream-assigned MPLS label.
The egress PE(s) will import this route.
The egress ABR will also propagate, with appropriate modifications,
the received Leaf A-D route into the backbone area.
Likewise, an ingress ABR will advertise into the backbone area an S-
PMSI A-D route whose NLRI is the same as the received Leaf A-D route,
minus the Ingress PE IP address. The egress ABR(s) will import this
route.
The ingress ABR will also propagate, with appropriate modifications,
the received Leaf A-D route into the ingress area.
Finally the ingress PE will advertise into the ingress area an S-PMSI
A-D route whose NLRI is the same as the received Leaf A-D route,
minus the Ingress PE IP address. The ingress ABR(s) and other PE(s)
in the ingress area, if any, will import this route. The ingress PE
will use the (intra-area) P2MP LSP advertised in this route for
carrying traffic associated with the original service A-D route
advertised by the PE.
.
.
13.6. Discussion
Use of inter-area transport P2MP LSPs, as described in this section,
creates a level of indirection between (inter-area) P2MP service
LSPs, and intra-area transport LSPs that carry the service LSPs.
Rather than segmenting (inter-area) service P2MP LSPs, and then
aggregating (intra-area) segments of these service LSPs into intra-
area transport LSPs, this approach first aggregates multiple (inter-
area) service P2MP LSPs into a single inter-area transport P2MP LSP,
then segments such inter-area transport P2MP LSPs, and then
aggregates (intra-area) segments of these inter-area transport LSPs
into intra-area transport LSPs.
On one hand this approach could result in reducing the state (and the
overhead associated with maintaining the state) on ABRs. This is
because instead of requiring ABRs to maintain state for individual
P2MP service LSPs, ABRs would need to maintain state only for the
inter-area P2MP transport LSPs. Note however, that this reduction is
possible only if a single inter-area P2MP transport LSP aggregates
more than one (inter-area) service LSP. In the absence of such
aggregation, use of inter-area transport LSPs provides no benefits,
yet results in extra overhead. And while such aggregation does allow
to reduce state on ABRs, it comes at a price, as described below.
As we mentioned before, aggregating multiple P2MP service LSPs into a
single inter-area P2MP transport LSP requires the PE rooted at these
LSPs to determine all the leaf nodes of the service LSPs to be
aggregated. This means that the root PE has to track all the leaf PEs
of these LSPs. In contrast, when one applies segmentation procedures
directly to the P2MP service LSPs, the root PE has to track only the
leaf PEs in its own IGP area, plus the ingress ABR(s). Likewise, an
ingress ABR has to track only the egress ABRs. Finally, an egress ABR
has to track only the leaf PEs in its own area. Therefore, while the
total overhead of leaf tracking due to the P2MP service LSPs is about
the same in both approaches, the distribution of this overhead is
different. Specifically, when one uses inter-area P2MP transport
LSPs, this overhead is concentrated on the ingress PE. When one
applies segmentation procedures directly to the P2MP service LSPs,
this overhead is distributed among ingress PE and ABRs.
Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to
bear the overhead of leaf tracking for inter-area P2MP transport
LSPs. In contrast, when one applies segmentation procedures directly
to the P2MP service LSPs, there is no such overhead (as there are no
inter-area P2MP transport LSPs).
Use of inter-area P2MP transport LSPs may also result in more
bandwidth inefficiency, as compared to applying segmentation
procedures directly to the P2MP service LSPs. This is because with
inter-area P2MP transport LSPs the ABRs aggregate segments of inter-
area P2MP transport LSPs, rather than segments of (inter-area) P2MP
service LSPs. To illustrate this consider the following example.
Assume PE1 in Area 1 is an ingress PE, with two multicast streams,
(C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected
to PE1. Assume that PE2 in Area 2 has an MVPN site with receivers
for (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with
receivers both for (C-S1, C-G1) and for (C-S2, C-G2). Finally, assume
that PE5 in Area 4 has an MVPN site with receivers for (C-S2, C-G2).
When segmentation applies directly to the P2MP service LSPs then Area
2 would have just one intra-area transport LSP which would carry the
egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3
would have just one intra-area transport LSP which would carry the
egress area segments of both the P2MP service LSP for (C-S1, C-G1)
and the P2MP service LSP for (C-S2, C-G2); Area 4 would have just one
intra-area transport LSP which would carry the egress area segment of
the P2MP service LSP for (C-S2, C-G2). Note that there is no
bandwidth inefficiency in this case at all.
When using inter-area P2MP transport LSPs, to achieve the same state
overhead on the routers within each of the egress areas (except for
egress ABRs), PE1 would need to aggregate the P2MP service LSP for
(C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same
inter-area P2MP transport LSP. While such aggregation would reduce
state on ABRs, it would also result in bandwidth inefficiency, as (C-
S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also
to PE5, which has no receivers for this stream. Likewise, (C-S2, C-
G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2,
which has no receivers for this stream.
14. IANA Considerations
This document defines a new BGP Extended Community called "Inter-area This document defines a new BGP Extended Community called "Inter-area
P2MP Segmented Next-Hop". This community is IP Address Specific, of P2MP Segmented Next-Hop". This community is IP Address Specific, of
an extended type, and is transitive. A codepoint for this community an extended type, and is transitive. A codepoint for this community
should be assigned both from the IPv4 Address Specific Extended 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 from both Community registry. The same code point should be assigned from both
registries. registries.
14. Security Considerations This document also assigns a new Tunnel Type in the PMSI Tunnel
Attribute, called the "Transport Tunnel". This Tunnel Type is
assigned a value of 8.
15. Security Considerations
These will be spelled out in a future revision. These will be spelled out in a future revision.
15. References 16. Acknowledgements
15.1. Normative References We would like to thank Eric Rosen for his comments.
17. References
17.1. Normative References
[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997 Levels.", Bradner, March 1997
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, draft-ietf- VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, draft-ietf-
l3vpn-2547bis-mcast-bgp l3vpn-2547bis-mcast-bgp
[[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, [[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang,
draft-ietf-l2vpn-vpls-mcast draft-ietf-l2vpn-vpls-mcast
[L3VPN-IBGP] "Internal BGP as PE-CE protocol", Pedro Marques, et al., [L3VPN-IBGP] "Internal BGP as PE-CE protocol", Pedro Marques, et al.,
draft-ietf-l3vpn-ibgp, work in progress draft-ietf-l3vpn-ibgp, work in progress
15.2. Informative References 17.2. Informative References
[SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al.,
draft-leymann-mpls-seamless-mpls draft-leymann-mpls-seamless-mpls
16. Author's Address 18. 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
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
 End of changes. 22 change blocks. 
95 lines changed or deleted 410 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/