doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6625.txt b/doc/rfc/rfc6625.txt
new file mode 100644
index 0000000..d5969ee
--- /dev/null
+++ b/doc/rfc/rfc6625.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     E. Rosen, Ed.
+Request for Comments: 6625                           Cisco Systems, Inc.
+Updates: 6514                                            Y. Rekhter, Ed.
+Category: Standards Track                         Juniper Networks, Inc.
+ISSN: 2070-1721                                            W. Henderickx
+                                                          Alcatel-Lucent
+                                                                  R. Qiu
+                                                                  Huawei
+                                                                May 2012
+
+
+            Wildcards in Multicast VPN Auto-Discovery Routes
+
+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 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/rfc6625.
+
+
+
+
+
+
+Rosen, et al.                Standards Track                    [Page 1]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+      1.2. Wildcards in S-PMSI A-D Routes .............................5
+      1.3. Use Cases ..................................................5
+   2. Encoding of Wildcards ...........................................7
+   3. Finding the Matching S-PMSI A-D Route ...........................8
+      3.1. Finding the Match for Data Transmission ....................8
+      3.2. Finding the Match for Data Reception .......................9
+           3.2.1. Finding the Match for (C-S,C-G) .....................9
+           3.2.2. Finding the Wildcard Match for (C-*,C-G) ............9
+   4. Procedures for S-PMSI A-D Routes with Wildcards ................10
+      4.1. Procedures for All Kinds of Wildcards .....................10
+      4.2. Procedures for (C-*,C-G) S-PMSI A-D Routes ................11
+      4.3. Procedures for (C-S,C-*) S-PMSI A-D Routes ................12
+      4.4. Procedures for (C-*,C-*) S-PMSI A-D Routes ................13
+   5. Security Considerations ........................................15
+   6. Acknowledgments ................................................15
+   7. Normative References ...........................................15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen, et al.                Standards Track                    [Page 2]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+1.  Introduction
+
+   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.
+
+1.1.  Terminology
+
+   This document uses terminology from [MVPN] and, in particular, uses
+   the prefixes "C-" and "P-", as specified in Section 3.1 of [MVPN], 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 [L3VPN] in which
+        multicast service is offered.
+
+      - VRF
+
+        VPN Routing and Forwarding table [L3VPN].
+
+      - 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.
+
+
+
+Rosen, et al.                Standards Track                    [Page 3]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+      - 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 [PIM].
+
+      - 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 [PIM] 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 [RFC2119].
+
+
+
+
+
+
+Rosen, et al.                Standards Track                    [Page 4]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+1.2.  Wildcards in S-PMSI A-D Routes
+
+   As specified in [MVPN] and [MVPN-BGP], 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 [MVPN] and [MVPN-BGP].  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.
+
+1.3.  Use Cases
+
+   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 [MVPN] and [MVPN-BGP] 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
+
+
+
+Rosen, et al.                Standards Track                    [Page 5]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+        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
+
+
+
+
+
+Rosen, et al.                Standards Track                    [Page 6]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+        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 Section 4, 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.
+
+2.  Encoding of Wildcards
+
+   Per [MVPN-BGP] Section 4.3, 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.
+
+
+
+
+
+Rosen, et al.                Standards Track                    [Page 7]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+      - 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.
+
+3.  Finding the Matching S-PMSI A-D Route
+
+   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 Section 4 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 3.1 and 3.2, 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.
+
+3.1.  Finding the Match for Data Transmission
+
+   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.
+
+
+
+
+
+Rosen, et al.                Standards Track                    [Page 8]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+      - 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.
+
+3.2.  Finding the Match for Data Reception
+
+   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.
+
+3.2.1.  Finding the Match for (C-S,C-G)
+
+   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" [MVPN] 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.
+
+3.2.2.  Finding the Wildcard Match for (C-*,C-G)
+
+   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 [MVPN-BGP]), it may also
+   match one or more wildcard S-PMSI A-D routes, as specified below.
+
+
+
+
+
+Rosen, et al.                Standards Track                    [Page 9]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+   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 [MVPN] 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 [MVPN] 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.
+
+4.  Procedures for S-PMSI A-D Routes with Wildcards
+
+4.1.  Procedures for All Kinds of Wildcards
+
+   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.
+
+
+
+
+
+Rosen, et al.                Standards Track                   [Page 10]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+   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 [MVPN-BGP], an S-PMSI A-D route is carried in the
+   NLRI field of an MP_REACH_NLRI attribute (see [BGP-MP]).  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.
+
+4.2.  Procedures for (C-*,C-G) S-PMSI A-D Routes
+
+   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
+
+
+
+
+
+Rosen, et al.                Standards Track                   [Page 11]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+   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 Section 3.1, 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 Section 3.2) 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 Section 12.3
+        ("Receiving S-PMSI A-D Routes by PEs") of [MVPN-BGP] 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 Section 3.2) each such (C-S,C-G).
+
+      - Otherwise, the PE "ignores" the route.
+
+4.3.  Procedures for (C-S,C-*) S-PMSI A-D Routes
+
+   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
+
+
+
+Rosen, et al.                Standards Track                   [Page 12]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+   (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 Section 3.1, 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 Section 3.2), 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 Section 3.2) a (C-S,C-*) S-PMSI A-D route, then PE1
+   applies the procedures of Section 12.3 ("Receiving S-PMSI A-D Routes
+   by PEs") of [MVPN-BGP] to the matching S-PMSI A-D route.
+
+4.4.  Procedures for (C-*,C-*) S-PMSI A-D Routes
+
+   (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.
+
+
+
+
+Rosen, et al.                Standards Track                   [Page 13]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+      - 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 Section 3.1, 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 Section 3.2), 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 Section 12.3
+   ("Receiving S-PMSI A-D Routes by PEs") of [MVPN-BGP] 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
+        Section 3.2) 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
+        Section 3.2) the (C-*,C-*) S-PMSI A-D route.
+
+
+
+
+Rosen, et al.                Standards Track                   [Page 14]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+5.  Security Considerations
+
+   There are no additional security considerations beyond those of
+   [MVPN] and [MVPN-BGP].
+
+6.  Acknowledgments
+
+   The authors wish to thank Arjen Boers, Dongling Duan, Apoorva Karan,
+   Thomas Morin, Keyur Patel, Karthik Subramanian, and Kurt Windisch for
+   many helpful discussions.
+
+7.  Normative References
+
+   [BGP-MP]    Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
+               "Multiprotocol Extensions for BGP-4", RFC 4760,
+               January 2007.
+
+   [L3VPN]     Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+               Networks (VPNs)", RFC 4364, February 2006.
+
+   [MVPN]      Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
+               MPLS/BGP IP VPNs", RFC 6513, February 2012.
+
+   [MVPN-BGP]  Aggarwal, R., Rosen, E., Morin, T., and Y.  Rekhter, "BGP
+               Encodings and Procedures for Multicast in MPLS/BGP IP
+               VPNs", RFC 6514, February 2012.
+
+   [PIM]       Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+               Protocol Specification (Revised)", RFC 4601, August 2006.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen, et al.                Standards Track                   [Page 15]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+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
+
+
+
+
+
+
+
+
+
+Rosen, et al.                Standards Track                   [Page 16]
+
+RFC 6625              Wildcards in MVPN A-D Routes              May 2012
+
+
+   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]
+