draft-ietf-bess-mvpn-bidir-04.txt   rfc7582.txt 
BESS Working Group E. Rosen Internet Engineering Task Force (IETF) E. Rosen
Internet-Draft Juniper Networks, Inc. Request for Comments: 7582 Juniper Networks, Inc.
Updates: 6513,6514,6625 (if approved) IJ. Wijnands Updates: 6513, 6514, 6625 IJ. Wijnands
Intended status: Standards Track Cisco Systems, Inc. Category: Standards Track Cisco Systems, Inc.
Expires: September 24, 2015 Y. Cai ISSN: 2070-1721 Y. Cai
Microsoft Microsoft
A. Boers A. Boers
March 23, 2015 July 2015
MVPN: Using Bidirectional P-Tunnels Multicast Virtual Private Network (MVPN):
draft-ietf-bess-mvpn-bidir-04 Using Bidirectional P-Tunnels
Abstract Abstract
A set of prior RFCs specify procedures for supporting multicast in A set of prior RFCs specify procedures for supporting multicast in
BGP/MPLS IP VPNs. These procedures allow customer multicast data to BGP/MPLS IP VPNs. These procedures allow customer multicast data to
travel across a service provider's backbone network through a set of travel across a service provider's backbone network through a set of
multicast tunnels. The tunnels are advertised in certain BGP multicast tunnels. The tunnels are advertised in certain BGP
multicast "auto-discovery" routes, by means of a BGP attribute known multicast auto-discovery routes, by means of a BGP attribute known
as the "Provider Multicast Service Interface (PMSI) Tunnel as the "Provider Multicast Service Interface (PMSI) Tunnel"
attribute". Encodings have been defined that allow the PMSI Tunnel attribute. Encodings have been defined that allow the PMSI Tunnel
attribute to identify bidirectional (multipoint-to-multipoint) attribute to identify bidirectional (multipoint-to-multipoint)
multicast distribution trees. However, the prior RFCs do not provide multicast distribution trees. However, the prior RFCs do not provide
all the necessary procedures for using bidirectional tunnels to all the necessary procedures for using bidirectional tunnels to
support multicast VPNs. This document updates RFCs 6513, 6514 and support multicast VPNs. This document updates RFCs 6513, 6514, and
6625 by specifying those procedures. In particular, it specifies the 6625 by specifying those procedures. In particular, it specifies the
procedures for assigning customer multicast flows (unidirectional or procedures for assigning customer multicast flows (unidirectional or
bidirectional) to specific bidirectional tunnels in the provider bidirectional) to specific bidirectional tunnels in the provider
backbone, for advertising such assignments, and for determining which backbone, for advertising such assignments, and for determining which
flows have been assigned to which tunnels. flows have been assigned to which tunnels.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by
material or to cite them other than as "work in progress." the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 5741.
This Internet-Draft will expire on September 24, 2015. Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7582.
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 ....................................................4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2. Overview ...................................................9
1.2.1. Bidirectional P-tunnel 1.2.1. Bidirectional P-Tunnel Technologies ................10
Technologies . . . . . . . . . . . . . . . . . . . . 9 1.2.2. Reasons for Using Bidirectional P-Tunnels ..........11
1.2.2. Reasons for Using Bidirectional 1.2.3. Knowledge of Group-to-RP and/or
P-tunnels . . . . . . . . . . . . . . . . . . . . . . 10 Group-to-RPA Mappings ..............................12
1.2.3. Knowledge of Group-to-RP and/or 1.2.4. PMSI Instantiation Methods .........................12
Group-to-RPA Mappings . . . . . . . . . . . . . . . . 11 2. The All BIDIR-PIM Wildcard .....................................15
1.2.4. PMSI Instantiation Methods . . . . . . . . . . . . . 11 3. Using Bidirectional P-Tunnels ..................................15
2. The All BIDIR-PIM Wild Card . . . . . . . . . . . . . . . . . 14 3.1. Procedures Specific to the Tunneling Technology ...........15
3. Using Bidirectional P-Tunnels . . . . . . . . . . . . . . . . 14 3.1.1. BIDIR-PIM P-Tunnels ................................16
3.1. Procedures Specific to the 3.1.2. MP2MP LSPs .........................................17
Tunneling Technology . . . . . . . . . . . . . . . . . . 15 3.2. Procedures Specific to the PMSI Instantiation Method ......17
3.1.1. BIDIR-PIM P-Tunnels . . . . . . . . . . . . . . . . . 15 3.2.1. Flat Partitioning ..................................17
3.1.2. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . 16 3.2.1.1. When an S-PMSI Is a 'Match for
3.2. Procedures Specific to the PMSI Transmission' .............................19
Instantiation Method . . . . . . . . . . . . . . . . . . 16 3.2.1.2. When an I-PMSI Is a 'Match for
3.2.1. Flat Partitioning . . . . . . . . . . . . . . . . . . 17 Transmission' .............................20
3.2.1.1. When an S-PMSI is a 'Match for 3.2.1.3. When an S-PMSI Is a 'Match for Reception' .21
Transmission' . . . . . . . . . . . . . . . . . . 19 3.2.1.4. When an I-PMSI Is a 'Match for Reception' .22
3.2.1.2. When an I-PMSI is a 'Match for 3.2.2. Hierarchical Partitioning ..........................23
Transmission' . . . . . . . . . . . . . . . . . . 19 3.2.2.1. Advertisement of PE Distinguisher Labels ..24
3.2.1.3. When an S-PMSI is a 'Match for 3.2.2.2. When an S-PMSI Is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 20 Transmission' .............................25
3.2.1.4. When an I-PMSI is a 'Match for 3.2.2.3. When an I-PMSI Is a 'Match for
Reception . . . . . . . . . . . . . . . . . . . . 21 Transmission' .............................26
3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 22 3.2.2.4. When an S-PMSI Is a 'Match for Reception' .27
3.2.2.1. Advertisement of PE 3.2.2.5. When an I-PMSI Is a 'Match for Reception' .27
Distinguisher Labels . . . . . . . . . . . . . . 23 3.2.3. Unpartitioned ......................................28
3.2.2.2. When an S-PMSI is a 'Match for 3.2.3.1. When an S-PMSI Is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 24 Transmission' .............................30
3.2.2.3. When an I-PMSI is a 'Match for 3.2.3.2. When an S-PMSI Is a 'Match for Reception' .30
Transmission' . . . . . . . . . . . . . . . . . . 25 3.2.4. Minimal Feature Set for Compliance .................31
3.2.2.4. When an S-PMSI is a 'Match for 4. Security Considerations ........................................32
Reception' . . . . . . . . . . . . . . . . . . . 26 5. References .....................................................32
3.2.2.5. When an I-PMSI is a 'Match for 5.1. Normative References ......................................32
Reception' . . . . . . . . . . . . . . . . . . . 26 5.2. Informative References ....................................33
3.2.3. Unpartitioned . . . . . . . . . . . . . . . . . . . . 27 Acknowledgments ...................................................34
3.2.3.1. When an S-PMSI is a 'Match for Authors' Addresses ................................................34
Transmission' . . . . . . . . . . . . . . . . . . 29
3.2.3.2. When an S-PMSI is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 30
3.2.4. Minimal Feature Set for
Compliance . . . . . . . . . . . . . . . . . . . . . 30
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The RFCs that specify multicast support for BGP/MPLS IP VPNs The RFCs that specify multicast support for BGP/MPLS IP VPNs
([RFC6513], [RFC6514], [RFC6625]) allow customer multicast data to be ([RFC6513], [RFC6514], and [RFC6625]) allow customer multicast data
transported across a service provider's network though a set of to be transported across a service provider's network though a set of
multicast tunnels. These tunnels are advertised in BGP multicast multicast tunnels. These tunnels are advertised in BGP multicast
"auto-discovery" (A-D) routes, by means of a BGP attribute known as auto-discovery (A-D) routes, by means of a BGP attribute known as the
the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. "Provider Multicast Service Interface (PMSI) Tunnel" attribute. The
The base specifications allow the use of bidirectional (multipoint- base specifications allow the use of bidirectional (multipoint-to-
to-multipoint) multicast distribution trees, and describe how to multipoint) multicast distribution trees and describe how to encode
encode the identifiers for bidirectional trees into the PMSI Tunnel the identifiers for bidirectional trees into the PMSI Tunnel
attribute. However, those specifications do not provide all the attribute. However, those specifications do not provide all the
necessary detailed procedures for using bidirectional tunnels; the necessary detailed procedures for using bidirectional tunnels; the
full specification of these procedures was considered to be outside full specification of these procedures was considered to be outside
the scope of those documents. The purpose of this document is to the scope of those documents. The purpose of this document is to
provide all the necessary procedures for using bidirectional trees in provide all the necessary procedures for using bidirectional trees in
a service provider's network to carry the multicast data of VPN a service provider's network to carry the multicast data of VPN
customers. customers.
1.1. Terminology 1.1. Terminology
skipping to change at page 4, line 39 skipping to change at page 5, line 18
o MP2MP o MP2MP
Multipoint-to-multipoint. Multipoint-to-multipoint.
o Unidirectional o Unidirectional
Adjective for a multicast distribution tree in which all traffic Adjective for a multicast distribution tree in which all traffic
travels downstream from the root of the tree. Traffic can enter a travels downstream from the root of the tree. Traffic can enter a
unidirectional tree only at the root. A P2MP LSP is one type of unidirectional tree only at the root. A P2MP LSP is one type of
unidirectional tree. Multicast distribution trees set up by PIM- unidirectional tree. Multicast distribution trees set up by
SM [RFC4601] are also unidirectional trees. Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]
Data traffic traveling along a unidirectional multicast are also unidirectional trees. Data traffic traveling along a
distribution tree is sometimes referred to in this document as unidirectional multicast distribution tree is sometimes referred
"unidirectional traffic". to in this document as "unidirectional traffic".
o Bidirectional o Bidirectional
Adjective for a multicast distribution tree in which traffic may Adjective for a multicast distribution tree in which traffic may
travel both upstream (towards the root) and downstream (away from travel both upstream (towards the root) and downstream (away from
the root). Traffic may enter a bidirectional tree at any node. A the root). Traffic may enter a bidirectional tree at any node.
MP2MP LSP is one type of bidirectional tree. Multicast An MP2MP LSP is one type of bidirectional tree. Multicast
distribution trees created by BIDIR-PIM [RFC5015] are also distribution trees created by Bidirectional Protocol Independent
bidirectional trees. Multicast (BIDIR-PIM) [RFC5015] are also bidirectional trees.
Data traffic traveling along a bidirectional multicast Data traffic traveling along a bidirectional multicast
distribution tree is sometimes referred to in this document as distribution tree is sometimes referred to in this document as
"bidirectional traffic". "bidirectional traffic".
o P-tunnel o P-tunnel
A tunnel through the network of one or more Service Providers A tunnel through the network of one or more SPs. In this
(SPs). In this document, the P-tunnels we speak of are are document, the P-tunnels we speak of are instantiated as
instantiated as bidirectional multicast distribution trees. bidirectional multicast distribution trees.
o SSM
Source-Specific Multicast. When SSM is being used, a multicast
distribution tree carries traffic from only a single source.
o ASM
Any Source Multicast. When ASM is being used, some multicast
distribution trees ("share trees") carry traffic from multiple
sources.
o C-S o C-S
Multicast Source. A multicast source address, in the address Multicast Source. A multicast source address, in the address
space of a customer network. space of a customer network.
o C-G o C-G
Multicast Group. A multicast group address (destination address) Multicast Group. A multicast group address (destination address)
in the address space of a customer network. When used without in the address space of a customer network. When used without
skipping to change at page 5, line 45 skipping to change at page 6, line 35
sites on a multicast distribution tree set up by the customer. sites on a multicast distribution tree set up by the customer.
These trees may be unidirectional or bidirectional, depending upon These trees may be unidirectional or bidirectional, depending upon
the multicast routing protocol used by the customer. A C-flow the multicast routing protocol used by the customer. A C-flow
travels between VPN customer sites by traveling through P-tunnels. travels between VPN customer sites by traveling through P-tunnels.
A C-flow from a particular customer source is identified by the A C-flow from a particular customer source is identified by the
ordered pair (source address, group address), where each address ordered pair (source address, group address), where each address
is in the customer's address space. The identifier of such a is in the customer's address space. The identifier of such a
C-flow is usually written as (C-S,C-G). C-flow is usually written as (C-S,C-G).
If a customer uses the "Any Source Multicast" (ASM) model, then If a customer uses the ASM model, then some or all of the
some or all of the customer's C-flows may be traveling along the customer's C-flows may be traveling along the same "shared tree".
same "shared tree". In this case, we will speak of a "(C-*,C-G)" In this case, we will speak of a "(C-*,C-G)" flow to refer to a
flow to refer to a set of C-flows that travel along the same set of C-flows that travel along the same shared tree in the
shared tree in the customer sites. customer sites.
o C-BIDIR flow or bidirectional C-flow o C-BIDIR flow or bidirectional C-flow
A C-flow that, in the VPN customer sites, travels along a A C-flow that, in the VPN customer sites, travels along a
bidirectional multicast distribution tree. The term "C-BIDIR bidirectional multicast distribution tree. The term "C-BIDIR
flow" indicates that the customer's bidirectional tree has been flow" indicates that the customer's bidirectional tree has been
set up by BIDIR-PIM. set up by BIDIR-PIM.
o RP o RP
A "Rendezvous Point", as defined in [RFC4601]. A Rendezvous Point, as defined in [RFC4601].
o C-RP o C-RP
A Rendezvous Point whose address is in the customer's address A Rendezvous Point whose address is in the customer's address
space. space.
o RPA o RPA
A "Rendezvous Point Address", as defined in [RFC5015]. A Rendezvous Point Address, as defined in [RFC5015].
o C-RPA o C-RPA
An RPA in the customer's address space. An RPA in the customer's address space.
o P-RPA o P-RPA
An RPA in the Service Provider's address space An RPA in the SP's address space.
o Selective P-tunnel o Selective P-tunnel
A P-tunnel that is joined only by Provider Edge (PE) routers that A P-tunnel that is joined only by PE routers that need to receive
need to receive one or more of the C-flows that are traveling one or more of the C-flows that are traveling through that
through that P-tunnel. P-tunnel.
o Inclusive P-tunnel o Inclusive P-tunnel
A P-tunnel that is joined by all PE routers that attach to sites A P-tunnel that is joined by all PE routers that attach to sites
of a given MVPN. of a given MVPN.
o PMSI o PMSI
Provider Multicast Service Interface. A PMSI is a conceptual Provider Multicast Service Interface. A PMSI is a conceptual
overlay on a Service Provider backbone, allowing a PE in a given overlay on a Service Provider backbone, allowing a PE in a given
skipping to change at page 7, line 16 skipping to change at page 8, line 7
by Inclusive P-tunnels. by Inclusive P-tunnels.
o S-PMSI o S-PMSI
Selective PMSI. Traffic multicast by a PE on an S-PMSI is Selective PMSI. Traffic multicast by a PE on an S-PMSI is
received by some (but not necessarily all) of the other PEs in the received by some (but not necessarily all) of the other PEs in the
MVPN. S-PMSIs are instantiated by Selective P-tunnels. MVPN. S-PMSIs are instantiated by Selective P-tunnels.
o Intra-AS I-PMSI A-D route o Intra-AS I-PMSI A-D route
Intra Autonomous System Inclusive Provider Multicast Service Intra-AS (Autonomous System) Inclusive Provider Multicast Service
Interface Auto-Discovery route. Carried in BGP Update messages, Interface Auto-Discovery route. Carried in BGP Update messages,
these routes can be used to advertise the use of Inclusive these routes can be used to advertise the use of Inclusive
P-tunnels. See [RFC6514] section 4.1. P-tunnels. See [RFC6514], Section 4.1.
o S-PMSI A-D route o S-PMSI A-D route
Selective Provider Multicast Service Interface Auto-Discovery Selective Provider Multicast Service Interface Auto-Discovery
route. Carried in BGP Update messages, these routes are used to route. Carried in BGP Update messages, these routes are used to
advertise the fact that a particular C-flow or a particular set of advertise the fact that a particular C-flow or a particular set of
C-flows is bound to (i.e., is traveling through) a particular C-flows is bound to (i.e., is traveling through) a particular
P-tunnel. See [RFC6514] section 4.3. P-tunnel. See [RFC6514], Section 4.3.
o (C-S,C-G) S-PMSI A-D route o (C-S,C-G) S-PMSI A-D route
An S-PMSI A-D route whose NLRI ("Network Layer Reachability An S-PMSI A-D route whose NLRI (Network Layer Reachability
Information") contains C-S in its "Multicast Source" field and C-G Information) contains C-S in its "Multicast Source" field and C-G
in its "Multicast Group" field. in its "Multicast Group" field.
o (C-*,C-G) S-PMSI A-D route o (C-*,C-G) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its
"Multicast Source" field and C-G in its "Multicast Group" field. "Multicast Source" field and C-G in its "Multicast Group" field.
See [RFC6625]. See [RFC6625].
o (C-*,C-G-BIDIR) S-PMSI A-D route o (C-*,C-G-BIDIR) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its
"Multicast Source" field and C-G-BIDIR in its "Multicast Group" "Multicast Source" field and C-G-BIDIR in its "Multicast Group"
field. See [RFC6625]. field. See [RFC6625].
o (C-*,C-*) S-PMSI A-D route o (C-*,C-*) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
"Multicast Source" field and the wildcard C-* in its "Multicast "Multicast Source" field and the wildcard C-* in its "Multicast
Group" field. See [RFC6625]. Group" field. See [RFC6625].
o (C-*,C-*) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
"Multicast Source" field and the wildcard C-* in its "Multicast
Group" field. See [RFC6625].
o (C-*,C-*-BIDIR) S-PMSI A-D route o (C-*,C-*-BIDIR) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains the wildcard C-* in its An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
"Multicast Source" field and the wildcard "C-*-BIDIR" in its "Multicast Source" field and the wildcard "C-*-BIDIR" in its
"Multicast Group" field. See Section 2 of this document. "Multicast Group" field. See Section 2 of this document.
o (C-S,C-*) S-PMSI A-D route o (C-S,C-*) S-PMSI A-D route
An S-PMSI A-D route whose NLRI contains C-S in its "Multicast An S-PMSI A-D route whose NLRI contains C-S in its "Multicast
Source" field and the wildcard C-* in its "Multicast Group" field. Source" field and the wildcard C-* in its "Multicast Group" field.
See [RFC6625]. See [RFC6625].
o Wildcard S-PMSI A-D route o Wildcard S-PMSI A-D route
A (C-*,C-G) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route, or A (C-*,C-G) S-PMSI A-D route, a (C-*,C-*) S-PMSI A-D route, a
a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D route.
route.
o PTA o PTA
PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel. PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel.
See [RFC6514] section 8. See [RFC6514], Section 8.
The terminology used for categorizing S-PMSI A-D routes will also be The terminology used for categorizing S-PMSI A-D routes will also be
used for categorizing the S-PMSIs advertised by those routes. E.g., used for categorizing the S-PMSIs advertised by those routes. For
the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known example, the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will
as a "(C-*,C-G) S-PMSI". be known as a "(C-*,C-G) S-PMSI".
Familiarity with multicast concepts and terminology [RFC4601] is also Familiarity with multicast concepts and terminology [RFC4601] is also
presupposed. presupposed.
This specification uses the terms "match for transmission" and "match This specification uses the terms "match for transmission" and "match
for reception" as they are defined in [RFC6625]. When it is clear for reception" as they are defined in [RFC6625]. When it is clear
from the context whether we are talking of transmission or reception, from the context whether we are talking of transmission or reception,
we will sometimes talk simply of a C-flow "matching" an I-PMSI or we will sometimes talk simply of a C-flow "matching" an I-PMSI or
S-PMSI A-D route. S-PMSI A-D route.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document, when and only when appearing in all caps, are to be document, when and only when appearing in all caps, are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.2. Overview 1.2. Overview
The base documents for MVPN ([RFC6513], [RFC6514]) define a "PMSI The base documents for MVPN ([RFC6513] and [RFC6514]) define a "PMSI
Tunnel attribute" (PTA). This is a BGP Path Attribute that may be Tunnel attribute" (PTA). This is a BGP Path attribute that may be
attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" that attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" that
are defined in those documents. The base documents define the way in are defined in those documents. The base documents define the way in
which the identifier of a bidirectional P-tunnel is to be encoded in which the identifier of a bidirectional P-tunnel is to be encoded in
the PTA. However, those documents do not contain the full set of the PTA. However, those documents do not contain the full set of
specifications governing the use of bidirectional P-tunnels; rather, specifications governing the use of bidirectional P-tunnels; rather,
those documents declare the full set of specifications for using those documents declare the full set of specifications for using
bidirectional P-tunnels to be outside their scope. Similarly, the bidirectional P-tunnels to be outside their scope. Similarly, the
use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D
routes is declared by [RFC6625] to be "out of scope." routes is declared by [RFC6625] to be "outside the scope" of that
document.
This document provides the specifications governing the use of This document provides the specifications governing the use of
bidirectional P-tunnels to provide MVPN support. This includes the bidirectional P-tunnels to provide MVPN support. This includes the
procedures for assigning C-flows to specific bidirectional P-tunnels, procedures for assigning C-flows to specific bidirectional P-tunnels,
for advertising the fact that a particular C-flow has been assigned for advertising the fact that a particular C-flow has been assigned
to a particular bidirectional P-tunnel, and for determining the to a particular bidirectional P-tunnel, and for determining the
bidirectional P-tunnel on which a given C-flow may be expected. bidirectional P-tunnel on which a given C-flow may be expected.
The C-flows carried on bidirectional P-tunnels may themselves be The C-flows carried on bidirectional P-tunnels may, themselves, be
either unidirectional or bidirectional. Procedures are provided for either unidirectional or bidirectional. Procedures are provided for
both cases. both cases.
This document does not specify any new data encapsulations for This document does not specify any new data encapsulations for
bidirectional P-tunnels. Section 12 ("Encapsulations") of [RFC6513] bidirectional P-tunnels. Section 12 ("Encapsulations") of [RFC6513]
applies unchanged. applies unchanged.
With regard to the procedures for using bidirectional P-tunnels to With regard to the procedures for using bidirectional P-tunnels to
instantiate PMSIs, if there is any conflict between the procedures instantiate PMSIs, if there is any conflict between the procedures
specified in this document and the procedures of [RFC6513], specified in this document and the procedures of [RFC6513],
[RFC6514], or [RFC6625], the procedures of this document take [RFC6514], or [RFC6625], the procedures of this document take
precedence. precedence.
The use of bidirectional P-tunnels to support extranets [MVPN-XNET] The use of bidirectional P-tunnels to support extranets [MVPN-XNET]
is outside the scope of this document. The use of bidirectional is outside the scope of this document. The use of bidirectional
P-tunnels as "segmented P-tunnels" (see [RFC6513] section 8 and P-tunnels as "segmented P-tunnels" (see Section 8 of [RFC6513] and
various sections of [RFC6514]) is also outside the scope of this various sections of [RFC6514]) is also outside the scope of this
document. document.
1.2.1. Bidirectional P-tunnel Technologies 1.2.1. Bidirectional P-Tunnel Technologies
This document supports two different technologies for creating and This document supports two different technologies for creating and
maintaining bidirectional P-tunnels: maintaining bidirectional P-tunnels:
o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that
are created through the use of the Label Distribution Protocol are created through the use of the Label Distribution Protocol
(LDP) Multipoint-to-Multipoint extensions [RFC6388]. (LDP) Multipoint-to-Multipoint extensions [RFC6388].
o Multicast distribution trees that are created through the use of o Multicast distribution trees that are created through the use of
BIDIR-PIM [RFC5015]. BIDIR-PIM [RFC5015].
Other bidirectional tunnel technologies are outside the scope of this Other bidirectional tunnel technologies are outside the scope of this
document. document.
1.2.2. Reasons for Using Bidirectional P-tunnels 1.2.2. Reasons for Using Bidirectional P-Tunnels
Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or
S-PMSIs. S-PMSIs.
An SP may decide to use bidirectional P-tunnels to instantiate An SP may decide to use bidirectional P-tunnels to instantiate
certain I-PMSIs and/or S-PMSIs in order to provide its customers with certain I-PMSIs and/or S-PMSIs in order to provide its customers with
C-BIDIR support, using the "Partitioned Set of PEs" technique C-BIDIR support, using the "Partitioned Set of PEs" technique
discussed in [RFC6513] section 11.2 and [RFC6517] section 3.6. This discussed in Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517].
technique can be used whether the C-BIDIR flows are being carried on This technique can be used whether the C-BIDIR flows are being
an I-PMSI or an S-PMSI. carried on an I-PMSI or an S-PMSI.
Even if an SP does not need to provide C-BIDIR support, it may still Even if an SP does not need to provide C-BIDIR support, it may still
decide to use bidirectional P-tunnels, in order to save state in the decide to use bidirectional P-tunnels, in order to save state in the
network's transit nodes. For example, if an MVPN has n PEs attached network's transit nodes. For example, if an MVPN has n PEs attached
to sites with multicast sources, and there is an I-PMSI for that to sites with multicast sources, and there is an I-PMSI for that
MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e., MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e.,
with P2MP multicast distribution trees) requires n multicast with P2MP multicast distribution trees) requires n multicast
distribution trees, each one rooted at a different PE. If the I-PMSI distribution trees, each one rooted at a different PE. If the I-PMSI
is instantiated by a bidirectional P-tunnel, a single multicast is instantiated by a bidirectional P-tunnel, a single multicast
distribution tree can be used, assuming appropriate support by the distribution tree can be used, assuming appropriate support by the
provisioning system. provisioning system.
An SP may decide to use bidirectional P-tunnels for either or both of An SP may decide to use bidirectional P-tunnels for either or both of
these reasons. Note that even if the reason for using bidirectional these reasons. Note that even if the reason for using bidirectional
P-tunnels is to provide C-BIDIR support, the same P-tunnels can also P-tunnels is to provide C-BIDIR support, the same P-tunnels can also
be used to carry unidirectional C-flows, if that is the choice of the be used to carry unidirectional C-flows, if that is the choice of the
SP. SP.
These two reasons for using bidirectional P-tunnels may appear to be These two reasons for using bidirectional P-tunnels may appear to be
somewhat in conflict with each other, since (as will be seen in somewhat in conflict with each other, since (as will be seen in
subsequent sections), the use of bidirectional P-tunnels for C-BIDIR subsequent sections) the use of bidirectional P-tunnels for C-BIDIR
support may require multiple bidirectional P-tunnels per VPN. Each support may require multiple bidirectional P-tunnels per VPN. Each
such P-tunnel is associated with a particular "distinguished PE", and such P-tunnel is associated with a particular "distinguished PE", and
can only carry those C-BIDIR flows whose C-RPAs are reachable through can only carry those C-BIDIR flows whose C-RPAs are reachable through
its distinguished PE. However, on platforms that support MPLS its distinguished PE. However, on platforms that support MPLS
upstream-assigned labels ([RFC5331]), "PE Distinguisher Labels" upstream-assigned labels ([RFC5331]), PE Distinguisher Labels
([RFC6513] Section 4 and [RFC6514] Section 8) can be used to (Section 4 of [RFC6513] and Section 8 of [RFC6514]) can be used to
aggregate multiple bidirectional P-tunnels onto a single "outer" aggregate multiple bidirectional P-tunnels onto a single outer
bidirectional P-tunnel, thereby allowing one to provide C-BIDIR bidirectional P-tunnel, thereby allowing one to provide C-BIDIR
support with minimal state at the transit nodes. support with minimal state at the transit nodes.
Since there are two fundamentally different reasons for using Since there are two fundamentally different reasons for using
bidirectional P-tunnels, and since many deployed router platforms do bidirectional P-tunnels, and since many deployed router platforms do
not support upstream-assigned labels at the current time, this not support upstream-assigned labels at the current time, this
document specifies several different methods of using bidirectional document specifies several different methods of using bidirectional
P-tunnels to instantiate PMSIs. We refer to these as "PMSI P-tunnels to instantiate PMSIs. We refer to these as "PMSI
Instantiation Methods". The method or methods deployed by any Instantiation Methods". The method or methods deployed by any
particular SP will depend upon that SP's goals and engineering particular SP will depend upon that SP's goals and engineering trade-
tradeoffs, and upon the set of platforms deployed by that SP. offs and upon the set of platforms deployed by that SP.
The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D
routes are not exactly the same as the rules for using unidirectional routes are not exactly the same as the rules for using unidirectional
P-tunnels, and the rules are also different for the different PMSI P-tunnels, and the rules are also different for the different PMSI
instantiation methods. Subsequent sections of this document specify instantiation methods. Subsequent sections of this document specify
the rules in detail. the rules in detail.
1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings 1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings
If a VPN customer is making use of a particular "Any Source If a VPN customer is making use of a particular ASM group address,
Multicast" (ASM) group address, the PEs of that VPN generally need to the PEs of that VPN generally need to know the group-to-RP mappings
know the group-to-RP mappings that are used within the VPN. If a VPN that are used within the VPN. If a VPN customer is making use of
customer is making use of BIDIR-PIM group addresses, the PEs need to BIDIR-PIM group addresses, the PEs need to know the group-to-RPA
know the group-to-RPA mappings that are used within the VPN. mappings that are used within the VPN. Commonly, the PEs obtain this
Commonly, the PEs obtain this knowledge either through provisioning knowledge either through provisioning or by participating in a
or by participating in a dynamic "group-to-RP(A) mapping discovery dynamic "group-to-RP(A) mapping discovery protocol" that runs within
protocol" that runs within the VPN. However, the way in which this the VPN. However, the way in which this knowledge is obtained is
knowledge is obtained is outside the scope of this document. outside the scope of this document.
The PEs also need to be able to forward traffic towards the C-RPs The PEs also need to be able to forward traffic towards the C-RPs
and/or C-RPAs, and to determine whether the next hop "interface" of and/or C-RPAs and to determine whether the next-hop interface of the
the route to a particular C-RP(A) is a VRF interface or a PMSI. This route to a particular C-RP(A) is a VRF interface or a PMSI. This is
is done by applying the procedures of [RFC6513] section 5.1. done by applying the procedures of [RFC6513], Section 5.1.
1.2.4. PMSI Instantiation Methods 1.2.4. PMSI Instantiation Methods
This document specifies three methods for using bidirectional This document specifies three methods for using bidirectional
P-tunnels to instantiate PMSIs: the Flat Partitioned Method, the P-tunnels to instantiate PMSIs: two partitioned methods (the Flat
Hierarchical Partitioned Method, and the Unpartitioned Method. Partitioned Method and the Hierarchical Partitioned Method) and the
Unpartitioned Method.
o Partitioned Methods o Partitioned Methods
In the Partitioned Methods, a particular PMSI is instantiated by a In the Partitioned Methods, a particular PMSI is instantiated by a
set of bidirectional P-tunnels. These P-tunnels may be aggregated set of bidirectional P-tunnels. These P-tunnels may be aggregated
(as "inner" P-tunnels) into a single "outer" bidirectional (as inner P-tunnels) into a single outer bidirectional P-tunnel
P-tunnel ("Hierarchical Partitioning"), or they may be ("Hierarchical Partitioning"), or they may be unaggregated ("Flat
unaggregated ("Flat Partitioning"). Any PE that joins one of Partitioning"). Any PE that joins one of these P-tunnels can
these P-tunnels can transmit a packet on it, and the packet will transmit a packet on it, and the packet will be received by all
be received by all the other PEs that have joined the P-tunnel. the other PEs that have joined the P-tunnel. For each such
For each such P-tunnel (each "inner" P-tunnel, in the case of P-tunnel (each inner P-tunnel, in the case of Hierarchical
Hierarchical Partitioning) there is one PE that is its Partitioning) there is one PE that is its distinguished PE. When
"distinguished PE". When a PE receives a packet from a given a PE receives a packet from a given P-tunnel, the PE can determine
P-tunnel, the PE can determine from the packet's encapsulation the from the packet's encapsulation the P-tunnel it has arrived on,
P-tunnel is has arrived on, and can thus infer the identity of the and it can thus infer the identity of the distinguished PE
distinguished PE associated with the packet. This association associated with the packet. This association plays an important
plays an important role in the treatment of the packet, as role in the treatment of the packet, as specified later on in this
specified later on in this document. document.
The number of P-tunnels needed (the number of "inner" P-tunnels The number of P-tunnels needed (the number of inner P-tunnels
needed, if Hierarchical Partitioning is used) depends upon a needed, if Hierarchical Partitioning is used) depends upon a
number of factors that are described later in this document. number of factors that are described later in this document.
The Hierarchical Partitioned Method requires the use of upstream- The Hierarchical Partitioned Method requires the use of upstream-
assigned MPLS labels ("PE Distinguisher Labels"), and requires the assigned MPLS labels (PE Distinguisher Labels) and requires the
use of the PE Distinguisher Labels attribute in BGP. The Flat use of the PE Distinguisher Labels attribute in BGP. The Flat
Partitioned Method requires neither of these. Partitioned Method requires neither of these.
The Partitioned Method (either flat or hierarchical) is a pre- The Partitioned Method (either Flat or Hierarchical) is a
requisite for implementing the "Partitioned Sets of PEs" technique prerequisite for implementing the "Partitioned Sets of PEs"
of supporting C-BIDIR, as discussed in [RFC6513] section 11.2. technique of supporting C-BIDIR, as discussed in [RFC6513],
The Partitioned Method (either flat or hierarchical) is also a Section 11.2. The Partitioned Method (either Flat or
pre-requisite for applying the "Discarding Packets from Wrong PE" Hierarchical) is also a prerequisite for applying the "Discarding
technique, discussed in [RFC6513] Section 9.1.1, to a PMSI that is Packets from Wrong PE" technique, discussed in [RFC6513], Section
instantiated by a bidirectional P-tunnel. 9.1.1, to a PMSI that is instantiated by a bidirectional P-tunnel.
The Flat Partitioned Method is a pre-requisite for implementing The Flat Partitioned Method is a prerequisite for implementing the
the "Partial Mesh of MP2MP P-tunnels" technique for carrying "Partial Mesh of MP2MP P-Tunnels" technique for carrying customer
customer bidirectional (C-BIDIR) traffic, as discussed in bidirectional (C-BIDIR) traffic, as discussed in [RFC6513],
[RFC6513] Section 11.2.3. Section 11.2.3.
The Hierarchical Partitioned Method is a pre-requisite for The Hierarchical Partitioned Method is a prerequisite for
implementing the "Using PE Distinguisher Labels" technique of implementing the "Using PE Distinguisher Labels" technique of
carrying customer bidirectional (C-BIDIR) traffic, as discussed in carrying customer bidirectional (C-BIDIR) traffic, as discussed in
[RFC6513] Section 11.2.2. [RFC6513], Section 11.2.2.
Note that a particular deployment may choose to use the Note that a particular deployment may choose to use the
Partitioned Method for carrying the C-BIDIR traffic on Partitioned Methods for carrying the C-BIDIR traffic on
bidirectional P-tunnels, while carrying other traffic either on bidirectional P-tunnels, while carrying other traffic either on
unidirectional P-tunnels, or on bidirectional P-tunnels using the unidirectional P-tunnels or on bidirectional P-tunnels using the
Unpartitioned Method. Routers in a given deployment must be Unpartitioned Method. Routers in a given deployment must be
provisioned to know which PMSI instantiation method to use for provisioned to know which PMSI instantiation method to use for
which PMSIs. which PMSIs.
There may be ways of implementing the Partitioned Method with There may be ways of implementing the Partitioned Methods with
PMSIs that are instantiated by unidirectional P-tunnels. (See, PMSIs that are instantiated by unidirectional P-tunnels. (See,
e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of the e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of the
current document. current document.
o Unpartitioned Method o Unpartitioned Method
In the Unpartitioned Method, a particular PMSI can be instantiated In the Unpartitioned Method, a particular PMSI can be instantiated
by a single bidirectional P-tunnel. Any PE that joins the tunnel by a single bidirectional P-tunnel. Any PE that joins the tunnel
can transmit a packet on it, and the packet will be received by can transmit a packet on it, and the packet will be received by
all the other PEs that have joined the tunnel. The receiving PEs all the other PEs that have joined the tunnel. The receiving PEs
can determine the tunnel on which the packet was transmitted, but can determine the tunnel on which the packet was transmitted, but
they cannot determine which PE transmitted the packet, nor can they cannot determine which PE transmitted the packet, nor can
they associate the packet with any particular "distinguished PE". they associate the packet with any particular distinguished PE.
When the Unpartitioned Method is used, this document does not When the Unpartitioned Method is used, this document does not
mandate that only one bidirectional P-tunnel be used to mandate that only one bidirectional P-tunnel be used to
instantiate each PMSI. It allows for the case where more than one instantiate each PMSI. It allows for the case where more than one
P-tunnel is used. In this case, the transmitting PEs will have a P-tunnel is used. In this case, the transmitting PEs will have a
choice of which such P-tunnel to use when transmitting, and the choice of which such P-tunnel to use when transmitting, and the
receiving PEs must be prepared to receive from any of those receiving PEs must be prepared to receive from any of those
P-tunnels. The use of multiple P-tunnels in this case provides P-tunnels. The use of multiple P-tunnels in this case provides
additional robustness, but no additional functionality. additional robustness, but it does not provide additional
functionality.
If bidirectional P-tunnels are being used to instantiate the PMSIs of If bidirectional P-tunnels are being used to instantiate the PMSIs of
a given MVPN, one of these methods must be chosen for that MVPN. All a given MVPN, one of these methods must be chosen for that MVPN. All
the PEs of that MVPN must be provisioned to know the method that is the PEs of that MVPN must be provisioned to know the method that is
being used for that MVPN. being used for that MVPN.
I-PMSIs may be instantiated by bidirectional P-tunnels using either I-PMSIs may be instantiated by bidirectional P-tunnels using either
the Partitioned (either Flat or Hierarchical) or the Unpartitioned the Partitioned (either Flat or Hierarchical) Methods or the
Method. The method used for a given MVPN is determined by Unpartitioned Method. The method used for a given MVPN is determined
provisioning. It SHOULD be possible to provision this on a per-MVPN by provisioning. It SHOULD be possible to provision this on a per-
basis, but all the VRFs of a single MVPN MUST be provisioned to use MVPN basis, but all the VRFs of a single MVPN MUST be provisioned to
the same method for the given MVPN's I-PMSI. use the same method for the given MVPN's I-PMSI.
If a bidirectional P-tunnel is used to instantiate an S-PMSI If a bidirectional P-tunnel is used to instantiate an S-PMSI
(including the case of a (C-*,C-*) S-PMSI), either the Partitioned (including the case of a (C-*,C-*) S-PMSI), either the Partitioned
Method (either Flat or Hierarchical) or the Unpartitioned Method may Methods (either Flat or Hierarchical) or the Unpartitioned Method may
be used. The method used by a given VRF is determined by be used. The method used by a given VRF is determined by
provisioning. It is desirable to be able to provision this on a per- provisioning. It is desirable to be able to provision this on a per-
MVPN basis. All the VRFs of a single MVPN MUST be provisioned to use MVPN basis. All the VRFs of a single MVPN MUST be provisioned to use
the same method for those of their S-PMSIs that are instantiated by the same method for those of their S-PMSIs that are instantiated by
bidirectional P-tunnels. bidirectional P-tunnels.
If the Partitioned Method is used, all the VRFs of a single MVPN MUST If one of the Partitioned Methods is used, all the VRFs of a single
be provisioned to use the same variant of the Partitioned Method, MVPN MUST be provisioned to use the same variant of the Partitioned
i.e., either they must all use the Flat Partitioned Method, or they Methods, i.e., either they must all use the Flat Partitioned Method
must all use the Hierarchical Partitioned Method. or they must all use the Hierarchical Partitioned Method.
It is valid to use the Unpartitioned Method to instantiate the It is valid to use the Unpartitioned Method to instantiate the
I-PMSIs, while using one of the Partitioned Methods to instantiate I-PMSIs, while using one of the Partitioned Methods to instantiate
the S-PMSIs. the S-PMSIs.
It is valid to instantiate some S-PMSIs by unidirectional P-tunnels It is valid to instantiate some S-PMSIs by unidirectional P-tunnels
and others by bidirectional P-tunnels. and others by bidirectional P-tunnels.
The procedures for the use of bidirectional P-tunnels, specified in The procedures for the use of bidirectional P-tunnels, specified in
subsequent sections of this document, depend on both the tunnel subsequent sections of this document, depend on both the tunnel
technology and on the PMSI instantiation method. Note that this technology and the PMSI instantiation method. Note that this
document does not necessarily specify procedures for every possible document does not specify procedures for every possible combination
combination of tunnel technology and PMSI instantiation method. of tunnel technology and PMSI instantiation method.
2. The All BIDIR-PIM Wild Card 2. The All BIDIR-PIM Wildcard
[RFC6514] specifies the method of encoding C-multicast source and [RFC6514] specifies the method of encoding C-multicast source and
group addresses into the NLRI of certain BGP routes. [RFC6625] group addresses into the NLRI of certain BGP routes. [RFC6625]
extends that specification by allowing the source and/or group extends that specification by allowing the source and/or group
address to be replaced by a wildcard. When an MVPN customer is using address to be replaced by a wildcard. When an MVPN customer is using
BIDIR-PIM, it is useful to be able to advertise an S-PMSI A-D route BIDIR-PIM, it is useful to be able to advertise an S-PMSI A-D route
whose semantics are: "by default, all BIDIR-PIM C-multicast traffic whose semantics are "by default, all BIDIR-PIM C-multicast traffic
(within a given VPN) that has not been bound to any other P-tunnel is (within a given VPN) that has not been bound to any other P-tunnel is
bound to the bidirectional P-tunnel identified by the PTA of this bound to the bidirectional P-tunnel identified by the PTA of this
route". This can be especially useful if one is using a route". This can be especially useful if one is using a
bidirectional P-tunnel to carry the C-BIDIR flows, while using bidirectional P-tunnel to carry the C-BIDIR flows while using
unidirectional P-tunnels to carry other C-flows. To do this, it is unidirectional P-tunnels to carry other C-flows. To do this, it is
necessary to have a way to encode a (C-*,C-*) wildcard that is necessary to have a way to encode a (C-*,C-*) wildcard that is
restricted to BIDIR-PIM C-groups. restricted to BIDIR-PIM C-groups.
We therefore define a special value of the group wildcard, whose Therefore, we define a special value of the group wildcard, whose
meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard" meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard"
is encoded as a group field whose length is 8 bits and whose value is is encoded as a group field whose length is 8 bits and whose value is
zero. That is, the "multicast group length" field contains the value zero. That is, the "multicast group length" field contains the value
0x08, and the "multicast group" field is a single octet containing 0x08, and the "multicast group" field is a single octet containing
the value 0x00. (This encoding is distinct from the group wildcard the value 0x00. (This encoding is distinct from the group wildcard
encoding defined in [RFC6625]). We will use the notation encoding defined in [RFC6625]). We will use the notation
(C-*,C-*-BIDIR) to refer to the "all BIDIR-PIM groups" wildcard. (C-*,C-*-BIDIR) to refer to the "all BIDIR-PIM groups" wildcard.
3. Using Bidirectional P-Tunnels 3. Using Bidirectional P-Tunnels
A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS
I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The
advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS
I-PMSI A-D route is outside the scope of this document. I-PMSI A-D route is outside the scope of this document.
3.1. Procedures Specific to the Tunneling Technology 3.1. Procedures Specific to the Tunneling Technology
This section discusses the procedures that are specific to a given This section discusses the procedures that are specific to a given
tunneling technology (BIDIR-PIM, or the MP2MP procedures of mLDP tunneling technology (BIDIR-PIM or the MP2MP procedures of mLDP
("Multipoint LDP")), but that are independent of the method (Multipoint LDP)) but that are independent of the method
(Unpartitioned, Flat Partitioned, or Hierarchical Partitioned) used (Unpartitioned, Flat Partitioned, or Hierarchical Partitioned) used
to instantiate a PMSI. to instantiate a PMSI.
3.1.1. BIDIR-PIM P-Tunnels 3.1.1. BIDIR-PIM P-Tunnels
Each BIDIR-PIM P-Tunnel is identified by a unique P-group address Each BIDIR-PIM P-tunnel is identified by a unique P-group address
([RFC6513], section 3.1). (The P-group address is called a ([RFC6513], Section 3.1). (The P-group address is called a
"P-Multicast Group" in [RFC6514]). Section 5 of [RFC6514] specifies "P-Multicast Group" in [RFC6514]). Section 5 of [RFC6514] specifies
the way to identify a particular BIDIR-PIM P-tunnel in the PTA of an the way to identify a particular BIDIR-PIM P-tunnel in the PTA of an
I-PMSI or S-PMSI A-D route. I-PMSI or S-PMSI A-D route.
Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM
P-tunnels. A BIDIR-PIM P-group address is always associated with a P-tunnels. A BIDIR-PIM P-group address is always associated with a
unique "Rendezvous Point Address" (RPA) in the SP's address space. unique Rendezvous Point Address (RPA) in the SP's address space. We
We will refer to this as the "P-RPA". Every PE needing to join a will refer to this as the "P-RPA". Every PE needing to join a
particular BIDIR-PIM P-tunnel must be able to determine the P-RPA particular BIDIR-PIM P-tunnel must be able to determine the P-RPA
that corresponds to the P-tunnel's P-group address. To construct the that corresponds to the P-tunnel's P-group address. To construct the
P-tunnel, PIM Join/Prune messages are sent along the path from the PE P-tunnel, PIM Join/Prune messages are sent along the path from the PE
to the P-RPA. Any P routers along that path must also be able to to the P-RPA. Any P routers along that path must also be able to
determine the P-RPA, so that they too can send PIM Join/Prune determine the P-RPA, so that they too can send PIM Join/Prune
messages towards it. The method of mapping a P-group address to an messages towards it. The method of mapping a P-group address to an
RPA may be static configuration, or some automated means of RPA RPA may be static configuration, or some automated means of RPA
discovery that is outside the scope of this specification. discovery that is outside the scope of this specification.
If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an
skipping to change at page 15, line 51 skipping to change at page 16, line 43
more complex. more complex.
The use of BIDIR-PIM P-tunnels to support the Hierarchical The use of BIDIR-PIM P-tunnels to support the Hierarchical
Partitioned Method is outside the scope of this document. Partitioned Method is outside the scope of this document.
When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route
identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT
include a PE Distinguisher Labels attribute. If it does, that include a PE Distinguisher Labels attribute. If it does, that
attribute MUST be ignored. When we say the attribute is "ignored", attribute MUST be ignored. When we say the attribute is "ignored",
we do not mean that its normal BGP processing is not done, but that we do not mean that its normal BGP processing is not done, but that
the attribute has no effect on the data plane. It MUST however be the attribute has no effect on the data plane. However, it MUST be
treated by BGP as if it were an unsupported optional transitive treated by BGP as if it were an unsupported optional transitive
attribute. (PE Distinguisher Labels are used for the Hierarchical attribute. (PE Distinguisher Labels are used for the Hierarchical
Partitioning Method, but this document does not provide support for Partitioning Method, but this document does not provide support for
the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.) the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.)
3.1.2. MP2MP LSPs 3.1.2. MP2MP LSPs
Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding
Equivalence Class) element" [RFC6388]. The FEC element contains the Equivalence Class) element" [RFC6388]. The FEC element contains the
IP address of the root node, followed by an opaque value that IP address of the root node, followed by an opaque value that
skipping to change at page 16, line 37 skipping to change at page 17, line 34
Section 5 of [RFC6514] specifies the way to identify a particular Section 5 of [RFC6514] specifies the way to identify a particular
MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route. MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route.
Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP
LSP. LSP.
3.2. Procedures Specific to the PMSI Instantiation Method 3.2. Procedures Specific to the PMSI Instantiation Method
When either the Flat Partitioned Method or the Hierarchical When either the Flat Partitioned Method or the Hierarchical
Partitioned Method is used to implement the "Partitioned Sets of PEs" Partitioned Method is used to implement the "Partitioned Sets of PEs"
method of supporting C-BIDIR, as discussed in section 11.2 of method of supporting C-BIDIR, as discussed in Section 11.2 of
[RFC6513] and section 3.6 of [RFC6517], a C-BIDIR flow MUST be [RFC6513] and Section 3.6 of [RFC6517], a C-BIDIR flow MUST be
carried only on an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR), carried only on an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR),
or (C-*,C-*) S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR) or (C-*,C-*) S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR)
S-PMSI A-D routes. (Though it may of course originate (C-S,C-G) S-PMSI A-D routes. (Though it may, of course, originate (C-S,C-G)
S-PMSI A-D routes for C-G's that are not C-BIDIR groups.) Packets of S-PMSI A-D routes for C-G's that are not C-BIDIR groups.) Packets of
a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI. a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI.
Section 3.2.1 and Section 3.2.2 specify additional details of the two Sections 3.2.1 and 3.2.2 specify additional details of the two
Partitioned Methods. Partitioned Methods.
3.2.1. Flat Partitioning 3.2.1. Flat Partitioning
The procedures of this section and its sub-sections apply when (and The procedures of this section and its subsections apply when (and
only when) the Flat Partitioned Method is used. This method is only when) the Flat Partitioned Method is used. This method is
introduced in [RFC6513] Section 11.2.3, where it is called "Partial introduced in [RFC6513], Section 11.2.3, where it is called "Partial
Mesh of MP2MP P-tunnels". This method can be used with MP2MP LSPs or Mesh of MP2MP P-Tunnels". This method can be used with MP2MP LSPs or
with BIDIR-PIM P-tunnels. with BIDIR-PIM P-tunnels.
When a PE originates an I-PMSI or S-PMSI A-D route whose PTA When a PE originates an I-PMSI or S-PMSI A-D route whose PTA
specifies a bidirectional P-tunnel, the PE MUST be the root node of specifies a bidirectional P-tunnel, the PE MUST be the root node of
the specified P-tunnel. the specified P-tunnel.
If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a
distinct P-group address. The PE advertising the tunnel will be distinct P-group address. The PE advertising the tunnel will be
considered to be the root node of the tunnel. Note that this creates considered to be the root node of the tunnel. Note that this creates
a unique mapping from P-group address to root node. The assignment a unique mapping from P-group address to root node. The assignment
of P-group addresses to MVPNs is by provisioning. of P-group addresses to MVPNs is by provisioning.
If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC
(i.e., distinct combination of root node and opaque value). The PE (i.e., a distinct combination of root node and opaque value). The PE
advertising the tunnel MUST be the same PE identified in the root advertising the tunnel MUST be the same PE identified in the root
node field of the MP2MP FEC that is encoded in the PTA. node field of the MP2MP FEC that is encoded in the PTA.
It follows that two different PEs may not advertise the same It follows that two different PEs may not advertise the same
bidirectional P-tunnel. Any PE that receives a packet from the bidirectional P-tunnel. Any PE that receives a packet from the
P-tunnel can infer the identity of the P-tunnel from the packet's P-tunnel can infer the identity of the P-tunnel from the packet's
encapsulation. Once the identity of the P-tunnel is known, the root encapsulation. Once the identity of the P-tunnel is known, the root
node of the P-tunnel is also known. The root node of the P-tunnel on node of the P-tunnel is also known. The root node of the P-tunnel on
which the packet arrived is treated as the "distinguished PE" for which the packet arrived is treated as the distinguished PE for that
that packet. packet.
The Flat Partitioned Method does not use upstream-assigned labels in The Flat Partitioned Method does not use upstream-assigned labels in
the data plane, and hence does not use the BGP PE Distinguisher the data plane, and hence does not use the BGP PE Distinguisher
Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D
routes SHOULD NOT contain a PE Distinguisher Labels attribute; if routes SHOULD NOT contain a PE Distinguisher Labels attribute; if
such an attribute is present in a received I-PMSI or S-PMSI A-D such an attribute is present in a received I-PMSI or S-PMSI A-D
route, it MUST be ignored. (When we say the attribute is "ignored", route, it MUST be ignored. (When we say the attribute is "ignored",
we do not mean that its normal BGP processing is not done, but that we do not mean that its normal BGP processing is not done, but that
the attribute has no effect on the data plane. It MUST however be the attribute has no effect on the data plane. It MUST, however, be
treated by BGP as if it were an unsupported optional transitive treated by BGP as if it were an unsupported optional transitive
attribute.) attribute.)
When the Flat Partitioned Method is used to instantiate the I-PMSIs When the Flat Partitioned Method is used to instantiate the I-PMSIs
of a given MVPN, every PE in that MVPN that originates an Intra-AS of a given MVPN, every PE in that MVPN that originates an Intra-AS
I-PMSI A-D route MUST include a PTA that specifies a bidirectional I-PMSI A-D route MUST include a PTA that specifies a bidirectional
P-tunnel. If the intention is to carry C-BIDIR traffic on the P-tunnel. If the intention is to carry C-BIDIR traffic on the
I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of
its VRF interfaces is the next hop interface on its best path to the its VRF interfaces is the next-hop interface on its best path to the
C-RPA of any bidirectional C-group of the MVPN. C-RPA of any bidirectional C-group of the MVPN.
When the Flat Partitioned Method is used to instantiate a (C-*,C-*) When the Flat Partitioned Method is used to instantiate a (C-*,C-*)
S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE
that originates the corresponding S-PMSI A-D route MUST include in that originates the corresponding S-PMSI A-D route MUST include in
that route a PTA specifying a bidirectional P-tunnel. Per the that route a PTA specifying a bidirectional P-tunnel. Per the
procedures of [RFC6513] and [RFC6514], a PE will originate such an procedures of [RFC6513] and [RFC6514], a PE will originate such an
S-PMSI A-D route only if one of the PE's VRF interfaces is the next S-PMSI A-D route only if one of the PE's VRF interfaces is the next-
hop interface of the PE's best path to the C-RPA of a C-BIDIR group hop interface of the PE's best path to the C-RPA of a C-BIDIR group
that is to be carried on the specified S-PMSI. that is to be carried on the specified S-PMSI.
PMSIs that are instantiated via the Flat Partitioned Method may carry PMSIs that are instantiated via the Flat Partitioned Method may carry
customer bidirectional traffic AND customer unidirectional traffic. customer bidirectional traffic AND customer unidirectional traffic.
The rules of Section 3.2.1.1 and Section 3.2.1.2 determine when a The rules of Sections 3.2.1.1 and 3.2.1.2 determine when a given
given customer multicast packet is a match for transmission to a customer multicast packet is a match for transmission to a given
given PMSI. However, if the "Partitioned Set of PEs" method of PMSI. However, if the "Partitioned Set of PEs" method of supporting
supporting C-BIDIR traffic is being used for a given MVPN, the PEs C-BIDIR traffic is being used for a given MVPN, the PEs must be
must be provisioned in such a way that packets from a C-BIDIR flow of provisioned in such a way that packets from a C-BIDIR flow of that
that MVPN never match any PMSI that is not instantiated by a MVPN never match any PMSI that is not instantiated by a bidirectional
bidirectional P-tunnel. (For example, if the given MVPN's (C-*,C-*) P-tunnel. (For example, if the given MVPN's (C-*,C-*) S-PMSI were
S-PMSI were not instantiated by a bidirectional P-tunnel, one could not instantiated by a bidirectional P-tunnel, one could meet this
meet this requirement by carrying all C-BIDIR traffic of that MVPN on requirement by carrying all C-BIDIR traffic of that MVPN on a
a (C-*,C-*-BIDIR) S-PMSI.) (C-*,C-*-BIDIR) S-PMSI.)
When a PE receives a customer multicast data packet from a When a PE receives a customer multicast data packet from a
bidirectional P-tunnel, it associates that packet with a bidirectional P-tunnel, it associates that packet with a
"distinguished PE". The distinguished PE for a given packet is the distinguished PE. The distinguished PE for a given packet is the
root node of the tunnel from which the packet is received. The rules root node of the tunnel from which the packet is received. The rules
of Section 3.2.1.1 and Section 3.2.1.2 ensure that: of Sections 3.2.1.1 and 3.2.1.2 ensure that:
o If the received packet is part of a unidirectional C-flow, its o If the received packet is part of a unidirectional C-flow, its
"distinguished PE" is the PE that transmitted the packet onto the distinguished PE is the PE that transmitted the packet onto the
P-tunnel. P-tunnel.
o If the received packet is part of a bidirectional C-flow, its o If the received packet is part of a bidirectional C-flow, its
"distinguished PE" is not necessarily the PE that transmitted it, distinguished PE is not necessarily the PE that transmitted it,
but rather the transmitter's "upstream PE" for the C-RPA of the but rather the transmitter's upstream PE [RFC6513] for the C-RPA
bidirectional C-group. of the bidirectional C-group.
The rules of Section 3.2.1.3 and Section 3.2.1.4 allow the receiving The rules of Sections 3.2.1.3 and 3.2.1.4 allow the receiving PEs to
PEs to determine the expected distinguished PE for each C-flow, and determine the expected distinguished PE for each C-flow, and ensure
ensure that a packet will be discarded if its distinguished PE is not that a packet will be discarded if its distinguished PE is not the
the expected distinguished PE for the C-flow to which the packet expected distinguished PE for the C-flow to which the packet belongs.
belongs. This prevents duplication of data for both bidirectional This prevents duplication of data for both bidirectional and
and unidirectional C-flows. unidirectional C-flows.
3.2.1.1. When an S-PMSI is a 'Match for Transmission' 3.2.1.1. When an S-PMSI Is a 'Match for Transmission'
Suppose a given PE, say PE1, needs to transmit multicast data packets Suppose a given PE, say PE1, needs to transmit multicast data packets
of a particular C-flow. [RFC6625] Section 3.1 gives a four-step of a particular C-flow. Section 3.1 of [RFC6625] gives a four-step
algorithm for determining the S-PMSI A-D route, if any, that matches algorithm for determining the S-PMSI A-D route, if any, that matches
that C-flow for transmission. that C-flow for transmission.
If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged; If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged;
the remainder of this section applies only to C-BIDIR flows. If a the remainder of this section applies only to C-BIDIR flows. If a
C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1
are given below: are given below:
o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's
route to the C-RPA is via a VRF interface, then: route to the C-RPA is via a VRF interface, then:
skipping to change at page 19, line 47 skipping to change at page 20, line 40
route originated by PE2, then the C-flow matches that route. route originated by PE2, then the C-flow matches that route.
* Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D route * Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D route
originated by PE2, then the C-flow matches that route. originated by PE2, then the C-flow matches that route.
If there is an S-PMSI A-D route that matches a given C-flow, and if If there is an S-PMSI A-D route that matches a given C-flow, and if
PE1 needs to transmit packets of that C-flow or other PEs, then it PE1 needs to transmit packets of that C-flow or other PEs, then it
MUST transmit those packets on the bidirectional P-tunnel identified MUST transmit those packets on the bidirectional P-tunnel identified
in the PTA of the matching S-PMSI A-D route. in the PTA of the matching S-PMSI A-D route.
3.2.1.2. When an I-PMSI is a 'Match for Transmission' 3.2.1.2. When an I-PMSI Is a 'Match for Transmission'
Suppose a given PE, say PE1, needs to transmit packets of a given Suppose a given PE, say PE1, needs to transmit packets of a given
C-flow (of a given MVPN) to other PEs, but according to the C-flow (of a given MVPN) to other PEs, but according to the
conditions of Section 3.2.1.1 and/or [RFC6625] section 3.1, that conditions of Section 3.2.1.1 and/or Section 3.1 of [RFC6625], that
C-flow does not match any S-PMSI A-D route. Then the packets of the C-flow does not match any S-PMSI A-D route. Then, the packets of the
C-flow need to be transmitted on the MVPN's I-PMSI. C-flow need to be transmitted on the MVPN's I-PMSI.
If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the
C-flow MUST be transmitted is the one identified in the PTA of the C-flow MUST be transmitted is the one identified in the PTA of the
Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN.
If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the
rules applied by PE1 are: rules applied by PE1 are:
o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's o Suppose that the C-RPA for C-G-BIDIR is a C-address of PE1, or
route to the C-RPA is via a VRF interface, then if there is an that PE1's route to the C-RPA is via a VRF interface. Then, if
I-PMSI A-D route currently originated by PE1, then the C-flow MUST there is an I-PMSI A-D route currently originated by PE1, the
be transmitted on the P-tunnel identified in the PTA of that C-flow MUST be transmitted on the P-tunnel identified in the PTA
I-PMSI A-D route. of that I-PMSI A-D route.
o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some
other PE, say PE2, then if there is an installed I-PMSI A-D route other PE, say PE2, then if there is an installed I-PMSI A-D route
originated by PE2, the C-flow MUST be transmitted on the P-tunnel originated by PE2, the C-flow MUST be transmitted on the P-tunnel
identified in the PTA of that route. identified in the PTA of that route.
If there is no I-PMSI A-D route meeting the above conditions, the If there is no I-PMSI A-D route meeting the above conditions, the
C-flow MUST NOT be transmitted. C-flow MUST NOT be transmitted.
3.2.1.3. When an S-PMSI is a 'Match for Reception' 3.2.1.3. When an S-PMSI Is a 'Match for Reception'
Suppose a given PE, say PE1, needs to receive multicast data packets Suppose a given PE, say PE1, needs to receive multicast data packets
of a particular C-flow. [RFC6625] Section 3.2 specifies procedures of a particular C-flow. Section 3.2 of [RFC6625] specifies
for determining the S-PMSI A-D route, if any, that matches that procedures for determining the S-PMSI A-D route, if any, that matches
C-flow for reception. Those rules apply unchanged for C-flows that that C-flow for reception. Those rules apply unchanged for C-flows
are not BIDIR-PIM C-flows. The remainder of this section applies that are not BIDIR-PIM C-flows. The remainder of this section
only to C-BIDIR flows. applies only to C-BIDIR flows.
The rules of [RFC6625] Section 3.2.1 are not applicable to C-BIDIR The rules of [RFC6625], Section 3.2.1, are not applicable to C-BIDIR
flows. The rules of [RFC6625] Section 3.2.2 are replaced by the flows. The rules of [RFC6625], Section 3.2.2, are replaced by the
following rules. following rules.
Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also
that PE1 has determined that PE2 is the "upstream PE" [RFC6513] for that PE1 has determined that PE2 is the upstream PE [RFC6513] for the
the C-RPA of C-G-BIDIR. Then: C-RPA of C-G-BIDIR. Then:
o If PE1 is not the same as PE2, and PE1 has an installed o If PE1 is not the same as PE2, and PE1 has an installed (C-*,C-G-
(C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR)
(C-*,C-G-BIDIR) matches this route. matches this route.
o Otherwise, if PE1 is the same as PE2, and PE1 has currently o Otherwise, if PE1 is the same as PE2, and PE1 has currently
originated a (C-*,C-G-BIDIR) S-PMSI A-D route, then originated a (C-*,C-G-BIDIR) S-PMSI A-D route, then
(C-*,C-G-BIDIR) matches this route. (C-*,C-G-BIDIR) matches this route.
o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed
(C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then
(C-*,C-G-BIDIR) matches this route. (C-*,C-G-BIDIR) matches this route.
o Otherwise, if PE1 is the same as PE2, and PE1 has currently o Otherwise, if PE1 is the same as PE2, and PE1 has currently
skipping to change at page 21, line 23 skipping to change at page 22, line 19
o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed
(C-*,C-*) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) (C-*,C-*) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR)
matches this route. matches this route.
o Otherwise, if PE1 is the same as PE2, and PE1 has currently o Otherwise, if PE1 is the same as PE2, and PE1 has currently
originated a (C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR) originated a (C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR)
matches this route. matches this route.
If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according
to these rules, the root node of that P-tunnel is considered to be to these rules, the root node of that P-tunnel is considered to be
the "distinguished PE" for that (C-*,C-G-BIDIR) flow. If a the distinguished PE for that (C-*,C-G-BIDIR) flow. If a
(C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is (C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is
not the distinguished PE for the C-flow, the packet MUST be not the distinguished PE for the C-flow, the packet MUST be
discarded. discarded.
3.2.1.4. When an I-PMSI is a 'Match for Reception 3.2.1.4. When an I-PMSI Is a 'Match for Reception'
Suppose a given PE, say PE1, needs to receive packets of a given Suppose a given PE, say PE1, needs to receive packets of a given
C-flow (of a given MVPN) from another PE, but according to the C-flow (of a given MVPN) from another PE, but according to the
conditions of Section 3.2.1.3 and/or [RFC6625] section 3.2, that conditions of Section 3.2.1.3 and/or Section 3.2 of [RFC6625], that
C-flow does not match any S-PMSI A-D route. Then the packets of the C-flow does not match any S-PMSI A-D route. Then, the packets of the
C-flow need to be received on the MVPN's I-PMSI. C-flow need to be received on the MVPN's I-PMSI.
If the C-flow is not a BIDIR-PIM C-flow, the rules for determining If the C-flow is not a BIDIR-PIM C-flow, the rules for determining
the P-tunnel on which packets of the C-flow are expected are given in the P-tunnel on which packets of the C-flow are expected are given in
[RFC6513]. The remainder of this section applies only to C-BIDIR [RFC6513]. The remainder of this section applies only to C-BIDIR
flows. flows.
Suppose that PE1 needs to receive (C-*,C-G-BIDIR) traffic from other Suppose that PE1 needs to receive (C-*,C-G-BIDIR) traffic from other
PEs. Suppose also that PE1 has determined that PE2 is the "upstream PEs. Suppose also that PE1 has determined that PE2 is the upstream
PE" [RFC6513] for the C-RPA of C-G-BIDIR. Then PE1 considers PE2 to PE [RFC6513] for the C-RPA of C-G-BIDIR. Then, PE1 considers PE2 to
be the "distinguished PE" for (C-*,C-G-BIDIR). If PE1 has an be the distinguished PE for (C-*,C-G-BIDIR). If PE1 has an installed
installed Intra-AS I-PMSI A-D route originated by PE2, PE1 will Intra-AS I-PMSI A-D route originated by PE2, PE1 will expect to
expect to receive packets of the C-flow from the tunnel specified in receive packets of the C-flow from the tunnel specified in that
that route's PTA. (If all VRFs of the MVPN have been properly route's PTA. (If all VRFs of the MVPN have been properly provisioned
provisioned to use the Flat Partitioned Method for the I-PMSI, the to use the Flat Partitioned Method for the I-PMSI, the PTA will
PTA will specify a bidirectional P-tunnel.) Note that if PE1 is the specify a bidirectional P-tunnel.) Note that if PE1 is the same as
same as PE2, then the relevant Intra-AS I-PMSI A-D route is the one PE2, then the relevant Intra-AS I-PMSI A-D route is the one currently
currently originated by PE1. originated by PE1.
If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the
expected one, packet MUST be discarded. expected one, the packet MUST be discarded.
3.2.2. Hierarchical Partitioning 3.2.2. Hierarchical Partitioning
The procedures of this section and its sub-sections apply when (and The procedures of this section and its subsections apply when (and
only when) the Hierarchical Partitioned Method is used. This method only when) the Hierarchical Partitioned Method is used. This method
is introduced in [RFC6513] Section 11.2.2. This document only is introduced in [RFC6513], Section 11.2.2. This document only
provides procedures for using this method when using MP2MP LSPs as provides procedures for using this method when using MP2MP LSPs as
the P-tunnels. the P-tunnels.
The Hierarchical Partitioned Method provides the same functionality The Hierarchical Partitioned Method provides the same functionality
as the Flat Partitioned Method, but requires a smaller amount of as the Flat Partitioned Method, but it requires a smaller amount of
state to be maintained in the core of the network. However, it state to be maintained in the core of the network. However, it
requires the use of upstream-assigned MPLS labels ("PE Distinguisher requires the use of upstream-assigned MPLS labels ("PE Distinguisher
Labels"), which are not necessarily supported by all hardware Labels"), which are not necessarily supported by all hardware
platforms. The upstream-assigned labels are used to provide an LSP platforms. The upstream-assigned labels are used to provide an LSP
hierarchy, in which an "outer" MP2MP LSP carries multiple "inner" hierarchy, in which an outer MP2MP LSP carries multiple inner MP2MP
MP2MP LSPs. Transit routers along the path between PE routers then LSPs. Transit routers along the path between PE routers then only
only need to maintain state for the outer MP2MP LSP. need to maintain state for the outer MP2MP LSP.
When this method is used to instantiate a particular PMSI, the When this method is used to instantiate a particular PMSI, the
bidirectional P-tunnel advertised in the PTA of the corresponding bidirectional P-tunnel advertised in the PTA of the corresponding
I-PMSI or S-PMSI A-D route is the "outer" P-tunnel. When a packet is I-PMSI or S-PMSI A-D route is the outer P-tunnel. When a packet is
received from a P-tunnel, the PE that receives it can infer the received from a P-tunnel, the PE that receives it can infer the
identity of the outer P-tunnel from the MPLS label that has risen to identity of the outer P-tunnel from the MPLS label that has risen to
the top of the packet's label stack. However, the packet's the top of the packet's label stack. However, the packet's
"distinguished PE" is not necessarily the root node of the the outer distinguished PE is not necessarily the root node of the outer
P-tunnel. Rather, the identity of the packet's distinguished PE is P-tunnel. Rather, the identity of the packet's distinguished PE is
inferred from the PE Distinguisher Label further down in the label inferred from the PE Distinguisher Label further down in the label
stack. (See [RFC6513] Section 12.3.) The PE Distinguisher Label may stack. (See [RFC6513], Section 12.3.) The PE Distinguisher Label
be thought of as identifying an "inner" MP2MP LSP whose root is the may be thought of as identifying an inner MP2MP LSP whose root is the
PE corresponding to that label. PE corresponding to that label.
In the context of a given MVPN, if it is desired to use the In the context of a given MVPN, if it is desired to use the
Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*) Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*)
S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes
MUST be originated by some of the PEs that attach to that MVPN. The MUST be originated by some of the PEs that attach to that MVPN. The
PEs that are REQUIRED to originate these routes are those that PEs that are REQUIRED to originate these routes are those that
satisfy one of the following conditions: satisfy one of the following conditions:
o There is a C-BIDIR group for which the best path from the PE to o There is a C-BIDIR group for which the best path from the PE to
the C-RPA of that C-group is via a VRF interface, or the C-RPA of that C-group is via a VRF interface.
o The PE might have to transmit unidirectional customer multicast o The PE might have to transmit unidirectional customer multicast
traffic on the PMSI identified in the route (of course this traffic on the PMSI identified in the route (of course this
condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR) condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR)
S-PMSIs). S-PMSIs).
o The PE is the root node of the MP2MP LSP that is used to o The PE is the root node of the MP2MP LSP that is used to
instantiate the PMSI. instantiate the PMSI.
When the Hierarchical Partitioned method is used to instantiate a When the Hierarchical Partitioned method is used to instantiate a
skipping to change at page 23, line 37 skipping to change at page 24, line 34
I-PMSI, one can minimize the amount of state in the transit nodes. I-PMSI, one can minimize the amount of state in the transit nodes.
By allowing them to specify different outer tunnels, one uses more By allowing them to specify different outer tunnels, one uses more
state, but may increase the robustness of the system. state, but may increase the robustness of the system.
The considerations of the previous paragraph apply as well when the The considerations of the previous paragraph apply as well when the
Hierarchical Partitioned Method is used to instantiate an S-PMSI. Hierarchical Partitioned Method is used to instantiate an S-PMSI.
3.2.2.1. Advertisement of PE Distinguisher Labels 3.2.2.1. Advertisement of PE Distinguisher Labels
A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331] A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331]
that can be used, in the context of a MP2MP LSP, to denote a that can be used, in the context of an MP2MP LSP, to denote a
particular PE that either has joined or may in the future join that particular PE that either has joined or may in the future join that
LSP. LSP.
In order to use upstream-assigned MPLS labels in the context of an In order to use upstream-assigned MPLS labels in the context of an
"outer" MP2MP LSP, there must be a convention that identifies a outer MP2MP LSP, there must be a convention that identifies a
particular router as the router that is responsible for allocating particular router as the router that is responsible for allocating
the labels and for advertising the labels to the PEs that may join the labels and for advertising the labels to the PEs that may join
the MP2MP LSP. This document REQUIRES that the PE Distinguisher the MP2MP LSP. This document REQUIRES that the PE Distinguisher
Labels used in the context of a given MP2MP LSP be allocated and Labels used in the context of a given MP2MP LSP be allocated and
advertised by the router that is the root node of the LSP. advertised by the router that is the root node of the LSP.
This convention accords with the rules of section 7 of [RFC5331]. This convention accords with the rules of Section 7 of [RFC5331].
Note that according to section 7 of [RFC5331], upstream-assigned Note that according to Section 7 of [RFC5331], upstream-assigned
labels are unique in the context of the IP address of the root node; labels are unique in the context of the IP address of the root node;
if two MP2MP LSPs have the same root node IP address, the upstream- if two MP2MP LSPs have the same root node IP address, the upstream-
assigned labels used within the two LSPs come from the same label assigned labels used within the two LSPs come from the same label
space. space.
This document assumes that the root node address of an MP2MP LSP is This document assumes that the root node address of an MP2MP LSP is
an IP address that is uniquely assigned to the node. The use of an an IP address that is uniquely assigned to the node. The use of an
"anycast address" as the root node address is outside the scope of "anycast address" as the root node address is outside the scope of
this document. this document.
A PE Distinguisher Labels attribute SHOULD NOT be attached to an A PE Distinguisher Labels attribute SHOULD NOT be attached to an
I-PMSI or S-PMSI A-D route unless that route also contains a PTA that I-PMSI or S-PMSI A-D route unless that route also contains a PTA that
specifies an MP2MP LSP. (While PE Distinguisher Labels could in specifies an MP2MP LSP. (While PE Distinguisher Labels could in
theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such
use is outside the scope of this document.) use is outside the scope of this document.)
The PE Distinguisher Labels attribute specifies a set of <MPLS label, The PE Distinguisher Labels attribute specifies a set of <MPLS label,
IP address> bindings. Within a given PE Distinguisher Labels IP address> bindings. Within a given PE Distinguisher Labels
attribute, each such IP address MUST appear at most once, and each attribute, each such IP address MUST appear at most once, and each
MPLS label MUST appear only once. Otherwise the attribute is MPLS label MUST appear only once. Otherwise, the attribute is
considered to be malformed, and the "treat-as-withdraw" error- considered to be malformed, and the "treat-as-withdraw" error-
handling approach described in Section 2 of [BGP-ERROR] MUST be used. handling approach described in Section 2 of [BGP-ERROR] MUST be used.
When a PE Distinguisher Labels attribute is included in a given When a PE Distinguisher Labels attribute is included in a given
I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address
of each of the following PEs: of each of the following PEs:
o The root node of the MP2MP LSP identified in the PTA of the route, o The root node of the MP2MP LSP identified in the PTA of the route.
o Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR o Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR
group. group.
o Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP o Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP
LSP identified in the PTA of the route. LSP identified in the PTA of the route.
One simple way to meet these requirements is to assign a PE One simple way to meet these requirements is to assign a PE
Distinguisher label to every PE that has originated an Intra-AS Distinguisher label to every PE that has originated an Intra-AS
I-PMSI A-D route. I-PMSI A-D route.
3.2.2.2. When an S-PMSI is a 'Match for Transmission' 3.2.2.2. When an S-PMSI Is a 'Match for Transmission'
Suppose a given PE, say PE1, needs to transmit multicast data packets Suppose a given PE, say PE1, needs to transmit multicast data packets
of a particular C-flow. [RFC6625] Section 3.1 gives a four-step of a particular C-flow. Section 3.1 of [RFC6625] gives a four-step
algorithm for determining the S-PMSI A-D route, if any, that matches algorithm for determining the S-PMSI A-D route, if any, that matches
that C-flow for transmission. that C-flow for transmission.
If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged. If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged.
If there is a matching S-PMSI A-D route, the P-tunnel on which the If there is a matching S-PMSI A-D route, the P-tunnel on which the
C-flow MUST be transmitted is the one identified in the PTA of the C-flow MUST be transmitted is the one identified in the PTA of the
matching route. Each packet of the C-flow MUST carry the PE matching route. Each packet of the C-flow MUST carry the PE
Distinguisher Label assigned by the root node of that P-tunnel to the Distinguisher Label assigned by the root node of that P-tunnel to the
IP address of PE1. See section 12.3 of [RFC6513] for encapsulation IP address of PE1. See Section 12.3 of [RFC6513] for encapsulation
details. details.
The remainder of this section applies only to C-BIDIR flows. If a The remainder of this section applies only to C-BIDIR flows. If a
C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1
are the same as the rules given in Section 3.2.1.1. are the same as the rules given in Section 3.2.1.1.
If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow
on the P-tunnel identified in its PTA. Suppose PE1 has determined on the P-tunnel identified in its PTA. Suppose PE1 has determined
that PE2 is the upstream PE for the C-RPA of the given C-flow. In that PE2 is the upstream PE for the C-RPA of the given C-flow. In
constructing the packet's MPLS label stack, PE1 must use the PE constructing the packet's MPLS label stack, PE1 must use the PE
Distinguisher Label that was assigned by the P-tunnel's root node to Distinguisher Label that was assigned by the P-tunnel's root node to
the IP address of "PE2", not the label assigned to the IP address of the IP address of "PE2", not the label assigned to the IP address of
"PE1" (unless, of course, PE1 is the same as PE2). See section 12.3 "PE1" (unless, of course, PE1 is the same as PE2). See Section 12.3
of [RFC6513] for encapsulation details. Note that the root of the of [RFC6513] for encapsulation details. Note that the root of the
P-tunnel might be a PE other than PE1 or PE2. P-tunnel might be a PE other than PE1 or PE2.
3.2.2.3. When an I-PMSI is a 'Match for Transmission' 3.2.2.3. When an I-PMSI Is a 'Match for Transmission'
Suppose a given PE, say PE1, needs to transmit packets of a given Suppose a given PE, say PE1, needs to transmit packets of a given
C-flow (of a given MVPN) to other PEs, but according to the C-flow (of a given MVPN) to other PEs, but according to the
conditions of Section 3.2.2.2 and/or [RFC6625] section 3.1, that conditions of Section 3.2.2.2 and/or Section 3.1 of [RFC6625], that
C-flow does not match any S-PMSI A-D route. Then the packets of the C-flow does not match any S-PMSI A-D route. Then the packets of the
C-flow need to be transmitted on the MVPN's I-PMSI. C-flow need to be transmitted on the MVPN's I-PMSI.
If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the
C-flow MUST be transmitted is the one identified in the PTA of the C-flow MUST be transmitted is the one identified in the PTA of the
Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each
packet of the C-flow MUST carry the PE Distinguisher Label assigned packet of the C-flow MUST carry the PE Distinguisher Label assigned
by the root node of that P-tunnel to the IP address of PE1. by the root node of that P-tunnel to the IP address of PE1.
If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the
rules as applied by PE1 are the same as those given in rules as applied by PE1 are the same as those given in Section
Section 3.2.1.2. 3.2.1.2.
If there is a matching I-PMSI A-D route, PE1 MUST transmit the C-flow If there is a matching I-PMSI A-D route, PE1 MUST transmit the C-flow
on the P-tunnel identified in its PTA. In constructing the packet's on the P-tunnel identified in its PTA. In constructing the packet's
MPLS label stack, it must use the PE Distinguisher Label that was MPLS label stack, it must use the PE Distinguisher Label that was
assigned by the P-tunnel's root node to the IP address of "PE2", not assigned by the P-tunnel's root node to the IP address of "PE2", not
the label assigned to the IP address of "PE1" (unless, of course, PE1 the label assigned to the IP address of "PE1" (unless, of course, PE1
is the same as PE2). (Section 3.2.1.2 specifies the difference is the same as PE2). (Section 3.2.1.2 specifies the difference
between PE1 and PE2.) See section 12.3 of [RFC6513] for between PE1 and PE2.) See Section 12.3 of [RFC6513] for
encapsulation details. Note that the root of the P-tunnel might be a encapsulation details. Note that the root of the P-tunnel might be a
PE other than PE1 or PE2. PE other than PE1 or PE2.
If, for a packet of a particular C-flow, there is no S-PMSI A-D route If, for a packet of a particular C-flow, there is no S-PMSI A-D route
or I-PMSI A-D route that is a match for transmission, the packet MUST or I-PMSI A-D route that is a match for transmission, the packet MUST
NOT be transmitted. NOT be transmitted.
3.2.2.4. When an S-PMSI is a 'Match for Reception' 3.2.2.4. When an S-PMSI Is a 'Match for Reception'
Suppose a given PE, say PE1, needs to receive multicast data packets Suppose a given PE, say PE1, needs to receive multicast data packets
of a particular C-flow. [RFC6625] Section 3.2 specifies procedures of a particular C-flow. Section 3.2 of [RFC6625] specifies
for determining the S-PMSI A-D route, if any, that matches that procedures for determining the S-PMSI A-D route, if any, that matches
C-flow for reception. Those rules require that the matching S-PMSI that C-flow for reception. Those rules require that the matching
A-D route has been originated by the upstream PE for the C-flow. The S-PMSI A-D route has been originated by the upstream PE for the
rules are modified in this section, as follows: C-flow. The rules are modified in this section, as follows:
Consider a particular C-flow. Suppose either: Consider a particular C-flow. Suppose either:
o the C-flow is unidirectional, and PE1 determines that its upstream o the C-flow is unidirectional, and PE1 determines that its upstream
PE is PE2, or PE is PE2, or
o the C-flow is bidirectional, and PE1 determines that the upstream o the C-flow is bidirectional, and PE1 determines that the upstream
PE for its C-RPA is PE2 PE for its C-RPA is PE2
Then the C-flow may match an installed S-PMSI A-D route that was not Then, the C-flow may match an installed S-PMSI A-D route that was not
originated by PE2, as long as: originated by PE2, as long as:
1. the PTA of that A-D route identifies an MP2MP LSP, and 1. the PTA of that A-D route identifies an MP2MP LSP,
2. there is an installed S-PMSI A-D route originated by the root 2. there is an installed S-PMSI A-D route originated by the root node
node of that LSP, or PE1 itself is the root node of the LSP and of that LSP, or PE1 itself is the root node of the LSP and there
there is a currently originated S-PMSI A-D route from PE1 whose is a currently originated S-PMSI A-D route from PE1 whose PTA
PTA identifies that LSP, and identifies that LSP, and
3. the latter S-PMSI A-D route (the one identified in 2 just above) 3. the latter S-PMSI A-D route (the one identified in 2 just above)
contains a PE Distinguisher Labels attribute that assigned an contains a PE Distinguisher Labels attribute that assigned an MPLS
MPLS label to the IP address of PE2. label to the IP address of PE2.
However, a bidirectional C-flow never matches an S-PMSI A-D route However, a bidirectional C-flow never matches an S-PMSI A-D route
whose NLRI contains (C-S,C-G). whose NLRI contains (C-S,C-G).
If a multicast data packet is received over a matching P-tunnel, but If a multicast data packet is received over a matching P-tunnel, but
does not carry the value of the PE Distinguisher Label that has been does not carry the value of the PE Distinguisher Label that has been
assigned to the upstream PE for its C-flow, then the packet MUST be assigned to the upstream PE for its C-flow, then the packet MUST be
discarded. discarded.
3.2.2.5. When an I-PMSI is a 'Match for Reception' 3.2.2.5. When an I-PMSI Is a 'Match for Reception'
If a PE needs to receive packets of a given C-flow (of a given MVPN) If a PE needs to receive packets of a given C-flow (of a given MVPN)
from another PE, and if, according to the conditions of from another PE, and if, according to the conditions of Section
Section 3.2.2.4, that C-flow does not match any S-PMSI A-D route, 3.2.2.4, that C-flow does not match any S-PMSI A-D route, then the
then the packets of the C-flow need to be received on the MVPN's packets of the C-flow need to be received on the MVPN's I-PMSI. The
I-PMSI. The P-tunnel on which the packets are expected to arrive is P-tunnel on which the packets are expected to arrive is determined by
determined by the Intra-AS I-PMSI A-D route originated by the the Intra-AS I-PMSI A-D route originated by the distinguished PE for
"distinguished PE" for the given C-flow. The PTA of that route the given C-flow. The PTA of that route specifies the "outer
specifies the "outer P-tunnel", and thus determines the top label P-tunnel" and thus determines the top label that packets of that
that packets of that C-flow will be carrying when received. A PE C-flow will be carrying when received. A PE that needs to receive
that needs to receive packets of a given C-flow must determine the packets of a given C-flow must determine the expected value of the
expected value of the second label for packets of that C-flow. This second label for packets of that C-flow. This will be the value of a
will be the value of a PE Distinguisher Label, taken from the PE PE Distinguisher Label, taken from the PE Distinguisher Labels
Distinguisher Labels attribute of the Intra-AS I-PMSI A-D route of attribute of the Intra-AS I-PMSI A-D route of the root node of that
the root node of that outer tunnel. The expected value of the second outer tunnel. The expected value of the second label on received
label on received packets (corresponding to the "inner tunnel") of a packets (corresponding to the "inner tunnel") of a given C-flow is
given C-flow is determined according to the following rules. determined according to the following rules.
First, the "distinguished PE" for the C-flow is determined: First, the distinguished PE for the C-flow is determined:
o If the C-flow is not a BIDIR-PIM C-flow, the "distinguished PE" o If the C-flow is not a BIDIR-PIM C-flow, the distinguished PE for
for the C-flow is its "upstream PE", as determined by the rules of the C-flow is its upstream PE, as determined by the rules of
[RFC6513]. [RFC6513].
o If the C-flow is a BIDIR-PIM C-flow, the "distinguished PE" for o If the C-flow is a BIDIR-PIM C-flow, the distinguished PE for the
the C-flow is its "upstream PE" of the C-flow's C-RPA, as C-flow is its upstream PE of the C-flow's C-RPA, as determined by
determined by the rules of [RFC6513]. the rules of [RFC6513].
The expected value of the second label is the value that the root PE The expected value of the second label is the value that the root PE
of the outer tunnel has assigned, in the PE Distinguisher Labels of the outer tunnel has assigned, in the PE Distinguisher Labels
attribute of its Intra-AS I-PMSI A-D route, to the IP address of the attribute of its Intra-AS I-PMSI A-D route, to the IP address of the
"distinguished PE". distinguished PE.
Packets addressed to C-G that arrive on other than the expected inner Packets addressed to C-G that arrive on other than the expected inner
and outer P-tunnels (i.e., that arrive with unexpected values of the and outer P-tunnels (i.e., that arrive with unexpected values of the
top two labels) MUST be discarded. top two labels) MUST be discarded.
3.2.3. Unpartitioned 3.2.3. Unpartitioned
When a particular MVPN uses the Unpartitioned Method of instantiating When a particular MVPN uses the Unpartitioned Method of instantiating
an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at
least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route
skipping to change at page 28, line 26 skipping to change at page 29, line 21
This allows a single bidirectional P-tunnel to be used to instantiate This allows a single bidirectional P-tunnel to be used to instantiate
the I-PMSI, but also allows the use of multiple bidirectional the I-PMSI, but also allows the use of multiple bidirectional
P-tunnels. There may be a robustness advantage in having multiple P-tunnels. There may be a robustness advantage in having multiple
P-tunnels available for use, but the number of P-tunnels used does P-tunnels available for use, but the number of P-tunnels used does
not impact the functionality in any way. If there are, e.g., two not impact the functionality in any way. If there are, e.g., two
P-tunnels available, these procedures allow each P-tunnel to be P-tunnels available, these procedures allow each P-tunnel to be
advertised by a single PE, but they also allow each P-tunnel to be advertised by a single PE, but they also allow each P-tunnel to be
advertised by multiple PEs. Note that the PE advertising a given advertised by multiple PEs. Note that the PE advertising a given
P-tunnel does not have to be the root node of the tunnel. The root P-tunnel does not have to be the root node of the tunnel. The root
node might not even be a PE router, and might not originate any BGP node might not even be a PE router, and it might not originate any
routes at all. BGP routes at all.
In the Unpartitioned Method, packets received on the I-PMSI cannot be In the Unpartitioned Method, packets received on the I-PMSI cannot be
associated with a distinguished PE, so duplicate detection using the associated with a distinguished PE, so duplicate detection using the
techniques of [RFC6513] section 9.1.1 is not possible; the techniques techniques of Section 9.1.1 of [RFC6513] is not possible; the
of [RFC6513] 9.1.2 or 9.1.3 would have to be used instead. Support techniques of Sections 9.1.2 or 9.1.3 of [RFC6513] would have to be
for C-BIDIR using the "Partitioned set of PEs" technique ([RFC6513] used instead. Support for C-BIDIR using the "Partitioned set of PEs"
section 11.2 and [RFC6517] section 3.6) is not possible when the technique (Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517]) is
Unpartitioned Method is used. If it is desired to use that technique not possible when the Unpartitioned Method is used. If it is desired
to support C-BIDIR, but also to use the Unpartitioned Method to to use that technique to support C-BIDIR, but also to use the
instantiate the I-PMSI, then all the C-BIDIR traffic would have to be Unpartitioned Method to instantiate the I-PMSI, then all the C-BIDIR
carried on an S-PMSI, where the S-PMSI is instantiated using one of traffic would have to be carried on an S-PMSI, where the S-PMSI is
the Partitioned Methods. instantiated using one of the Partitioned Methods.
When a PE, say PE1, needs to transmit multicast data packets of a When a PE, say PE1, needs to transmit multicast data packets of a
particular C-flow to other PEs, and PE1 does not have an S-PMSI that particular C-flow to other PEs, and PE1 does not have an S-PMSI that
is a match for transmission for that C-flow (see Section 3.2.3.1), is a match for transmission for that C-flow (see Section 3.2.3.1),
PE1 transmits the packets on one of the P-tunnel(s) that instantiates PE1 transmits the packets on one of the P-tunnel(s) that instantiates
the I-PMSI. When a PE, say PE1, needs to receive multicast data the I-PMSI. When a PE, say PE1, needs to receive multicast data
packets of a particular C-flow from another PE, and PE1 does not have packets of a particular C-flow from another PE, and PE1 does not have
an S-PMSI that is a match for reception for that C-flow (see an S-PMSI that is a match for reception for that C-flow (see Section
Section 3.2.3.2), PE1 expects to receive the packets on any of the 3.2.3.2), PE1 expects to receive the packets on any of the P-tunnels
P-tunnel(s) that instantiates the I-PMSI. that instantiate the I-PMSI.
When a particular MVPN uses the Unpartitioned Method to instantiate a When a particular MVPN uses the Unpartitioned Method to instantiate a
(C-*,C-*) S-PMSI or a (C-*,C-*-BIDIR) S-PMSI using a bidirectional (C-*,C-*) S-PMSI or a (C-*,C-*-BIDIR) S-PMSI using a bidirectional
P-tunnel, the same conditions apply as when an I-PMSI is instantiated P-tunnel, the same conditions apply as when an I-PMSI is instantiated
via the Unpartitioned Method. The only difference is that a PE need via the Unpartitioned Method. The only difference is that a PE need
not join a P-tunnel that instantiates the S-PMSI unless that PE needs not join a P-tunnel that instantiates the S-PMSI unless that PE needs
to receive multicast packets on the S-PMSI. to receive multicast packets on the S-PMSI.
When a particular MVPN uses bidirectional P-tunnels to instantiate When a particular MVPN uses bidirectional P-tunnels to instantiate
other S-PMSIs, different S-PMSI A-D routes that do not contain other S-PMSIs, different S-PMSI A-D routes that do not contain
(C-*,C-*) or (C-*,C-*-BIDIR), originated by the same or by different (C-*,C-*) or (C-*,C-*-BIDIR), originated by the same or by different
PEs, MAY have PTAs that identify the same bidirectional tunnel, and PEs, MAY have PTAs that identify the same bidirectional tunnel, and
they MAY have PTAs that do not identify the same bidirectional they MAY have PTAs that do not identify the same bidirectional
tunnel. tunnel.
While the Unpartitioned Method MAY be used to instantiate an S-PMSI While the Unpartitioned Method MAY be used to instantiate an S-PMSI
to which one or more C-BIDIR flows are bound, it must be noted that to which one or more C-BIDIR flows are bound, it must be noted that
the "Partitioned Set of PEs" method discussed in [RFC6513] section the "Partitioned Set of PEs" method discussed in Section 11.2 of
11.2 and [RFC6517] section 3.6 cannot be supported using the [RFC6513] and Section 3.6 of [RFC6517] cannot be supported using the
Unpartitioned Method. C-BIDIR support would have to be provided by Unpartitioned Method. C-BIDIR support would have to be provided by
the procedures of [RFC6513] section 11.1. the procedures of [RFC6513], Section 11.1.
3.2.3.1. When an S-PMSI is a 'Match for Transmission' 3.2.3.1. When an S-PMSI Is a 'Match for Transmission'
Suppose a PE needs to transmit multicast data packets of a particular Suppose a PE needs to transmit multicast data packets of a particular
customer C-flow. [RFC6625] Section 3.1 gives a four-step algorithm customer C-flow. [RFC6625], Section 3.1, gives a four-step algorithm
for determining the S-PMSI A-D route, if any, that matches that for determining the S-PMSI A-D route, if any, that matches that
C-flow for transmission. When referring to that section, please C-flow for transmission. When referring to that section, please
recall that BIDIR-PIM groups are also "Any Source Multicast" (ASM) recall that BIDIR-PIM groups are also ASM groups.
groups.
When bidirectional P-tunnels are used in the Unpartitioned Method, When bidirectional P-tunnels are used in the Unpartitioned Method,
the same algorithm applies, with one modification, when the PTA of an the same algorithm applies, with one modification, when the PTA of an
S-PMSI A-D route identifies a bidirectional P-tunnel. One additional S-PMSI A-D route identifies a bidirectional P-tunnel. One additional
step is added to the algorithm. This new step occurs before the step is added to the algorithm. This new step occurs before the
fourth step of the algorithm, and is as follows: fourth step of the algorithm, and is as follows:
o Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route o Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route
currently originated by PE1, and if C-G is a BIDIR group, the currently originated by PE1, and if C-G is a BIDIR group, the
C-flow matches that route. C-flow matches that route.
When the Unpartitioned Method is used, the PE SHOULD transmit the When the Unpartitioned Method is used, the PE SHOULD transmit the
C-flow on the P-tunnel advertised in the in the matching S-PMSI A-D C-flow on the P-tunnel advertised in the in the matching S-PMSI A-D
route, but it MAY transmit the C-flow on any P-tunnel that is route, but it MAY transmit the C-flow on any P-tunnel that is
advertised in the PTA of any installed S-PMSI A-D route that contains advertised in the PTA of any installed S-PMSI A-D route that contains
the same (C-S,C-G) as the matching S-PMSI A-D route. the same (C-S,C-G) as the matching S-PMSI A-D route.
3.2.3.2. When an S-PMSI is a 'Match for Reception' 3.2.3.2. When an S-PMSI Is a 'Match for Reception'
Suppose a PE needs to receive multicast data packets of a particular Suppose a PE needs to receive multicast data packets of a particular
customer C-flow. [RFC6625] Section 3.2 specifies the procedures for customer C-flow. Section 3.2 of [RFC6625] specifies the procedures
determining the S-PMSI A-D route, if any, that advertised the for determining the S-PMSI A-D route, if any, that advertised the
P-tunnel on which the PE should expect to receive that C-flow. P-tunnel on which the PE should expect to receive that C-flow.
When bidirectional P-tunnels are used in the Unpartitioned Method, When bidirectional P-tunnels are used in the Unpartitioned Method,
the same procedures apply, with one modification. the same procedures apply, with one modification.
The last paragraph of Section 3.2.2 of [RFC6625] begins: The last paragraph of Section 3.2.2 of [RFC6625] begins:
"If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2,
PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then
then (C-*,C-G) matches the (C-*,C-*) route if one of the following (C-*,C-G) matches the (C-*,C-*) route if one of the following
conditions holds:" conditions holds:
This is changed to: This is changed to:
"If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2,
PE2, but C-G is a BIDIR group and PE1 has an installed but C-G is a BIDIR group and PE1 has an installed (C-*,C-*-BIDIR)
(C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that S-PMSI A-D route, then (C-*,C-G) matches that route. Otherwise,
route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D if PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then
route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one (C-*,C-G) matches the (C-*,C-*) route if one of the following
of the following conditions holds:" conditions holds:
When the Unpartitioned Method is used, the PE MUST join the P-tunnel When the Unpartitioned Method is used, the PE MUST join the P-tunnel
that is advertised in the matching S-PMSI A-D route, and MUST also that is advertised in the matching S-PMSI A-D route, and it MUST also
join the P-tunnels that are advertised in other installed S-PMSI A-D join the P-tunnels that are advertised in other installed S-PMSI A-D
routes that contain the same (C-S,C-G) as the matching S-PMSI A-D routes that contain the same (C-S,C-G) as the matching S-PMSI A-D
route. route.
3.2.4. Minimal Feature Set for Compliance 3.2.4. Minimal Feature Set for Compliance
Implementation of bidirectional P-tunnels is OPTIONAL. If Implementation of bidirectional P-tunnels is OPTIONAL. If
bidirectional P-tunnels are not implemented, the issue of compliance bidirectional P-tunnels are not implemented, the issue of compliance
to this specification does not arise. However, for the case where to this specification does not arise. However, for the case where
bidirectional P-tunnels ARE implemented, this section specifies the bidirectional P-tunnels ARE implemented, this section specifies the
minimal set of features that MUST be implemented in order to claim minimal set of features that MUST be implemented in order to claim
compliance to this specification. compliance to this specification.
In order to be compliant with this specification, an implementation In order to be compliant with this specification, an implementation
that provides bidirectional P-tunnels MUST support at least one of that provides bidirectional P-tunnels MUST support at least one of
the two P-tunnel technologies mentioned in section Section 1.2.1. the two P-tunnel technologies mentioned in Section 1.2.1.
A PE that does not provide C-BIDIR support using the "partitioned set A PE that does not provide C-BIDIR support using the "partitioned set
of PEs" method is deemed compliant to this specification if it of PEs" method is deemed compliant to this specification if it
supports the Unpartitioned Method, using either MP2MP LSPs or BIDIR- supports the Unpartitioned Method, using either MP2MP LSPs or BIDIR-
PIM multicast distribute trees as P-tunnels. PIM multicast distribution trees as P-tunnels.
A PE that does provide C-BIDIR support using the "partitioned set of A PE that does provide C-BIDIR support using the "partitioned set of
PEs" method, MUST, at a minimum, be able to provide C-BIDIR support PEs" method MUST, at a minimum, be able to provide C-BIDIR support
using the "Partial Mesh of MP2MP P-tunnels" variant of this method using the "Partial Mesh of MP2MP P-tunnels" variant of this method
(see section 11.2 of [RFC6513]). An implementation will be deemed (see Section 11.2 of [RFC6513]). An implementation will be deemed
compliant to this minimum requirement if it can carry all of a VPN's compliant to this minimum requirement if it can carry all of a VPN's
C-BIDIR traffic on a (C-*,C-*-BIDIR) S-PMSI that is instantiated by a C-BIDIR traffic on a (C-*,C-*-BIDIR) S-PMSI that is instantiated by a
bidirectional P-tunnel, using the flat partitioned method. bidirectional P-tunnel, using the Flat Partitioned Method.
4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations 4. Security Considerations
There are no additional security considerations beyond those of There are no additional security considerations beyond those of
[RFC6513] and [RFC6514], or any that may apply to the particular [RFC6513] and [RFC6514], or any that may apply to the particular
protocol used to set up the bidirectional tunnels ([RFC5015], protocol used to set up the bidirectional tunnels ([RFC5015],
[RFC6388]). [RFC6388]).
6. Acknowledgments 5. References
The authors wish to thank Karthik Subramanian, Rajesh Sharma, and 5.1. Normative References
Apoorva Karan for their input. We also thank Yakov Rekhter for his
valuable critique.
Special thanks go to Jeffrey (Zhaohui) Zhang for his careful review, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
probing questions, and useful suggestions. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7. References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364,
February 2006, <http://www.rfc-editor.org/info/rfc4364>.
7.1. Normative References [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Networks (VPNs)", RFC 4364, February 2006. Thomas, "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November
2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
"Protocol Independent Multicast - Sparse Mode (PIM-SM): MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
Protocol Specification (Revised)", RFC 4601, August 2006. February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
"Bidirectional Protocol Independent Multicast (BIDIR- Encodings and Procedures for Multicast in MPLS/BGP IP
PIM)", RFC 5015, October 2007. VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
"Label Distribution Protocol Extensions for Point-to- Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
Multipoint and Multipoint-to-Multipoint Label Switched RFC 6625, DOI 10.17487/RFC6625, May 2012,
Paths", RFC 6388, November 2011. <http://www.rfc-editor.org/info/rfc6625>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 5.2. Informative References
VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [BGP-ERROR] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Encodings and Procedures for Multicast in MPLS/BGP IP Patel, "Revised Error Handling for BGP UPDATE Messages",
VPNs", RFC 6514, February 2012. Work in Progress, draft-ietf-idr-error-handling-19, April
2015.
[RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, [MVPN-BIDIR-IR]
"Wildcards in Multicast VPN Auto-Discovery Routes", RFC Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating
6625, May 2012. 'Partial Mesh of MP2MP P-Tunnels' with Ingress
Replication", Work in Progress,
draft-ietf-bess-mvpn-bidir-ingress-replication-00,
January 2015.
7.2. Informative References [MVPN-XNET] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
Work in Progress, draft-ietf-bess-mvpn-extranet-02, May
2015.
[BGP-ERROR] [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Chen, E., Scudder, J., Mohapatra, P., and K. Patel, Label Assignment and Context-Specific Label Space", RFC
"Revised Error Handling for BGP UPDATE Messages", 5331, DOI 10.17487/RFC5331, August 2008,
internet-draft draft-ietf-idr-error-handling-18, December <http://www.rfc-editor.org/info/rfc5331>.
2014.
[MVPN-BIDIR-IR] [RFC6517] Morin, T., Ed., Niven-Jenkins, B., Ed., Kamite, Y.,
Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating Zhang, R., Leymann, N., and N. Bitar, "Mandatory Features
'Partial Mesh of MP2MP P-Tunnels' with Ingress in a Layer 3 Multicast BGP/MPLS VPN Solution", RFC 6517,
Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir- DOI 10.17487/RFC6517, February 2012,
ingress-replication-01, July 2014. <http://www.rfc-editor.org/info/rfc6517>.
[MVPN-XNET] Acknowledgments
Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP
MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet-
05, July 2014.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream The authors wish to thank Karthik Subramanian, Rajesh Sharma, and
Label Assignment and Context-Specific Label Space", RFC Apoorva Karan for their input. We also thank Yakov Rekhter for his
5331, August 2008. valuable critique.
[RFC6517] Morin, T., Niven-Jenkins, B., Kamite, Y., Zhang, R., Special thanks go to Jeffrey (Zhaohui) Zhang for his careful review,
Leymann, N., and N. Bitar, "Mandatory Features in a Layer probing questions, and useful suggestions.
3 Multicast BGP/MPLS VPN Solution", RFC 6517, February
2012.
Authors' Addresses Authors' Addresses
Eric C. Rosen Eric C. Rosen
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, MA 01886
US United States
Email: erosen@juniper.net Email: erosen@juniper.net
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
BE Belgium
Email: ice@cisco.com Email: ice@cisco.com
Yiqun Cai Yiqun Cai
Microsoft Microsoft
1065 La Avenida 1065 La Avenida
Mountain View, CA 94043 Mountain View, CA 94043
US United States
Email: yiqunc@microsoft.com Email: yiqunc@microsoft.com
Arjen Boers Arjen Boers
Email: arjen@boers.com Email: arjen@boers.com
 End of changes. 170 change blocks. 
449 lines changed or deleted 450 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/