tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7582

Proposed STD
Pages: 34
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: BESS

Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels

Part 1 of 2, p. 1 to 15
None       Next RFC Part

Updates:    6513    6514    6625


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                          E. Rosen
Request for Comments: 7582                        Juniper Networks, Inc.
Updates: 6513, 6514, 6625                                   IJ. Wijnands
Category: Standards Track                            Cisco Systems, Inc.
ISSN: 2070-1721                                                   Y. Cai
                                                               Microsoft
                                                                A. Boers
                                                               July 2015


               Multicast Virtual Private Network (MVPN):
                     Using Bidirectional P-Tunnels

Abstract

   A set of prior RFCs specify procedures for supporting multicast in
   BGP/MPLS IP VPNs.  These procedures allow customer multicast data to
   travel across a service provider's backbone network through a set of
   multicast tunnels.  The tunnels are advertised in certain BGP
   multicast auto-discovery routes, by means of a BGP attribute known
   as the "Provider Multicast Service Interface (PMSI) Tunnel"
   attribute.  Encodings have been defined that allow the PMSI Tunnel
   attribute to identify bidirectional (multipoint-to-multipoint)
   multicast distribution trees.  However, the prior RFCs do not provide
   all the necessary procedures for using bidirectional tunnels to
   support multicast VPNs.  This document updates RFCs 6513, 6514, and
   6625 by specifying those procedures.  In particular, it specifies the
   procedures for assigning customer multicast flows (unidirectional or
   bidirectional) to specific bidirectional tunnels in the provider
   backbone, for advertising such assignments, and for determining which
   flows have been assigned to which tunnels.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by
   the Internet Engineering Steering Group (IESG).  Further
   information on Internet Standards is available in Section 2 of
   RFC 5741.

   Information about the current status of this document, any
   errata, and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7582.

Page 2 
Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................4
      1.2. Overview ...................................................9
           1.2.1. Bidirectional P-Tunnel Technologies ................10
           1.2.2. Reasons for Using Bidirectional P-Tunnels ..........11
           1.2.3. Knowledge of Group-to-RP and/or
                  Group-to-RPA Mappings ..............................12
           1.2.4. PMSI Instantiation Methods .........................12
   2. The All BIDIR-PIM Wildcard .....................................15
   3. Using Bidirectional P-Tunnels ..................................15
      3.1. Procedures Specific to the Tunneling Technology ...........15
           3.1.1. BIDIR-PIM P-Tunnels ................................16
           3.1.2. MP2MP LSPs .........................................17
      3.2. Procedures Specific to the PMSI Instantiation Method ......17
           3.2.1. Flat Partitioning ..................................17
                  3.2.1.1. When an S-PMSI Is a 'Match for
                           Transmission' .............................19
                  3.2.1.2. When an I-PMSI Is a 'Match for
                           Transmission' .............................20
                  3.2.1.3. When an S-PMSI Is a 'Match for Reception' .21
                  3.2.1.4. When an I-PMSI Is a 'Match for Reception' .22
           3.2.2. Hierarchical Partitioning ..........................23
                  3.2.2.1. Advertisement of PE Distinguisher Labels ..24
                  3.2.2.2. When an S-PMSI Is a 'Match for
                           Transmission' .............................25
                  3.2.2.3. When an I-PMSI Is a 'Match for
                           Transmission' .............................26
                  3.2.2.4. When an S-PMSI Is a 'Match for Reception' .27
                  3.2.2.5. When an I-PMSI Is a 'Match for Reception' .27
           3.2.3. Unpartitioned ......................................28
                  3.2.3.1. When an S-PMSI Is a 'Match for
                           Transmission' .............................30
                  3.2.3.2. When an S-PMSI Is a 'Match for Reception' .30
           3.2.4. Minimal Feature Set for Compliance .................31
   4. Security Considerations ........................................32
   5. References .....................................................32
      5.1. Normative References ......................................32
      5.2. Informative References ....................................33
   Acknowledgments ...................................................34
   Authors' Addresses ................................................34

