12.  Using S-PMSI A-D Routes to Bind C-Trees to P-Tunnels

   This section describes BGP-based procedures for using S-PMSIs A-D
   routes to bind (C-S,C-G) trees to P-tunnels.

12.1.  Originating S-PMSI A-D Routes

   The following describes procedures for originating S-PMSI A-D routes
   by a PE.

   The PE constructs the MCAST-VPN NLRI of an S-PMSI A-D route for a
   given (C-S,C-G) as follows.

    + The RD in this NLRI is set to the RD of the MVPN's VRF associated
      with (C-S,C-G).

    + The Multicast Source field MUST contain the source address
      associated with the C-multicast stream, and the Multicast Source
      Length field is set appropriately to reflect this.

    + The Multicast Group field MUST contain the group address
      associated with the C-multicast stream, and the Multicast Group
      Length field is set appropriately to reflect this.

    + The Originating Router's IP Address field MUST be set to the IP
      address that the (local) PE places in the Global Administrator
      field of the VRF Route Import Extended Community of the VPN-IP
      routes advertised by the PE.  Note that the <RD, Originating
      Router's IP address> tuple uniquely identifies a given multicast
      VRF.

   The PE constructs the rest of the S-PMSI A-D route as follows.

   Depending on the type of P-multicast tree used for the P-tunnel, the
   PMSI Tunnel attribute of the S-PMSI A-D route is constructed as
   follows:

    + The PMSI Tunnel attribute MUST contain the identity of the
      P-multicast tree (note that the PE could create the identity of
      the tree prior to the actual instantiation of the tree).

    + If, in order to establish the P-multicast tree, the PE needs to
      know the leaves of the tree within its own AS, then the PE obtains
      this information from the Leaf A-D routes received from other
      PEs/ASBRs within its own AS (as other PEs/ASBRs originate Leaf A-D
      routes in response to receiving the S-PMSI A-D route) by setting
      the Leaf Information Required flag in the PMSI Tunnel attribute to
      1.

    + If a PE originates S-PMSI A-D routes with the Leaf Information
      Required flag in the PMSI Tunnel attribute set to 1, then the PE
      MUST be (auto-)configured with an import Route Target, which
      controls acceptance of Leaf A-D routes by the PE.  (Procedures for
      originating Leaf A-D routes by the PEs that receive the S-PMSI A-D
      route are described in Section 12.3.)

      This Route Target is IP address specific.  The Global
      Administrator field of this Route Target MUST be set to the IP
      address carried in the Next Hop of all the S-PMSI A-D routes
      advertised by this PE (if the PE uses different Next Hops, then
      the PE MUST be (auto-)configured with multiple import RTs, one per
      each such Next Hop).  The Local Administrator field of this Route
      Target MUST be set to 0.

      If the PE supports Route Target Constraint [RT-CONSTRAIN], the PE
      SHOULD advertise this import Route Target within its own AS using
      Route Target Constraints.  To constrain distribution of the Route
      Target Constraint routes to the AS of the advertising PE, these
      routes SHOULD carry the NO_EXPORT Community [RFC1997].

    + A PE MAY aggregate two or more S-PMSIs originated by the PE onto
      the same P-multicast tree.  If the PE already advertises S-PMSI
      A-D routes for these S-PMSIs, then aggregation requires the PE to
      re-advertise these routes.  The re-advertised routes MUST be the
      same as the original ones, except for the PMSI Tunnel attribute.
      If the PE has not previously advertised S-PMSI A-D routes for
      these S-PMSIs, then the aggregation requires the PE to advertise
      (new) S-PMSI A-D routes for these S-PMSIs.  The PMSI Tunnel
      attribute in the newly advertised/re-advertised routes MUST carry
      the identity of the P-multicast tree that aggregates the S-PMSIs.
      If at least some of the S-PMSIs aggregated onto the same
      P-multicast tree belong to different MVPNs, then all these routes
      MUST carry an MPLS upstream-assigned label [RFC5331].

   If all these aggregated S-PMSIs belong to the same MVPN, and this
   MVPN uses PIM as its C-multicast routing protocol, then the
   corresponding S-PMSI A-D routes MAY carry an MPLS upstream-assigned
   label [RFC5331].  Moreover, in this case, the labels MUST be distinct
   on a per-MVPN basis and MAY be distinct on a per-route basis.

   If all these aggregated S-PMSIs belong to the MVPN(s) that uses mLDP
   as its C-multicast routing protocol, then the corresponding S-PMSI
   A-D routes MUST carry an MPLS upstream-assigned label [RFC5331], and
   these labels MUST be distinct on a per-route (per-mLDP FEC) basis,
   irrespective of whether the aggregated S-PMSIs belong to the same or
   different MVPNs.

   The Next Hop field of the MP_REACH_NLRI attribute of the route MUST
   be set to the same IP address as the one carried in the Originating
   Router's IP Address field.

   The route always carries a set of Route Targets.  The default set of
   Route Targets is determined as follows:

    + If there is a (unicast) VPN-IP route to C-S originated from the
      VRF, but no (unicast) VPN-IP route to C-RP originated from the
      VRF, then the set of Route Targets is formed by a set intersection
      between the set of Route Targets carried in the Intra-AS I-PMSI A-
      D route originated from the VRF and the set of Route Targets
      carried by the (unicast) VPN-IP route to C-S.

    + If there is no (unicast) VPN-IP route to C-S originated from the
      VRF, but there is a (unicast) VPN-IP route to C-RP originated from
      the VRF, then the set of Route Targets is formed by a set
      intersection between the set of Route Targets carried in the
      intra-AS I-PMSI A-D route originated from the VRF and the set of
      Route Targets carried by the (unicast) VPN-IP route to C-RP.

    + If there is a (unicast) VPN-IP route to C-S originated from the
      VRF, and a (unicast) VPN-IP route to C-RP originated from the VRF,
      then the set of Route Targets is formed by a set intersection
      between the set of Route Targets carried in the Intra-AS I-PMSI A-
      D route originated from the VRF and the set union of Route Targets
      carried by the (unicast) VPN-IP route to C-S and the (unicast)
      VPN-IP route to C-RP.

   In each of the above cases, an implementation MUST allow the set of
   Route Targets carried by the 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.

