<pre>Internet Engineering Task Force (IETF)                     E. Rosen, Ed.
Request for Comments: 6625                           Cisco Systems, Inc.
Updates: <a href="./rfc6514">6514</a>                                            Y. Rekhter, Ed.
Category: Standards Track                         Juniper Networks, Inc.
ISSN: 2070-1721                                            W. Henderickx
                                                          Alcatel-Lucent
                                                                  R. Qiu
                                                                  Huawei
                                                                May 2012


            <span class="h1">Wildcards in Multicast VPN Auto-Discovery Routes</span>

Abstract

   In Multicast Virtual Private Networks (MVPNs), customer multicast
   flows are carried in "tunnels" through a service provider's network.
   The base specifications for MVPN define BGP multicast VPN "auto-
   discovery routes" and specify how to use an auto-discovery route to
   advertise the fact that an individual customer multicast flow is
   being carried in a particular tunnel.  However, those specifications
   do not provide a way to specify, in a single such route, that
   multiple customer flows are being carried in a single tunnel.  Those
   specifications also do not provide a way to advertise that a
   particular tunnel is to be used by default to carry all customer
   flows, except in the case where that tunnel is joined by all the
   provider edge routers of the MVPN.  This document eliminates these
   restrictions by specifying the use of "wildcard" elements in the
   customer flow identifiers.  With wildcard elements, a single auto-
   discovery route can refer to multiple customer flows or even to all
   customer flows.

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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

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






<span class="grey">Rosen, et al.                Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-3">3</a>
      <a href="#section-1.2">1.2</a>. Wildcards in S-PMSI A-D Routes .............................<a href="#page-5">5</a>
      <a href="#section-1.3">1.3</a>. Use Cases ..................................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Encoding of Wildcards ...........................................<a href="#page-7">7</a>
   <a href="#section-3">3</a>. Finding the Matching S-PMSI A-D Route ...........................<a href="#page-8">8</a>
      <a href="#section-3.1">3.1</a>. Finding the Match for Data Transmission ....................<a href="#page-8">8</a>
      <a href="#section-3.2">3.2</a>. Finding the Match for Data Reception .......................<a href="#page-9">9</a>
           <a href="#section-3.2.1">3.2.1</a>. Finding the Match for (C-S,C-G) .....................<a href="#page-9">9</a>
           <a href="#section-3.2.2">3.2.2</a>. Finding the Wildcard Match for (C-*,C-G) ............<a href="#page-9">9</a>
   <a href="#section-4">4</a>. Procedures for S-PMSI A-D Routes with Wildcards ................<a href="#page-10">10</a>
      <a href="#section-4.1">4.1</a>. Procedures for All Kinds of Wildcards .....................<a href="#page-10">10</a>
      <a href="#section-4.2">4.2</a>. Procedures for (C-*,C-G) S-PMSI A-D Routes ................<a href="#page-11">11</a>
      <a href="#section-4.3">4.3</a>. Procedures for (C-S,C-*) S-PMSI A-D Routes ................<a href="#page-12">12</a>
      <a href="#section-4.4">4.4</a>. Procedures for (C-*,C-*) S-PMSI A-D Routes ................<a href="#page-13">13</a>
   <a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-15">15</a>
   <a href="#section-6">6</a>. Acknowledgments ................................................<a href="#page-15">15</a>
   <a href="#section-7">7</a>. Normative References ...........................................<a href="#page-15">15</a>
















