draft-ietf-bess-mvpn-bidir-03.txt   draft-ietf-bess-mvpn-bidir-04.txt 
BESS Working Group E. Rosen BESS Working Group E. Rosen
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 6513,6514,6625 (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: August 23, 2015 Y. Cai Expires: September 24, 2015 Y. Cai
Microsoft Microsoft
A. Boers A. Boers
March 23, 2015
February 19, 2015
MVPN: Using Bidirectional P-Tunnels MVPN: Using Bidirectional P-Tunnels
draft-ietf-bess-mvpn-bidir-03 draft-ietf-bess-mvpn-bidir-04
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
skipping to change at page 2, line 4 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2015.
This Internet-Draft will expire on September 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 15
3.1.1. BIDIR-PIM P-Tunnels . . . . . . . . . . . . . . . . . 14 3.1.1. BIDIR-PIM P-Tunnels . . . . . . . . . . . . . . . . . 15
3.1.2. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . 15 3.1.2. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . 16
3.2. Procedures Specific to the PMSI 3.2. Procedures Specific to the PMSI
Instantiation Method . . . . . . . . . . . . . . . . . . 16 Instantiation Method . . . . . . . . . . . . . . . . . . 16
3.2.1. Flat Partitioning . . . . . . . . . . . . . . . . . . 16 3.2.1. Flat Partitioning . . . . . . . . . . . . . . . . . . 17
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' . . . . . . . . . . . . . . . . . . 19
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' . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . 21 3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 22
3.2.2.1. Advertisement of PE 3.2.2.1. Advertisement of PE
Distinguisher Labels . . . . . . . . . . . . . . 23 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' . . . . . . . . . . . . . . . . . . 24 Transmission' . . . . . . . . . . . . . . . . . . 24
3.2.2.3. When an I-PMSI is a 'Match for 3.2.2.3. When an I-PMSI is a 'Match for
Transmission' . . . . . . . . . . . . . . . . . . 24 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' . . . . . . . . . . . . . . . . . . . 25 Reception' . . . . . . . . . . . . . . . . . . . 26
3.2.2.5. When an I-PMSI is a 'Match for 3.2.2.5. When an I-PMSI is a 'Match for
Reception' . . . . . . . . . . . . . . . . . . . 26 Reception' . . . . . . . . . . . . . . . . . . . 26
3.2.3. Unpartitioned . . . . . . . . . . . . . . . . . . . . 27 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' . . . . . . . . . . . . . . . . . . . 29 Reception' . . . . . . . . . . . . . . . . . . . 30
3.2.4. Minimal Feature Set for 3.2.4. Minimal Feature Set for
Compliance . . . . . . . . . . . . . . . . . . . . . 30 Compliance . . . . . . . . . . . . . . . . . . . . . 30
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 31 7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 31 7.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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], [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 5, line 48 skipping to change at page 5, line 45
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, the If a customer uses the "Any Source Multicast" (ASM) model, then
some or all of the customer's C-flows may be traveling along the some or all of the customer's C-flows may be traveling along the
same "shared tree". In this case, we will speak of a "(C-*,C-G)" same "shared tree". In this case, we will speak of a "(C-*,C-G)"
flow to refer to a set of C-flows that travel along the same flow to refer to a set of C-flows that travel along the same
shared tree in the customer sites. shared tree in the 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
skipping to change at page 6, line 46 skipping to change at page 6, line 41
A P-tunnel that is joined only by Provider Edge (PE) routers that A P-tunnel that is joined only by Provider Edge (PE) routers that
need to receive one or more of the C-flows that are traveling need to receive one or more of the C-flows that are traveling
through that P-tunnel. through that 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
Provider Multicast Service Interface. A PMSI is a conceptual
overlay on a Service Provider backbone, allowing a PE in a given
MVPN to multicast to other PEs in the MVPN. PMSIs are
instantiated by P-tunnels.
o I-PMSI
Inclusive PMSI. Traffic multicast by a PE on an I-PMSI is
received by all other PEs in the MVPN. I-PMSIs are instantiated
by Inclusive P-tunnels.
o S-PMSI
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
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 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
skipping to change at page 8, line 46 skipping to change at page 9, line 13
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
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 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 "out of scope."
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.
skipping to change at page 10, line 36 skipping to change at page 10, line 51
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" can be upstream-assigned labels ([RFC5331]), "PE Distinguisher Labels"
used to aggregate multiple bidirectional P-tunnels onto a single ([RFC6513] Section 4 and [RFC6514] Section 8) can be used to
"outer" bidirectional P-tunnel, thereby allowing one to provide aggregate multiple bidirectional P-tunnels onto a single "outer"
C-BIDIR support with minimal state at the transit nodes. bidirectional P-tunnel, thereby allowing one to provide C-BIDIR
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
tradeoffs, and upon the set of platforms deployed by that SP. tradeoffs, and upon the set of platforms deployed by that SP.
skipping to change at page 13, line 11 skipping to change at page 13, line 29
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 If bidirectional P-tunnels are being used to instantiate the PMSIs of
of a given MVPN, one of these methods must be chosen for that MVPN. a given MVPN, one of these methods must be chosen for that MVPN. All
All the PEs of that MVPN must be provisioned to know the method that the PEs of that MVPN must be provisioned to know the method that is
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) 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
be used. The method used by a given VRF used is determined by be used. The method used by a given VRF is determined by
provisioning. It SHOULD be possible to provision this on a per-MVPN provisioning. It is desirable to be able to provision this on a per-
basis, but 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 the Partitioned Method is used, all the VRFs of a single MVPN MUST
be provisioned to use the same variant of the Partitioned Method, be provisioned to use the same variant of the Partitioned Method,
i.e., either they must all use the Flat Partitioned Method, or they i.e., either they must all use the Flat Partitioned Method, or they
must all use the Hierarchical Partitioned Method. 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
skipping to change at page 14, line 7 skipping to change at page 14, line 22
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 on the PMSI instantiation method. Note that this
document does not necessarily specify procedures for every possible document does not necessarily specify procedures for every possible
combination of tunnel technology and PMSI instantiation method. combination of tunnel technology and PMSI instantiation method.
2. The All BIDIR-PIM Wild Card 2. The All BIDIR-PIM Wild Card
When an MVPN customer is using BIDIR-PIM, it is useful to be able to [RFC6514] specifies the method of encoding C-multicast source and
advertise an S-PMSI A-D route whose semantics are: "by default, all group addresses into the NLRI of certain BGP routes. [RFC6625]
BIDIR-PIM C-multicast traffic (within a given VPN) that has not been extends that specification by allowing the source and/or group
bound to any other P-tunnel is bound to the bidirectional P-tunnel address to be replaced by a wildcard. When an MVPN customer is using
identified by the PTA of this route". This can be especially useful BIDIR-PIM, it is useful to be able to advertise an S-PMSI A-D route
if one is using a bidirectional P-tunnel to carry the C-BIDIR flows, whose semantics are: "by default, all BIDIR-PIM C-multicast traffic
while using unidirectional P-tunnels to carry other C-flows. To do (within a given VPN) that has not been bound to any other P-tunnel is
this, it is necessary to have a way to encode a (C-*,C-*) wildcard bound to the bidirectional P-tunnel identified by the PTA of this
that is restricted to BIDIR-PIM C-groups. route". This can be especially useful if one is using a
bidirectional P-tunnel to carry the C-BIDIR flows, while using
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
restricted to BIDIR-PIM C-groups.
We therefore define a special value of the group wildcard, whose We therefore 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. We will use the notation (C-*,C-*-BIDIR) to refer to the value 0x00. (This encoding is distinct from the group wildcard
the "all BIDIR-PIM groups" wildcard. encoding defined in [RFC6625]). We will use the notation
(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 MP2MP mLDP), but that are tunneling technology (BIDIR-PIM, or the MP2MP procedures of mLDP
independent of the method (Unpartitioned, Flat Partitioned, or ("Multipoint LDP")), but that are independent of the method
Hierarchical Partitioned) used to instantiate a PMSI. (Unpartitioned, Flat Partitioned, or Hierarchical Partitioned) used
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
skipping to change at page 22, line 14 skipping to change at page 22, line 43
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 may
be thought of as identifying an "inner" MP2MP LSP whose root is the 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 are REQUIRED to originate these routes are those that satisfy one PEs that are REQUIRED to originate these routes are those that
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, or
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
skipping to change at page 23, line 30 skipping to change at page 24, line 7
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 This document assumes that the root node address of an MP2MP LSP is
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,
skipping to change at page 30, line 15 skipping to change at page 30, line 47
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 one or both of the that provides bidirectional P-tunnels MUST support at least one of
two P-tunnel technologies mentioned in section Section 1.2.1. the two P-tunnel technologies mentioned in section 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 may be 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 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
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.
 End of changes. 32 change blocks. 
59 lines changed or deleted 84 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/