12.2.  Handling S-PMSI A-D Routes by ASBRs

   Procedures for handling an S-PMSI A-D route by ASBRs (both within and
   outside of the AS of the PE that originates the route) are the same
   as specified in Section 9.2.3, except that instead of Inter-AS I-PMSI
   A-D routes, the procedures apply to S-PMSI A-D routes.

12.2.1.  Merging S-PMSI into an I-PMSI

   Consider the situation where:

    + An ASBR is receiving (or expecting to receive) inter-AS (C-S,C-G)
      data from upstream via an S-PMSI.

    + The ASBR is sending (or expecting to send) the inter-AS (C-S,C-G)
      data downstream via an I-PMSI.

   This situation may occur if the upstream providers have a policy of
   using S-PMSIs but the downstream providers have a policy of using
   I-PMSIs.  To support this situation, an ASBR MAY, under certain
   conditions, merge one or more upstream S-PMSIs into a downstream
   I-PMSI.

   An S-PMSI (corresponding to a particular S-PMSI A-D route) MAY be
   merged by a particular ASBR into an I-PMSI (corresponding to a
   particular Inter-AS I-PMSI A-D route) if and only if the following
   conditions all hold:

    + BGP is used to exchange C-multicast routes.

    + The S-PMSI A-D route and the Inter-AS I-PMSI A-D route originate
      in the same AS.  The Inter-AS I-PMSI A-D route carries the
      originating AS in the Source AS field of the NLRI of the route and
      in the AS_PATH attribute of the route.  The S-PMSI A-D route
      carries the originating AS in the AS_PATH attribute of the route.

    + The S-PMSI A-D route and the Inter-AS I-PMSI A-D route have
      exactly the same set of RTs.

    + For each (C-S,C-G) mentioned in the S-PMSI route, if the ASBR has
      installed a Source Tree Join (C-S,C-G) C-multicast route, then the
      S-PMSI route was originated by the upstream PE of the C-multicast
      route.  The address of the upstream PE is carried in the RT of the
      C-multicast route.  The address of the PE that originated the
      S-PMSI route is carried in the Originating Router's IP Address
      field of the MCAST-VPN NLRI of the route.

    + The ASBR supports the optional capability to discard (C-S,C-G)
      traffic received on an I-PMSI.

   An ASBR performs merging by stitching the tail end of the P-tunnel,
   as specified in the PMSI Tunnel attribute of the S-PMSI A-D route
   received by the ASBR, to the head of the P-tunnel, as specified in
   the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D route re-
   advertised by the ASBR.

   IP processing during merge: If an ASBR merges a (C-S,C-G) S-PMSI A-D
   route into an Inter-AS I-PMSI A-D route, the ASBR MUST discard all
   (C-S,C-G) traffic it receives on the tunnel advertised in the I-PMSI
   A-D route.

   An ASBR that merges an S-PMSI A-D route into an Inter-AS I-PMSI A-D
   route MUST NOT re-advertise the S-PMSI A-D route.

