draft-ietf-bess-ir-00.txt   draft-ietf-bess-ir-01.txt 
BESS Working Group E. Rosen, Ed. BESS Working Group E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 6513,6514 (if approved) K. Subramanian Updates: 6513,6514 (if approved) K. Subramanian
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 17, 2015 Z. Zhang Expires: November 12, 2015 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
January 13, 2015 May 11, 2015
Ingress Replication Tunnels in Multicast VPN Ingress Replication Tunnels in Multicast VPN
draft-ietf-bess-ir-00 draft-ietf-bess-ir-01
Abstract Abstract
RFCs 6513, 6514, and other RFCs describe procedures by which a RFCs 6513, 6514, and other RFCs describe procedures by which a
Service Provider may offer Multicast VPN service to its customers. Service Provider may offer Multicast VPN service to its customers.
These procedures create point-to-multipoint (P2MP) or multipoint-to- These procedures create point-to-multipoint (P2MP) or multipoint-to-
multipoint trees across the Service Provider's backbone. One type of multipoint trees across the Service Provider's backbone. One type of
P2MP tree that may be used is known as an "Ingress Replication (IR) P2MP tree that may be used is known as an "Ingress Replication (IR)
tunnel". In an IR tunnel, a parent node need not be "directly tunnel". In an IR tunnel, a parent node need not be "directly
connected" to its child nodes. When a parent node has to send a connected" to its child nodes. When a parent node has to send a
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 17, 2015. This Internet-Draft will expire on November 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5 2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5
3. How are IR P-tunnels Identified? . . . . . . . . . . . . . . 6 3. How are IR P-tunnels Identified? . . . . . . . . . . . . . . 6
4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 8 4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 8
4.1. Advertised P-tunnels . . . . . . . . . . . . . . . . . . 9 4.1. Advertised P-tunnels . . . . . . . . . . . . . . . . . . 9
4.1.1. If the 'Leaf Info Required Bit' is Set . . . . . . . 9 4.1.1. If the 'Leaf Info Required Bit' is Set . . . . . . . 9
4.1.2. If the 'Leaf Info Required Bit' is Not Set . . . . . 10 4.1.2. If the 'Leaf Info Required Bit' is Not Set . . . . . 10
4.2. Unadvertised P-tunnels . . . . . . . . . . . . . . . . . 10 4.2. Unadvertised P-tunnels . . . . . . . . . . . . . . . . . 10
5. The PTA's 'Tunnel Identifier' Field . . . . . . . . . . . . . 11 5. The PTA's 'Tunnel Identifier' Field . . . . . . . . . . . . . 11
6. The PTA's 'MPLS Label' Field . . . . . . . . . . . . . . . . 11 6. The PTA's 'MPLS Label' Field . . . . . . . . . . . . . . . . 11
6.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 12 6.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 12
6.2. Leaf A-D Route Originated by an Intermediate Node . . . . 13 6.2. Leaf A-D Route Originated by an Intermediate Node . . . . 14
6.2.1. Upstream and Downstream Segments are IR Segments . . 14
6.2.2. Only One Segment is IR . . . . . . . . . . . . . . . 14
6.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 15 6.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 15
7. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 15 7. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 15
8. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 16 8. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 16
9. Use of Timers when Switching UMH . . . . . . . . . . . . . . 17 9. Use of Timers when Switching UMH . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 47 skipping to change at page 4, line 41
procedures; rather it makes explicit just how a router is to use the procedures; rather it makes explicit just how a router is to use the
protocol elements and procedures of [RFC6513] and [RFC6514] to protocol elements and procedures of [RFC6513] and [RFC6514] to
identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself
from an IR P-tunnel. This document also discusses the MPLS label from an IR P-tunnel. This document also discusses the MPLS label
allocation policies that need to be supported when binding MPLS allocation policies that need to be supported when binding MPLS
labels to IR P-tunnels, and the timer policies that need to be labels to IR P-tunnels, and the timer policies that need to be
supported when switching a customer multicast flow from one P-tunnel supported when switching a customer multicast flow from one P-tunnel
to another. As the material in this document must be understood in to another. As the material in this document must be understood in
order to properly implement IR P-tunnels, this document is considered order to properly implement IR P-tunnels, this document is considered
to update [RFC6513] and [RFC6514]. This document also discusses the to update [RFC6513] and [RFC6514]. This document also discusses the
application of "seamless multicast" [SMLS-MC] and "extranet" [MVPN- application of "seamless multicast" [RFC7524] and "extranet"
XNET] procedures to IR P-tunnels. [MVPN-XNET] procedures to IR P-tunnels.
This draft does not discuss the use of IR P-tunnels to support a VPN This draft does not discuss the use of IR P-tunnels to support a VPN
customer's use of BIDIR-PIM. [C-BIDIR-IR] explains how to adapt the customer's use of BIDIR-PIM. [C-BIDIR-IR] explains how to adapt the
procedures of [RFC6513], [RFC6514], and [MVPN-BIDIR] so that a procedures of [RFC6513], [RFC6514], and [MVPN-BIDIR] so that a
customer's use of BIDIR-PIM can be supported by IR P-tunnels. customer's use of BIDIR-PIM can be supported by IR P-tunnels.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are "OPTIONAL", when and only when appearing in all capital letters, are
to be interpreted as described in [RFC2119]. to be interpreted as described in [RFC2119].
2. What is an IR P-tunnel? 2. What is an IR P-tunnel?
An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that
support the MVPN procedures of [RFC6514] and related RFCs. In support the MVPN procedures of [RFC6514] and related RFCs. In
general, the nodes of an IR P-tunnel are either PE routers, ASBRs, or general, the nodes of an IR P-tunnel are either PE routers, ASBRs, or
(if [SMLS-MC] is supported) ABRs. (MVPN procedures are sometimes (if [RFC7524] is supported) ABRs. (MVPN procedures are sometimes
used to support non-MVPN, or "global table" multicast; one way of used to support non-MVPN, or "global table" multicast; one way of
doing this is defined in [SMLS-MC]. In such a case, IR P-tunnels can doing this is defined in [RFC7524]. In such a case, IR P-tunnels can
be used outside the context of MVPN.) be used outside the context of MVPN.)
MVPN P-tunnels may be either "segmented" or "non-segmented" (as these MVPN P-tunnels may be either "segmented" or "non-segmented" (as these
terms are defined in [RFC6513] and [RFC6514]). terms are defined in [RFC6513] and [RFC6514]).
A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting
only of a root node and a set of nodes that are children of the root only of a root node and a set of nodes that are children of the root
node. When used in an MVPN context, the root is an ingress PE, and node. When used in an MVPN context, the root is an ingress PE, and
the child nodes of the root are the egress PEs. the child nodes of the root are the egress PEs.
In a segmented P-tunnel, IR may be used for some or all of the In a segmented P-tunnel, IR may be used for some or all of the
segments. If a particular segment of a segmented P-tunnel uses IR, segments. If a particular segment of a segmented P-tunnel uses IR,
then the root of that segment may have child nodes that are ABRs or then the root of that segment may have child nodes that are ABRs or
ASBRs, rather than egress PEs. ASBRs, rather than egress PEs.
As with any type of P2MP tree, each node of an IR P-tunnel holds As with any type of P2MP tree, each node of an IR P-tunnel holds
"multicast state" for the P-tunnel. That is, each node knows the "multicast state" for the P-tunnel. That is, each node knows the
identity of its parent node on the tree, and each node knows the identity of its parent node on the tree, and each node knows the
identities of its child nodes on the tree. In the MVPN specs, the identities of its child nodes on the tree. In the MVPN specs, the
"parent" node is also known as the "Upstream Multicast Hop" or "UMH". "parent" node is also known as the "Upstream Multicast Hop" or "UMH".
Note that the "UMH" may be a PE, an ASBR, or (if procedures from
[RFC7524] are being used) an ABR. (In [RFC7524], the term "upstream
node" is used instead of "UMH".)
What distinguishes an IR P-tunnel from any other kind of P2MP tree is What distinguishes an IR P-tunnel from any other kind of P2MP tree is
the method by which a data packet is transmitted from a parent node the method by which a data packet is transmitted from a parent node
to a child node. To transmit a multicast data packet from a parent to a child node. To transmit a multicast data packet from a parent
node to a child node along a particular IR P-tunnel, the parent node node to a child node along a particular IR P-tunnel, the parent node
does the following: does the following:
o It labels the packet with a label (call it a "P-tunnel label") o It labels the packet with a label (call it a "P-tunnel label")
that the child node has assigned to that P-tunnel, that the child node has assigned to that P-tunnel,
skipping to change at page 7, line 9 skipping to change at page 7, line 4
There are four MVPN BGP route types in which P-tunnels can be There are four MVPN BGP route types in which P-tunnels can be
identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes,
S-PMSI A-D routes, and Leaf A-D routes. (These route types are all S-PMSI A-D routes, and Leaf A-D routes. (These route types are all
defined in [RFC6514]). defined in [RFC6514]).
Whenever it is necessary to identify a P-tunnel in a route of one of Whenever it is necessary to identify a P-tunnel in a route of one of
these types, a "PMSI Tunnel Attribute" (PTA) is added to the route. these types, a "PMSI Tunnel Attribute" (PTA) is added to the route.
As defined in [RFC6514] section 5, the PTA contains four fields: As defined in [RFC6514] section 5, the PTA contains four fields:
"Tunnel Type", "MPLS Label", "Tunnel Identifier", and "Flags". "Tunnel Type", "MPLS Label", "Tunnel Identifier", and "Flags".
[RFC6514] defines only one bit in the "Flags" field, the "Leaf [RFC6514] defines only one bit in the "Flags" field, the "Leaf
Information Required" bit. Information Required" bit.
If a route identifies an IR P-tunnel, the "Tunnel Type" field of its If a route identifies an IR P-tunnel, the "Tunnel Type" field of its
PTA is set to the value 6, meaning "Ingress Replication". PTA is set to the value 6, meaning "Ingress Replication".
Most types of P-tunnel are associated with specific protocols that Most types of P-tunnel are associated with specific protocols that
are used to set up and maintain tunnels of that type. For example, are used to set up and maintain tunnels of that type. For example,
if the "Tunnel Type" field is set to 2, meaning "mLDP P2MP LSP", the if the "Tunnel Type" field is set to 2, meaning "mLDP P2MP LSP", the
associated setup protocol is mLDP [mLDP]. The associated setup associated setup protocol is mLDP [RFC6388]. The associated setup
protocol always has a method of identifying the tunnels that it sets protocol always has a method of identifying the tunnels that it sets
up. For example, mLDP uses a "FEC element" to identify a tree. If up. For example, mLDP uses a "FEC element" to identify a tree. If
the "Tunnel type" field is set to 3, meaning "PIM SSM Tree", the the "Tunnel type" field is set to 3, meaning "PIM SSM Tree", the
associated setup protocol is PIM, and "(S,G)" is used to identify the associated setup protocol is PIM, and "(S,G)" is used to identify the
tree. In these cases, the "Tunnel Identifier" field of the PTA tree. In these cases, the "Tunnel Identifier" field of the PTA
carries a tree identifier as defined by the setup protocol used for carries a tree identifier as defined by the setup protocol used for
the particular tunnel type. the particular tunnel type.
IR P-tunnels, on the other hand, are entirely setup and maintained by IR P-tunnels, on the other hand, are entirely setup and maintained by
the use of BGP A-D routes, and are not associated with any other the use of BGP A-D routes, and are not associated with any other
skipping to change at page 8, line 52 skipping to change at page 8, line 48
significance, but it does not identify the IR P-tunnel. The use of significance, but it does not identify the IR P-tunnel. The use of
the PTA's "Tunnel Identifier" field in this case is discussed in the PTA's "Tunnel Identifier" field in this case is discussed in
Section 5. Section 5.
4. How to Join an IR P-tunnel 4. How to Join an IR P-tunnel
The procedures for joining an IR P-tunnel depend upon whether the The procedures for joining an IR P-tunnel depend upon whether the
P-tunnel has been previously advertised, and if so, upon how the P-tunnel has been previously advertised, and if so, upon how the
P-tunnel was advertised. Note that joining an unadvertised P-tunnel P-tunnel was advertised. Note that joining an unadvertised P-tunnel
is only possible when using the "Global Table Multicast" procedures is only possible when using the "Global Table Multicast" procedures
of [SMLS-MC]. of [RFC7524].
4.1. Advertised P-tunnels 4.1. Advertised P-tunnels
The procedures in this section apply when the P-tunnel to be joined The procedures in this section apply when the P-tunnel to be joined
has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D
route, or an Intra-AS I-PMSI A-D route. route, or an Intra-AS I-PMSI A-D route.
The procedures for joining an advertised IR P-tunnel depend upon The procedures for joining an advertised IR P-tunnel depend upon
whether the A-D route that advertises the P-tunnel has the "Leaf Info whether the A-D route that advertises the P-tunnel has the "Leaf Info
Required" bit set in its PTA. Required" bit set in its PTA.
4.1.1. If the 'Leaf Info Required Bit' is Set 4.1.1. If the 'Leaf Info Required Bit' is Set
The procedures in this section apply when the P-tunnel to be joined The procedures in this section apply when the P-tunnel to be joined
has been advertised in a route whose PTA has the "Leaf Info Required has been advertised in a route whose PTA has the "Leaf Info Required
Bit" set. Bit" set.
The router joining a particular IR P-tunnel must determine its UMH The router joining a particular IR P-tunnel must determine its UMH
for that P-tunnel. If the route that advertised the P-tunnel for that P-tunnel. If the route that advertised the P-tunnel
contains a P2MP Segmented Next Hop Extended Community, the UMH is contains a P2MP Segmented Next Hop Extended Community, the UMH is
determined from the value of this community (see [SMLS-MC]). determined from the value of this community (see [RFC7524]).
Otherwise the UMH is determined from the route's next hop (see Otherwise the UMH is determined from the route's next hop (see
[RFC6514]). [RFC6514]).
Once the UMH is determined, the router joining the IR P-tunnel Once the UMH is determined, the router joining the IR P-tunnel
originates a Leaf A-D route. The NLRI of the Leaf A-D route MUST originates a Leaf A-D route. The NLRI of the Leaf A-D route MUST
contain the tunnel identifier (as defined in Section 3 above) as its contain the tunnel identifier (as defined in Section 3 above) as its
"route key". The UMH MUST be identified by attaching an "IP Address "route key". The UMH MUST be identified by attaching an "IP Address
Specific Route Target" (or an "IPv6 Address Specific Route Target") Specific Route Target" (or an "IPv6 Address Specific Route Target")
to the Leaf A-D route. The IP address of the UMH appears in the to the Leaf A-D route. The IP address of the UMH appears in the
"global administrator" field of the Route Target (RT). Details can "global administrator" field of the Route Target (RT). Details can
be found in [RFC6514] and [SMLS-MC]. be found in [RFC6514] and [RFC7524].
The Leaf A-D route MUST also contain a PTA whose fields are set as The Leaf A-D route MUST also contain a PTA whose fields are set as
follows: follows:
o The "Tunnel Type" field is set to "IR". o The "Tunnel Type" field is set to "IR".
o The "Tunnel Identifier" field is set as described in Section 5 of o The "Tunnel Identifier" field is set as described in Section 5 of
this document. this document.
o The "MPLS Label" field is set to a non-zero value. This is the o The "MPLS Label" field is set to a non-zero value. This is the
skipping to change at page 10, line 43 skipping to change at page 10, line 43
Note that if a set of IR P-tunnels is joined in this manner, the Note that if a set of IR P-tunnels is joined in this manner, the
"discard from the wrong PE" procedures of [RFC6513] section 9.1.1 "discard from the wrong PE" procedures of [RFC6513] section 9.1.1
cannot be applied to that P-tunnel. Thus duplicate prevention on cannot be applied to that P-tunnel. Thus duplicate prevention on
such IR P-tunnels requires the use of either Single Forwarder such IR P-tunnels requires the use of either Single Forwarder
Selection ([RFC6513] section 9.1.2) or native PIM procedures Selection ([RFC6513] section 9.1.2) or native PIM procedures
([RFC6513] section 9.1.3). ([RFC6513] section 9.1.3).
4.2. Unadvertised P-tunnels 4.2. Unadvertised P-tunnels
In [SMLS-MC], a procedure is defined for "Global Table Multicast", in In [RFC7524], a procedure is defined for "Global Table Multicast", in
which a P-tunnel can be joined even if the P-tunnel has not been which a P-tunnel can be joined even if the P-tunnel has not been
previously advertised. See the sections of that document entitled previously advertised. See the sections of that document entitled
"Leaf A-D Route for Global Table Multicast" and "Constructing the "Leaf A-D Route for Global Table Multicast" and "Constructing the
Rest of the Leaf A-D Route". The route key of the Leaf A-D route has Rest of the Leaf A-D Route". The route key of the Leaf A-D route has
the form of the "S-PMSI Route-Type Specific NLRI" in this case, and the form of the "S-PMSI Route-Type Specific NLRI" in this case, and
that should be considered to be the P-tunnel identifier. Note that that should be considered to be the P-tunnel identifier. Note that
the procedure for finding the UMH is different in this case; the UMH the procedure for finding the UMH is different in this case; the UMH
is the next hop of the best UMH-eligible route towards the "ingress is the next hop of the best UMH-eligible route towards the "ingress
PE". See the section of that document entitled "Determining the PE". See the section of that document entitled "Determining the
Upstream ABR/PE/ASBR (Upstream Node)". Upstream ABR/PE/ASBR (Upstream Node)".
skipping to change at page 11, line 40 skipping to change at page 11, line 40
Section 4 of [RFC6515] MUST be applied when a PTA is carried in a Section 4 of [RFC6515] MUST be applied when a PTA is carried in a
Leaf A-D route, and describes how to determine whether the "Tunnel Leaf A-D route, and describes how to determine whether the "Tunnel
Identifier" field carries an IPv4 or an IPv6 address. Identifier" field carries an IPv4 or an IPv6 address.
If neither of the above conditions hold, then the "Tunnel Identifier" If neither of the above conditions hold, then the "Tunnel Identifier"
field is of no significance, and MUST be ignored upon reception. field is of no significance, and MUST be ignored upon reception.
6. The PTA's 'MPLS Label' Field 6. The PTA's 'MPLS Label' Field
When a PTA is carried by an S-PMSI A-D route or an Inter-AS I-PMSI When the "Tunnel Type" field of a PTA is set to "IR", the "MPLS
A-D route, and the "Tunnel Type" field is set to "IR", the "MPLS Label" field is not always significant. It is significant only under
Label" field is of no significance. In this case, it SHOULD be set the following conditions:
to zero upon transmission and MUST be ignored upon reception.
The "MPLS Label" field is significant only when the PTA appears 1. Either the PTA is being carried in a Leaf A-D route, or
either in a Leaf A-D route or in an Intra-AS I-PMSI A-D route that
does not have the "Leaf Information Required" bit set. In these 2. the "Leaf Information Required" flag of the PTA is NOT set.
cases, the MPLS label is the label that the originator of the route
is assigning to the IR P-tunnel(s) identified by the route's NLRI. Note that the "Leaf Information Required" flag of the PTA is always
(That is, the MPLS label assigned in the PTA is what we have called set when a PTA specifying an IR tunnel is carried in an S-PMSI A-D
the "P-tunnel label".) route or in an Inter-AS I-PMSI A-D route; thus the "MPLS Label" field
of the PTA is never significant when the PTA is carried by one of
these route types. The "MPLS Label" field is significant only when
the PTA appears either in a Leaf A-D route or in an Intra-AS I-PMSI
A-D route that does not have the "Leaf Information Required" bit set.
In these cases, the MPLS label is the label that the originator of
the route is assigning to the IR P-tunnel(s) identified by the
route's NLRI. (That is, the MPLS label assigned in the PTA is what
we have called the "P-tunnel label".)
In those cases where the "MPLS Label" field is not significant, it
SHOULD be set to zero upon transmission and MUST be ignored upon
reception.
6.1. Leaf A-D Route Originated by an Egress PE 6.1. Leaf A-D Route Originated by an Egress PE
As previously stated, when a Leaf A-D route is used to join an IR As previously stated, when a Leaf A-D route is used to join an IR
P-tunnel, the "route key" of the Leaf A-D route is the P-tunnel P-tunnel, the "route key" of the Leaf A-D route is the P-tunnel
identifier. identifier.
We now define the notion of the "root of an IR P-tunnel". We now define the notion of the "root of an IR P-tunnel".
o If the identifier of an IR P-tunnel is of the form of an S-PMSI o If the identifier of an IR P-tunnel is of the form of an S-PMSI
NLRI, the "root" of the P-tunnel is the router identified in the NLRI, the "root" of the P-tunnel is the router identified in the
"Originating Router's IP Address" field of that NLRI. "Originating Router's IP Address" field of that NLRI.
o If the identifier of an IR P-tunnel is of the form specified in o If the identifier of an IR P-tunnel is of the form specified in
Section "Leaf A-D Route for Global Table Multicast" of [SMLS-MC], Section "Leaf A-D Route for Global Table Multicast" of [RFC7524],
the "root" of the P-tunnel is the router identified in the the "root" of the P-tunnel is the router identified in the
"Ingress PE's IP Address" field of that NLRI. "Ingress PE's IP Address" field of that NLRI.
o If the identifier of an IR P-tunnel is of the form of an Intra-AS o If the identifier of an IR P-tunnel is of the form of an Intra-AS
I-PMSI NLRI, the "root" of the P-tunnel is the router identified I-PMSI NLRI, the "root" of the P-tunnel is the router identified
in the "Originating Router's IP Address" field of that NLRI. in the "Originating Router's IP Address" field of that NLRI.
o If the identifier of an IR P-tunnel is of the form of an Inter-AS o If the identifier of an IR P-tunnel is of the form of an Inter-AS
I-PMSI NLRI, the "root" of the P-tunnel is same as the identifier I-PMSI NLRI, the "root" of the P-tunnel is same as the identifier
of the P-tunnel, i.e., the combination of an RD and an AS. of the P-tunnel, i.e., the combination of an RD and an AS.
Note that if a P-tunnel is segmented, the root of the P-tunnel, by Note that if a P-tunnel is segmented, the root of the P-tunnel, by
this definition, is actually the root of the entire P-tunnel, not the this definition, is actually the root of the entire P-tunnel, not the
root of the local segment. root of the local segment. In this case, there may be segments
upstream that are not themselves IR P-tunnels. However, the egress
PE is aware only of the final segment of the P-tunnel, and hence
considers the P-tunnel to be an IR P-tunnel.
In order to apply the procedures of RFC 6513 Section 9.1.1 In order to apply the procedures of RFC 6513 Section 9.1.1
("Discarding Packets from Wrong PE"), the following condition MUST be ("Discarding Packets from Wrong PE"), the following condition MUST be
met by the MPLS label allocation policy: met by the MPLS label allocation policy:
Suppose an egress PE originates two Leaf A-D routes, each with a Suppose an egress PE originates two Leaf A-D routes, each with a
different route key in its NLRI, and each with a PTA specifying a different route key in its NLRI, and each with a PTA specifying a
"Tunnel Type" of "IR". Thus each of the Leaf A-D routes "Tunnel Type" of "IR". Thus each of the Leaf A-D routes
identifies a different IR P-tunnel. Suppose further that each of identifies a different IR P-tunnel. Suppose further that each of
those IR P-tunnels has a different root. Then the egress PE MUST those IR P-tunnels has a different root. Then the egress PE MUST
skipping to change at page 13, line 41 skipping to change at page 14, line 9
the PTA of Leaf A-D routes originated by a given egress PE MUST be the PTA of Leaf A-D routes originated by a given egress PE MUST be
unique for the ordered triple <root, root RD, parent node>, where the unique for the ordered triple <root, root RD, parent node>, where the
"root RD" is taken from the RD field of the IR P-tunnel identifier. "root RD" is taken from the RD field of the IR P-tunnel identifier.
(All forms of IR P-tunnel identifier contain an embedded "RD" field.) (All forms of IR P-tunnel identifier contain an embedded "RD" field.)
This policy is also sufficient for supporting non-extranet cases, but This policy is also sufficient for supporting non-extranet cases, but
in some cases may result in the use of more labels than the policy of in some cases may result in the use of more labels than the policy of
the previous paragraph. the previous paragraph.
6.2. Leaf A-D Route Originated by an Intermediate Node 6.2. Leaf A-D Route Originated by an Intermediate Node
When a P-tunnel is segmented, there will be "intermediate nodes" When a P-tunnel is segmented, there will be "intermediate nodes",
(nodes that have a parent and also have children on the P-tunnel). i.e., nodes that have a parent and also have children on the
Each intermediate node is a leaf node of an "upstream segment" and a P-tunnel. Each intermediate node is a leaf node of an "upstream
parent node of a "downstream segment". The intermediate node segment" and a parent node of one or more "downstream segments". The
"splices" together the two segments, so that data it receives on the intermediate node needs to set up its forwarding state so that data
upstream segment gets transmitted on the downstream segment. If it receives on the upstream segment gets transmitted on the proper
either the upstream or downstream segments (or both) are instantiated downstream segments.
by IR, the need to do this splicing places certain constraints on the
MPLS label allocation policy.
6.2.1. Upstream and Downstream Segments are IR Segments
An intermediate node N (i.e., a node that has a parent and also has If the upstream segment is instantiated by IR, the intermediate node
children) on an IR P-tunnel may originate a Leaf A-D route with a will need to originate a Leaf A-D route to join that segment, and
particular route key as a result of receiving a Leaf A-D route with will need to allocate a downstream-assigned MPLS label to advertise
that same route key. This will happen only if the received Leaf A-D in the MPLS label field of the Leaf A-D route's PTA. Section 6.1
route carries an IP address specific RT whose Global Administrator specifies constraints on the label allocation policy for egress PEs;
field identifies node N. this section specifies constraints on the label allocation policy for
intermediate nodes.
Suppose intermediate node N originates two Leaf A-D routes, one whose Suppose intermediate node N originates two Leaf A-D routes, one whose
route key is K1, and one whose route key is K2, where K1 != K2. In route key is K1, and one whose route key is K2, where K1 != K2. The
general, the respective PTAs of these Leaf A-D routes MUST specify respective PTAs of these Leaf A-D routes MUST specify distinct non-
distinct non-zero MPLS labels, such that it is possible to map zero MPLS labels, UNLESS the following conditions all hold:
uniquely from the specified label value to a single IR P-tunnel (call
this the "uniqueness rule"). There is one exception to this rule;
the exception is specified below.
Consider the set of Leaf A-D routes with route key K1 or route key K2
such that:
o N has received these Leaf A-D routes and has them currently 1. N's parent node for P-tunnel K1 is the same as N's parent node
installed. for P-tunnel K2.
o Each of these Leaf A-D routes carries an IP Address Specific Route 2. N's forwarding state is such that any packet it receives from
Target that identifies N in its Global Administrator field. P-tunnel K1 is forwarded to the exact same set of downstream
neighbors as any packet it receives from P-tunnel K2.
Now suppose that all the Leaf A-D routes in this set have the same 3. For each downstream neighbor D to which N sends the packets it
originating router, and that the PTAs of these Leaf A-D routes all receives from P-tunnels K1 and K2, N's forwarding state is such
specify the same MPLS label. Suppose further that N's UMH for K1 is that it applies the exact same encapsulation to packets it
the same as N's UMH for K2. In this particular case, N MAY specify forwards from either tunnel to D. (E.g., if N uses MPLS to
the same MPLS label in the PTA of Leaf A-D route it originates for K1 forward the packets to D, it pushes the exact same set of labels
as in the PTA of he route it originates for K2. However, if at any on packets from P-tunnel K1 as it pushes on packets from P-tunnel
future time these conditions no longer hold, N must reoriginate at K2.)
least one of the Leaf A-D routes with a different label so that the
"uniqueness rule" holds.
6.2.2. Only One Segment is IR Of course, N MAY always specify distinct non-zero labels in each of
the Leaf A-D routes that it originates.
To handle the case where an intermediate node, call it N, is splicing Note that the rules of this section apply whenever the upstream
together two P-tunnel segments, only one of which is IR, it is P-tunnel segment is an IR P-tunnel. These rules hold whether or not
necessary to generalize the rules of the preceding sub-section. some or all of the downstream segments are other types of P-tunnels.
Suppose N is a leaf node of two (upstream) P-tunnel segments, call If the P-tunnels from N to a particular downstream neighbor D are IR
them U1 and U2. Suppose also that N is a parent node of two P-tunnels, then condition 3 above will hold with respect to D only if
(downstream) P-tunnel segments, call them D1 and D2. And suppose the following conditions all hold as well:
that N needs to splice U1 to D1, and U2 to D2.
To follow the uniqueness rule of Section 6.2.1 of this document, N o N has received and installed a Leaf A-D route from D, whose route
must assign a different MPLS label to U1 than it assigns to U2. How key is K1, and which carries an IP-address-specific RT identifying
this assignment is made depends, of course, on the control protocol N,
used to set up U1 and U2.
There is one case in which the uniqueness rule need not be followed. o N has received and installed a Leaf A-D route from D, whose route
Suppose that there is a node M such that (a) M is N's only child node key is K2, and which carries an IP-address-specific RT identifying
on D1, and (b) M is N's only child node on D2. M will have N,
advertised to N a label L1 bound to D1, and a label L2 bound to D2.
If (and for as long as) L1==L2, then N MAY violate the uniqueness
rule by advertising to its parent node for U1 the same MPLS label it
advertises to its parent node for U2.
Section 6.2.1 of this document specifies in detail the way this o Those two Leaf A-D routes specify the same MPLS label in their
requirement is applied when the upstream and downstream segments are respective PTAs.
all IR segments.
6.3. Intra-AS I-PMSI A-D Route 6.3. Intra-AS I-PMSI A-D Route
When a router joins a set of IR P-tunnels using the procedures of When a router joins a set of IR P-tunnels using the procedures of
Section 4.1.2 of this document, the procedures of section 9.1.1 of Section 4.1.2 of this document, the procedures of section 9.1.1 of
[RFC6513] cannot be applied, no matter what the label allocation [RFC6513] cannot be applied, no matter what the label allocation
policy is. In this case, the ingress PE is the same as the UMH, but policy is. In this case, the ingress PE is the same as the UMH, but
it is not possible to assign a label uniquely to a particular ingress it is not possible to assign a label uniquely to a particular ingress
PE or UMH. However, the label in the MPLS label field of the PTA PE or UMH. However, the label in the MPLS label field of the PTA
MUST NOT appear in the MPLS label field of the PTA carried by any MUST NOT appear in the MPLS label field of the PTA carried by any
skipping to change at page 16, line 26 skipping to change at page 16, line 22
state. Note that the pruning of a child node may appear to the state. Note that the pruning of a child node may appear to the
parent node as the explicit withdrawal of a Leaf A-D route, or it may parent node as the explicit withdrawal of a Leaf A-D route, or it may
appear as a change in the Route Target of a Leaf A-D route. If the appear as a change in the Route Target of a Leaf A-D route. If the
Route Target of a particular Leaf A-D route previously identified a Route Target of a particular Leaf A-D route previously identified a
particular parent node, but changes so that it no longer does so, the particular parent node, but changes so that it no longer does so, the
effect on the multicast state of the parent node is the same as if effect on the multicast state of the parent node is the same as if
the Leaf A-D route had been explicitly withdrawn. the Leaf A-D route had been explicitly withdrawn.
8. Parent Node Actions Upon Receiving Leaf A-D Route 8. Parent Node Actions Upon Receiving Leaf A-D Route
These actions are detailed in [RFC6514] and [SMLS-MC]. Two points of These actions are detailed in [RFC6514] and [RFC7524]. Two points of
clarification are made: clarification are made:
o If a router R1 receives and installs a Leaf A-D route originated o If a router R1 receives and installs a Leaf A-D route originated
by router R2, R1's multicast state is affected only if the Leaf by router R2, R1's multicast state is affected only if the Leaf
A-D route carries an "IP Address Specific RT" (or "IPv6 Address A-D route carries an "IP Address Specific RT" (or "IPv6 Address
Specific RT") whose "global administrator" field identifies R1. Specific RT") whose "global administrator" field identifies R1.
(This is as specified in [RFC6514] and [SMLS-MC].) If a Leaf A-D (This is as specified in [RFC6514] and [RFC7524].) If a Leaf A-D
route's RT does not identify R1, but then changes so that it does route's RT does not identify R1, but then changes so that it does
identify R1, R1 must take the same actions it would take if the identify R1, R1 must take the same actions it would take if the
Leaf A-D route were newly received. Leaf A-D route were newly received.
o It is possible that router R1 will receive and install a Leaf A-D o It is possible that router R1 will receive and install a Leaf A-D
route originated by router R2, where: route originated by router R2, where:
* the route's RT identifies R1, * the route's RT identifies R1,
* the route's NLRI contains a route key whose first octet * the route's NLRI contains a route key whose first octet
skipping to change at page 18, line 38 skipping to change at page 18, line 33
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
Addresses in BGP Updates for Multicast VPN", RFC 6515, Addresses in BGP Updates for Multicast VPN", RFC 6515,
February 2012. February 2012.
13.2. Informative References 13.2. Informative References
[C-BIDIR-IR] [C-BIDIR-IR]
Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating
'Partial Mesh of MP2MP P-Tunnels' with Ingress 'Partial Mesh of MP2MP P-Tunnels' with Ingress
Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir- Replication", internet-draft draft-ietf-bess-mvpn-bidir-
ingress-replication-01, July 2015. ingress-replication-00, January 2015.
[MVPN-BIDIR] [MVPN-BIDIR]
Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, ""MVPN: Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, ""MVPN:
Using Bidirectional P-Tunnels", internet-draft draft-ietf- Using Bidirectional P-Tunnels", internet-draft draft-ietf-
l3vpn-mvpn-bidir-08, June 2014. bess-mvpn-bidir-04, April 2015.
[MVPN-XNET] [MVPN-XNET]
Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet-
05, July 2014. draft draft-ietf-bess-mvpn-extranet-02, May 2015.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
[RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu,
"Wildcards in Multicast VPN Auto-Discovery Routes", RFC "Wildcards in Multicast VPN Auto-Discovery Routes", RFC
6625, May 2012. 6625, May 2012.
[SMLS-MC] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Leymann, N., and S. Saad, "Inter-Area P2MP Segmented Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP
LSPs", internet-draft draft-ietf-mpls-seamless-mcast-15, Segmented LSPs", RFC 7524, May 2015.
June 2014.
Authors' Addresses Authors' Addresses
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
US United States
Email: erosen@juniper.net Email: erosen@juniper.net
Karthik Subramanian Karthik Subramanian
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
US United States
Email: kartsubr@cisco.com Email: kartsubr@cisco.com
Zhaohui Zhang Zhaohui Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
US United States
Email: zzhang@juniper.net Email: zzhang@juniper.net
 End of changes. 42 change blocks. 
106 lines changed or deleted 110 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/