draft-ietf-bess-mvpn-bidir-02.txt   draft-ietf-bess-mvpn-bidir-03.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: July 23, 2015 Y. Cai Expires: August 23, 2015 Y. Cai
Microsoft Microsoft
A. Boers A. Boers
January 19, 2015 February 19, 2015
MVPN: Using Bidirectional P-Tunnels MVPN: Using Bidirectional P-Tunnels
draft-ietf-bess-mvpn-bidir-02 draft-ietf-bess-mvpn-bidir-03
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 July 23, 2015. This Internet-Draft will expire on August 23, 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
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 . . . . . . . . . . . . . . . . . . . . . . 10 P-tunnels . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 16 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' . . . . . . . . . . . . . . . . . . 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' . . . . . . . . . . . . . . . . . . . 20 Reception' . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . . 21 Reception . . . . . . . . . . . . . . . . . . . . 20
3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 21 3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 21
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' . . . . . . . . . . . . . . . . . . 25 Transmission' . . . . . . . . . . . . . . . . . . 24
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' . . . . . . . . . . . . . . . . . . . 25
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' . . . . . . . . . . . . . . . . . . 29 Transmission' . . . . . . . . . . . . . . . . . . 28
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' . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . 31
skipping to change at page 9, line 43 skipping to change at page 9, line 43
This document supports two different technologies for creating and This document supports two different technologies for creating and
maintaining bidirectional P-tunnels: maintaining bidirectional P-tunnels:
o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that
are created through the use of the Label Distribution Protocol are created through the use of the Label Distribution Protocol
(LDP) Multipoint-to-Multipoint extensions [RFC6388]. (LDP) Multipoint-to-Multipoint extensions [RFC6388].
o Multicast distribution trees that are created through the use of o Multicast distribution trees that are created through the use of
BIDIR-PIM [RFC5015]. BIDIR-PIM [RFC5015].
An implementation may be considered compliant with this document if Other bidirectional tunnel technologies are outside the scope of this
it provides either one of these tunneling technologies. Other
bidirectional tunnel technologies are outside the scope of this
document. document.
1.2.2. Reasons for Using Bidirectional P-tunnels 1.2.2. Reasons for Using Bidirectional P-tunnels
Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or
S-PMSIs. S-PMSIs.
An SP may decide to use bidirectional P-tunnels to instantiate An SP may decide to use bidirectional P-tunnels to instantiate
certain I-PMSIs and/or S-PMSIs in order to provide its customers with certain I-PMSIs and/or S-PMSIs in order to provide its customers with
C-BIDIR support, using the "Partitioned Set of PEs" technique C-BIDIR support, using the "Partitioned Set of PEs" technique
skipping to change at page 30, line 22 skipping to change at page 30, line 14
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
that provides bidirectional P-tunnels MUST support one or both of 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 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. 11 change blocks. 
12 lines changed or deleted 14 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/