12.3.  Receiving S-PMSI A-D Routes by PEs

   Consider a PE that receives an S-PMSI A-D route.  If one or more of
   the VRFs on the PE have their import Route Targets that contain one
   or more of the Route Targets carried by the received S-PMSI A-D
   route, then for each such VRF (and associated MVPN-TIB) the PE
   performs the following.

   Procedures for receiving an S-PMSI A-D route by a PE (both within and
   outside of the AS of the PE that originates the route) are the same
   as specified in Section 9.2.3.4 except that (a) instead of Inter-AS

   I-PMSI A-D routes, the procedures apply to S-PMSI A-D routes and (b)
   a PE performs procedures specified in that section only if, in
   addition to the criteria there, one of the following is true:

    + the PE originates a Source Tree Join (C-S,C-G) C-multicast route,
      and the upstream PE of that route is the PE that originates the
      S-PMSI A-D route; or

    + the PE does not originate a Source Tree Join (C-S,C-G) C-multicast
      route, but it originates a Shared Tree Join (C-*,C-G) C-multicast
      route.  The best (as determined by the BGP route selection
      procedures) Source Active A-D route for (C-S,C-G) selected by the
      PE is originated by the same PE as the one that originates the
      S-PMSI A-D route; or

    + the PE does not originate a Source Tree Join (C-S,C-G), has not
      received any Source Active A-D routes for (C-S,C-G), but does
      originate a Shared Tree Join (C-*,C-G) route.  The upstream PE for
      that route is the PE that originates the received S-PMSI A-D
      route.

   If the received S-PMSI A-D route has a PMSI Tunnel attribute with the
   Leaf Information Required flag set to 1, then the PE originates a
   Leaf A-D route.  The Route Key of the Leaf A-D route is set to the
   MCAST-VPN NLRI of the S-PMSI A-D route.  The rest of the Leaf A-D
   route is constructed using the same procedures as specified in
   section 9.2.3.4.1, except that instead of originating Leaf A-D routes
   in response to receiving Inter-AS I-PMSI A-D routes, the procedures
   apply to originating Leaf A-D routes in response to receiving S-PMSI
   A-D routes.

   In addition to the procedures specified in Section 9.2.3.4.1, the PE
   MUST set up its forwarding path to receive (C-S,C-G) traffic from the
   tunnel advertised by the S-PMSI A-D route (the PE MUST switch to the
   S-PMSI).

   If a PE that is a leaf node of a particular Selective tunnel
   determines that it no longer needs to receive any of (C-S,C-G)s
   carried over that tunnel, the PE SHOULD prune itself off that tunnel.
   Procedures for pruning are specific to a particular tunneling
   technology.

13.  Switching from Shared a C-Tree to a Source C-Tree

   The procedures defined in this section only apply when the
   C-multicast routing protocol is PIM [RFC4601]; moreover, they only
   apply for the multicast ASM mode and MUST NOT be applied to multicast

   group addresses belonging to the SSM range.  The procedures also MUST
   NOT be applied when the C-multicast routing protocol is BIDIR-PIM
   [RFC5015].

   The procedures of this section are applicable only to MVPNs that use
   both shared (i.e., rooted at a C-RP) and source (i.e., rooted at a
   C-S) inter-site C-trees.

   These procedures are not applicable to MVPNs that do not use shared
   inter-site C-trees and rely solely on source inter-site C-trees.  See
   Section 14 for the procedures applicable to that scenario.

   Whether or not a given MVPN uses both inter-site shared and source
   C-trees must be known a priori (e.g., via provisioning).

   In the scenario where an MVPN customer switches from a C-RP-based
   tree (RPT) to the shortest path tree (SPT), in order to avoid packet
   duplication, choosing of a single consistent upstream PE, as
   described in [MVPN], may not suffice.  To illustrate this, consider a
   set of PEs {PE2, PE4, PE6} that are on the C-RP tree for (C-*,C-G)
   and have chosen a consistent upstream PE, as described in [MVPN], for
   (C-*,C-G) state.  Further, this upstream PE, say PE1, is using a
   Multidirectional Inclusive PMSI (MI-PMSI) for (C-*,C-G).  If a site
   attached to one of these PEs, say PE2, switches to the C-S tree for
   (C-S,C-G), PE2 generates a Source Tree Join C-multicast route towards
   the upstream PE that is on the path to C-S, say PE3.  PE3 also uses
   the MI-PMSI for (C-S,C-G), as PE1 uses for (C-*,C-G).  This results
   in {PE2, PE4, PE6} receiving duplicate traffic for (C-S,C-G) -- both
   on the C-RP tree (from PE1) and C-S tree (from PE3).  If it is
   desirable to suppress receiving duplicate traffic, then it is
   necessary to choose a single forwarder PE for (C-S,C-G).  The
   following describes how this is achieved.

13.1.  Source within a Site - Source Active Advertisement

   When, as a result of receiving a Source Tree Join C-multicast route
   for (C-S,C-G) from some other PE the local PE adds either the S-PMSI
   or the I-PMSI to the outgoing interface list of the (C-S,C-G) state
   (see Section 11.3.1.1), the local PE MUST originate a Source Active
   A-D route if the PE has not originated such route already.  The route
   carries a single MCAST-VPN NLRI constructed as follows:

    + The RD in this NLRI is set to the RD of the VRF of the MVPN on the
      PE.

    + The Multicast Source field MUST be set to C-S.  The Multicast
      Source Length field is set appropriately to reflect this.

    + The Multicast Group field MUST be set to C-G.  The Multicast Group
      Length field is set appropriately to reflect this.

   The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the
   IP address that the PE places in the Global Administrator field of
   the VRF Route Import Extended Community of the VPN-IP routes
   advertised by the PE from the MVPN's VRF.

   The route SHOULD carry the same set of Route Targets as the Intra-AS
   I-PMSI A-D route of the MVPN originated by the PE.

   Using the normal BGP procedures, the Source Active A-D route is
   propagated to all the PEs of the MVPN.

   Note that the advertisement of a Source Active A-D route for a given
   (C-S,C-G) could be combined, if desired, with the advertisement of an
   S-PMSI A-D route for the same (C-S,C-G).  This is accomplished by
   using the same BGP Update message to carry both the NLRI of the
   S-PMSI A-D route and the NLRI of the Source Active A-D route.

   Note that even if the originating PE advertises both the Source
   Active A-D route and the S-PMSI A-D route in the same BGP Update
   message, an implementation cannot assume that all other PEs will
   receive both of these routes in the same Update message.

   When, as a result of receiving a withdrawal of the previously
   advertised Source Tree Join C-multicast route for (C-S,C-G), the PE
   is going to remove the S-PMSI/I-PMSI from the outgoing interface list
   of the (C-S,C-G) state.  The local PE MUST also withdraw the Source
   Active A-D route for (C-S,C-G), if such a route has been advertised.

   Note that if the PE is also acting as a C-RP, but inter-site shared
   trees are being used, the reception of a PIM Register message by the
   PE does not result in the origination of a Source Active A-D route.