Top      ToC       Page 4 
1.  Introduction

   The RFCs that specify multicast support for BGP/MPLS IP VPNs
   ([RFC6513], [RFC6514], and [RFC6625]) allow customer multicast data
   to be transported across a service provider's network though a set of
   multicast tunnels.  These tunnels are advertised in BGP multicast
   auto-discovery (A-D) routes, by means of a BGP attribute known as the
   "Provider Multicast Service Interface (PMSI) Tunnel" attribute.  The
   base specifications allow the use of bidirectional (multipoint-to-
   multipoint) multicast distribution trees and describe how to encode
   the identifiers for bidirectional trees into the PMSI Tunnel
   attribute.  However, those specifications do not provide all the
   necessary detailed procedures for using bidirectional tunnels; the
   full specification of these procedures was considered to be outside
   the scope of those documents.  The purpose of this document is to
   provide all the necessary procedures for using bidirectional trees in
   a service provider's network to carry the multicast data of VPN
   customers.

1.1.  Terminology

   This document uses terminology from [RFC6513] and, in particular,
   uses the prefixes "C-" and "P-", as specified in Section 3.1 of
   [RFC6513], to distinguish addresses in the "customer address space"
   from addresses in the "provider address space".  The following
   terminology and acronyms are particularly important in this document:

   o  MVPN

      Multicast Virtual Private Network -- a VPN [RFC4364] in which
      multicast service is offered.

   o  VRF

      VPN Routing and Forwarding table [RFC4364].

   o  PE

      A Provider Edge router, as defined in [RFC4364].

   o  SP

      Service Provider.

   o  LSP

      An MPLS Label Switched Path.

Top      ToC       Page 5 
   o  P2MP

      Point-to-Multipoint.

   o  MP2MP

      Multipoint-to-multipoint.

   o  Unidirectional

      Adjective for a multicast distribution tree in which all traffic
      travels downstream from the root of the tree.  Traffic can enter a
      unidirectional tree only at the root.  A P2MP LSP is one type of
      unidirectional tree.  Multicast distribution trees set up by
      Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]
      are also unidirectional trees.  Data traffic traveling along a
      unidirectional multicast distribution tree is sometimes referred
      to in this document as "unidirectional traffic".

   o  Bidirectional

      Adjective for a multicast distribution tree in which traffic may
      travel both upstream (towards the root) and downstream (away from
      the root).  Traffic may enter a bidirectional tree at any node.
      An MP2MP LSP is one type of bidirectional tree.  Multicast
      distribution trees created by Bidirectional Protocol Independent
      Multicast (BIDIR-PIM) [RFC5015] are also bidirectional trees.

      Data traffic traveling along a bidirectional multicast
      distribution tree is sometimes referred to in this document as
      "bidirectional traffic".

   o  P-tunnel

      A tunnel through the network of one or more SPs.  In this
      document, the P-tunnels we speak of are instantiated as
      bidirectional multicast distribution trees.

   o  SSM

      Source-Specific Multicast.   When SSM is being used, a multicast
      distribution tree carries traffic from only a single source.

   o  ASM

      Any Source Multicast.  When ASM is being used, some multicast
      distribution trees ("share trees") carry traffic from multiple
      sources.

