draft-ietf-bess-mvpn-bidir-01.txt   draft-ietf-bess-mvpn-bidir-02.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: June 25, 2015 Y. Cai Expires: July 23, 2015 Y. Cai
Microsoft Microsoft
A. Boers A. Boers
December 22, 2014 January 19, 2015
MVPN: Using Bidirectional P-Tunnels MVPN: Using Bidirectional P-Tunnels
draft-ietf-bess-mvpn-bidir-01 draft-ietf-bess-mvpn-bidir-02
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 2, line 4
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 June 25, 2015. This Internet-Draft will expire on July 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 10, line 25 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. Note that the actual number of distribution tree can be used, assuming appropriate support by the
bidirectional P-tunnels that are used in a given deployment is provisioning system.
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 15, line 45 skipping to change at page 15, line 45
the attribute has no effect on the data plane. It MUST however be the attribute has no effect on the data plane. It MUST however be
treated by BGP as if it were an unsupported optional transitive treated by BGP as if it were an unsupported optional transitive
attribute. (PE Distinguisher Labels are used for the Hierarchical attribute. (PE Distinguisher Labels are used for the Hierarchical
Partitioning Method, but this document does not provide support for Partitioning Method, but this document does not provide support for
the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.) the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.)
3.1.2. MP2MP LSPs 3.1.2. MP2MP LSPs
Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding
Equivalence Class) element" [RFC6388]. The FEC element contains the Equivalence Class) element" [RFC6388]. The FEC element contains the
IP address of the "root node", followed by an "opaque value" that IP address of the root node, followed by an opaque value that
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 there is no need for different root nodes to use the same opaque
the same opaque value. value for a given MVPN.
The mLDP specification supports the use of several different ways of The mLDP specification supports the use of several different ways of
constructing the tunnel identifiers. The current specification does constructing the tunnel identifiers. The current specification does
not place any restriction on the type or types of tunnel identifier not place any restriction on the type or types of tunnel identifier
that is used in a given deployment. A given implementation is not 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 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 routes) tunnel identifiers of every possible type. However, an
implementation SHOULD be able to accept and properly process a PTA implementation SHOULD be able to accept and properly process a PTA
that uses any legal type of tunnel identifier. that uses any legal type of tunnel identifier.
skipping to change at page 16, line 41 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. the specified P-tunnel.
If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a
distinct P-group address. The PE advertising the tunnel will be distinct P-group address. The PE advertising the tunnel will be
considered to be the "root node" of the tunnel. Note that this considered to be the root node of the tunnel. Note that this creates
creates a unique mapping from P-group address to "root node". The a unique mapping from P-group address to root node. The assignment
assignment of P-group addresses to MVPNs is by provisioning. of P-group addresses to MVPNs is by provisioning.
If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC
(i.e., distinct combination of "root node" and "opaque value"). The (i.e., distinct combination of root node and opaque value). The PE
PE advertising the tunnel MUST be the same PE identified in the "root advertising the tunnel MUST be the same PE identified in the root
node" field of the MP2MP FEC that is encoded in the PTA. node field of the MP2MP FEC that is encoded in the PTA.
It follows that two different PEs may not advertise the same It follows that two different PEs may not advertise the same
bidirectional P-tunnel. Any PE that receives a packet from the bidirectional P-tunnel. Any PE that receives a packet from the
P-tunnel can infer the identity of the P-tunnel from the packet's P-tunnel can infer the identity of the P-tunnel from the packet's
encapsulation. Once the identity of the P-tunnel is known, the root encapsulation. Once the identity of the P-tunnel is known, the root
node of the P-tunnel is also known. The root node of the P-tunnel on node of the P-tunnel is also known. The root node of the P-tunnel on
which the packet arrived is treated as the "distinguished PE" for which the packet arrived is treated as the "distinguished PE" for
that packet. that packet.
The Flat Partitioned Method does not use upstream-assigned labels in The Flat Partitioned Method does not use upstream-assigned labels in
skipping to change at page 20, line 26 skipping to change at page 20, line 26
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 is not the same as PE2, and PE1 has an installed o If PE1 is not the same as PE2, and PE1 has an installed
(C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then
(C-*,C-G-BIDIR) matches this route. (C-*,C-G-BIDIR) matches this route.
o If PE1 is the same as PE2, and PE1 has currently originated a o Otherwise, if PE1 is the same as PE2, and PE1 has currently
(C-*,C-G-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches originated a (C-*,C-G-BIDIR) S-PMSI A-D route, then
this route. (C-*,C-G-BIDIR) matches this route.
o If PE1 is not the same as PE2, and PE1 has an installed o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed
(C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then
(C-*,C-G-BIDIR) matches this route. (C-*,C-G-BIDIR) matches this route.
o If PE1 is the same as PE2, and PE1 has currently originated a o Otherwise, if PE1 is the same as PE2, and PE1 has currently
(C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches originated a (C-*,C-*-BIDIR) S-PMSI A-D route, then
this route. (C-*,C-G-BIDIR) matches this route.
o If PE1 is not the same as PE2, and PE1 has an installed (C-*,C-*) o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed
S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) matches (C-*,C-*) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR)
this route. matches this route.
o If PE1 is the same as PE2, and PE1 has currently originated a o Otherwise, if PE1 is the same as PE2, and PE1 has currently
(C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR) matches this originated a (C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR)
route. matches this route.
If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according
to these rules, the root node of that P-tunnel is considered to be to these rules, the root node of that P-tunnel is considered to be
the "distinguished PE" for that (C-*,C-G-BIDIR) flow. If a the "distinguished PE" for that (C-*,C-G-BIDIR) flow. If a
(C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is (C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is
not the distinguished PE for the C-flow, the packet MUST be not the distinguished PE for the C-flow, the packet MUST be
discarded. discarded.
3.2.1.4. When an I-PMSI is a 'Match for Reception 3.2.1.4. When an I-PMSI is a 'Match for Reception
skipping to change at page 30, line 15 skipping to change at page 30, line 15
of the following conditions holds:" of the following conditions holds:"
When the Unpartitioned Method is used, the PE MUST join the P-tunnel When the Unpartitioned Method is used, the PE MUST join the P-tunnel
that is advertised in the matching S-PMSI A-D route, and MUST also that is advertised in the matching S-PMSI A-D route, and MUST also
join the P-tunnels that are advertised in other installed S-PMSI A-D join the P-tunnels that are advertised in other installed S-PMSI A-D
routes that contain the same (C-S,C-G) as the matching S-PMSI A-D routes that contain the same (C-S,C-G) as the matching S-PMSI A-D
route. route.
3.2.4. Minimal Feature Set for Compliance 3.2.4. Minimal Feature Set for Compliance
Implementation of bidirectional P-tunnels is OPTIONAL. If
bidirectional P-tunnels are not implemented, the issue of compliance
to this specification does not arise. However, for the case where
bidirectional P-tunnels ARE implemented, this section specifies the
minimal set of features that MUST be implemented in order to claim
compliance to this specification.
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
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
 End of changes. 17 change blocks. 
32 lines changed or deleted 38 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/