13.2.  Receiving Source Active A-D Route

   When a PE receives a new Source Active A-D route from some other PE,
   the PE finds a VRF whose import Route Targets match one or more of
   the Route Targets carried by the route.  If the match is found, then
   the PE updates the VRF with the received route.

   We say that a given (C-S,C-G) Source Active A-D route stored in a
   given VRF on a PE matches a given (C-*,C-G) entry present in the
   MVPN-TIB associated with the VRF if C-G carried by the route is the
   same as C-G of the entry, and the PE originates a Shared Tree Join
   C-multicast route for the same C-G as the C-G of the entry.

   When (as a result of receiving PIM messages from one of its CEs) a PE
   creates in one of its MVPN-TIBs a (new) (C-*,C-G) entry with a non-
   empty outgoing interface list that contains one or more PE-CE
   interfaces, the PE MUST check if it has any matching Source Active
   A-D routes.  If there is one or more such matching route, such that
   the PE does not have (C-S,C-G) state in its MVPN-TIB for (C-S,C-G)
   carried in the route, then the PE selects one of them (using the BGP
   route selection procedures), and sets up its forwarding path to
   receive (C-S,C-G) traffic from the tunnel that the originator of the
   selected Source Active A-D route uses for sending (C-S,C-G).

   When, as a result of receiving a new Source Active A-D route, a PE
   updates its VRF with the route, the PE MUST check if the newly
   received route matches any (C-*,C-G) entries.  If (a) there is a
   matching entry, (b) the PE does not have (C-S,C-G) state in its MVPN-
   TIB for (C-S,C-G) carried in the route, and (c) the received route is
   selected as the best (using the BGP route selection procedures), then
   the PE sets up its forwarding path to receive (C-S,C-G) traffic from
   the tunnel the originator of the selected Source Active A-D route
   uses for sending (C-S,C-G).

   Note that if the PE is also acting as a C-RP, and inter-site shared
   trees are being used, the BGP Source Active A-D routes do not replace
   the Multicast Source Discovery Protocol (MSDP) or PIM-based Anycast
   RP peerings among C-RPs that would be needed to disseminate source
   discovery information among C-RPs.