Top      ToC       Page 6 
   o  C-S

      Multicast Source.  A multicast source address, in the address
      space of a customer network.

   o  C-G

      Multicast Group.  A multicast group address (destination address)
      in the address space of a customer network.  When used without
      qualification, "C-G" may refer to either a unidirectional group
      address or a bidirectional group address.

   o  C-G-BIDIR

      A bidirectional multicast group address (i.e., a group address
      whose IP multicast distribution tree is built by BIDIR-PIM).

   o  C-multicast flow or C-flow

      A customer multicast flow.  A C-flow travels through VPN customer
      sites on a multicast distribution tree set up by the customer.
      These trees may be unidirectional or bidirectional, depending upon
      the multicast routing protocol used by the customer.  A C-flow
      travels between VPN customer sites by traveling through P-tunnels.

      A C-flow from a particular customer source is identified by the
      ordered pair (source address, group address), where each address
      is in the customer's address space.  The identifier of such a
      C-flow is usually written as (C-S,C-G).

      If a customer uses the ASM model, then 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)" flow to refer to a
      set of C-flows that travel along the same shared tree in the
      customer sites.

   o  C-BIDIR flow or bidirectional C-flow

      A C-flow that, in the VPN customer sites, travels along a
      bidirectional multicast distribution tree.  The term "C-BIDIR
      flow" indicates that the customer's bidirectional tree has been
      set up by BIDIR-PIM.

   o  RP

      A Rendezvous Point, as defined in [RFC4601].

Top      ToC       Page 7 
   o  C-RP

      A Rendezvous Point whose address is in the customer's address
      space.

   o  RPA

      A Rendezvous Point Address, as defined in [RFC5015].

   o  C-RPA

      An RPA in the customer's address space.

   o  P-RPA

      An RPA in the SP's address space.

   o  Selective P-tunnel

      A P-tunnel that is joined only by PE routers that need to receive
      one or more of the C-flows that are traveling through that
      P-tunnel.

   o  Inclusive P-tunnel

      A P-tunnel that is joined by all PE routers that attach to sites
      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.

Top      ToC       Page 8 
   o  Intra-AS I-PMSI A-D route

      Intra-AS (Autonomous System) Inclusive Provider Multicast Service
      Interface Auto-Discovery route.  Carried in BGP Update messages,
      these routes can be used to advertise the use of Inclusive
      P-tunnels.  See [RFC6514], Section 4.1.

   o  S-PMSI A-D route

      Selective Provider Multicast Service Interface Auto-Discovery
      route.  Carried in BGP Update messages, these routes are used to
      advertise the fact that a particular C-flow or a particular set of
      C-flows is bound to (i.e., is traveling through) a particular
      P-tunnel.  See [RFC6514], Section 4.3.

   o  (C-S,C-G) S-PMSI A-D route

      An S-PMSI A-D route whose NLRI (Network Layer Reachability
      Information) contains C-S in its "Multicast Source" field and C-G
      in its "Multicast Group" field.

   o  (C-*,C-G) S-PMSI A-D route

      An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its
      "Multicast Source" field and C-G in its "Multicast Group" field.
      See [RFC6625].

   o  (C-*,C-G-BIDIR) S-PMSI A-D route

      An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its
      "Multicast Source" field and C-G-BIDIR in its "Multicast Group"
      field.  See [RFC6625].

   o  (C-*,C-*) S-PMSI A-D route

      An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
      "Multicast Source" field and the wildcard C-* in its "Multicast
      Group" field.  See [RFC6625].

   o  (C-*,C-*-BIDIR) S-PMSI A-D route

      An S-PMSI A-D route whose NLRI contains the wildcard C-* in its
      "Multicast Source" field and the wildcard "C-*-BIDIR" in its
      "Multicast Group" field.  See Section 2 of this document.

