draft-ietf-bess-ir-01.txt   draft-ietf-bess-ir-02.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: November 12, 2015 Z. Zhang Expires: April 17, 2016 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
May 11, 2015 October 15, 2015
Ingress Replication Tunnels in Multicast VPN Ingress Replication Tunnels in Multicast VPN
draft-ietf-bess-ir-01 draft-ietf-bess-ir-02
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 November 12, 2015. This Internet-Draft will expire on April 17, 2016.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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? . . . . . . . . . . . . . . 7
4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 8 4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 9
4.1. Advertised P-tunnels . . . . . . . . . . . . . . . . . . 9 4.1. Advertised IR 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 IR P-tunnels . . . . . . . . . . . . . . . . 11
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. A Note on IR P-tunnels and 'Discarding Packets from the Wrong
6.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 12 PE' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Leaf A-D Route Originated by an Intermediate Node . . . . 14 7. The PTA's 'MPLS Label' Field . . . . . . . . . . . . . . . . 13
6.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 15 7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14
7. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 15 7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 15
8. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 16 7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17
9. Use of Timers when Switching UMH . . . . . . . . . . . . . . 17 8. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Use of Timers when Switching UMH . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
RFCs 6513, 6514, and others describe procedures by which a Service RFCs 6513, 6514, and others describe procedures by which a Service
Provider (SP) may offer Multicast VPN (MVPN) service to its Provider (SP) may offer Multicast VPN (MVPN) service to its
customers. These procedures create point-to-multipoint (P2MP) or customers. These procedures create point-to-multipoint (P2MP) or
multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels" multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels"
(Provider-tunnels), across the SP's backbone network. Customer (Provider-tunnels), across the SP's backbone network. Customer
multicast traffic is carried through the P-tunnels. multicast traffic is carried through the P-tunnels.
A number of different P-tunnel technologies are supported. One of A number of different P-tunnel technologies are supported. One of
the supported P-tunnel technologies is known as "ingress replication" the supported P-tunnel technologies is known as "ingress replication"
or "unicast replication". We will use the acronym "IR" to refer to or "unicast replication". We will use the acronym "IR" to refer to
this P-tunnel technology. this P-tunnel technology.
An IR P-tunnel is a P2MP tree, but a given node on the tree is not An IR P-tunnel is a P2MP tree, but a given node on the tree is not
necessarily "directly attached" to its parent node or to its child necessarily "directly attached" to its parent node or to its child
nodes. To send a multicast data packet from a parent node to one of nodes. To send a multicast data packet from a parent node to one of
its child nodes, the parent node encapsulates the packet and then its child nodes, the parent node encapsulates the packet and then
unicasts it (through a P2P or MP2P MPLS LSP or a unicast IP tunnel) unicasts it through a tunnel to the child node. The tunnel may be a
to the child node. If a node on an IR tree has n child nodes, and P2P (point-to-point) or MP2P (multipoint-to-point) MPLS LSP (label
has a multicast data packet that must be sent along the tree, the switched path) or a unicast IP tunnel. If a node on an IR tree has n
parent node makes n individual copies of the data packet, and then child nodes, and has a multicast data packet that must be sent along
sends each copy, through a unicast tunnel, to exactly one child node. the tree, the parent node makes n individual copies of the data
No lower layer multicast technology is used when sending traffic from packet, and then sends each copy, through a unicast tunnel, to
a parent node to a child node; multiple copies of the packet may exactly one child node. No lower layer multicast technology is used
therefore be sent out a single interface. when sending traffic from a parent node to a child node; multiple
copies of the packet may therefore be sent out a single interface.
With the single exception of IR, the P-tunnel technologies supported With the single exception of IR, the P-tunnel technologies supported
by the MVPN specifications are pre-existing IP multicast or MPLS by the MVPN specifications are pre-existing IP multicast or MPLS
multicast technologies. Each such technology has its own set of multicast technologies. Each such technology has its own set of
specifications, its own setup and maintenance protocols, its own specifications, its own setup and maintenance protocols, its own
syntax for identifying specific multicast trees, and its own syntax for identifying specific multicast trees, and its own
procedures for enabling a router to be added to or removed from a procedures for enabling a router to be added to or removed from a
particular multicast tree. For IR P-tunnels, on the other hand, particular multicast tree. For IR P-tunnels, on the other hand,
there is no prior specification for setting up and maintaining the there is no prior specification for setting up and maintaining the
P2MP trees; the procedures and protocol elements used for setting up P2MP trees; the procedures and protocol elements used for setting up
skipping to change at page 4, line 10 skipping to change at page 4, line 17
unicast tunnels used by a particular IR P-tunnel need not be specific unicast tunnels used by a particular IR P-tunnel need not be specific
to that P-tunnel; a single unicast tunnel can carry the multicast to that P-tunnel; a single unicast tunnel can carry the multicast
traffic of many different IR P-tunnels (and can also carry unicast traffic of many different IR P-tunnels (and can also carry unicast
traffic as well). traffic as well).
In this document, we provide a clearer and more explicit conceptual In this document, we provide a clearer and more explicit conceptual
model for IR P-tunnels, clarifying the relationship between an IR model for IR P-tunnels, clarifying the relationship between an IR
P-tunnel and the unicast tunnels that are used for data transmission P-tunnel and the unicast tunnels that are used for data transmission
along the IR P-tunnel. along the IR P-tunnel.
RFC 6514 defines a protocol element called a "tunnel identifier", Section 5 of [RFC6514] defines a BGP Path Attribute known as the
which for most P-tunnel technologies is used to identify a P-tunnel "PMSI (Provider Multicast Service Interface) Tunnel attribute" (PTA).
(i.e., to identify a P2MP or MP2MP tree). However, when IR P-tunnels This attribute contains a field known as the "Tunnel Identifier"
are used, this protocol element does not identify an IR P-tunnel. In field. For most P-tunnel technologies, the PTA's "Tunnel Identifier"
some cases it identifies one of the P-tunnel's constituent unicast field is used to identify a P-tunnel (i.e., to identify a P2MP or
MP2MP tree). However, when IR P-tunnels are used, the PTA "Tunnel
Identifier" field does not actually identify an IR P-tunnel. In some
cases it identifies one of the P-tunnel's constituent unicast
tunnels, and in other cases it is not used to identify a tunnel at tunnels, and in other cases it is not used to identify a tunnel at
all. In this document, we provide an explicit specification for how all. In this document, we provide an explicit specification for how
IR P-tunnels are actually identified. IR P-tunnels are actually identified.
Some of the MVPN specifications use phrases like "join the identified Some of the MVPN specifications use phrases like "join the identified
P-tunnel", even though there has up to now not been an explicit P-tunnel", even though there has up to now not been an explicit
specification of how to identify an IR P-tunnel, of how a router specification of how to identify an IR P-tunnel, of how a router
joins such a P-tunnel, or of how a router prunes itself from such a joins such a P-tunnel, or of how a router prunes itself from such a
P-tunnel. In this document, we make these procedures more explicit. P-tunnel. In this document, we make these procedures more explicit.
RFC 6514 does provide a method for binding an MPLS label to a [RFC6514] does provide a method for binding an MPLS label to a
P-tunnel, but does not discuss the label allocation policies that are P-tunnel, but does not discuss the label allocation policies that are
needed for correct operation when the P-tunnel is an IR P-tunnel. needed for correct operation when the P-tunnel is an IR P-tunnel.
Those policies are discussed in this document. Those policies are discussed in this document.
This document does not provide any new protocol elements or This document does not provide any new protocol elements, or any
procedures; rather it makes explicit just how a router is to use the fundamentally new procedures; its purpose is to make explicit just
protocol elements and procedures of [RFC6513] and [RFC6514] to how a router is to use the protocol elements and procedures of
identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR
from an IR P-tunnel. This document also discusses the MPLS label P-tunnel, and to prune itself from an IR P-tunnel.
allocation policies that need to be supported when binding MPLS
labels to IR P-tunnels, and the timer policies that need to be This document also discusses the MPLS label allocation policies that
supported when switching a customer multicast flow from one P-tunnel need to be supported when binding MPLS labels to IR P-tunnels, and
to another. As the material in this document must be understood in the timer policies that need to be supported when switching a
order to properly implement IR P-tunnels, this document is considered customer multicast flow from one IR P-tunnel to another. These are
to update [RFC6513] and [RFC6514]. This document also discusses the procedures that are not clearly specified in [RFC6513] or [RFC6514].
application of "seamless multicast" [RFC7524] and "extranet" As the material in this document must be understood in order to
[MVPN-XNET] procedures to IR P-tunnels. properly implement IR P-tunnels, this document is considered to
update [RFC6513] and [RFC6514].
This document also discusses the application of "seamless multicast"
[RFC7524] and "extranet" [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 Bidirectional Protocol Independent Multicast
procedures of [RFC6513], [RFC6514], and [MVPN-BIDIR] so that a (BIDIR-PIM). [C-BIDIR-IR] explains how to adapt the procedures of
customer's use of BIDIR-PIM can be supported by IR P-tunnels. [RFC6513], [RFC6514], and [RFC7582] so that a 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 Provider Edge (PE)
(if [RFC7524] is supported) ABRs. (MVPN procedures are sometimes routers, Autonomous System Border Routers (ASBRs), or (if [RFC7524]
used to support non-MVPN, or "global table" multicast; one way of is supported) Area Border Routers (ABRs). (MVPN procedures are
doing this is defined in [RFC7524]. In such a case, IR P-tunnels can sometimes used to support non-MVPN, or "global table" multicast; one
be used outside the context of MVPN.) way of doing this is defined in [RFC7524]. Another way is defined in
[GTM]. In such cases, IR P-tunnels can 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
skipping to change at page 6, line 31 skipping to change at page 6, line 51
R2 on two different IR P-tunnels, a single unicast tunnel from R1 to R2 on two different IR P-tunnels, a single unicast tunnel from R1 to
R2 may be used to carry data along both IR P-tunnels. All that is R2 may be used to carry data along both IR P-tunnels. All that is
required is that when the data packets arrive at R2, R2 will see the required is that when the data packets arrive at R2, R2 will see the
"P-tunnel label" at the top of the packets' label stack; R2's further "P-tunnel label" at the top of the packets' label stack; R2's further
processing of the packets will depend upon that label. Note that the processing of the packets will depend upon that label. Note that the
same unicast tunnel between R1 and R2 may also be carrying unicast same unicast tunnel between R1 and R2 may also be carrying unicast
data packets. data packets.
Typically the unicast tunnels are the Label Switched Paths (LSPs) Typically the unicast tunnels are the Label Switched Paths (LSPs)
that already exist to carry unicast traffic; either MP2P LSPs created that already exist to carry unicast traffic; either MP2P LSPs created
by LDP [RFC5036] or P2P LSPs created by RSVP-TE [RFC3209]. However, by LDP (Label Distribution Protocol, [RFC5036]) or P2P LSPs created
any other kind of unicast tunnel may be used. A unicast tunnel may by RSVP-TE (Resource Reservation Protocol - Traffic Engineering,
have an arbitrary number of intermediate routers; those routers do
not maintain any multicast state for the IR P-tunnel, and in general [RFC3209]). However, any other kind of unicast tunnel may be used.
are not even aware of its existence. A unicast tunnel may have an arbitrary number of intermediate
routers; those routers do not maintain any multicast state for the IR
P-tunnel, and in general are not even aware of its existence.
As with all other P-tunnel types, IR P-tunnels may be used as As with all other P-tunnel types, IR P-tunnels may be used as
Inclusive P-tunnels or as Selective P-tunnels. Inclusive P-tunnels or as Selective P-tunnels.
3. How are IR P-tunnels Identified? 3. How are IR P-tunnels Identified?
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 (Intra Autonomous System Inclusive
S-PMSI A-D routes, and Leaf A-D routes. (These route types are all PMSI A-D) routes, Inter-AS I-PMSI A-D routes, S-PMSI (Selective PMSI)
defined in [RFC6514]). A-D routes, and Leaf A-D routes. (These route types are all 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 [RFC6388]. The associated setup associated setup protocol is mLDP [RFC6388]. The associated setup
skipping to change at page 7, line 16 skipping to change at page 7, line 36
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 [RFC6388]. 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" (Forwarding Equivalence
the "Tunnel type" field is set to 3, meaning "PIM SSM Tree", the Class Element) to identify a tree. If the "Tunnel type" field is set
associated setup protocol is PIM, and "(S,G)" is used to identify the to 3, meaning "PIM SSM Tree" (Protocol Independent Multicast Source-
tree. In these cases, the "Tunnel Identifier" field of the PTA Specific Tree), the associated setup protocol is PIM, and "(S,G)" is
carries a tree identifier as defined by the setup protocol used for used to identify the tree. In these cases, the "Tunnel Identifier"
the particular tunnel type. field of the PTA carries a tree identifier as defined by the setup
protocol used for 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
setup protocol. (The unicast tunnels used to transmit multicast data setup protocol. (The unicast tunnels used to transmit multicast data
along an IR P-tunnel may have their own setup and maintenance along an IR P-tunnel may have their own setup and maintenance
protocols, of course.) Further, the identifier of an IR P-tunnel protocols, of course.) The means of identifying a P-tunnel is very
does not appear in the PTA at all. Rather, the P-tunnel identifier different for IR P-tunnels than for other types of P-tunnel:
is in the "Network Layer Reachability Information" (NLRI) field of
the A-D routes that are used to advertise and to setup the P-tunnel.
When an IR P-tunnel is identified in an S-PMSI A-D route, an Intra-AS When an IR P-tunnel is identified in an S-PMSI A-D route, an
I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we will refer to Intra-AS I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we
these three route types as "advertising A-D routes"), its identifier will refer to these three route types as "advertising A-D
is hereby defined to be the NLRI of that route. See sections 4.1, routes"), its identifier is hereby defined to be the NLRI (Network
4.2, and 4.3 of [RFC6514] for the specification of these NLRIs. Note Layer Reachability Information) of that route. See sections 4.1,
that the P-tunnel identifier includes the "route type" and "length" 4.2, and 4.3 of [RFC6514] for the specification of these NLRIs.
octets of the NLRI. Note that the IR P-tunnel identifier includes the "route type" and
"length" octets of the NLRI.
An advertising A-D route is considered to identify an IR P-tunnel To reiterate:
only if it carries a PTA whose "Tunnel Type" field is set to "IR".
The identifier of the IR P-tunnel does not appear in the PTA at
all; the "Tunnel Identifier" field of the PTA does not contain the
identifier of the IR P-tunnel.
Rather,the identifier of the IR P-tunnel appears in the "Network
Layer Reachability Information" (NLRI) field of the A-D routes
that are used to advertise and to setup the IR P-tunnel.
Note that an advertising A-D route is considered to identify an IR
P-tunnel only if it carries a PTA whose "Tunnel Type" field is set to
"IR".
When an IR P-tunnel is identified in an S-PMSI A-D route or in an When an IR P-tunnel is identified in an S-PMSI A-D route or in an
Inter-AS I-PMSI A-D route, the "Leaf Info Required" bit of the Flags Inter-AS I-PMSI A-D route, the "Leaf Info Required" bit of the Flags
field of the PTA MUST be set. field of the PTA MUST be set.
In an advertising A-D route: In an advertising A-D route:
o If the "Leaf Info Required" bit of the Flags field of the PTA is o If the "Leaf Info Required" bit of the Flags field of the PTA is
set, then the "Tunnel Identifier" field of the PTA has no set, then the "Tunnel Identifier" field of the PTA has no
significance whatsoever, and MUST be ignored upon reception. significance whatsoever, and MUST be ignored upon reception.
Note that, per RFC6514, the length of the "Tunnel Identifier" Note that, per RFC6514, the length of the "Tunnel Identifier"
field is variable, and is inferred from the length of the PTA. field of the PTA is variable, and is inferred from the length of
Even when this field is of no significance, its length MUST be the the PTA. Even when this field is of no significance, its length
length of an IP address in the address space of the SP's backbone, MUST be the length of an IP address in the address space of the
as specified in section 4.2 of [RFC6515]. In this case, it is SP's backbone, as specified in section 4.2 of [RFC6515]. In this
RECOMMENDED that it be set to a routable address of the router case, it is RECOMMENDED that it be set to a routable address of
that constructed the PTA. (While it might make more sense to the router that constructed the PTA. (While it might make more
allow or even require the field to be omitted entirely, that might sense to allow or even require the field to be omitted entirely,
raise issues of backwards compatibility with implementations that that might raise issues of backwards compatibility with
were designed prior to the publication of this document.) implementations that were designed prior to the publication of
this document.)
o If the "Leaf Info Required" bit is not set, the "Tunnel o If the "Leaf Info Required" bit is not set, the "Tunnel
Identifier" field of the PTA does have significance, but it does Identifier" field of the PTA does have significance, but it does
not identify the IR P-tunnel. The use of the PTA's "Tunnel not identify the IR P-tunnel. The use of the PTA's "Tunnel
Identifier" field in this case is discussed in Section 5 of this Identifier" field in this case is discussed in Section 5 of this
document. document.
Note that according to the above definition, there is no way for two Note that according to the above definition, there is no way for two
different advertising A-D routes (i.e., two advertising A-D routes different advertising A-D routes (i.e., two advertising A-D routes
with different NLRIs) to advertise the same IR P-tunnel. In the with different NLRIs) to advertise the same IR P-tunnel. In the
terminology of [RFC6513], an IR P-tunnel can instantiate only a terminology of [RFC6513], an IR P-tunnel can instantiate only a
single PMSI. If an ingress PE, for example, wants to bind two single PMSI. If an ingress PE, for example, wants to bind two
customer multicast flows to a single IR P-tunnel, it must advertise customer multicast flows to a single IR P-tunnel, it must advertise
that tunnel in an I-PMSI A-D route or in an S-PMSI A-D route whose that IR P-tunnel either in an I-PMSI A-D route or in an S-PMSI A-D
NLRI contains wildcards ([RFC6625]). route whose NLRI contains wildcards ([RFC6625]).
When an IR P-tunnel is identified in a Leaf A-D route, its identifier When an IR P-tunnel is identified in a Leaf A-D route, its identifier
is the "route key" field of the route's NLRI. See section 4.4 of is the "route key" field of the route's NLRI. See section 4.4 of
[RFC6514]. [RFC6514].
A Leaf A-D route is considered to identify an IR P-tunnel only if it A Leaf A-D route is considered to identify an IR P-tunnel only if it
carries a PTA whose "Tunnel Type" field is set to "IR". In this type carries a PTA whose "Tunnel Type" field is set to "IR". In this type
of route, the "Tunnel Identifier" field of the PTA does have of route, the "Tunnel Identifier" field of the PTA does have
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 IR
is only possible when using the "Global Table Multicast" procedures P-tunnel is only possible when using the "Global Table Multicast"
of [RFC7524]. procedures of [RFC7524].
4.1. Advertised P-tunnels 4.1. Advertised IR P-tunnels
The procedures in this section apply when the P-tunnel to be joined The procedures in this section apply when the IR P-tunnel to be
has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI
route, or an Intra-AS I-PMSI A-D route. A-D 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 IR P-tunnel has the "Leaf
Required" bit set in its PTA. Info 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 IR 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 [RFC7524]). 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 is
contain the tunnel identifier (as defined in Section 3 above) as its formed following the procedures of [RFC6514]. As a result, the NLRI
"route key". The UMH MUST be identified by attaching an "IP Address of the Leaf A-D route will contain the IR P-tunnel identifier defined
Specific Route Target" (or an "IPv6 Address Specific Route Target") in Section 3 above as its "route key". The UMH MUST be identified by
to the Leaf A-D route. The IP address of the UMH appears in the attaching an "IP Address Specific Route Target" (or an "IPv6 Address
"global administrator" field of the Route Target (RT). Details can Specific Route Target") to the Leaf A-D route. The IP address of the
be found in [RFC6514] and [RFC7524]. UMH appears in the "global administrator" field of the Route Target
(RT). Details can 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. (Note that this field does not contain the IR
P-tunnel Identifier that is defined in Section 3.)
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
"P-tunnel label". The value must be chosen so as to satisfy "P-tunnel label". The value must be chosen so as to satisfy
various constraints, as discussed in Section 6 this document. various constraints, as discussed in Section 7 this document.
4.1.2. If the 'Leaf Info Required Bit' is Not Set 4.1.2. If the 'Leaf Info Required Bit' is Not Set
The procedures in this section apply when the P-tunnel to be joined The procedures in this section apply when the IR P-tunnel to be
has been advertised in a route whose PTA does not have the "Leaf Info joined has been advertised in a route whose PTA does not have the
Required Bit" set. This can only be the case if the P-tunnel was "Leaf Info Required Bit" set. This can only be the case if the IR
advertised in an Intra-AS I-PMSI A-D route. P-tunnel was advertised in an Intra-AS I-PMSI A-D route.
If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes
originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can
be thought of as being instantiated by a set of IR P-tunnels. Each be thought of as being instantiated by a set of IR P-tunnels. Each
PE is the root of one such P-tunnel, and the other PEs are children PE is the root of one such IR P-tunnel, and the other PEs are
of the root. A PE simultaneously joins all these P-tunnels by children of the root. A PE simultaneously joins all these P-tunnels
originating (if it hasn't already done so) an Intra-AS I-PMSI A-D by originating (if it hasn't already done so) an Intra-AS I-PMSI A-D
route with a PTA whose fields are set as follows: route with a PTA whose fields are set as 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. (Note that this field does not contain the IR
P-tunnel Identifier that defined in Section 3.)
o The "MPLS Label" field MUST be set to a non-zero value. This o The "MPLS Label" field MUST be set to a non-zero value. This
label value will be used by the child node to associate a received label value will be used by the child node to associate a received
packet with the I-PMSI of a particular MVPN. The MPLS label packet with the I-PMSI of a particular MVPN. The MPLS label
allocation policy must be such as to ensure that the binding from allocation policy must be such as to ensure that the binding from
label to I-PMSI is one-to-one. label to I-PMSI is one-to-one.
The NLRI and the RTs of the originated I-PMSI A-D route are set as The NLRI and the RTs of the originated I-PMSI A-D route are set as
specified in [RFC6514]. specified in [RFC6514].
Note that if a set of IR P-tunnels is joined in this manner, the 4.2. Unadvertised IR P-tunnels
"discard from the wrong PE" procedures of [RFC6513] section 9.1.1
cannot be applied to that P-tunnel. Thus duplicate prevention on
such IR P-tunnels requires the use of either Single Forwarder
Selection ([RFC6513] section 9.1.2) or native PIM procedures
([RFC6513] section 9.1.3).
4.2. Unadvertised P-tunnels
In [RFC7524], 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 IR P-tunnel identifier. Note
the procedure for finding the UMH is different in this case; the UMH that the procedure for finding the UMH is different in this case; the
is the next hop of the best UMH-eligible route towards the "ingress UMH is the next hop of the best UMH-eligible route towards the
PE". See the section of that document entitled "Determining the "ingress PE". See the section of that document entitled "Determining
Upstream ABR/PE/ASBR (Upstream Node)". the Upstream ABR/PE/ASBR (Upstream Node)".
5. The PTA's 'Tunnel Identifier' Field 5. The PTA's 'Tunnel Identifier' Field
As previously specified, when the "Tunnel Type" field of a PTA is set
to "IR", the "Tunnel Identifier" field of that PTA does not contain
the IR P-tunnel identifier. This section specifies the procedures
for setting the "Tunnel Identifier" field of the PTA when the "Tunnel
Type" field of the PTA is set to "IR".
If the "Tunnel Type" field of a PTA is set to "IR", its "Tunnel If the "Tunnel Type" field of a PTA is set to "IR", its "Tunnel
Identifier" field is significant only when one of the following two Identifier" field is significant only when one of the following two
conditions holds: conditions holds:
o The PTA is carried by a Leaf A-D route, or o The PTA is carried by a Leaf A-D route, or
o The "Leaf Information Required" bit of the "Flags" field of the o The "Leaf Information Required" bit of the "Flags" field of the
PTA is not set. PTA is not set.
If one of these conditions holds, then the "Tunnel Identifier" field If one of these conditions holds, then the "Tunnel Identifier" field
skipping to change at page 11, line 38 skipping to change at page 12, line 17
the unicast tunnel is set up and maintained is also outside the scope the unicast tunnel is set up and maintained is also outside the scope
of this document. of this document.
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. A Note on IR P-tunnels and 'Discarding Packets from the Wrong PE'
Section 9.1.1 of [RFC6513] specifies a procedure known as "Discarding
Packets from the Wrong PE". When an egress PE receives a multicast
data packet, this procedure requires it to determine the packet's
ingress PE.
In this document, we assume that when a packet has reached an egress
PE via an IR P-tunnel, the egress PE will infer the identity of the
packet's ingress PE by examining the packet's P-tunnel label.
Section 7 specifies certain constraints on the way in which the
P-tunnel label is allocated for a given P-tunnel. In general, if
these constraints are followed, an egress PE will be able to infer
the identity of a packet's ingress PE from the P-tunnel label, and
hence will be able to apply the procedures of Section 9.1.1 of
[RFC6513]. This method of identifying a packet's ingress PE works
exactly the same when the unicast tunnels are IP tunnels as it does
when the unicast tunnels are MPLS LSPs.
However, if the egress PE joined a particular IR P-tunnel using the
procedures of Section 4.1.2, then when the egress PE receives a
packet through that P-tunnel, it will not be able to infer the
identity of the packet's ingress PE from the P-tunnel label, and thus
will not be able to apply the procedures of Section 9.1.1 of
[RFC6513].
One might think that if a particular IR P-tunnel uses IP unicast
tunnels rather than MPLS LSPs, an egress PE could identify the
ingress PE by inspecting the IP source address field of the
encapsulating IP header. However, there are several reasons why this
procedure is not desirable:
o When segmented P-tunnels are being used, the IP source address
field of the encapsulating IP header might not contain the address
of the ingress PE.
o Even if the IP source address field of the encapsulating IP header
does identify the ingress PE, there is no guarantee that the IP
source address in that header is the same as the IP address used
by the ingress PE for the MVPN signaling procedures.
o To apply the procedures of Section 9.1.1 of [RFC6513] when
extranet functionality [MVPN-XNET] is supported, it is necessary
to infer a packet's ingress VRF (Virtual Routing and Forwarding
table), not merely its ingress PE. This can be inferred from the
P-tunnel label (assuming that the label is allocated following the
procedures of Section 7), but can not be inferred from the IP
source address of the encapsulating IP header.
We therefore assume in this document that if the procedures of
Section 9.1.1 of [RFC6513] are to be applied to packets traveling
through IR P-tunnels, those procedures will be based on the P-tunnel
label, even if the IR P-tunnel is using IP unicast tunnels.
This means that if an egress PE joined a particular IR P-tunnel using
the procedures of Section 4.1.2, duplicate prevention on that IR
P-tunnel requires the use of either Single Forwarder Selection
([RFC6513] section 9.1.2) or native PIM procedures ([RFC6513] section
9.1.3).
7. The PTA's 'MPLS Label' Field
When the "Tunnel Type" field of a PTA is set to "IR", the "MPLS When the "Tunnel Type" field of a PTA is set to "IR", the "MPLS
Label" field is not always significant. It is significant only under Label" field is not always significant. It is significant only under
the following conditions: the following conditions:
1. Either the PTA is being carried in a Leaf A-D route, or 1. Either the PTA is being carried in a Leaf A-D route, or
2. the "Leaf Information Required" flag of the PTA is NOT set. 2. the "Leaf Information Required" flag of the PTA is NOT set.
Note that the "Leaf Information Required" flag of the PTA is always Note that the "Leaf Information Required" flag of the PTA is always
set when a PTA specifying an IR tunnel is carried in an S-PMSI A-D set when a PTA specifying an IR P-tunnel is carried in an S-PMSI A-D
route or in an Inter-AS I-PMSI A-D route; thus the "MPLS Label" field 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 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 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 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. 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 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 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 route's NLRI. (That is, the MPLS label assigned in the PTA is what
we have called the "P-tunnel label".) we have called the "P-tunnel label".)
In those cases where the "MPLS Label" field is not significant, it In those cases where the "MPLS Label" field is not significant, it
SHOULD be set to zero upon transmission and MUST be ignored upon SHOULD be set to zero upon transmission and MUST be ignored upon
reception. reception.
6.1. Leaf A-D Route Originated by an Egress PE 7.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 IR P-tunnel is the router identified in
"Originating Router's IP Address" field of that NLRI. the "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 [RFC7524], 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 IR 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 IR P-tunnel is the router
in the "Originating Router's IP Address" field of that NLRI. identified 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 IR P-tunnel is same as the
of the P-tunnel, i.e., the combination of an RD and an AS. identifier of the IR 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 an IR P-tunnel is segmented, the root of the IR
this definition, is actually the root of the entire P-tunnel, not the P-tunnel, by this definition, is actually the root of the entire
root of the local segment. In this case, there may be segments P-tunnel, not the root of the local segment. In this case, there may
upstream that are not themselves IR P-tunnels. However, the egress be segments upstream that are not themselves IR P-tunnels. However,
PE is aware only of the final segment of the P-tunnel, and hence the egress PE is aware only of the final segment of the P-tunnel, and
considers the P-tunnel to be an IR P-tunnel. 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 14, line 7 skipping to change at page 15, line 48
Packets from the Wrong P-tunnel" procedures that are specified in Packets from the Wrong P-tunnel" procedures that are specified in
[MVPN-XNET]. To support those procedures, the labels specified in [MVPN-XNET]. To support those procedures, the labels specified in
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 7.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",
i.e., nodes that have a parent and also have children on the i.e., nodes that have a parent and also have children on the
P-tunnel. Each intermediate node is a leaf node of an "upstream P-tunnel. Each intermediate node is a leaf node of an "upstream
segment" and a parent node of one or more "downstream segments". The segment" and a parent node of one or more "downstream segments". The
intermediate node needs to set up its forwarding state so that data intermediate node needs to set up its forwarding state so that data
it receives on the upstream segment gets transmitted on the proper it receives on the upstream segment gets transmitted on the proper
downstream segments. downstream segments.
If the upstream segment is instantiated by IR, the intermediate node If the upstream segment is instantiated by IR, the intermediate node
will need to originate a Leaf A-D route to join that segment, and will need to originate a Leaf A-D route to join that segment, and
will need to allocate a downstream-assigned MPLS label to advertise will need to allocate a downstream-assigned MPLS label to advertise
in the MPLS label field of the Leaf A-D route's PTA. Section 6.1 in the MPLS label field of the Leaf A-D route's PTA. Section 7.1
specifies constraints on the label allocation policy for egress PEs; specifies constraints on the label allocation policy for egress PEs;
this section specifies constraints on the label allocation policy for this section specifies constraints on the label allocation policy for
intermediate nodes. 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. The route key is K1, and one whose route key is K2, where K1 != K2. The
respective PTAs of these Leaf A-D routes MUST specify distinct non- respective PTAs of these Leaf A-D routes MUST specify distinct non-
zero MPLS labels, UNLESS the following conditions all hold: zero MPLS labels, UNLESS the following conditions all hold:
1. N's parent node for P-tunnel K1 is the same as N's parent node 1. N's parent node for P-tunnel K1 is the same as N's parent node
skipping to change at page 15, line 20 skipping to change at page 17, line 12
key is K1, and which carries an IP-address-specific RT identifying key is K1, and which carries an IP-address-specific RT identifying
N, N,
o N has received and installed a Leaf A-D route from D, whose route o N has received and installed a Leaf A-D route from D, whose route
key is K2, and which carries an IP-address-specific RT identifying key is K2, and which carries an IP-address-specific RT identifying
N, N,
o Those two Leaf A-D routes specify the same MPLS label in their o Those two Leaf A-D routes specify the same MPLS label in their
respective PTAs. respective PTAs.
6.3. Intra-AS I-PMSI A-D Route 7.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
other route originated by the same router. other route originated by the same router.
7. How A Child Node Prunes Itself from an IR P-tunnel 8. How A Child Node Prunes Itself from an IR P-tunnel
If a particular IR P-tunnel was joined via the procedures of If a particular IR P-tunnel was joined via the procedures of
Section 4.1.2 of this document, a router can prune itself from the Section 4.1.2 of this document, a router can prune itself from the
P-tunnel by withdrawing the Intra-AS I-PMSI A-D route it used to join P-tunnel by withdrawing the Intra-AS I-PMSI A-D route it used to join
the P-tunnel. This is not usually done unless the router is removing the P-tunnel. This is not usually done unless the router is removing
itself entirely from a particular MVPN. itself entirely from a particular MVPN.
The procedures in the remainder of this section apply when a router The procedures in the remainder of this section apply when a router
joined a particular IR P-tunnel by originating a Leaf A-D route (as joined a particular IR P-tunnel by originating a Leaf A-D route (as
described in Section 4.1.1 or Section 4.2 of this document). described in Section 4.1.1 or Section 4.2 of this document).
If a router no longer has a need to receive any multicast data from a If a router no longer has a need to receive any multicast data from a
given IR P-tunnel, it may prune itself from the P-tunnel by given IR P-tunnel, it may prune itself from the P-tunnel by
withdrawing the Leaf A-D route it used to join the tunnel. This is withdrawing the Leaf A-D route it used to join the tunnel. This is
done, e.g., if the router no longer needs any of the flows traveling done, e.g., if the router no longer needs any of the flows traveling
over the P-tunnel, or if all the flows the router does need are being over the P-tunnel, or if all the flows the router does need are being
received over other P-tunnels. received over other P-tunnels.
A router that is attached to a particular IR P-tunnel via a A router that is attached to a particular IR P-tunnel via a
particular parent node may determine that it needs to stay joined to particular parent node may determine that it needs to stay joined to
that P-tunnel, but via a different parent node. This can happen, for that IR P-tunnel, but via a different parent node. This can happen,
example, if there is a change in the Next Hop or the P2MP Segmented for example, if there is a change in the Next Hop or the P2MP
Next Hop Extended Community of the S-PMSI A-D route in which that Segmented Next Hop Extended Community of the S-PMSI A-D route in
P-tunnel was advertised. In this case, the router changes the Route which that P-tunnel was advertised. In this case, the router changes
Target of the Leaf A-D route it used to join the IR P-tunnel, so that the Route Target of the Leaf A-D route it used to join the IR
the Route Target now identifies the new parent node. P-tunnel, so that the Route Target now identifies the new parent
node.
A parent node must notice when a child node has been pruned from a A parent node must notice when a child node has been pruned from a
particular tree, as this will affect the parent node's multicast data particular tree, as this will affect the parent node's multicast data
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 9. Parent Node Actions Upon Receiving Leaf A-D Route
These actions are detailed in [RFC6514] and [RFC7524]. 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 [RFC7524].) If a Leaf A-D (This is as specified in [RFC6514] and [RFC7524].) If a Leaf A-D
skipping to change at page 17, line 7 skipping to change at page 19, line 5
route. route.
If at some later time, R1 installs the corresponding S-PMSI A-D If at some later time, R1 installs the corresponding S-PMSI A-D
route, and the Leaf A-D route is still installed, and the Leaf A-D route, and the Leaf A-D route is still installed, and the Leaf A-D
route's RT still identifies R1, then R1 MUST follow the same route's RT still identifies R1, then R1 MUST follow the same
procedures it would have followed if the S-PMSI A-D route had been procedures it would have followed if the S-PMSI A-D route had been
installed before the Leaf A-D route was installed. (I.e., installed before the Leaf A-D route was installed. (I.e.,
implementers must not assume that events occur in the "usual" or implementers must not assume that events occur in the "usual" or
"expected" order.) "expected" order.)
9. Use of Timers when Switching UMH 10. Use of Timers when Switching UMH
Suppose a child node has joined a particular IR P-tunnel via a Consider a child node that has joined a particular IR P-tunnel via a
particular UMH, and it now determines (for whatever reason) that it particular UMH. To do so, it will have originated a Leaf A-D route
needs to change its UMH on that P-tunnel. It does this by modifying with an RT that identifies the UMH. Suppose the child node now
the RT of a Leaf A-D route. determines (for whatever reason) that it needs to change its UMH for
that P-tunnel. It does this by:
o modifying the RT of the Leaf A-D route, so that the RT now
identifies the new parent rather than the old one, and by
o modifying the PTA of the Leaf A-D route, changing the MPLS Label
field as discussed in Section 7.
Note that, in accordance with the procedures of [RFC6514] and of
Section 4 of this document, the NLRI of the Leaf A-D route is not
modified; only the RT and the PTA are changed.
It is desirable for such a "switch of UMH" to be done using a "make It is desirable for such a "switch of UMH" to be done using a "make
before break" technique, so that the older UMH does not stop before break" technique, so that the old UMH does not stop
transmitting the packets on the given P-tunnel to the child until the transmitting packets of the given P-tunnel to the child until the new
newer UMH has a chance to start transmitting the packets on the given UMH has a chance to start transmitting packets of the given P-tunnel
P-tunnel to the child. However, the control plane operation to the child. However, the control plane operation (i.e., modifying
(modifying the RT of the Leaf A-D route) does not permit the child the RT and PTA of the Leaf A-D route) does not permit the child node
node to first join the P-tunnel at the new UMH, and then later prune to first join the IR P-tunnel via the new UMH, and then later prune
itself from the old UMH; a single control plane operation has both itself from the old UMH. Rather, a single control plane operation
effects. Therefore, to achieve "make before break", timers must be has both effects.
used as follows:
1. The old UMH must continue transmitting to the child node for a Therefore, the old UMH MUST continue transmitting to the child node
period of time after it sees the child's Leaf A-D route being for a period of time after it sees the child's Leaf A-D route being
withdrawn (or its RT changing to identify a different UMH). withdrawn (or its RT changing to identify a different UMH). This
timer (the "parent-continues" timer) SHOULD have a default value of
60 seconds, and SHOULD be configurable.
2. The child node must continue to accept packets from the old UMH By the procedures of Section 7, the child node will have advertised a
for a period of time before it starts to accept packets from the different label for the IR P-tunnel to the new UMH than it had
new UMH (and discard packets from the old). advertised to the old UMH. This allows it to distinguish the packets
of that IR P-tunnel transmitted by the new UMH from packets of that
IR P-tunnel transmitted by the old UMH. At any given time, the child
node will accept packets of that IR P-tunnel from only one parent
node, and will discard packets of that IR P-tunnel that are received
from the other. To achieve "make before break" functionality, the
child node needs to continue to accept packets from the old UMH for a
period of time. After this period, it will discard any packets from
the given IR P-tunnel that it receives from the old UMH, and will
only accept such packets from the new UMH.
Further, the timer in 1 should be longer than the timer in 2. This Once the child node modifies the RT of its Leaf A-D route, it MUST
allows the child to switch from one UMH to another without any loss run a timer (the "switch-parents-delay" timer). This timer SHOULD
of data. default to 30 seconds, and SHOULD be configurable. The child node
MUST continue to accept packets of the given IR P-tunnel from the old
UMH until the timer expires. However, once the child node receives a
packet of the given IR P-tunnel from the new UMH, it MAY consider the
switch-parents-delay timer to have expired.
10. IANA Considerations The "parent-continues" timer MUST be longer than the "switch-parents-
delay" timer. Note that both timers are specific to a given IR
P-tunnel.
11. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
11. Acknowledgments 12. Acknowledgments
The authors wish to thank Yakov Rekhter for his contributions to this The authors wish to thank Yakov Rekhter for his contributions to this
work. We also wish to thank Huajin Jeng and Samir Saad for their work. We also wish to thank Huajin Jeng and Samir Saad for their
contributions, and to thank Thomas Morin for pointing out some of the contributions, and to thank Thomas Morin for pointing out (both
issues that needed further elaboration. before and after the document was written) some of the issues that
needed further elaboration. We also thank Lucy Yong for her review
and comments.
Section 6.1 discusses the importance of having an MPLS label Section 7.1 discusses the importance of having an MPLS label
allocation policy that, when ingress replication is used, allows an allocation policy that, when ingress replication is used, allows an
egress PE to infer the identity of a received packet's ingress PE. egress PE to infer the identity of a received packet's ingress PE.
This issue was first raised in earlier work by Xu Xiaohu. This issue was first raised in earlier work by Xu Xiaohu.
12. Security Considerations 13. Security Considerations
No security considerations are raised by this document beyond those No security considerations are raised by this document beyond those
already discussed in [RFC6513] and [RFC6514]. already discussed in [RFC6513] and [RFC6514].
13. References 14. References
13.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
VPNs", RFC 6513, February 2012. BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[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. DOI 10.17487/RFC6515, February 2012,
<http://www.rfc-editor.org/info/rfc6515>.
13.2. Informative References 14.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-bess-mvpn-bidir- Replication", internet-draft draft-ietf-bess-mvpn-bidir-
ingress-replication-00, January 2015. ingress-replication-03, September 2015.
[MVPN-BIDIR] [GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K., and D.
Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, ""MVPN: Pacella, "Global Table Multicast with BGP-MVPN
Using Bidirectional P-Tunnels", internet-draft draft-ietf- Procedures", internet-draft draft-ietf-bess-mvpn-global-
bess-mvpn-bidir-04, April 2015. table-mcast-03, September 2015.
[MVPN-XNET] [MVPN-XNET]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet- Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet-
draft draft-ietf-bess-mvpn-extranet-02, May 2015. 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, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Specification", RFC 5036, October 2007. "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
"Label Distribution Protocol Extensions for Point-to- Thomas, "Label Distribution Protocol Extensions for Point-
Multipoint and Multipoint-to-Multipoint Label Switched to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<http://www.rfc-editor.org/info/rfc6388>.
[RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
"Wildcards in Multicast VPN Auto-Discovery Routes", RFC Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
6625, May 2012. RFC 6625, DOI 10.17487/RFC6625, May 2012,
<http://www.rfc-editor.org/info/rfc6625>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Segmented LSPs", RFC 7524, May 2015. Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<http://www.rfc-editor.org/info/rfc7524>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <http://www.rfc-editor.org/info/rfc7582>.
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
United States United States
Email: erosen@juniper.net Email: erosen@juniper.net
 End of changes. 78 change blocks. 
219 lines changed or deleted 359 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/