13.2.1.  Pruning Sources off the Shared Tree

   In addition to the procedures in the previous section, a PE applies
   the following procedure when importing a Source Active A-D route for
   (C-S,C-G) into a VRF.

   The PE finds a (C-*,C-G) entry in the MVPN-TIB whose C-G is the same
   as the C-G carried in the Multicast Group field of the Source Active
   A-D route.

   If the outgoing interface list (oif) for the found (C-*,C-G) entry in
   the MVPN-TIB on the PE contains either I-PMSI or S-PMSI, and the PE
   does not originate the Source Tree Join C-multicast route for
   (C-S,C-G) (where C-S is address carried in the Multicast Source field
   and C-G is the address carried in the Multicast Group field of the
   received Source Active A-D route), then the PE MUST transition the
   (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI to the Prune
   state.  (Conceptually, the C-PIM state machine on the PE will act "as
   if" it had received Prune (C-S,C-G,rpt) on I-PMSI/S-PMSI, without

   actually having received one.)  Depending on the (C-S,C-G,rpt) state
   of the PE-CE interfaces, this may result in the PE using PIM
   procedures to prune the C-S off the (C-*,C-G) tree.

   Transitioning the state machine to the Prune state SHOULD be done
   after a delay that is controlled by a timer.  The value of the timer
   MUST be configurable.  The purpose of this timer is to ensure that
   the C-S is not pruned off the shared tree until all PEs have had time
   to receive the Source Active A-D route for (C-S,C-G).

   Note that before C-S is pruned off the shared tree, there is a
   possibility to have (C-S,C-G) packets sent at the same time on the
   PMSI by distinct PEs.  This would result in a transient unnecessary
   traffic on the provider backbone.  However, no duplicates will reach
   customer hosts subscribed to C-G as long as the downstream PEs apply
   procedures described in Section 9.1 of [MVPN].

   The PE MUST keep the (C-S,C-G,rpt) downstream state machine on
   I-PMSI/S-PMSI in the Prune state for as long as (a) the outgoing
   interface list (oif) for the found (C-*,C-G) entry in the MVPN-TIB on
   the PE contains either I-PMSI or S-PMSI, (b) the PE has at least one
   Source Active A-D route for (C-S,C-G), and (c) the PE does not
   originate the Source Tree Join C-multicast route for (C-S,C-G).  Once
   any of these conditions become no longer valid, the PE MUST
   transition the (C-S,C-G,rpt) downstream state machine on
   I-PMSI/S-PMSI to the NoInfo state.

   Note that changing the state on the downstream state machine on
   I-PMSI/S-PMSI, as described above, does not imply exchanging PIM
   messages over I-PMSI/S-PMSI.

   Also, note that except for the scenario described in the third
   paragraph of this section, in all other scenarios relying solely on
   PIM procedures on the PE is sufficient to ensure the correct behavior
   when pruning sources off the shared tree.

14.  Supporting PIM-SM without Inter-Site Shared C-Trees

   The procedures defined in this section only apply when the
   C-multicast routing protocol is PIM [RFC4601]; moreover, only apply
   for the multicast ASM mode, and MUST NOT be applied to multicast
   group addresses belonging to the SSM range.  The procedures also MUST
   NOT be applied when the C-multicast routing protocol is BIDIR-PIM
   [RFC5015].

   The procedures of this section are applicable only to MVPNs that do
   not use inter-site shared (i.e., rooted at a C-RP) C-trees.

   These procedures are not applicable to MVPNs that use both shared and
   shortest path inter-site C-trees.  See Section 13 for the procedures
   applicable to that scenario.

   Whether or not a given MVPN uses inter-site shared C-trees must be
   known a priori (e.g., via provisioning).

14.1.  Discovering Active Multicast Sources

   A PE can obtain information about active multicast sources within a
   given MVPN in a variety of ways.  One way is for the PE to act as a
   fully functional customer RP (C-RP) for that MVPN.  Another way is to
   use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information
   about active multicast sources from one or more of the MVPN C-RPs to
   the PE.  Yet another way is to use MSDP [MSDP] to convey information
   about active multicast sources from the MVPN C-RPs to the PE.

   When a PE using any of the above methods first learns of a new
   (multicast) source within that MVPN, the PE constructs a Source
   Active A-D route and sends this route to all other PEs that have one
   or more sites of that MVPN connected to them.  The route carries a
   single MCAST-VPN NLRI constructed as follows:

    + The RD in this NLRI is set to the RD of the VRF of the MVPN on the
      PE.

    + The Multicast Source field MUST be set to the source IP address of
      the multicast data packet carried in the PIM Register message
      (RP/PIM register case) or of the MSDP Source-Active message (MSDP
      case).  The Multicast Source Length field is set appropriately to
      reflect this.

    + The Multicast Group field MUST be set to the group IP address of
      the multicast data packet carried in the PIM Register message
      (RP/PIM register case) or of the MSDP Source-Active message (MSDP
      case).  The Multicast Group Length field is set appropriately to
      reflect this.

   The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the
   IP address that the PE places in the Global Administrator field of
   the VRF Route Import Extended Community of the VPN-IP routes
   advertised by the PE.

   The route SHOULD carry the same set of Route Targets as the Intra-AS
   I-PMSI A-D route of the MVPN originated by the PE.

   Using the normal BGP procedures, the Source Active A-D route is
   propagated to all the PEs of the MVPN.

   When a PE that previously advertised a Source Active A-D route for a
   given (multicast) source learns that the source is no longer active
   (the PE learns this by using the same mechanism by which the PE
   learned that the source was active), the PE SHOULD withdraw the
   previously advertised Source Active route.

14.2.  Receiver(s) within a Site

   A PE follows the procedures specified in Section 11.1, except that
   the procedures specified in Section 11.1.1.2 are replaced with the
   procedures specified in this section.

   When a PE receives a new Source Active A-D route, the PE finds a VRF
   whose import Route Targets match one or more of the Route Targets
   carried by the route.  If the match is found, then the PE updates the
   VRF with the received route.

   We say that a given (C-S,C-G) Source Active A-D route stored in a
   given VRF matches a given (C-*,C-G) entry present in the MVPN-TIB
   associated with the VRF if C-G carried by the route is the same as
   C-G of the entry.

   When (as a result of receiving PIM messages from one of its CEs) a PE
   creates, in one of its MVPN-TIBs, a (new) (C-*,C-G) entry with a non-
   empty outgoing interface list that contains one or more PE-CE
   interfaces, the PE MUST check if it has any matching Source Active
   A-D routes.  If there is one or more such matching routes, and the
   best path to C-S carried in the matching route(s) is reachable
   through some other PE, then for each such route the PE MUST originate
   a Source Tree Join C-multicast route.  If there is one or more such
   matching routes, and the best path to C-S carried in the matching
   route(s) is reachable through a CE connected to the PE, then for each
   such route the PE MUST originate a PIM Join (C-S,C-G) towards the CE.

   When, as a result of receiving a new Source Active A-D route, a PE
   updates its VRF with the route, the PE MUST check if the newly
   received route matches any (C-*,C-G) entries.  If there is a matching
   entry, and the best path to C-S carried in the (A-D) route is
   reachable through some other PE, the PE MUST originate a Source Tree
   Join C-multicast route for the (C-S,C-G) carried by the route.  If
   there is a matching entry, and the best path to C-S carried in the
   (A-D) route is reachable through a CE connected to the PE, the PE
   MUST originate a PIM Join (C-S,C-G) towards the CE.

   Construction and distribution of the Source Tree Join C-multicast
   route follows the procedures specified in Section 11.1.1.1, except
   that the Multicast Source Length, Multicast Source, Multicast Group

   Length, and Multicast Group fields in the MCAST-VPN NLRI of the
   Source Tree Join C-multicast route are copied from the corresponding
   field in the Source Active A-D route.

   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S,C-G)
   if, as a result of having received PIM messages from one of its CEs,
   the PE creates a Prune (C-S,C-G,rpt) upstream state in one of its
   MVPN-TIBs but has no (C-S,C-G) Joined state in that MVPN-TIB and had
   previously advertised the said route.  (This is even if the VRF
   associated with the MVPN-TIB still has a (C-S,C-G) Source Active A-D
   route.)

   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S,C-G)
   if the Source Active A-D route that triggered the advertisement of
   the C-multicast route is withdrawn.

   When a PE deletes the (C-*,C-G) state (e.g., due to receiving PIM
   Prune (C-*,C-G) from its CEs), the PE MUST withdraw all the Source
   Tree Join C-multicast routes for C-G that have been advertised by the
   PE, except for the routes for which the PE still maintains the
   corresponding (C-S,C-G) state.

   Even though PIM is used as a C-multicast protocol, procedures
   described in Section 11.1.1.2 do not apply here, as only the Source
   Tree Join C-multicast routes are exchanged among PEs.