<span class="grey">Rosen, et al.                Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   In Multicast Virtual Private Networks (MVPNs), customer multicast
   flows are carried in tunnels through a service provider's network.
   The base specifications for MVPN define BGP multicast VPN
   "auto-discovery routes" and specify how to use an auto-discovery
   route to advertise the fact that an individual customer multicast
   flow is being carried in a particular tunnel.  However, those
   specifications do not provide a way to specify, in a single such
   route, that multiple customer flows are being carried in a single
   tunnel.  Those specifications also do not provide a way to advertise
   that a particular tunnel is to be used by default to carry all
   customer flows, except in the case where that tunnel is joined by all
   the provider edge routers of the MVPN.  This document eliminates
   these restrictions by specifying the use of "wildcard" elements in
   the customer flow identifiers.  With wildcard elements, a single
   auto-discovery route can refer to multiple customer flows or even to
   all customer flows.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Terminology</span>

   This document uses terminology from [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] and, in particular, uses
   the prefixes "C-" and "P-", as specified in Section 3.1 of [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>], 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:

      - MVPN

        Multicast Virtual Private Network -- a VPN [<a href="#ref-L3VPN" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">L3VPN</a>] in which
        multicast service is offered.

      - VRF

        VPN Routing and Forwarding table [<a href="#ref-L3VPN" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">L3VPN</a>].

      - SP

        Service Provider.

      - P-tunnel

        A tunnel through the network of one or more SPs.

      - C-S

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



<span class="grey">Rosen, et al.                Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


      - C-G

        Multicast Group.  A multicast group address (destination
        address) in the address space of a customer network.

      - C-multicast flow or C-flow

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

      - RP

        A "Rendezvous Point", as defined in [<a href="#ref-PIM" title="&quot;Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)&quot;">PIM</a>].

      - C-RP

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

      - Selective P-tunnel

        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 through that P-tunnel.

      - Inclusive P-tunnel

        A P-tunnel that is joined by all PE routers that attach to sites
        of a given MVPN.

      - 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 particular C-flows are bound to (i.e.,
        are traveling through) particular P-tunnels.

   Familiarity with multicast concepts and terminology [<a href="#ref-PIM" title="&quot;Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)&quot;">PIM</a>] is also
   presupposed.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].






<span class="grey">Rosen, et al.                Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Wildcards in S-PMSI A-D Routes</span>

   As specified in [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] and [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>], an S-PMSI A-D route advertises
   that a particular C-flow is bound to a particular selective P-tunnel.

   The identifier of the specified C-flow, e.g., (C-S,C-G), is encoded
   into the Network Layer Reachability Information (NLRI) of the S-PMSI
   A-D route.  The identifier of the specified P-tunnel is encoded into
   an attribute (the "PMSI Tunnel Attribute") of the S-PMSI A-D route.
   Each S-PMSI A-D route thus specifies a single C-flow.  To bind
   multiple C-flows to a single P-tunnel, it is necessary to advertise
   one S-PMSI A-D route for each C-flow, specifying the same P-tunnel in
   each such route.

   This document defines OPTIONAL extensions to the procedures and
   encodings specified in [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] and [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>].  These extensions
   enable a single S-PMSI A-D route to advertise that multiple
   C-multicast flows are bound to a single P-tunnel.

   The extensions specified in this document are based on the notion of
   allowing the NLRI of an S-PMSI A-D route to contain a "wildcard".  In
   the NLRI encoding, a wildcard can replace the C-S, the C-G, or both.
   We use the notation "C-*" to denote a wildcard.  The extensions allow
   the NLRI to encode three kinds of wildcards: (C-*,C-*), (C-S,C-*),
   and (C-*,C-G).

   By using wildcards, a PE may be able to reduce the number of S-PMSI
   A-D routes it originates, thereby improving the scalability of the
   control plane.  There is, however, no impact on data plane
   scalability, as the number of P-tunnels is not reduced.

   Encoding and detailed procedures are specified in subsequent sections
   of this document.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Use Cases</span>

   There are a number of situations in which it can be useful to use
   wildcards in the NLRI of an S-PMSI A-D route.

      - Using a selective P-tunnel as the default tunnel.

        There are procedures in [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] and [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>] that allow a PE to
        advertise that it is going to use an inclusive P-tunnel as the
        P-tunnel on which it will transmit all C-flows by "default".
        However, those documents do not provide any way for a PE to
        advertise that it is going to use a selective P-tunnel as the
        P-tunnel on which it will transmit all C-flows by "default".
        Using the extensions defined in this document, a PE can



<span class="grey">Rosen, et al.                Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


        advertise that it is going to use a selective P-tunnel as its
        default P-tunnel.  It does so by advertising an S-PMSI A-D route
        whose NLRI contains (C-*,C-*).

      - Binding multiple C-flows traveling along a customer's Protocol
        Independent Multicast - Sparse Mode (PIM-SM) shared tree to a
        single P-tunnel.

        A PE router may be connected to an MVPN site that contains a
        customer RP (C-RP).  The C-RP may be the root of one or more
        shared trees.  In multicast terminology, these are known as
        (*,G) trees.  By advertising a single S-PMSI A-D route whose
        NLRI contains the (C-*,C-G) wildcard, the PE can bind all the
        C-flows traveling along a customer's (*,G) tree to a single
        P-tunnel.  This use case applies only when C-G is a
        non-bidirectional ASM (Any Source Multicast) group.

      - Binding multiple C-flows with the same C-group address to a
        single P-tunnel, even if each such C-flow is traveling along a
        customer's PIM source tree.

        A PE router may be connected to an MVPN site containing several
        multicast sources that are all sending to a common multicast
        group, along a customer's PIM source trees.  Alternatively, the
        PE may be connected to several sites, each containing at least
        one source sending to the common multicast group.  By
        advertising a single S-PMSI A-D route whose NLRI contains
        (C-*,C-G), the PE can bind these C-flows to a single P-tunnel.

        This use case applies only when the C-group is a
        non-bidirectional ASM group.

      - Binding multiple C-flows with the same C-group address to a
        single P-tunnel, when those C-flows are traveling along a
        customer's BIDIR-PIM shared tree.

        This use case applies only when the C-group is a BIDIR-PIM
        group.

      - Binding multiple C-flows from a given C-source to a given
        P-tunnel, irrespective of whether those C-flows all have the
        same C-group address.

        This can be useful when the C-group addresses are SSM (Single
        Source Multicast) addresses.  Suppose, for example, that a given
        source transmits multiple "channels" of information, each with





<span class="grey">Rosen, et al.                Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


        its own C-group address.  It may be desirable to bind all these
        channels to a single P-tunnel, without having to advertise an
        S-PMSI A-D route for each one.

   Of course, a specific C-flow, (C-S,C-G), can always be assigned
   individually to a particular P-tunnel by advertising an S-PMSI A-D
   route whose NLRI contains (C-S,C-G).

   In <a href="#section-4">Section 4</a>, we will sometimes speak of an S-PMSI A-D route being
   ignored.  When we say the route is "ignored", we do not mean that its
   normal BGP processing is not done, but that the route is not
   considered when determining which P-tunnel to use when receiving
   multicast data, and that the MPLS label values it conveys are not
   used.  We will use "ignore" in quotes to indicate this meaning.

   This document provides procedures only for the case where the
   P-tunnels are "unidirectional", i.e., point-to-multipoint.  The use
   of "bidirectional" (multipoint-to-multipoint) P-tunnels is outside
   the scope of this document.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Encoding of Wildcards</span>

   Per [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>] <a href="#section-4.3">Section 4.3</a>, the MCAST-VPN NLRI in an S-PMSI A-D route
   is encoded as follows:

                +-----------------------------------+
                |      RD   (8 octets)              |
                +-----------------------------------+
                | Multicast Source Length (1 octet) |
                +-----------------------------------+
                |  Multicast Source (variable)      |
                +-----------------------------------+
                |  Multicast Group Length (1 octet) |
                +-----------------------------------+
                |  Multicast Group   (variable)     |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   where the "source length" and "group length" fields always have a
   non-zero value.  This document specifies that a "zero-length" source
   or group represents the corresponding wildcard.  Specifically,

      - A source wildcard is encoded as a zero-length source field.
        That is, the "multicast source length" field contains the value
        0x00, and the "multicast source" field is omitted.





<span class="grey">Rosen, et al.                Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


      - A group wildcard is encoded as a zero-length group field.  That
        is, the "multicast group length" field contains the value 0x00,
        and the "multicast group" field is omitted.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Finding the Matching S-PMSI A-D Route</span>

   This section gives the precise rules for determining the S-PMSI A-D
   route that is "matched" by a given (C-S,C-G) or (C-*,C-G).  The
   procedures in <a href="#section-4">Section 4</a> will make use of the matching rules defined
   in this section.

   All matching rules assume the context of a given VRF at a given PE.

   The rules that a PE applies to find the S-PMSI A-D route that matches
   a (C-S,C-G) C-flow that it needs to transmit are slightly different
   than the rules it applies to find the S-PMSI A-D route that matches a
   (C-S,C-G) C-flow that it needs to receive.  These rules are specified
   in Sections <a href="#section-3.1">3.1</a> and <a href="#section-3.2">3.2</a>, respectively.

   The S-PMSI A-D route that is matched by a given (C-S,C-G) may change
   over time, as the result of S-PMSI A-D routes being withdrawn or as a
   result of new S-PMSI A-D routes being originated and/or advertised.
   In particular, if (C-S,C-G) matches an S-PMSI A-D route whose NLRI
   contains (C-*,C-*), the origination or reception of an S-PMSI A-D
   route whose NLRI contains (C-S,C-G) may cause (C-S,C-G) to match the
   latter route instead.  Note also that the S-PMSI A-D route that
   matches a given (C-S,C-G) is independent of the order in which the
   routes were originated or received.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Finding the Match for Data Transmission</span>

   Consider a given PE; call it PE1.  At any given time, for a given VRF
   at PE1, there is a (possibly empty) set of S-PMSI A-D routes that PE1
   has originated and advertised, but not withdrawn.  We will refer to
   these routes as "currently originated" by PE1.  Suppose that PE1
   needs to transmit a particular C-flow (C-S,C-G) to one or more other
   PEs.  We use the following algorithm to find the S-PMSI A-D route
   that the C-flow "matches":

      - If there is an S-PMSI A-D route currently originated by PE1,
        whose NLRI contains (C-S,C-G), the (C-S,C-G) C-flow matches that
        route.

      - Otherwise, if there is an S-PMSI A-D route currently originated
        by PE1, whose NLRI contains (C-S,C-*), AND if C-G is an SSM
        group address, the (C-S,C-G) C-flow matches that route.





<span class="grey">Rosen, et al.                Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


      - Otherwise, if there is an S-PMSI A-D route currently originated
        by PE1, whose NLRI contains (C-*,C-G), AND if C-G is an ASM
        group address, the (C-S,C-G) C-flow matches that route.

      - Otherwise, if there is an S-PMSI A-D route currently originated
        by PE1, whose NLRI contains (C-*,C-*), the (C-S,C-G) C-flow
        matches that route.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Finding the Match for Data Reception</span>

   We refer to an S-PMSI A-D route as being "installed" (in a given VRF)
   if it has been selected by the BGP decision process as the preferred
   route for its NLRI.

   An S-PMSI A-D route is considered to be "originated by a given PE" if
   that PE's IP address is contained in the "Originating Router's IP
   Address" field in the MCAST-VPN NLRI of the route.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Finding the Match for (C-S,C-G)</span>

   Suppose that a PE router (call it PE1) needs to receive (C-S,C-G),
   and that PE1 has chosen another PE router (call it PE2) as the
   "upstream PE" [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] for that flow.

      - If there is an installed S-PMSI A-D route originated by PE2,
        whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that
        route.

      - Otherwise, if there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM
        multicast group address, then (C-S,C-G) matches that route.

      - Otherwise, if there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM
        multicast group address, then (C-S,C-G) matches that route.

      - Otherwise, if there is an installed S-PMSI A-D route originated
        by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches
        that route.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Finding the Wildcard Match for (C-*,C-G)</span>

   Suppose that a PE router (call it PE1) needs to receive (C-*,C-G)
   traffic.  Note that even if (C-*,C-G) matches a non-wildcard S-PMSI
   A-D route (as detailed in Section 12.3 of [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>]), it may also
   match one or more wildcard S-PMSI A-D routes, as specified below.





<span class="grey">Rosen, et al.                Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


   If on PE1 there is an installed S-PMSI A-D route originated by PE2,
   whose NLRI contains (C-*,C-G), then (C-*,C-G) matches this route if
   one of the following conditions holds:

      - PE1 determines that PE2 is the "upstream" PE [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] for the C-RP
        of C-G, or

      - PE1 has installed one or more Source Active A-D routes for C-G
        originated by PE2, and for at least one of these routes, PE1
        does not have a corresponding (C-S,C-G) state, or

      - C-G is a BIDIR-PIM group, or

      - Source Active A-D routes are not being used.

   If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2,
   but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then
   (C-*,C-G) matches the (C-*,C-*) route if one of the following
   conditions holds:

      - PE1 determines that PE2 is the "upstream" PE [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] for the C-RP
        of C-G, or

      - PE1 has installed one or more Source Active A-D routes for C-G
        originated by PE2, and for at least one of these routes, PE1
        does not have a corresponding (C-S,C-G) state, or

      - C-G is a BIDIR-PIM group, or

      - Source Active A-D routes are not being used.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Procedures for S-PMSI A-D Routes with Wildcards</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Procedures for All Kinds of Wildcards</span>

   This document defines procedures for the following uses of the
   wildcard in the NLRI of an S-PMSI A-D route:

      - (C-*,C-G): Source wildcard, group specified.

      - (C-S,C-*): Source specified, group wildcard.

      - (C-*,C-*): Source wildcard, group wildcard.

   All other wildcard functionality is outside the scope of this
   document.





<span class="grey">Rosen, et al.                Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


   The ability to originate S-PMSI A-D routes with a particular kind of
   wildcard is OPTIONAL.  However, if a PE has the ability to originate
   S-PMSI A-D routes with a particular kind of wildcard, it MUST have
   the ability to interpret and correctly process S-PMSI A-D routes with
   that kind of wildcard, and it SHOULD have the ability to interpret
   and correctly process all three kinds of wildcards.

   For a given MVPN, A PE MUST NOT originate S-PMSI A-D routes with a
   particular kind of wildcard unless it is known a priori that all PEs
   attached to that MVPN have the ability to interpret and correctly
   process that kind of wildcard.

   The criteria for originating and withdrawing S-PMSI A-D routes with
   wildcards are local to the originating PE.

   As specified in [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>], an S-PMSI A-D route is carried in the
   NLRI field of an MP_REACH_NLRI attribute (see [<a href="#ref-BGP-MP" title="&quot;Multiprotocol Extensions for BGP-4&quot;">BGP-MP</a>]).  Every
   S-PMSI A-D route has a particular address family (IPv4 or IPv6), as
   specified in the Address Family Identifier (AFI) field of the
   MP_REACH_NLRI attribute.  A wildcard in a particular S-PMSI A-D route
   always refers only to multicast flows of that same address family.

   The procedures specified in this document apply only when the PMSI
   Tunnel Attribute of an S-PMSI A-D route specifies a "unidirectional"
   P-tunnel.  The use of "bidirectional" P-tunnels (e.g., Multipoint-to-
   Multipoint Label Switched Paths, BIDIR-PIM trees) is outside the
   scope of this document.

   In the following sections, an S-PMSI A-D route whose NLRI contains
   (C-*,C-G), (C-S,C-*), or (C-*,C-*) will be referred to as a
   "(C-*,C-G) route", a "(C-S,C-*) route", or a "(C-*,C-*)" route,
   respectively.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Procedures for (C-*,C-G) S-PMSI A-D Routes</span>

   This document specifies the use of (C-*,C-G) S-PMSI A-D routes only
   in the case where C-G is an ASM group address.  Use of (C-*,C-G)
   S-PMSI A-D routes where C-G is an SSM group address is outside the
   scope of this document.  If a PE receives a (C-*,C-G) S-PMSI A-D
   route, and the PE can determine that C-G is an SSM group address, the
   PE SHOULD "ignore" this S-PMSI A-D route.

   By default, the set of Route Targets carried by a (C-*,C-G) S-PMSI
   A-D route originated by a given VRF is the same as the set of Route
   Targets carried in the (unicast) VPN-IP routes that originated from
   that VRF.  An implementation MUST allow the set of Route Targets





<span class="grey">Rosen, et al.                Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


   carried by the (C-*,C-G) S-PMSI A-D route to be specified by
   configuration.  In the absence of a configured set of Route Targets,
   the route MUST carry the default set of Route Targets.

   If a PE needs to transmit packets of a (C-S,C-G) C-flow, and if
   (C-S,C-G) matches a (C-*,C-G) S-PMSI A-D route according to the rules
   of <a href="#section-3.1">Section 3.1</a>, then the PE MUST use the P-tunnel advertised in this
   route for transmitting that C-flow.  (Note that it is impossible for
   a given (C-S,C-G) to match both a (C-*,C-G) wildcard and a (C-S,C-*)
   wildcard.)

   If PIM is being used as the PE-PE control protocol, then if the PE
   has (C-*,C-G) and/or (C-S,C-G) state that matches (according to the
   procedures of <a href="#section-3.2">Section 3.2</a>) an S-PMSI A-D route, the PE MUST join the
   P-tunnel specified in the PMSI Tunnel Attribute of that route.

   If BGP is being used as the PE-PE control protocol, then

      - If a given PE has currently originated a C-multicast Shared Tree
        Join for (C-*,C-G), and if (C-*,C-G) matches a (C-*,C-G) S-PMSI
        A-D route, then the PE applies the procedures of <a href="#section-12.3">Section 12.3</a>
        ("Receiving S-PMSI A-D Routes by PEs") of [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>] to that
        S-PMSI A-D route.

      - Otherwise (the given PE does not have a currently originated
        C-multicast Shared Tree Join for (C-*,C-G)), if there are one or
        more values of C-S for which the PE has a currently originated
        Source Tree Join C-multicast route for (C-S,C-G), the PE MUST
        join the tunnels advertised by the S-PMSI A-D routes that match
        (according to <a href="#section-3.2">Section 3.2</a>) each such (C-S,C-G).

      - Otherwise, the PE "ignores" the route.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Procedures for (C-S,C-*) S-PMSI A-D Routes</span>

   This document covers the use of (C-S,C-*) S-PMSI A-D routes for only
   the C-multicast flows where C-G is an SSM group address.  Use of
   (C-S,C-*) S-PMSI A-D routes for other C-multicast flows is outside
   the scope of this document.  Specifically, if a PE receives a
   (C-S,C-*) S-PMSI A-D route, and the PE can determine that C-G is not
   an SSM group address, the PE SHOULD "ignore" this S-PMSI A-D route.

   By default, the set of Route Targets carried by a (C-S,C-*) S-PMSI
   A-D route originated by a given VRF is an intersection between the
   set of Route Targets carried in the Intra-AS I-PMSI A-D route that
   originated from that VRF, and the set of Route Targets carried by the
   unicast VPN-IP route to C-S originated from that VRF.  An
   implementation MUST allow the set of Route Targets carried by the



<span class="grey">Rosen, et al.                Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


   (C-S,C-*) S-PMSI A-D route to be specified by configuration.  In the
   absence of a configured set of Route Targets, the route MUST carry
   the default set of Route Targets.

   If a PE needs to transmit packets of a (C-S,C-G) C-flow, and if
   (C-S,C-G) matches a (C-S,C-*) S-PMSI A-D route according to the rules
   of <a href="#section-3.1">Section 3.1</a>, then the PE MUST use the P-tunnel advertised in this
   route for transmitting that C-flow.  (Note that it is impossible for
   a given (C-S,C-G) to match both a (C-*,C-G) wildcard and a (C-S,C-*)
   wildcard.)

   If PIM is being used as the PE-PE control protocol for distributing
   C-multicast routing, and if a given PE needs to receive a (C-S,C-G)
   flow, and if (C-S,C-G) matches the (C-S,C-*) S-PMSI A-D route
   (according to the procedures of <a href="#section-3.2">Section 3.2</a>), then the PE MUST join
   the P-tunnel specified in the PMSI Tunnel Attribute of that route.

   If BGP is being used as the PE-PE control protocol for distributing
   C-multicast routing, and if there is some (C-S,C-G) such that (a) the
   PE has a currently originated (C-S,C-G) Source Tree Join C-multicast
   route, AND (b) the given (C-S,C-G) matches (according to the
   procedures of <a href="#section-3.2">Section 3.2</a>) a (C-S,C-*) S-PMSI A-D route, then PE1
   applies the procedures of <a href="#section-12.3">Section 12.3</a> ("Receiving S-PMSI A-D Routes
   by PEs") of [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>] to the matching S-PMSI A-D route.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Procedures for (C-*,C-*) S-PMSI A-D Routes</span>

   (C-*,C-*) S-PMSI A-D routes are used when, for a given MVPN, a PE has
   a policy not to use an I-PMSI for carrying multicast data traffic
   originated in the MVPN's site(s) connected to that PE.  When the
   (C-*,C-*) wildcard is used together with BGP C-multicast routing,
   this results in the "S-PMSI only" model, where no I-PMSIs are used at
   all for the given MVPN.

   A (C-*,C-*) S-PMSI A-D route is originated for a given MVPN by a
   given PE only if that PE has been provisioned with the policy to
   do so.

   When so provisioned, the PE MAY originate the (C-*,C-*) S-PMSI A-D
   route as soon as it is enabled to support the given MVPN.
   Alternatively, the PE MAY delay originating the route until one of
   the following conditions holds:

      - The PE-PE protocol for distributing C-multicast routing is PIM,
        and for the given MVPN, the PE has some (C-S,C-G) or (C-*,C-G)
        state for which the upstream interface is one of the VRF
        interfaces for the given MVPN.




<span class="grey">Rosen, et al.                Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


      - The PE-PE protocol for distributing C-multicast routing is BGP,
        and the given PE has received and installed either of the
        following:

        * a Source Tree Join C-multicast route, with the C-S contained
          in the route's NLRI being reachable via one of the given
          MVPN's VRF interfaces, or

        * a Shared Tree Join C-multicast route, with the C-RP carried in
          that route being reachable via one of the given MVPN's VRF
          interfaces.

   By default, the set of Route Targets carried by a (C-*,C-*) S-PMSI
   A-D route originated from a given VRF is the same as the set of Route
   Targets carried in the VPN-IP unicast routes originated from that
   VRF.  An implementation MUST allow the set of Route Targets carried
   by the (C-*,C-*) S-PMSI A-D route to be specified by configuration.
   In the absence of a configured set of Route Targets, the route MUST
   carry the default set of Route Targets, as specified above.

   If a PE needs to transmit packets of a (C-S,C-G) C-flow, and if
   (C-S,C-G) matches a (C-*,C-*) S-PMSI A-D route according to the rules
   of <a href="#section-3.1">Section 3.1</a>, then the PE MUST use the P-tunnel advertised in this
   route for transmitting that C-flow.  (Note that it is impossible for
   a given (C-S,C-G) to match both a (C-*,C-*) wildcard and any other
   wildcard.)

   If PIM is being used as the PE-PE control protocol for distributing
   C-multicast routing, and if a given PE, say PE1, needs to receive a
   (C-S,C-G) flow, and if (C-S,C-G) matches the (C-*,C-*) S-PMSI A-D
   route (according to the procedures of <a href="#section-3.2">Section 3.2</a>), then PE1 MUST
   join the P-tunnel specified in the PMSI Tunnel Attribute of that
   route.

   If BGP is being used as the PE-PE control protocol for distributing
   C-multicast routing, then if (and only if) one of the following
   conditions holds, the PE applies the procedures of <a href="#section-12.3">Section 12.3</a>
   ("Receiving S-PMSI A-D Routes by PEs") of [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>] to the matching
   S-PMSI A-D route.  The conditions are as follows:

      - The PE has a currently originated C-multicast Source Tree Join
        route for (C-S,C-G) that matches (according to the procedures of
        <a href="#section-3.2">Section 3.2</a>) the (C-*,C-*) S-PMSI A-D route, or

      - The PE has a currently originated a C-multicast Shared Tree Join
        route for (C-*,C-G) that matches (according to the procedures of
        <a href="#section-3.2">Section 3.2</a>) the (C-*,C-*) S-PMSI A-D route.




<span class="grey">Rosen, et al.                Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   There are no additional security considerations beyond those of
   [<a href="#ref-MVPN" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">MVPN</a>] and [<a href="#ref-MVPN-BGP" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">MVPN-BGP</a>].

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Acknowledgments</span>

   The authors wish to thank Arjen Boers, Dongling Duan, Apoorva Karan,
   Thomas Morin, Keyur Patel, Karthik Subramanian, and Kurt Windisch for
   many helpful discussions.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Normative References</span>

   [<a id="ref-BGP-MP">BGP-MP</a>]    Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
               "Multiprotocol Extensions for BGP-4", <a href="./rfc4760">RFC 4760</a>,
               January 2007.

   [<a id="ref-L3VPN">L3VPN</a>]     Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
               Networks (VPNs)", <a href="./rfc4364">RFC 4364</a>, February 2006.

   [<a id="ref-MVPN">MVPN</a>]      Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
               MPLS/BGP IP VPNs", <a href="./rfc6513">RFC 6513</a>, February 2012.

   [<a id="ref-MVPN-BGP">MVPN-BGP</a>]  Aggarwal, R., Rosen, E., Morin, T., and Y.  Rekhter, "BGP
               Encodings and Procedures for Multicast in MPLS/BGP IP
               VPNs", <a href="./rfc6514">RFC 6514</a>, February 2012.

   [<a id="ref-PIM">PIM</a>]       Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
               Protocol Specification (Revised)", <a href="./rfc4601">RFC 4601</a>, August 2006.

   [<a id="ref-RFC2119">RFC2119</a>]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.


















<span class="grey">Rosen, et al.                Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


Authors' Addresses

   Rahul Aggarwal
   Arktan

   EMail: raggarwa_1@yahoo.com


   Yiqun Cai
   Microsoft
   1065 La Avenida
   Mountain View, CA  94043

   EMail: yiqunc@microsoft.com


   Wim Henderickx
   Alcatel-Lucent

   EMail: wim.henderickx@alcatel-lucent.be


   Praveen Muley
   Alcatel-Lucent

   EMail: Praveen.Muley@alcatel-lucent.com


   Ray (Lei) Qiu
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   EMail: rayq@huawei.com


   Yakov Rekhter (editor)
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA  94089

   EMail: yakov@juniper.net









<span class="grey">Rosen, et al.                Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6625">RFC 6625</a>              Wildcards in MVPN A-D Routes              May 2012</span>


   Eric C. Rosen (editor)
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA  01719

   EMail: erosen@cisco.com


   IJsbrand Wijnands
   Cisco Systems, Inc.
   De kleetlaan 6a Diegem 1831
   Belgium

   EMail: ice@cisco.com





































Rosen, et al.                Standards Track                   [Page 17]
</pre>