Top      ToC       Page 9 
   o  (C-S,C-*) S-PMSI A-D route

      An S-PMSI A-D route whose NLRI contains C-S in its "Multicast
      Source" field and the wildcard C-* in its "Multicast Group" field.
      See [RFC6625].

   o  Wildcard S-PMSI A-D route

      A (C-*,C-G) S-PMSI A-D route, a (C-*,C-*) S-PMSI A-D route, a
      (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D route.

   o  PTA

      PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel.
      See [RFC6514], Section 8.

   The terminology used for categorizing S-PMSI A-D routes will also be
   used for categorizing the S-PMSIs advertised by those routes.  For
   example, the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will
   be known as a "(C-*,C-G) S-PMSI".

   Familiarity with multicast concepts and terminology [RFC4601] is also
   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document, when and only when appearing in all caps, are to be
   interpreted as described in [RFC2119].

1.2.  Overview

   The base documents for MVPN ([RFC6513] and [RFC6514]) define a "PMSI
   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
   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
   the PTA.  However, those documents do not contain the full set of
   specifications governing the use of bidirectional P-tunnels; rather,
   those documents declare the full set of specifications for using
   bidirectional P-tunnels to be outside their scope.  Similarly, the

Top      ToC       Page 10 
   use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D
   routes is declared by [RFC6625] to be "outside the scope" of that
   document.

   This document provides the specifications governing the use of
   bidirectional P-tunnels to provide MVPN support.  This includes the
   procedures for assigning C-flows to specific bidirectional P-tunnels,
   for advertising the fact that a particular C-flow has been assigned
   to a particular bidirectional P-tunnel, and for determining the
   bidirectional P-tunnel on which a given C-flow may be expected.

   The C-flows carried on bidirectional P-tunnels may, themselves, be
   either unidirectional or bidirectional.  Procedures are provided for
   both cases.

   This document does not specify any new data encapsulations for
   bidirectional P-tunnels.  Section 12 ("Encapsulations") of [RFC6513]
   applies unchanged.

   With regard to the procedures for using bidirectional P-tunnels to
   instantiate PMSIs, if there is any conflict between the procedures
   specified in this document and the procedures of [RFC6513],
   [RFC6514], or [RFC6625], the procedures of this document take
   precedence.

   The use of bidirectional P-tunnels to support extranets [MVPN-XNET]
   is outside the scope of this document.  The use of bidirectional
   P-tunnels as "segmented P-tunnels" (see Section 8 of [RFC6513] and
   various sections of [RFC6514]) is also outside the scope of this
   document.

1.2.1.  Bidirectional P-Tunnel Technologies

   This document supports two different technologies for creating and
   maintaining bidirectional P-tunnels:

   o  Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that
      are created through the use of the Label Distribution Protocol
      (LDP) Multipoint-to-Multipoint extensions [RFC6388].

   o  Multicast distribution trees that are created through the use of
      BIDIR-PIM [RFC5015].

   Other bidirectional tunnel technologies are outside the scope of this
   document.

Top      ToC       Page 11 
1.2.2.  Reasons for Using Bidirectional P-Tunnels

   Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or
   S-PMSIs.

   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
   C-BIDIR support, using the "Partitioned Set of PEs" technique
   discussed in Section 11.2 of [RFC6513] and Section 3.6 of [RFC6517].
   This technique can be used whether the C-BIDIR flows are being
   carried on an I-PMSI or an S-PMSI.

   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
   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
   MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e.,
   with P2MP multicast distribution trees) requires n multicast
   distribution trees, each one rooted at a different PE.  If the I-PMSI
   is instantiated by a bidirectional P-tunnel, a single multicast
   distribution tree can be used, assuming appropriate support by the
   provisioning system.

   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
   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
   SP.

   These two reasons for using bidirectional P-tunnels may appear to be
   somewhat in conflict with each other, since (as will be seen in
   subsequent sections) the use of bidirectional P-tunnels for C-BIDIR
   support may require multiple bidirectional P-tunnels per VPN.  Each
   such P-tunnel is associated with a particular "distinguished PE", and
   can only carry those C-BIDIR flows whose C-RPAs are reachable through
   its distinguished PE.  However, on platforms that support MPLS
   upstream-assigned labels ([RFC5331]), PE Distinguisher Labels
   (Section 4 of [RFC6513] and Section 8 of [RFC6514]) can be used to
   aggregate multiple bidirectional P-tunnels onto a single outer
   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
   bidirectional P-tunnels, and since many deployed router platforms do
   not support upstream-assigned labels at the current time, this
   document specifies several different methods of using bidirectional
   P-tunnels to instantiate PMSIs.  We refer to these as "PMSI
   Instantiation Methods".  The method or methods deployed by any