14.3.  Receiving C-Multicast Routes by a PE

   In this model, the only valid type of a C-multicast route that a PE
   could receive is a Source Tree Join C-multicast route.  Processing of
   such a route follows the procedures specified in Section 11.3.1.1.

15.  Carrier's Carrier

   A way to support the Carrier's Carrier model is provided by using
   mLDP as the CE-PE multicast routing and label distribution protocol,
   as specified in this document.

   To improve scalability, it is RECOMMENDED that for the Carrier's
   Carrier scenario within an AS, all the S-PMSIs of a given MVPN be
   aggregated into a single P-multicast tree (by using upstream-assigned
   labels).

16.  Scalability Considerations

   A PE should use Route Target Constraint [RT-CONSTRAIN] to advertise
   the Route Targets that the PE uses for the VRF Route Imports Extended
   Community (note that doing this requires just a single Route Target

   Constraint advertisement by the PE).  This allows each C-multicast
   route to reach only the relevant PE, rather than all the PEs
   participating the an MVPN.

   To keep the intra-AS membership/binding information within the AS of
   the advertising router the BGP Update message originated by the
   advertising router SHOULD carry the NO_EXPORT Community [RFC1997].

   An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra-
   AS I-PMSI A-D routes originated within the ASBR's own AS.  Thus,
   while the Intra-AS I-PMSI A-D routes originated within an AS are at
   the granularity of <PE, MVPN> within that AS, outside of that AS the
   (aggregated) Inter-AS I-PMSI A-D routes are at the granularity of
   <AS, MVPN>.  An Inter-AS I-PMSI A-D route for a given <AS, MVPN>
   indicates the presence of one or more sites of the MVPN connected to
   the PEs of the AS.

   For a given inter-AS tunnel, each of its intra-AS segments could be
   constructed by its own mechanism.  Moreover, by using upstream-
   assigned labels within a given AS, multiple intra-AS segments of
   different inter-AS tunnels of either the same or different MVPNs may
   share the same P-multicast tree.

   Since (aggregated) Inter-AS I-PMSI A-D routes may have a granularity
   of <AS, MVPN>, an MVPN that is present in N ASes would have total of
   N inter-AS tunnels.  Thus, for a given MVPN, the number of inter-AS
   tunnels is independent of the number of PEs that have this MVPN.

   Within each Autonomous System, BGP route reflectors can be
   partitioned among MVPNs present in that Autonomous System so that
   each partition carries routes for only a subset of the MVPNs
   supported by the service provider.  Thus, no single route reflector
   is required to maintain routes for all MVPNs.  Moreover, route
   reflectors used for MVPN do not have to be used for VPN-IP routes
   (although they may be used for VPN-IP routes as well).

   As described in Section 11.4, C-multicast routes for a given (S,G) of
   a given MVPN originated by PEs that are clients of a given route
   reflector are aggregated by the route reflector.  Therefore, even if,
   within a route reflector cluster, there are multiple C-multicast
   routes for a given (S,G) of a given MVPN, outside of the cluster, all
   these routes are aggregated into a single C-multicast route.
   Additional aggregation of C-multicast routes occurs at ASBRs, where
   an ASBR aggregates all the received C-multicast routes for a given
   (S,G) of a given MVPN into a single C-multicast route.  Moreover,
   both route reflectors and ASBRs maintain C-multicast routes only in
   the control plane, but not in the data plane.

