draft-ietf-bess-mvpn-bidir-00.txt   draft-ietf-bess-mvpn-bidir-01.txt 
BESS Working Group E. Rosen BESS Working Group E. Rosen
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 6513,6514 (if approved) IJ. Wijnands Updates: 6513,6514,6625 (if approved) IJ. Wijnands
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: May 22, 2015 Y. Cai Expires: June 25, 2015 Y. Cai
Microsoft Microsoft
A. Boers A. Boers
November 18, 2014 December 22, 2014
MVPN: Using Bidirectional P-Tunnels MVPN: Using Bidirectional P-Tunnels
draft-ietf-bess-mvpn-bidir-00 draft-ietf-bess-mvpn-bidir-01
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 and 6625 by support multicast VPNs. This document updates RFCs 6513, 6514 and
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2015. This Internet-Draft will expire on June 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1. Bidirectional P-tunnel 1.2.1. Bidirectional P-tunnel
Technologies . . . . . . . . . . . . . . . . . . . . 9 Technologies . . . . . . . . . . . . . . . . . . . . 9
1.2.2. Reasons for Using Bidirectional 1.2.2. Reasons for Using Bidirectional
P-tunnels . . . . . . . . . . . . . . . . . . . . . . 9 P-tunnels . . . . . . . . . . . . . . . . . . . . . . 10
1.2.3. Knowledge of Group-to-RP and/or 1.2.3. Knowledge of Group-to-RP and/or
Group-to-RPA Mappings . . . . . . . . . . . . . . . . 10 Group-to-RPA Mappings . . . . . . . . . . . . . . . . 11
1.2.4. PMSI Instantiation Methods . . . . . . . . . . . . . 11 1.2.4. PMSI Instantiation Methods . . . . . . . . . . . . . 11
2. The All BIDIR-PIM Wild Card . . . . . . . . . . . . . . . . . 13 2. The All BIDIR-PIM Wild Card . . . . . . . . . . . . . . . . . 14
3. Using Bidirectional P-Tunnels . . . . . . . . . . . . . . . . 14 3. Using Bidirectional P-Tunnels . . . . . . . . . . . . . . . . 14
3.1. Procedures Specific to the 3.1. Procedures Specific to the
Tunneling Technology . . . . . . . . . . . . . . . . . . 14 Tunneling Technology . . . . . . . . . . . . . . . . . . 14
3.1.1. BIDIR-PIM P-Tunnels . . . . . . . . . . . . . . . . . 14 3.1.1. BIDIR-PIM P-Tunnels . . . . . . . . . . . . . . . . . 14
3.1.2. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . 15 3.1.2. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . 15
3.2. Procedures Specific to the PMSI 3.2. Procedures Specific to the PMSI
Instantiation Method . . . . . . . . . . . . . . . . . . 15 Instantiation Method . . . . . . . . . . . . . . . . . . 16
3.2.1. Flat Partitioning . . . . . . . . . . . . . . . . . . 16 3.2.1. Flat Partitioning . . . . . . . . . . . . . . . . . . 16
3.2.1.1. When an S-PMSI is a 'Match for 3.2.1.1. When an S-PMSI is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 18 Transmission' . . . . . . . . . . . . . . . . . . 18
3.2.1.2. When an I-PMSI is a 'Match for 3.2.1.2. When an I-PMSI is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 18 Transmission' . . . . . . . . . . . . . . . . . . 19
3.2.1.3. When an S-PMSI is a 'Match for 3.2.1.3. When an S-PMSI is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 19 Reception' . . . . . . . . . . . . . . . . . . . 20
3.2.1.4. When an I-PMSI is a 'Match for 3.2.1.4. When an I-PMSI is a 'Match for
Reception . . . . . . . . . . . . . . . . . . . . 20 Reception . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 20 3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 21
3.2.2.1. Advertisement of PE 3.2.2.1. Advertisement of PE
Distinguisher Labels . . . . . . . . . . . . . . 22 Distinguisher Labels . . . . . . . . . . . . . . 23
3.2.2.2. When an S-PMSI is a 'Match for 3.2.2.2. When an S-PMSI is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 23
3.2.2.3. When an I-PMSI is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 24 Transmission' . . . . . . . . . . . . . . . . . . 24
3.2.2.3. When an I-PMSI is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 25
3.2.2.4. When an S-PMSI is a 'Match for 3.2.2.4. When an S-PMSI is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 24
3.2.2.5. When an I-PMSI is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 25 Reception' . . . . . . . . . . . . . . . . . . . 25
3.2.3. Unpartitioned . . . . . . . . . . . . . . . . . . . . 26 3.2.2.5. When an I-PMSI is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 26
3.2.3. Unpartitioned . . . . . . . . . . . . . . . . . . . . 27
3.2.3.1. When an S-PMSI is a 'Match for 3.2.3.1. When an S-PMSI is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 28 Transmission' . . . . . . . . . . . . . . . . . . 29
3.2.3.2. When an S-PMSI is a 'Match for 3.2.3.2. When an S-PMSI is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 28 Reception' . . . . . . . . . . . . . . . . . . . 29
3.2.4. Minimal Feature Set for 3.2.4. Minimal Feature Set for
Compliance . . . . . . . . . . . . . . . . . . . . . 29 Compliance . . . . . . . . . . . . . . . . . . . . . 30
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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], [RFC6625]) allow customer multicast data to be
transported across a service provider's network though a set of 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 "Provider Multicast Service Interface (PMSI) Tunnel" attribute. the "Provider Multicast Service Interface (PMSI) Tunnel" attribute.
The base specifications allow the use of bidirectional (multipoint- The base specifications allow the use of bidirectional (multipoint-
skipping to change at page 4, line 20 skipping to change at page 4, line 20
multicast service is offered. multicast service is offered.
o VRF o VRF
VPN Routing and Forwarding table [RFC4364]. VPN Routing and Forwarding table [RFC4364].
o PE o PE
A Provider Edge router, as defined in [RFC4364]. A Provider Edge router, as defined in [RFC4364].
o SP
Service Provider.
o LSP o LSP
An MPLS Label Switched Path. An MPLS Label Switched Path.
o P2MP o P2MP
Point-to-Multipoint. Point-to-Multipoint.
o MP2MP o MP2MP
skipping to change at page 8, line 21 skipping to change at page 8, line 27
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. E.g.,
the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known
as a "(C-*,C-G) S-PMSI". 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
for reception" as they are defined in [RFC6625]. When it is clear
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
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], [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
skipping to change at page 10, line 9 skipping to change at page 10, line 25
an I-PMSI or an S-PMSI. 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. distribution tree can be used. Note that the actual number of
bidirectional P-tunnels that are used in a given deployment is
determined by provisioning.
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
skipping to change at page 12, line 49 skipping to change at page 13, line 18
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 no additional functionality.
If a 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 the PEs of that MVPN must be provisioned to know the method that
is 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) or the Unpartitioned
Method. The method used for a given MVPN is determined by Method. The method used for a given MVPN is determined by
provisioning. It SHOULD be possible to provision this on a per-MVPN provisioning. It SHOULD be possible to provision this on a per-MVPN
basis, but all the VRFs of a single MVPN MUST be provisioned to use basis, but all the VRFs of a single MVPN MUST be provisioned to use
the same method for the given MVPN's I-PMSI. 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 Method (either Flat or Hierarchical) or the Unpartitioned Method may
skipping to change at page 15, line 27 skipping to change at page 15, line 49
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
identifies the MP2MP LSP uniquely in the context of the root node's identifies the MP2MP LSP uniquely in the context of the root node's
IP address. This opaque value may be configured or autogenerated, IP address. This opaque value may be configured or autogenerated,
and within an MVPN, there is no need for different root nodes to use and within an MVPN, there is no need for different root nodes to use
the same opaque value. The mLDP specification supports the use of the same opaque value.
several different ways of constructing the tunnel identifiers. The
current specification does not place any restriction on the type of The mLDP specification supports the use of several different ways of
tunnel identifier that might be used. However, a given constructing the tunnel identifiers. The current specification does
implementation might not support every possible type of tunnel not place any restriction on the type or types of tunnel identifier
identifier. that is used in a given deployment. A given implementation is not
expected to be able to advertise (in the PTAs of I-PMSI or S-PMSI A-D
routes) tunnel identifiers of every possible type. However, an
implementation SHOULD be able to accept and properly process a PTA
that uses any legal type of tunnel identifier.
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
skipping to change at page 16, line 17 skipping to change at page 16, line 41
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 sub-sections 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. It follows that two different PEs may not the specified P-tunnel.
advertise the same 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 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 which the packet arrived is treated as the
"distinguished PE" for that packet.
If MP2MP LSPs are used, each P-tunnel MUST have have a distinct MP2MP
FEC (i.e., distinct combination of "root node" and "opaque value").
The PE advertising the tunnel MUST be the same PE identified in the
"root node" field of the MP2MP FEC that is encoded in the PTA.
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
a unique mapping from P-group address to "root node". creates a unique mapping from P-group address to "root node". The
assignment of P-group addresses to MVPNs is by provisioning.
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 advertising the tunnel MUST be the same PE identified in the "root
node" field of the MP2MP FEC that is encoded in the PTA.
It follows that two different PEs may not advertise the same
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
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
which the packet arrived is treated as the "distinguished PE" for
that 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
skipping to change at page 17, line 19 skipping to change at page 17, line 46
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 Section 3.2.1.1 and Section 3.2.1.2 determine when a
given customer multicast packet is a "match for transmission" to a given customer multicast packet is a match for transmission to a
given PMSI. However, if the "Partitioned Set of PEs" method of given PMSI. However, if the "Partitioned Set of PEs" method of
supporting C-BIDIR traffic is being used, the PEs must be provisioned supporting C-BIDIR traffic is being used for a given MVPN, the PEs
in such a way that packets from a C-BIDIR flow never match any PMSI must be provisioned in such a way that packets from a C-BIDIR flow of
that is not instantiated by a bidirectional P-tunnel. (For example, that MVPN never match any PMSI that is not instantiated by a
if the (C-*,C-*) S-PMSI were not instantiated by a bidirectional bidirectional P-tunnel. (For example, if the given MVPN's (C-*,C-*)
P-tunnel, one could meet this requirement by carrying all C-BIDIR S-PMSI were not instantiated by a bidirectional P-tunnel, one could
traffic on a (C-*,C-*-BIDIR) S-PMSI.) meet this requirement by carrying all C-BIDIR traffic of that MVPN on
a (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 Section 3.2.1.1 and Section 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.
skipping to change at page 18, line 9 skipping to change at page 18, line 34
PEs to determine the expected distinguished PE for each C-flow, and PEs to determine the expected distinguished PE for each C-flow, and
ensure that a packet will be discarded if its distinguished PE is not ensure that a packet will be discarded if its distinguished PE is not
the expected distinguished PE for the C-flow to which the packet the expected distinguished PE for the C-flow to which the packet
belongs. This prevents duplication of data for both bidirectional belongs. This prevents duplication of data for both bidirectional
and unidirectional C-flows. and 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. [RFC6625] Section 3.1 gives a four-step
algorithm for determining the S-PMSI A-D route, if any, that algorithm for determining the S-PMSI A-D route, if any, that matches
"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:
* If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently * If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently
skipping to change at page 19, line 32 skipping to change at page 20, line 9
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. [RFC6625] Section 3.2 specifies procedures
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 reception. Those rules apply unchanged for C-flows that C-flow for reception. Those rules apply unchanged for C-flows that
are not BIDIR-PIM C-flows. The remainder of this section applies are not BIDIR-PIM C-flows. The remainder of this section applies
only to C-BIDIR flows. 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 C-RPA of C-G-BIDIR. Then: the C-RPA of C-G-BIDIR. Then:
o If PE1 has an installed (C-*,C-G-BIDIR) S-PMSI A-D route o If PE1 is not the same as PE2, and PE1 has an installed
originated by PE2, then (C-*,C-G-BIDIR) matches this route. (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then
(C-*,C-G-BIDIR) matches this route.
o Otherwise, if PE1 has an installed (C-*,C-*-BIDIR) route o If PE1 is the same as PE2, and PE1 has currently originated a
originated by PE2, then (C-*,C-G-BIDIR) matches this route. (C-*,C-G-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches
this route.
o Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D route o If PE1 is not the same as PE2, and PE1 has an installed
originated by PE2, then (C-*,C-G-BIDIR) matches this route. (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then
(C-*,C-G-BIDIR) matches this route.
o If PE1 is the same as PE2, and PE1 has currently originated a
(C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches
this route.
o 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) matches
this route.
o 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) 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
skipping to change at page 20, line 33 skipping to change at page 21, line 23
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 Intra-AS I-PMSI A-D route originated by PE2, PE1 will installed Intra-AS I-PMSI A-D route originated by PE2, PE1 will
expect to receive packets of the C-flow from the tunnel specifies in expect to receive packets of the C-flow from the tunnel specified in
that route's PTA. (If all VRFs of the MVPN have been properly that route's PTA. (If all VRFs of the MVPN have been properly
provisioned to use the Flat Partitioned Method for the I-PMSI, the provisioned to use the Flat Partitioned Method for the I-PMSI, the
PTA will specify a bidirectional P-tunnel.) PTA will specify a bidirectional P-tunnel.) Note that if PE1 is the
same as PE2, then the relevant Intra-AS I-PMSI A-D route is the one
currently 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, 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 sub-sections 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
skipping to change at page 22, line 41 skipping to change at page 23, line 33
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 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
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. considered to be malformed, and the "treat-as-withdraw" error-
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.
skipping to change at page 23, line 25 skipping to change at page 24, line 25
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. [RFC6625] Section 3.1 gives a four-step
algorithm for determining the S-PMSI A-D route, if any, that algorithm for determining the S-PMSI A-D route, if any, that matches
"matches" that C-flow for transmission. that C-flow for transmission.
If the C-flow is not a BIDIR-PIM C-flow, these 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. In constructing the packet's on the P-tunnel identified in its PTA. Suppose PE1 has determined
MPLS label stack, it must use the PE Distinguisher Label that was that PE2 is the upstream PE for the C-RPA of the given C-flow. In
assigned by the P-tunnel's root node to the IP address of "PE2", not constructing the packet's MPLS label stack, PE1 must use the PE
the label assigned to the IP address of "PE1". (Section 3.2.1.1 Distinguisher Label that was assigned by the P-tunnel's root node to
specifies the difference between PE1 and PE2.) See section 12.3 of the IP address of "PE2", not the label assigned to the IP address of
[RFC6513] for encapsulation details. Note that the root of the "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
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 [RFC6625] section 3.1, 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.
skipping to change at page 24, line 27 skipping to change at page 25, line 27
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 3.2.1.2. Section 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". (Section 3.2.1.2 the label assigned to the IP address of "PE1" (unless, of course, PE1
specifies the difference between PE1 and PE2.) See section 12.3 of is the same as PE2). (Section 3.2.1.2 specifies the difference
[RFC6513] for encapsulation details. Note that the root of the between PE1 and PE2.) See section 12.3 of [RFC6513] for
P-tunnel might be a PE other than PE1 or PE2. encapsulation details. Note that the root of the P-tunnel might be a
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. [RFC6625] Section 3.2 specifies procedures
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 reception. Those rules require that the matching S-PMSI C-flow for reception. Those rules require that the matching S-PMSI
A-D route has been originated by the upstream PE for the C-flow. The A-D route has been originated by the upstream PE for the C-flow. The
rules are modified in this section, as follows: 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, and
2. there is an installed S-PMSI A-D route originated the root node 2. there is an installed S-PMSI A-D route originated by the root
of that LSP, or PE1 itself the root node of the LSP and there is node of that LSP, or PE1 itself is the root node of the LSP and
a currently originated S-PMSI A-D route from PE1 whose PTA there is a currently originated S-PMSI A-D route from PE1 whose
identifies that LSP, and PTA 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 label to the IP address of PE2. MPLS 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
skipping to change at page 27, line 22 skipping to change at page 28, line 22
for C-BIDIR using the "Partitioned set of PEs" technique ([RFC6513] for C-BIDIR using the "Partitioned set of PEs" technique ([RFC6513]
section 11.2 and [RFC6517] section 3.6) is not possible when the section 11.2 and [RFC6517] section 3.6) is not possible when the
Unpartitioned Method is used. If it is desired to use that technique Unpartitioned Method is used. If it is desired to use that technique
to support C-BIDIR, but also to use the Unpartitioned Method to to support C-BIDIR, but also to use the Unpartitioned Method to
instantiate the I-PMSI, then all the C-BIDIR traffic would have to be instantiate the I-PMSI, then all the C-BIDIR traffic would have to be
carried on an S-PMSI, where the S-PMSI is instantiated using one of carried on an S-PMSI, where the S-PMSI is instantiated using one of
the Partitioned Methods. 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 3.2.3.2), PE1 expects to receive the packets on any of the Section 3.2.3.2), PE1 expects to receive the packets on any of the
P-tunnel(s) that instantiates the I-PMSI. P-tunnel(s) that instantiates 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.
skipping to change at page 28, line 9 skipping to change at page 29, line 9
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 [RFC6513] section
11.2 and [RFC6517] section 3.6 cannot be supported using the 11.2 and [RFC6517] section 3.6 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 "Any Source Multicast" (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:
skipping to change at page 29, line 24 skipping to change at page 30, line 24
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 may be deemed compliant to this specification if it of PEs" method may be 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 distribute 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
complaint 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 4. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
5. Security Considerations 5. 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 6. Acknowledgments
The authors wish to thank Karthik Subramanian, Rajesh Sharma, and The authors wish to thank Karthik Subramanian, Rajesh Sharma, and
Apoorva Karan for their input. We also thank Yakov Rekhter for his Apoorva Karan for their input. We also thank Yakov Rekhter for his
valuable critique. valuable critique.
Special thanks go to Jeffrey Zhang for his careful review, probing Special thanks go to Jeffrey (Zhaohui) Zhang for his careful review,
questions, and useful suggestions. probing questions, and useful suggestions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
skipping to change at page 30, line 41 skipping to change at page 31, line 41
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, February 2012.
[RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu,
"Wildcards in Multicast VPN Auto-Discovery Routes", RFC "Wildcards in Multicast VPN Auto-Discovery Routes", RFC
6625, May 2012. 6625, May 2012.
7.2. Informative References 7.2. Informative References
[BGP-ERROR]
Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Messages",
internet-draft draft-ietf-idr-error-handling-18, December
2014.
[MVPN-BIDIR-IR] [MVPN-BIDIR-IR]
Zhang, J., Rekhter, Y., and A. Dolganow, "Simulating Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating
'Partial Mesh of MP2MP P-Tunnels' with Ingress 'Partial Mesh of MP2MP P-Tunnels' with Ingress
Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir- Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir-
ingress-replication-01, July 2014. ingress-replication-01, July 2014.
[MVPN-XNET] [MVPN-XNET]
Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP
MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet-
05, July 2014. 05, July 2014.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
 End of changes. 52 change blocks. 
98 lines changed or deleted 154 lines changed or added

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