Top      ToC       Page 12 
   particular SP will depend upon that SP's goals and engineering trade-
   offs and upon the set of platforms deployed by that SP.

   The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D
   routes are not exactly the same as the rules for using unidirectional
   P-tunnels, and the rules are also different for the different PMSI
   instantiation methods.  Subsequent sections of this document specify
   the rules in detail.

1.2.3.  Knowledge of Group-to-RP and/or Group-to-RPA Mappings

   If a VPN customer is making use of a particular ASM group address,
   the PEs of that VPN generally need to know the group-to-RP mappings
   that are used within the VPN.  If a VPN customer is making use of
   BIDIR-PIM group addresses, the PEs need to know the group-to-RPA
   mappings that are used within the VPN.  Commonly, the PEs obtain this
   knowledge either through provisioning or by participating in a
   dynamic "group-to-RP(A) mapping discovery protocol" that runs within
   the VPN.  However, the way in which this knowledge is obtained is
   outside the scope of this document.

   The PEs also need to be able to forward traffic towards the C-RPs
   and/or C-RPAs and to determine whether the next-hop interface of the
   route to a particular C-RP(A) is a VRF interface or a PMSI.  This is
   done by applying the procedures of [RFC6513], Section 5.1.

1.2.4.  PMSI Instantiation Methods

   This document specifies three methods for using bidirectional
   P-tunnels to instantiate PMSIs: two partitioned methods (the Flat
   Partitioned Method and the Hierarchical Partitioned Method) and the
   Unpartitioned Method.

   o  Partitioned Methods

      In the Partitioned Methods, a particular PMSI is instantiated by a
      set of bidirectional P-tunnels.  These P-tunnels may be aggregated
      (as inner P-tunnels) into a single outer bidirectional P-tunnel
      ("Hierarchical Partitioning"), or they may be unaggregated ("Flat
      Partitioning").  Any PE that joins one of these P-tunnels can
      transmit a packet on it, and the packet will be received by all
      the other PEs that have joined the P-tunnel.  For each such
      P-tunnel (each inner P-tunnel, in the case of Hierarchical
      Partitioning) there is one PE that is its distinguished PE.  When
      a PE receives a packet from a given P-tunnel, the PE can determine
      from the packet's encapsulation the P-tunnel it has arrived on,
      and it can thus infer the identity of the distinguished PE
      associated with the packet.  This association plays an important

Top      ToC       Page 13 
      role in the treatment of the packet, as specified later on in this
      document.

      The number of P-tunnels needed (the number of inner P-tunnels
      needed, if Hierarchical Partitioning is used) depends upon a
      number of factors that are described later in this document.

      The Hierarchical Partitioned Method requires the use of upstream-
      assigned MPLS labels (PE Distinguisher Labels) and requires the
      use of the PE Distinguisher Labels attribute in BGP.  The Flat
      Partitioned Method requires neither of these.

      The Partitioned Method (either Flat or Hierarchical) is a
      prerequisite for implementing the "Partitioned Sets of PEs"
      technique of supporting C-BIDIR, as discussed in [RFC6513],
      Section 11.2.  The Partitioned Method (either Flat or
      Hierarchical) is also a prerequisite for applying the "Discarding
      Packets from Wrong PE" technique, discussed in [RFC6513], Section
      9.1.1, to a PMSI that is instantiated by a bidirectional P-tunnel.

      The Flat Partitioned Method is a prerequisite for implementing the
      "Partial Mesh of MP2MP P-Tunnels" technique for carrying customer
      bidirectional (C-BIDIR) traffic, as discussed in [RFC6513],
      Section 11.2.3.

      The Hierarchical Partitioned Method is a prerequisite for
      implementing the "Using PE Distinguisher Labels" technique of
      carrying customer bidirectional (C-BIDIR) traffic, as discussed in
      [RFC6513], Section 11.2.2.

      Note that a particular deployment may choose to use the
      Partitioned Methods for carrying the C-BIDIR traffic on
      bidirectional P-tunnels, while carrying other traffic either on
      unidirectional P-tunnels or on bidirectional P-tunnels using the
      Unpartitioned Method.  Routers in a given deployment must be
      provisioned to know which PMSI instantiation method to use for
      which PMSIs.

      There may be ways of implementing the Partitioned Methods with
      PMSIs that are instantiated by unidirectional P-tunnels.  (See,
      e.g., [MVPN-BIDIR-IR].)  However, that is outside the scope of the
      current document.

   o  Unpartitioned Method

      In the Unpartitioned Method, a particular PMSI can be instantiated
      by a single bidirectional P-tunnel.  Any PE that joins the tunnel
      can transmit a packet on it, and the packet will be received by

Top      ToC       Page 14 
      all the other PEs that have joined the tunnel.  The receiving PEs
      can determine the tunnel on which the packet was transmitted, but
      they cannot determine which PE transmitted the packet, nor can
      they associate the packet with any particular distinguished PE.

      When the Unpartitioned Method is used, this document does not
      mandate that only one bidirectional P-tunnel be used to
      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
      choice of which such P-tunnel to use when transmitting, and the
      receiving PEs must be prepared to receive from any of those
      P-tunnels.  The use of multiple P-tunnels in this case provides
      additional robustness, but it does not provide additional
      functionality.

   If bidirectional P-tunnels are being used to instantiate the PMSIs of
   a given MVPN, one of these methods must be chosen for that MVPN.  All
   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
   the Partitioned (either Flat or Hierarchical) Methods or the
   Unpartitioned Method.  The method used for a given MVPN is determined
   by 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 the same method for the given MVPN's I-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
   Methods (either Flat or Hierarchical) or the Unpartitioned Method may
   be used.  The method used by a given VRF is determined by
   provisioning.  It is desirable to be able to provision this on a per-
   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
   bidirectional P-tunnels.

   If one of the Partitioned Methods is used, all the VRFs of a single
   MVPN MUST be provisioned to use the same variant of the Partitioned
   Methods, i.e., either they must all use the Flat Partitioned Method
   or they must all use the Hierarchical Partitioned Method.

   It is valid to use the Unpartitioned Method to instantiate the
   I-PMSIs, while using one of the Partitioned Methods to instantiate
   the S-PMSIs.

   It is valid to instantiate some S-PMSIs by unidirectional P-tunnels
   and others by bidirectional P-tunnels.

Top      ToC       Page 15 
   The procedures for the use of bidirectional P-tunnels, specified in
   subsequent sections of this document, depend on both the tunnel
   technology and the PMSI instantiation method.  Note that this
   document does not specify procedures for every possible combination
   of tunnel technology and PMSI instantiation method.

2.  The All BIDIR-PIM Wildcard

   [RFC6514] specifies the method of encoding C-multicast source and
   group addresses into the NLRI of certain BGP routes.  [RFC6625]
   extends that specification by allowing the source and/or group
   address to be replaced by a wildcard.  When an MVPN customer is using
   BIDIR-PIM, it is useful to be able to advertise an S-PMSI A-D route
   whose semantics are "by default, all BIDIR-PIM C-multicast traffic
   (within a given VPN) that has not been bound to any other P-tunnel is
   bound to the bidirectional P-tunnel identified by the PTA of this
   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.

   Therefore, we define a special value of the group wildcard, whose
   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
   zero.  That is, the "multicast group length" field contains the value
   0x08, and the "multicast group" field is a single octet containing
   the value 0x00.  (This encoding is distinct from the group wildcard
   encoding defined in [RFC6625]).  We will use the notation
   (C-*,C-*-BIDIR) to refer to the "all BIDIR-PIM groups" wildcard.



(page 15 continued on part 2)

Next RFC Part