16.1.  Dampening C-Multicast Routes

   The rate of C-multicast routing changes advertised by a PE is not
   necessarily directly proportional to the rate of multicast routing
   changes within the MVPN sites connected to the PE, as after the first
   (C-S,C-G) Join originated within a site, all the subsequent Joins for
   same (C-S,C-G) originated within the sites of the same MVPN connected
   to the PE do not cause origination of new C-multicast routes by the
   PE.

   Depending on how multicast VPN is engineered, dynamic addition and
   removal of P2MP RSVP-TE leaves through advertisement/withdrawal of
   Leaf A-D routes will happen.  Dampening techniques can be used to
   limit corresponding processing.

   To lessen the control plane overhead associated with the processing
   of C-multicast routes, this document proposes OPTIONAL route
   dampening procedures similar to what is described in [RFC2439].  The
   following OPTIONAL procedures can be enabled on a PE, ASBR, or BGP
   Route Reflector advertising or receiving C-multicast routes.

16.1.1.  Dampening Withdrawals of C-Multicast Routes

   A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of
   withdrawals of C-multicast routes.  An implementation SHOULD provide
   the ability to control the delay via a configurable timer, possibly
   with some backoff algorithm to adapt the delay to multicast routing
   activity.

   Dampening of withdrawals of C-multicast routes does not impede the
   multicast Join latency observed by MVPN customers, and it also does
   not impede the multicast leave latency observed by a CE, as multicast
   forwarding from the VRF will stop as soon as C-multicast state is
   removed in the VRF.

   The potential drawbacks of dampening of withdrawals of C-multicast
   routes are as follows:

    + Until the withdrawals are actually sent, multicast traffic for the
      C-multicast routes in question will be continued to be transmitted
      to the PE, which will just have to discard it.  Note that the PE
      may receive useless (multicast) traffic anyway, irrespective of
      dampening of withdrawals of C-multicast routes due to the use of
      I-PMSIs.

    + Any state in the upstream PEs that would be removed as a result of
      processing the withdrawals will remain until the withdrawals are
      sent.

   Discussion on whether the potential drawbacks mentioned above are of
   any practical significance is outside the scope of this document.

16.1.2.  Dampening Source/Shared Tree Join C-Multicast Routes

   A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of
   Source/Shared Tree Join C-multicast routes.  An implementation SHOULD
   provide the ability to control the delay via a configurable timer,
   possibly with some backoff algorithm to adapt the delay to multicast
   routing activity.

   Dampening Source/Shared Tree Join C-multicast routes will not impede
   multicast Join latency observed by a given MVPN, except if the PE
   advertising the Source/Shared Tree Join C-multicast route for a
   particular C-S/C-RP is the first to do so for all the sites of the
   MVPN that share the same upstream PE with respect to the C-S/C-RP.

16.2.  Dampening Withdrawals of Leaf A-D Routes

   Similar to the procedures proposed above for withdrawal of
   C-multicast routes, dampening can be applied to the withdrawal of
   Leaf A-D routes.

17.  Security Considerations

   The mechanisms described in this document could reuse the existing
   BGP security mechanisms [RFC4271] [RFC4272].  The security model and
   threats specific to Provider Provisioned VPNs, including L3VPNs, are
   discussed in [RFC4111].  [MVPN] discusses additional threats specific
   to the use of multicast in L3VPNs.  There is currently work in
   progress to improve the security of TCP authentication.  When the
   document is finalized as an RFC, the method defined in [RFC5925]
   SHOULD be used where authentication of BGP control packets is needed.

   A PE router MUST NOT accept, from CEs routes, with MCAST-VPN SAFI.

   If BGP is used as a CE-PE routing protocol, then when a PE receives a
   route from a CE, if this route carries the VRF Route Import Extended
   Community, the PE MUST remove this Community from the route before
   turning it into a VPN-IP route.  Routes that a PE advertises to a CE
   MUST NOT carry the VRF Route Import Extended Community.

   It is important to protect the control plane resources within the PE
   to prevent any one VPN from hogging excessive resources.  This is the
   subject of the remainder of the Security Considerations section.

   When C-multicast routing information is exchanged among PEs using
   BGP, an implementation SHOULD provide the ability to rate limit BGP
   messages used for this exchange.  This SHOULD be provided on a per-
   PE, per-MVPN granularity.

   An implementation SHOULD provide capabilities to impose an upper
   bound on the number of S-PMSI A-D routes, as well as on how
   frequently they may be originated.  This SHOULD be provided on a per-
   PE, per-MVPN granularity.

   In conjunction with the procedures specified in Section 14, an
   implementation SHOULD provide capabilities to impose an upper bound
   on the number of Source Active A-D routes, as well as on how
   frequently they may be originated.  This SHOULD be provided on a per-
   PE, per-MVPN granularity.

   In conjunction with the procedures specified in Section 13 limiting
   the amount of (C-S,C-G) state would limit the amount of Source Active
   A-D route, as in the context of this section, Source Active A-D
   routes are created in response to Source Tree Join C-multicast
   routes, and Source Tree Join C-multicast routes are created as a
   result of creation of (C-S,C-G) state on PEs.  However, to provide an
   extra level of robustness in the context of these procedures, an
   implementation MAY provide capabilities to impose an upper bound on
   the number of Source Active A-D routes, as well as on how frequently
   they may be originated.  This MAY be provided on a per-PE, per-MVPN
   granularity.

   Section 16.1.1 describes optional procedures for dampening
   withdrawals of C-multicast routes.  It is RECOMMENDED that an
   implementation support such procedures.

   Section 16.1.1 describes optional procedures for dampening
   withdrawals of Leaf A-D routes.  It is RECOMMENDED that an
   implementation support such procedures.

18.  IANA Considerations

   This document defines a new BGP Extended Community called "Source
   AS".  This Community is of an extended type and is transitive.  The
   Type value for this Community has been allocated from the two-octet
   AS-Specific Extended Community registry as 0x0009 and from the four-
   octet AS-Specific Extended Community registry as 0x0209.

   This document defines a new BGP Extended Community called "VRF Route
   Import" (Type value 0x010b).  This Community is IP address specific,
   of an extended type, and is transitive.

   This document defines a new NLRI, called "MCAST-VPN", to be carried
   in BGP using multiprotocol extensions.  It has been assigned SAFI 5.
   Also, SAFI 129 has been assigned to "Multicast for BGP/MPLS IP
   Virtual Private Networks (VPNs)".

   This document defines a new BGP optional transitive attribute, called
   "PMSI_TUNNEL".  IANA has assigned the codepoint 22 in the "BGP Path
   Attributes" registry to the PMSI_TUNNEL attribute.

   This document defines a new BGP optional transitive attribute, called
   "PE Distinguisher Labels".  IANA has assigned the codepoint 27 in the
   "BGP Path Attributes" registry to the PE Distinguisher Labels
   attribute.

19.  Acknowledgements

   We would like to thank Chaitanya Kodeboniya for helpful discussions.
   We would also like to thank members of the L3VPN IETF Working Group
   for insightful comments and review.

20.  References

20.1.  Normative References

   [IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI)
               Parameters", http://www.iana.org.

   [MVPN]      Rosen, E., Ed. and R. Aggarwal, Ed., "Mulitcast in
               MPLS/BGP IP VPNs", RFC 6513, February 2012.

   [RFC1997]   Chandra, R., Traina, P., and T. Li, "BGP Communities
               Attribute", RFC 1997, August 1996.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]   Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
               Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
               2006.

   [RFC4360]   Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
               Communities Attribute", RFC 4360, February 2006.

   [RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
               Networks (VPNs)", RFC 4364, February 2006.

   [RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
               Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4659]   De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
               "BGP-MPLS IP Virtual Private Network (VPN) Extension for
               IPv6 VPN", RFC 4659, September 2006.

   [RFC4760]   Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
               "Multiprotocol Extensions for BGP-4", RFC 4760, January
               2007.

20.2.  Informative References

   [mLDP]      Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
               Thomas, "Label Distribution Protocol Extensions for
               Point-to-Multipoint and Multipoint-to-Multipoint Label
               Switched Paths", RFC 6388, November 2011.

   [MSDP]      Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
               Discovery Protocol (MSDP)", RFC 3618, October 2003.

   [PIM-ANYCAST-RP]
               Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
               Independent Multicast (PIM)", RFC 4610, August 2006.

   [RFC5331]   Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
               Label Assignment and Context-Specific Label Space", RFC
               5331, August 2008.

   [RT-CONSTRAIN]
               Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
               R., Patel, K., and J. Guichard, "Constrained Route
               Distribution for Border Gateway Protocol/MultiProtocol
               Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
               Private Networks (VPNs)", RFC 4684, November 2006.

   [RFC2439]   Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
               Flap Damping", RFC 2439, November 1998.

   [RFC4111]   Fang, L., Ed., "Security Framework for Provider-
               Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
               July 2005.

   [RFC4272]   Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
               4272, January 2006.

   [RFC4607]   Holbrook, H. and B. Cain, "Source-Specific Multicast for
               IP", RFC 4607, August 2006.

   [RFC4875]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
               Yasukawa, Ed., "Extensions to Resource Reservation
               Protocol - Traffic Engineering (RSVP-TE) for Point-to-
               Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
               2007.

   [RFC5015]   Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
               "Bidirectional Protocol Independent Multicast (BIDIR-
               PIM)", RFC 5015, October 2007.

   [RFC5925]   Touch, J., Mankin, A., and R. Bonica, "The TCP
               Authentication Option", RFC 5925, June 2010.

Authors' Addresses

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   EMail: raggarwa_1@yahoo.com

   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA, 01719
   EMail: erosen@cisco.com

   Thomas Morin
   France Telecom - Orange
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   EMail: thomas.morin@orange.com

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   EMail: yakov@juniper.net