9.  MVPN Auto-Discovery/Binding

   This section specifies procedures for the auto-discovery of MVPN
   memberships and the distribution of information used to instantiate
   I-PMSIs.

   There are two MVPN auto-discovery/binding mechanisms, dubbed "intra-
   AS" and "inter-AS" respectively.

   The intra-AS mechanisms provide auto-discovery/binding within a
   single AS.

   The intra-AS mechanisms also provide auto-discovery/binding across
   multiple ASes when non-segmented inter-AS tunnels are being used.

   The inter-AS mechanisms provide auto-discovery/binding across
   multiple ASes when segmented inter-AS tunnels are being used.

   Note that if a multi-AS system uses option (a) of section 10 of
   [RFC4364], the notion of inter-AS tunnels does not apply, and so it
   needs only the intra-AS mechanisms.

9.1.  MVPN Auto-Discovery/Binding - Intra-AS Operations

   This section describes exchanges of Intra-AS I-PMSI A-D routes
   originated/received by PEs within the same AS, or if non-segmented
   inter-AS tunnels are used, then by all PEs.

9.1.1.  Originating Intra-AS I-PMSI A-D Routes

   To participate in the MVPN auto-discovery/binding, a PE router that
   has a given VRF of a given MVPN MUST, except for the cases specified
   in this section, originate an Intra-AS I-PMSI A-D route and
   advertises this route in IBGP.  The route is constructed as follows.

   The route carries a single MCAST-VPN NLRI with the RD set to the RD
   of the VRF, and the Originating Router's IP Address field 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.  Note that the <RD, Originating Router's IP
   Address> tuple uniquely identifies a given multicast VRF.

   The route carries the PMSI Tunnel attribute if and only if an I-PMSI
   is used for the MVPN (the conditions under which an I-PMSI is used
   can be found in [MVPN]).  Depending on the technology used for the
   P-tunnel for the MVPN on the PE, the PMSI Tunnel attribute of the
   Intra-AS I-PMSI A-D route is constructed as follows.

    + If the PE that originates the advertisement uses a P-multicast
      tree for the P-tunnel for the MVPN, the PMSI Tunnel attribute MUST
      contain the identity of the tree (note that the PE could create
      the identity of the tree prior to the actual instantiation of the
      tree).

    + A PE that uses a P-multicast tree for the P-tunnel MAY aggregate
      two or more MVPNs present on the PE onto the same tree.  In this
      case, in addition to carrying the identity of the tree, the PMSI
      Tunnel attribute of the Intra-AS I-PMSI A-D route MUST carry an
      MPLS upstream-assigned label that the PE has bound uniquely to the
      MVPN associated with this route (as determined by its RTs).


      If the PE has already advertised Intra-AS I-PMSI A-D routes for
      two or more MVPNs that it now desires to aggregate, then the PE
      MUST re-advertise those routes.  The re-advertised routes MUST be
      the same as the original ones, except for the PMSI Tunnel
      attribute and the label carried in that attribute.

    + If the PE that originates the advertisement uses ingress
      replication for the P-tunnel for the MVPN, the route MUST include
      the PMSI Tunnel attribute with the Tunnel Type set to Ingress
      Replication and Tunnel Identifier set to a routable address of the
      PE.  The PMSI Tunnel attribute MUST carry a downstream-assigned
      MPLS label.  This label is used to demultiplex the MVPN traffic
      received over a unicast tunnel by the PE.

    + The Leaf Information Required flag of the PMSI Tunnel attribute
      MUST be set to zero and MUST be ignored on receipt.

   Discovery of PE capabilities in terms of what tunnel types they
   support is outside the scope of this document.  Within a given AS,
   PEs participating in an MVPN are expected to advertise tunnel
   bindings whose tunnel types are supported by all other PEs that are

   participating in this MVPN and are part of the same AS.  In addition,
   in the inter-AS scenario with non-segmented inter-AS tunnels, the
   tunnel types have to be supported by all PEs that are participating
   in this MVPN, irrespective of whether or not these PEs are in the
   same AS.

   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.

   By default, the distribution of the Intra-AS I-PMSI A-D routes is
   controlled by the same Route Targets as the ones used for the
   distribution of VPN-IP unicast routes.  That is, by default, the
   Intra-AS I-PMSI A-D route MUST carry the export Route Target used by
   the unicast routing.  If any other PE has one of these Route Targets
   configured as an import Route Target for a VRF present on the PE, it
   treats the advertising PE as a member in the MVPN to which the VRF
   belongs.  The default could be modified via configuration by having a
   set of Route Targets used for the Intra-AS I-PMSI A-D routes being
   distinct from the ones used for the VPN-IP unicast routes (see also
   Section 10).

   To constrain distribution of the intra-AS membership/binding
   information to the AS of the advertising PE, the BGP Update message
   originated by the advertising PE SHOULD carry the NO_EXPORT Community
   [RFC1997].

   Note that if non-segmented inter-AS P-tunnels are being used, then
   the Intra-AS I-PMSI routes need to be distributed to other ASes and
   MUST NOT carry the NO_EXPORT Community.

   When BGP is used to exchange C-multicast routes, if (a) it is known a
   priori that, as a matter of policy, none of the MVPN sites connected
   to a given PE are allowed to send multicast traffic to other sites of
   that MVPN (in other words, all these sites are only in the Receiver
   Sites set), (b) the PE does not use ingress replication for the
   incoming traffic of that MVPN, and (c) none of the other PEs that
   have VRFs of that MVPN use RSVP-TE P2MP LSP for that MVPN, then the
   local PE SHOULD NOT originate an Intra-AS I-PMSI A-D route.

   When BGP is used to exchange C-multicast routes, if it is known a
   priori that, as a matter of policy, none of the MVPN sites connected
   to a given PE can receive multicast traffic from other sites of that
   MVPN (in other words, all these sites are only in the Sender Sites
   set), and the PE uses ingress replication for that MVPN, then the PE
   SHOULD NOT originate an Intra-AS I-PMSI A-D route for that MVPN.

9.1.2.  Receiving Intra-AS I-PMSI A-D Routes

   When a PE receives a BGP Update message that carries an Intra-AS
   I-PMSI A-D route such that (a) at least one of the Route Targets of
   the route matches one of the import Route Targets configured for a
   particular VRF on the local PE, (b) either the route was originated
   by some other PE within the same AS as the local PE, or the MVPN
   associated with the VRF uses non-segmented inter-AS tunnels, and (c)
   the BGP route selection determines that this is the best route with
   respect to the NLRI carried by the route, the PE performs the
   following.

   If the route does not carry the PMSI Tunnel attribute and ingress
   replication is not used, either a) the PE that originated the route
   will be using only S-PMSIs to send traffic to remote PEs, or b) as a
   matter of policy, the PE that originated the route cannot send
   multicast traffic from the MVPN sites connected to it to other sites
   of that MVPN (in other words, the sites connected to the PE are only
   in the Receiver Sites set).

   When BGP is used to exchange C-multicast routes, to distinguish
   between cases (a) and (b), we use the presence/absence of the VRF
   Route Import Extended Community in the unicast VPN routes, as
   follows.  As specified in Section 7, if it is know a priori that none
   of the addresses carried in the NLRI of a given (unicast) VPN route
   could act as multicast sources and/or C-RP, then such a route does
   not carry the VRF Route Import Extended Community.  Hence, based on
   the Upstream Multicast Hop (UMH) selection algorithm specified in
   [MVPN], such a route will be ineligible for the UMH selection.  This
   implies that if a given VPN route is selected by the UMH selection
   procedures, and the PE that originates this VPN route also originates
   an Intra-AS I-PMSI A-D route, but this route does not carry the PMSI
   Tunnel attribute, then this PE will be using only S-PMSIs for sending
   (multicast) data.

   If the route carries the PMSI Tunnel attribute, then:

    + If the Tunnel Type in the PMSI Tunnel attribute is set to Ingress
      Replication, then the MPLS label and the address carried in the
      Tunnel Identifier field of the PMSI Tunnel attribute should be
      used when the local PE sends multicast traffic to the PE that
      originated the route.

    + If the Tunnel Type in the PMSI Tunnel attribute is set to mLDP
      P2MP LSP, mLDP MP2MP LSP, PIM-SSM tree, PIM-SM tree, or BIDIR-PIM
      tree, the PE SHOULD join as soon as possible the P-multicast tree
      whose identity is carried in the Tunnel Identifier.

    + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE
      P2MP LSP, then the PE that originated the route MUST establish an
      RSVP-TE P2MP LSP with the local PE as a leaf.  This LSP may have
      been established before the local PE receives the route, or it may
      be established after the local PE receives the route.

    + The receiving PE has to establish the appropriate state to
      properly handle the traffic received on the P-multicast tree.

    + If the PMSI Tunnel attribute does not carry a label, then all
      packets that are received on the P-multicast tree, as identified
      by the PMSI Tunnel attribute, are forwarded using the VRF that has
      at least one of its import Route Targets that matches one of the
      Route Targets of the received Intra-AS I-PMSI A-D route.

    + If the PMSI Tunnel attribute has the Tunnel Type set to mLDP P2MP
      LSP, PIM-SSM tree, PIM-SM tree, BIDIR-PIM tree, or RSVP-TE P2MP
      LSP, and the attribute also carries an MPLS label, then this is an
      upstream-assigned label, and all packets that are received on the
      P-multicast tree, as identified by the PMSI Tunnel attribute, with
      that upstream-assigned label are forwarded using the VRF that has
      at least one of its import Route Targets that matches one of the
      Route Targets of the received Intra-AS I-PMSI A-D route.

   Irrespective of whether the route carries the PMSI Tunnel attribute,
   if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic
   from the VRF to the sites attached to other PEs, then the local PE
   uses the Originating Router's IP address information carried in the
   route to add the PE that originated the route as a leaf node to the
   LSP.

9.2.  MVPN Auto-Discovery/Binding - Inter-AS Operations

   This section applies only to the case where segmented inter-AS
   tunnels are used.

   An Autonomous System Border Router (ASBR) may be configured to
   support a particular MVPN as follows:

    + An ASBR MUST be configured with a set of (import) Route Targets
      (RTs) that specifies the set of MVPNs supported by the ASBR.
      These Route Targets control acceptance of Intra-AS/Inter-AS I-PMSI
      A-D routes by the ASBR.  As long as unicast and multicast
      connectivity are congruent, this could be the same set of Route
      Targets as the one used for supporting unicast (and therefore
      would not require any additional configuration above and beyond of

      what is required for unicast).  Note that instead of being
      configured, the ASBR MAY obtain this set of (import) Route Targets
      (RTs) by using Route Target Constraint [RT-CONSTRAIN].

    + The ASBR MUST be (auto-)configured with an import Route Target
      called "ASBR Import RT".  ASBR Import RT controls acceptance of
      Leaf A-D routes and C-multicast routes by the ASBR, and is used to
      constrain distribution of both Leaf A-D routes and C-multicast
      routes (see Section 11).

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

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

    + The ASBR MUST be configured with the tunnel types for the intra-AS
      segments of the MVPNs supported by the ASBR, as well as (depending
      on the tunnel type) the information needed to create the PMSI
      attribute for these tunnel types.  Note that instead of being
      configured, the ASBR MAY derive the tunnel types from the Intra-AS
      I-PMSI A-D routes received by the ASBR.

    + If the ASBR originates an Inter-AS I-PMSI A-D route for a
      particular MVPN present on some of the PEs within its own AS, the
      ASBR MUST be (auto-)configured with an RD for that MVPN.  It is
      RECOMMENDED that one of the following two options be used:

  (1) To allow more aggregation of Inter-AS I-PMSI A-D routes, it is
      recommended that all the ASBRs within an AS that are configured to
      originate an Inter-AS I-PMSI A-D route for a particular MVPN be
      configured with the same RD (although for a given MVPN each AS may
      assign this RD on its own, without coordination with other ASes).

  (2) To allow more control over spreading MVPN traffic among multiple
      ASBRs within a given AS, it is recommended that each ASBR have a
      distinct RD per each MVPN; in which case, such an RD SHOULD be
      auto-configured.

   If an ASBR is configured to support a particular MVPN, the ASBR MUST
   participate in the intra-AS MVPN auto-discovery/binding procedures
   for that MVPN within the ASBR's own AS, as specified in Section 9.1.

   Moreover, in addition to the above, the ASBR performs procedures
   described in Sections 9.2.1, 9.2.2, and 9.2.3.

9.2.1.  Originating Inter-AS I-PMSI A-D Routes

   For a given MVPN configured on an ASBR when the ASBR determines
   (using the intra-AS auto-discovery procedures) that at least one of
   the PEs of its own AS has (directly) connected site(s) of the MVPN,
   the ASBR originates an Inter-AS I-PMSI A-D route and advertises it in
   External BGP (EBGP).  The route is constructed as follows:

    + The route carries a single MCAST-VPN NLRI with the RD set to the
      RD configured for that MVPN on the ASBR, and the Source AS set to
      the ASN of the ASBR.

    + The route carries the PMSI Tunnel attribute if and only if an
      I-PMSI is used for the MVPN.  The Tunnel Type in the attribute is
      set to Ingress Replication; the Leaf Information Required flag is
      set to 1; the attribute carries no MPLS labels.

    + The Next Hop field of the MP_REACH_NLRI attribute is set to a
      routable IP address of the ASBR.

    + The default policy for aggregation of Intra-AS I-PMSI A-D routes
      into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI
      A-D route aggregates only the Intra-AS I-PMSI A-D routes that
      carry exactly the same set of RTs (note that this set may have
      just one RT).  In this case, an Inter-AS I-PMSI A-D route
      originated by an ASBR carries exactly the same RT(s) as the RT(s)
      carried by the Intra-AS I-PMSI A-D routes that the ASBR aggregates
      into that Inter-AS I-PMSI A-D route.  An implementation MUST
      support the default policy for aggregation of Intra-AS I-PMSI A-D
      routes into an Inter-AS I-PMSI A-D route.

    + The default policy for aggregation could be modified via
      configuration on the ASBR.  An implementation MAY support such
      functionality.  Modified policy MUST include rules for
      constructing RTs carried by the Inter-AS I-PMSI A-D routes
      originated by the ASBR.

   An Inter-AS I-PMSI A-D route for a given <AS, MVPN> indicates the
   presence of the MVPN sites connected to one or more PEs of the AS.

   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 could be at the granularity
   of <AS, MVPN>.

9.2.2.  When Not to Originate Inter-AS I-PMSI A-D Routes

   If, for a given MVPN and a given AS, all of the sites connected to
   the PEs within the AS are known a priori to have no multicast
   sources, then ASBRs of that AS MAY refrain from originating an Inter-
   AS I-PMSI A-D route for that MVPN at all.

9.2.3.  Propagating Inter-AS I-PMSI A-D Routes

   An Inter-AS I-PMSI A-D route for a given MVPN originated by an ASBR
   within a given AS is propagated via BGP to other ASes.

9.2.3.1.  Propagating Inter-AS I-PMSI A-D Routes - Overview

   Suppose that ASBR A installs an Inter-AS I-PMSI A-D route for MVPN V
   that originated at a particular AS, AS1.  The BGP Next Hop of that
   route becomes A's "upstream multicast hop" on a multicast
   distribution tree for V that is rooted at AS1.  When the Inter-AS
   I-PMSI A-D routes have been distributed to all the necessary ASes,
   they define a "reverse path" from any AS that supports MVPN V back to
   AS1.  For instance, if AS2 supports MVPN V, then there will be a
   reverse path for MVPN V from AS2 to AS1.  This path is a sequence of
   ASBRs, the first of which is in AS2, and the last of which is in AS1.
   Each ASBR in the sequence is the BGP Next Hop of the previous ASBR in
   the sequence on the given Inter-AS I-PMSI A-D route.

   This reverse path information can be used to construct a
   unidirectional multicast distribution tree for MVPN V, containing all
   the ASes that support V, and having AS1 at the root.  We call such a
   tree an "inter-AS tree".  Multicast data originating in MVPN sites
   connected to PEs within a given AS will travel downstream along the
   tree, which is rooted at that AS.

   The path along an inter-AS tree is a sequence of ASBRs; it is still
   necessary to specify how the multicast data gets from a given ASBR to
   the set of ASBRs that are immediately downstream of the given ASBR
   along the tree.  This is done by creating "segments": ASBRs in
   adjacent ASes will be connected by inter-AS segments, ASBRs in the
   same AS will be connected by "intra-AS segments".

   An ASBR initiates creation of an intra-AS segment when the ASBR
   receives an Inter-AS I-PMSI A-D route from an EBGP neighbor.
   Creation of the segment is completed as a result of distributing, via
   IBGP, this route within the ASBR's own AS.

   For a given inter-AS tunnel, each of its intra-AS segments could be
   constructed by its own independent 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.

   If the P-multicast tree that serves as a particular intra-AS segment
   of an inter-AS tunnel is created by a multicast control protocol that
   uses receiver-initiated joins (e.g., mLDP, any PIM variant), and this
   P-multicast tree does not aggregate multiple segments, then all the
   information needed to create that segment is present in the PMSI
   Tunnel attribute of the Inter-AS I-PMSI A-D routes.  However, if the
   P-multicast tree that serves as the segment is created by a protocol
   that does not use receiver-initiated joins (e.g., RSVP-TE, ingress
   unicast replication), or if this P-multicast tree aggregates multiple
   segments (irrespective of the multicast control protocol used to
   create the tree), then it is also necessary to use Leaf A-D routes.
   The precise conditions under which Leaf A-D routes need to be used
   are described in subsequent sections.

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

   The precise rules for distributing and processing the Inter-AS I-PMSI
   A-D routes across ASes are given in the following sections.

9.2.3.2.  Inter-AS I-PMSI A-D Route Received via EBGP

   When an ASBR receives, from one of its EBGP neighbors, a BGP Update
   message that carries an Inter-AS I-PMSI A-D route, if (a) at least
   one of the Route Targets carried in the message matches one of the
   import Route Targets configured on the ASBR, and (b) the ASBR
   determines that the received route is the best route for its NLRI,
   the ASBR re-advertises this route to other PEs and ASBRs within its
   own AS (handling of this route by other PEs and ASBRs is described in
   Section 9.2.3.4).

   When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set
   the Next Hop field of the MP_REACH_NLRI attribute to a routable IP
   address of the ASBR.

   If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
   attribute, then, depending on the technology used to instantiate the
   intra-AS segment of the inter-AS tunnel, the ASBR constructs the PMSI
   Tunnel attribute of the re-advertised Inter-AS I-PMSI A-D route as
   follows.

    + If the ASBR uses ingress replication for the intra-AS segment of
      the inter-AS tunnel, the re-advertised route MUST carry the PMSI
      Tunnel attribute with the Tunnel Type set to Ingress Replication,
      but no MPLS labels.

    + If the ASBR uses a P-multicast tree for the intra-AS segment of
      the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the
      identity of the tree (note that the ASBR could create the identity
      of the tree prior to the actual instantiation of the tree).  If,
      in order to instantiate the tree, the ASBR needs to know the
      leaves of the tree, then the ASBR obtains this information from
      the Leaf A-D routes received from other PEs/ASBRs in the ASBR's
      own AS (as described in Section 9.2.3.5) by setting the Leaf
      Information Required flag in the PMSI Tunnel attribute to 1.

    + An ASBR that uses a P-multicast tree as the intra-AS segment of
      the inter-AS tunnel MAY aggregate two or more MVPNs present on the
      ASBR onto the same tree.  In this case, in addition to the
      identity of the tree, the PMSI Tunnel attribute of the Inter-AS I-
      PMSI A-D route MUST carry an MPLS upstream-assigned label that the
      PE has bound uniquely to the MVPN associated with this route (as
      determined by its RTs).

      If the ASBR has already advertised Inter-AS I-PMSI A-D routes for
      two or more MVPNs that it now desires to aggregate, then the ASBR
      MUST re-advertise those routes.  The re-advertised routes MUST be
      the same as the original ones, except for the PMSI Tunnel
      attribute and the MVPN label.

9.2.3.2.1.  Originating Leaf A-D Route into EBGP

   In addition, the ASBR MUST send to the EBGP neighbor from whom it
   received the Inter-AS I-PMSI A-D route, a BGP Update message that
   carries a Leaf A-D route constructed as follows.

    + The route carries a single MCAST-VPN NLRI with the Route Key field
      set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route
      received from that neighbor and the Originating Router's IP
      address set to the IP address of the ASBR (this MUST be a routable
      IP address).

    + The Leaf A-D route MUST include the PMSI Tunnel attribute with the
      Tunnel Type set to Ingress Replication and the Tunnel Identifier
      set to a routable address of the advertising router.  The PMSI
      Tunnel attribute MUST carry a downstream-assigned MPLS label that
      is used by the advertising router to demultiplex the MVPN traffic
      received over a unicast tunnel from the EBGP neighbor.

    + The ASBR constructs an IP-based Route Target Extended Community by
      placing the IP address carried in the Next Hop of the received
      Inter-AS I-PMSI A-D route in the Global Administrator field of the
      Community, with the Local Administrator field of this Community
      set to 0 and setting the Extended Communities attribute of the
      Leaf A-D route to that Community.  Note that this Route Target is
      the same as the ASBR Import RT of the EBGP neighbor from which the
      ASBR received the Inter-AS I-PMSI A-D route.

    + 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 of the route.

    + To constrain the distribution scope of this route, the route MUST
      carry the NO_ADVERTISE BGP Community [RFC1997].

   Handling of this Leaf A-D route by the EBGP neighbor is described in
   Section 9.2.3.3.

   The ASBR MUST set up its forwarding state such that packets that
   arrive on the one-hop ASBR-ASBR LSP, as specified in the PMSI Tunnel
   attribute of the Leaf A-D route, are transmitted on the intra-AS
   segment, as specified in the PMSI Tunnel attribute of the Inter-AS
   I-PMSI A-D route that the ASBR re-advertises in its own AS.  However,
   the packets MAY be filtered before forwarding, as specified in
   Section 9.2.3.6.

9.2.3.3.  Leaf A-D Route Received via EBGP

   When an ASBR receives, via EBGP, a Leaf A-D route originated by its
   neighbor ASBR, if the Route Target carried in the Extended
   Communities attribute of the route matches one of the ASBR Import RT
   (auto-)configured on the ASBR, the ASBR performs the following.

    + The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI
      has the same value as the Route Key field of the Leaf A-D route.

    + If the found Inter-AS I-PMSI A-D route was originated by ASBR
      itself, then the ASBR sets up its forwarding state such that
      packets received on the intra-AS tunnels originating in the ASBR's
      own AS are transmitted on the one-hop ASBR-ASBR LSP specified by

      the MPLS label carried in the PMSI Tunnel attribute of the
      received Leaf A-D route.  (However, the packets MAY be filtered
      before transmission as specified in Section 9.2.3.6).  The intra-
      AS tunnels are specified in the PMSI Tunnel attribute of all the
      Intra-AS I-PMSI A-D routes received by the ASBR that the ASBR
      aggregated into the Inter-AS I-PMSI A-D route.  For each of these
      intra-AS tunnels, if a non-zero MPLS label is carried in the PMSI
      Tunnel attribute (i.e., aggregation is used), then only packets
      received on the inner LSP corresponding to that label MUST be
      forwarded, not the packets received on the outer LSP, as the outer
      LSP possibly carries the traffic of other VPNs.

    + If the found Inter-AS I-PMSI A-D route was originated by some
      other ASBR, then the ASBR sets up its forwarding state such that
      packets received on the intra-AS tunnel segment, as specified in
      the PMSI Tunnel attribute of the found Inter-AS I-PMSI A-D route,
      are transmitted on the one-hop ASBR-ASBR LSP, as specified by the
      MPLS label carried in the PMSI Tunnel attribute of the Leaf A-D
      route.

9.2.3.4.  Inter-AS I-PMSI A-D Route Received via IBGP

   In the context of this section, we use the term "PE/ASBR router" to
   denote either a PE or an ASBR router.

   If a given Inter-AS I-PMSI A-D route is received via IBGP by a BGP
   route reflector, the BGP route reflector MUST NOT modify the Next Hop
   field of the MP_REACH_NLRI attribute when re-advertising the route
   into IBGP (this is because the information carried in the Next Hop is
   used for controlling flow of C-multicast routes, as specified in
   Section 11.2).

   If a given Inter-AS I-PMSI A-D route is advertised within an AS by
   multiple ASBRs of that AS, the BGP best route selection performed by
   other PE/ASBR routers within the AS does not require all these
   PE/ASBR routers to select the route advertised by the same ASBR -- to
   the contrary, different PE/ASBR routers may select routes advertised
   by different ASBRs.

   When a PE/ASBR router receives, from one of its IBGP neighbors, a BGP
   Update message that carries an Inter-AS I-PMSI A-D route, if (a) at
   least one of the Route Targets carried in the message matches one of
   the import Route Targets configured on the PE/ASBR, and (b) the
   PE/ASBR determines that the received route is the best route to the
   destination carried in the NLRI of the route, the PE/ASBR performs
   the following operations.

    + If the router is a PE, then the router imports the route into the
      VRF(s) that have the matching import Route Targets.

    + If the router is an ASBR, then the ASBR propagates the route to
      its EBGP neighbors.  When propagating the route to the EBGP
      neighbors, the ASBR MUST set the Next Hop field of the
      MP_REACH_NLRI attribute to a routable IP address of the ASBR.  If
      the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
      attribute, then the propagated route MUST carry the PMSI Tunnel
      attribute with the Tunnel Type set to Ingress Replication; the
      attribute carries no MPLS labels.

    + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
      attribute with the Tunnel Type set to mLDP P2MP LSP, PIM-SSM tree,
      PIM-SM tree, or BIDIR-PIM tree, the PE/ASBR SHOULD join as soon as
      possible the P-multicast tree whose identity is carried in the
      Tunnel Identifier.

    + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
      attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then
      the ASBR that originated the route MUST establish an RSVP-TE P2MP
      LSP with the local PE/ASBR as a leaf.  This LSP MAY have been
      established before the local PE/ASBR receives the route, or it MAY
      be established after the local PE receives the route.

    + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
      attribute with the Tunnel Type set to mLDP P2MP LSP, RSVP-TE P2MP
      LSP, PIM-SSM, PIM-SM tree, or BIDIR-PIM tree, but the attribute
      does not carry a label, then the P-multicast tree, as identified
      by the PMSI Tunnel attribute, is an intra-AS LSP segment that is
      part of the inter-AS tunnel for the MVPN advertised by the Inter-
      AS I-PMSI A-D route and rooted at the AS that originated the
      Inter-AS I-PMSI A-D route.  If the PMSI Tunnel attribute carries a
      (upstream-assigned) label, then a combination of this tree and the
      label identifies the intra-AS segment.  If the receiving router is
      an ASBR, this intra-AS segment may further be stitched to the
      ASBR-ASBR inter-AS segment of the inter-AS tunnel.  If the PE/ASBR
      has local receivers in the MVPN, packets received over the intra-
      AS segment must be forwarded to the local receivers using the
      local VRF.

9.2.3.4.1.  Originating Leaf A-D Route into IBGP

   If the Leaf Information Required flag in the PMSI Tunnel attribute of
   the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR
   MUST originate a new Leaf A-D route as follows.

    + The route carries a single MCAST-VPN NLRI with the Route Key field
      set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route
      received from that neighbor and the Originating Router's IP
      address set to the IP address of the PE/ASBR (this MUST be a
      routable IP address).

    + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
      attribute with the Tunnel Type set to Ingress Replication, then
      the Leaf A-D route MUST carry the PMSI Tunnel attribute with the
      Tunnel Type set to Ingress Replication.  The Tunnel Identifier
      MUST carry a routable address of the PE/ASBR.  The PMSI Tunnel
      attribute MUST carry a downstream-assigned MPLS label that is used
      to demultiplex the MVPN traffic received over a unicast tunnel by
      the PE/ASBR.

    + The PE/ASBR constructs an IP-based Route Target Extended Community
      by placing the IP address carried in the Next Hop of the received
      Inter-AS I-PMSI A-D route in the Global Administrator field of the
      Community, with the Local Administrator field of this Community
      set to 0 and setting the Extended Communities attribute of the
      Leaf A-D route to that Community.

    + 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 of the route.

    + To constrain the distribution scope of this route, the route MUST
      carry the NO_EXPORT Community [RFC1997].

    + Once the Leaf A-D route is constructed, the PE/ASBR advertises
      this route into IBGP.

9.2.3.5.  Leaf A-D Route Received via IBGP

   When an ASBR receives, via IBGP, a Leaf A-D route, if the Route
   Target carried in the Extended Communities attribute of the route
   matches one of the ASBR Import RT (auto-)configured on the ASBR, the
   ASBR performs the following.

   The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has
   the same value as the Route Key field of the Leaf A-D route.

   The received route may carry either (a) no PMSI Tunnel attribute, or
   (b) the PMSI Tunnel attribute, but only with the Tunnel Type set to
   Ingress Replication.

   If the received route does not carry the PMSI Tunnel attribute, the
   ASBR uses the information from the received route to determine the
   leaves of the P-multicast tree rooted at the ASBR that would be used
   for the intra-AS segment associated with the found Inter-AS I-PMSI
   A-D route.  The IP address of a leaf is the IP address carried in the
   Originating Router's IP address field of the received Leaf A-D route.

   If the received route carries the PMSI Tunnel attribute with the
   Tunnel Type set to Ingress Replication, the ASBR uses the information
   carried by the route to construct the intra-AS segment with ingress
   replication.

9.2.3.6.  Optimizing Bandwidth by IP Filtering on ASBRs

   An ASBR that has a given Inter-AS I-PMSI A-D route MAY discard some
   of the traffic carried in the tunnel specified in the PMSI Tunnel
   attribute of this route, if the ASBR determines that there are no
   downstream receivers for that traffic.

   When BGP is being used to distribute C-multicast routes, an ASBR that
   has a given Inter-AS I-PMSI A-D route MAY discard traffic from a
   particular customer multicast source C-S and destined to a particular
   customer multicast group address C-G that is carried over the tunnel
   specified in the PMSI Tunnel attribute of the route, if none of the
   C-multicast routes on the ASBR with RD and Source AS being the same
   as the RD and Source AS of the Inter-AS I-PMSI A-D route matches the
   (C-S,C-G) tuple.  A C-multicast route is said to match a (C-S,C-G)
   tuple, if it is a Source Tree Join route with Multicast Source set to
   C-S and Multicast Group set to C-G or a Shared Tree Join route with
   Multicast Group set to C-G.

   The above procedures MAY also apply to an ASBR that originates a
   given Inter-AS I-PMSI A-D route.  In this case, the ASBR applies them
   to the traffic carried over the tunnels specified in the PMSI Tunnel
   attribute of the Intra-AS I-PMSI A-D routes that the ASBR aggregates
   into the Inter-AS I-PMSI A-D route and whose tails are stitched to
   the one-hop ASBR-ASBR tunnel specified in the Inter-AS I-PMSI A-D
   route.

10.  Non-Congruent Unicast and Multicast Connectivity

   It is possible to deploy MVPN such that the multicast routing and the
   unicast routing are "non-congruent".  For instance, the CEs may be
   distributing to the PEs a special set of unicast routes that are to
   be used exclusively for the purpose of upstream multicast hop
   selection, and not used for unicast routing at all.  (For example,
   when BGP is the CE-PE unicast routing protocol, the CEs may be using
   SAFI 2 ("Network Layer Reachability Information used for multicast

   forwarding" [IANA-SAFI]), and either IPv4 or IPv6 AFI to distribute a
   special set of routes that are to be used for, and only for, upstream
   multicast hop selection.) In such a situation, we will speak of the
   MVPN as having two VRFs on a given PE: one containing the routes that
   are used for unicast, the other containing the unicast routes that
   are used for UMH selection.  We will call the former the "unicast
   routing VRF" and the latter the "UMH VRF" (upstream-multicast-hop
   VRF).

   In this document, when we speak without qualification of the MVPN's
   VRF, then if the MVPN has both a unicast VRF and a UMH VRF, we are
   speaking of the UMH VRF.  (Of course, if there is no separate UMH
   VRF, then we are speaking of the unicast VRF.)

   If there is a separate UMH VRF, it MAY have its own import and export
   Route Targets, different from the ones used by the unicast VRF.
   These Route Targets MUST be used to control distribution of auto-
   discovery routes.  In addition, the export Route Targets of the UMH
   VRF are added to the Route Targets used by the unicast VRF when
   originating (unicast) VPN-IP routes.  The import Route Targets
   associated with a given UMH VRF are used to determine which of the
   received (unicast) VPN-IP routes should be accepted into the UMH VRF.

   If a PE maintains an UMH VRF for that MVPN, then it is RECOMMENDED
   that the UMH VRF use the same RD as the one used by the unicast VRF
   of that MVPN.

   If an MVPN site is multihomed to several PEs, then to support non-
   congruent unicast and multicast connectivity, on each of these PEs,
   the UMH VRF of the MVPN MUST use its own distinct RD (although on a
   given PE, the RD used by the UMH VRF SHOULD be the same as the one
   used by the unicast VRF).

   If an MVPN has a UMH VRF distinct from its unicast VRF, then one
   option to support non-congruency is to exchange the routes to/from
   that UMH VRF by using the same AFI/SAFI as used by the routes from
   the unicast VRF.

   Another option is to exchange the routes to/from the UMH VRF using
   the IPv4 or IPv6 AFI (as appropriate), but with the SAFI set to SAFI
   129 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)"
   [IANA-SAFI].  The NLRI carried by these routes is defined as follows:

      +---------------------------+
      |   Length (1 octet)        |
      +---------------------------+
      |   Prefix (variable)       |
      +---------------------------+

   The use and the meaning of these fields are as follows:

   a) Length:

      The Length field indicates the length, in bits, of the address
      prefix.

   b) Prefix:

      The Prefix field contains a Route Distinguisher as defined in
      [RFC4364] prepended to an IPv4 or IPv6 address prefix, followed by
      enough trailing bits to make the end of the field fall on an octet
      boundary.  Note that the value of trailing bits is irrelevant.

   These routes MUST carry the VRF Route Import Extended Community.  If,
   for a given MVPN, BGP is used for exchanging C-multicast routes, or
   if segmented inter-AS tunnels are used, then these routes MUST also
   carry the Source AS Extended Community.

   The detailed procedures for selecting forwarder PE in the presence of
   such routes are outside the scope of this document.  However, this
   document requires these procedures to preserve the constraints
   imposed by the single forwarder PE selection procedures, as specified
   in [MVPN].

11.  Exchange of C-Multicast Routing Information among PEs

   VPN C-Multicast Routing Information is exchanged among PEs by using
   C-multicast routes that are carried using an MCAST-VPN NLRI.  These
   routes are originated and propagated as follows.

11.1.  Originating C-Multicast Routes by a PE

   Part of the procedures for constructing MCAST-VPN NLRI depends on the
   multicast routing protocol between CE and PE (C-multicast protocol).

11.1.1.  Originating Routes: PIM as the C-Multicast Protocol

   The following specifies the construction of MCAST-VPN NLRI of
   C-multicast routes for the case where the C-multicast protocol is
   PIM.  These C-multicast routes are originated as a result of updates
   in the (C-S,C-G), or (C-*,C-G) state learned by a PE via the
   C-multicast protocol.

   Note that creation and deletion of (C-S,C-G,rpt) states on a PE when
   the C-multicast protocol is PIM do not result in any BGP actions.

11.1.1.1.  Originating Source Tree Join C-Multicast Route

   Whenever (a) a C-PIM instance on a particular PE creates a new
   (C-S,C-G) state, and (b) the selected upstream PE for C-S (see
   [MVPN]) is not the local PE, then the local PE MUST originate a
   C-multicast route of type Source Tree Join.  The Multicast Source
   field in the MCAST-VPN NLRI of the route is set to C-S; the Multicast
   Group field is set of C-G.

   This C-multicast route is said to "correspond" to the C-PIM (C-S,C-G)
   state.

   The semantics of the route are such that the PE has one or more
   receivers for (C-S,C-G) in the sites connected to the PE (the route
   has the (C-S,C-G) Join semantics).

   Whenever a C-PIM instance on a particular PE deletes a (C-S,C-G)
   state, the corresponding C-multicast route MUST be withdrawn.  (The
   withdrawal of the route has the (C-S,C-G) Prune semantics).  The
   MCAST-VPN NLRI of the withdrawn route is carried in the
   MP_UNREACH_NLRI attribute.

11.1.1.2.  Originating Shared Tree Join C-Multicast Route

   Whenever (a) a C-PIM instance on a particular PE creates a new
   (C-*,C-G) state, and (b) the selected upstream PE for the C-RP
   corresponding to the C-G (see [MVPN]) is not the local PE, then the
   local PE MUST originate a C-multicast route of type Shared Tree Join.
   The Multicast Source field in the MCAST-VPN NLRI of the route is set
   to the C-RP address.  The Multicast Group field in the MCAST-VPN NLRI
   is set to the C-G address.

   This C-multicast route is said to "correspond" to the C-PIM (C-*,C-G)
   state.

   The semantics of the route are such that the PE has one or more
   receivers for (C-*,C-G) in the sites connected to the PE (the route
   has the (C-*,C-G) Join semantics).

   Whenever a C-PIM instance on a particular PE deletes a (C-*,C-G)
   state, the corresponding C-multicast route MUST be withdrawn.  (The
   withdrawal of the route has the (C-S,C-G) Prune semantics).  The
   MCAST-VPN NLRI of the withdrawn route is carried in the
   MP_UNREACH_NLRI attribute.

11.1.2.  Originating Routes: mLDP as the C-Multicast Protocol

   The following specifies the construction of the MCAST-VPN NLRI of
   C-multicast routes for the case where the C-multicast protocol is
   mLDP [mLDP].

   Whenever a PE receives, from one of its CEs, a P2MP Label Map
   <X, Y, L> over interface I, where X is the Root Node Address, Y is
   the Opaque Value, and L is an MPLS label, the PE checks whether it
   already has state for <X, Y> in the VRF associated with the CE.  If
   so, then all the PE needs to do in this case is to update its
   forwarding state by adding <I, L> to the forwarding state associated
   with <X, Y>.

   If the PE does not have state for <X, Y> in the VRF associated with
   the CE, then the PE constructs a Source Tree Join C-multicast route
   whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y
   as the Multicast Group field.

   Whenever a PE deletes a previously created <X, Y> state that had
   resulted in originating a C-multicast route, the PE withdraws the
   C-multicast route.  The MCAST-VPN NLRI of the withdrawn route is
   carried in the MP_UNREACH_NLRI attribute.

11.1.3.  Constructing the Rest of the C-Multicast Route

   The rest of the C-multicast route is constructed as follows (the same
   procedures apply to both PIM and mLDP as the C-Multicast protocol).

   The local PE executes the procedures of [MVPN] to find the selected
   Upstream Multicast Hop (UMH) route and the selected upstream PE for
   the address carries in the Multicast Source field of MCAST-VPN NLRI.

   From the selected UMH route, the local PE extracts (a) the ASN of the
   upstream PE (as carried in the Source AS Extended Community of the
   route), and (b) the C-multicast Import RT of the VRF on the upstream
   PE (the value of this C-multicast Import RT is the value of the VRF
   Route Import Extended Community carried by the route).  The Source AS
   field in the C-multicast route is set to that AS.  The Route Target
   Extended Community of the C-multicast route is set to that
   C-multicast Import RT.

   If there is more than one (remote) PE that originates the (unicast)
   route to the address carried in the Multicast Source field of the
   MCAST-VPN NLRI, then the procedures for selecting the UMH route and
   the upstream PE to reach that address are as specified in [MVPN].

   If the local and the upstream PEs are in the same AS, then the RD of
   the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route
   that contains the address carried in the Multicast Source field.

   The C-multicast route is then advertised into IBGP.

   If the local and the upstream PEs are in different ASes, then the
   local PE finds in its VRF an Inter-AS I-PMSI A-D route whose Source
   AS field carries the ASN of the upstream PE.  The RD of the found
   Inter-AS I-PMSI A-D route is used as the RD of the advertised
   C-multicast route.  The local PE constructs an IP-based Route Target
   Extended Community by placing the Next Hop of the found Inter-AS I-
   PMSI A-D route in the Global Administrator field of this Community,
   with the Local Administrator field of this Community set to 0; it
   then adds this Community to the Extended Communities attribute of the
   C-multicast route.  (Note that this Route Target is the same as the
   ASBR Import RT of the ASBR identified by the Next Hop of the found
   Inter-AS I-PMSI A-D route.)

   Inter-AS I-PMSI A-D routes are not used to support non-segmented
   inter-AS tunnels.  To support non-segmented inter-AS tunnels, if the
   local and the upstream PEs are in different ASes, the local system
   finds in its VRF an Intra-AS I-PMSI A-D route from the upstream PE
   (the Originating Router's IP Address field of that route has the same
   value as the one carried in the VRF Route Import of the (unicast)
   route to the address carried in the Multicast Source field).  The RD
   of the found Intra-AS I-PMSI A-D route is used as the RD of the
   advertised C-multicast route.  The Source AS field in the C-multicast
   route is set to value of the Originating Router's IP Address field of
   the found Intra-AS I-PMSI A-D route.

   The Next Hop field of the MP_REACH_NLRI attribute MUST be set to a
   routable IP address of the local PE.

   If the Next Hop of the found (Inter-AS or Intra-AS) I-PMSI A-D route
   is an EBGP neighbor of the local PE, then the PE advertises the C-
   multicast route to that neighbor.  If the Next Hop of the found
   (Inter-AS or Intra-AS) I-PMSI A-D route is within the same AS as the
   local PE, then the PE advertises the C-multicast route into IBGP.

11.1.4.  Unicast Route Changes

   The particular UMH route that is selected by a given PE for a given
   C-S may be influenced by the network's unicast routing.  In that
   case, a change in the unicast routing may invalidate prior choices of
   the UMH route for some C-S.  If this happens, the local PE MUST
   execute the UMH route selection procedures for C-S again.  If the

   result is that a different UMH route is selected, then for all C-G,
   any previously originated C-multicast routes for (C-S,C-G) MUST be
   re-originated.

   Similarly, if a unicast routing change results in a change of the UMH
   route for a C-RP, then for all C-G such that C-RP is the RP
   associated with C-G, any previously originated C-multicast routes for
   (C-*,C-G) MUST be re-originated.

11.2.  Propagating C-Multicast Routes by an ASBR

   When an ASBR receives a BGP Update message that carries a C-multicast
   route, if at least one of the Route Targets of the route matches one
   of the ASBR Import RTs (auto-)configured on the ASBR, the ASBR finds
   an Inter-AS I-PMSI A-D route whose RD and Source AS matches the RD
   and Source AS carried in the C-multicast route.  If no matching route
   is found, the ASBR takes no further action.  If a matching route is
   found, the ASBR proceeds as follows.

   To support non-segmented inter-AS tunnels, instead of matching the RD
   and Source AS carried in the C-multicast route against the RD and
   Source AS of an Inter-AS I-PMSI A-D route, the ASBR should match it
   against the RD and the Originating Router's IP Address of the Intra-
   AS I-PMSI A-D routes.

   The ASBR first checks if it already has one or more C-multicast
   routes that have the same MCAST-VPN NLRI as the newly received route.
   If such a route(s) already exists, the ASBR keeps the newly received
   route, but SHALL NOT re-advertise the newly received route.
   Otherwise, the ASBR re-advertises the route, as described in this
   section.

   When an ASBR receives a BGP Update message that carries a withdrawal
   of a previously advertised C-multicast route, the ASBR first checks
   if it already has at least one other C-multicast route that has the
   same MCAST-VPN NLRI.  If such a route already exists, the ASBR
   processes the withdrawn route, but SHALL NOT re-advertise the
   withdrawal.  Otherwise, the ASBR re-advertises the withdrawal of the
   previously advertised C-multicast route, as described below.

   If the ASBR is the ASBR that originated the found Inter-AS I-PMSI A-D
   route, then before re-advertising the C-multicast route into IBGP,
   the ASBR removes from the route the Route Target that matches one of
   the ASBR Import RTs (auto-)configured on the ASBR.

   If the ASBR is not the ASBR that originated the found Inter-AS I-PMSI
   A-D route, then before re-advertising the C-multicast route, the ASBR
   modifies the Extended Communities attribute of the C-multicast route

   by replacing the Route Target of the route that matches one of the
   ASBR Import RTs (auto-)configured on the ASBR with a new Route Target
   constructed as follows.  The new Route Target is an IP-based Route
   Target that has the Global Administrator field set to the Next Hop of
   the found Inter-AS I-PMSI A-D route, and Local Administrator field of
   this Community set to 0.  Note that this newly constructed Route
   Target is the same as the ASBR Import RT of the ASBR identified by
   the Next Hop of the found Inter-AS I-PMSI A-D route.  The rest of the
   Extended Communities attribute of the route SHOULD be passed
   unmodified.

   The Next Hop field of the MP_REACH_NLRI attribute SHOULD be set to an
   IP address of the ASBR.

   If the Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or
   Intra-AS) I-PMSI A-D route is an EBGP neighbor of the ASBR, then the
   ASBR re-advertises the C-multicast route to that neighbor.  If the
   Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or Intra-
   AS) I-PMSI A-D route is an IBGP neighbor of the ASBR, the ASBR re-
   advertises the C-multicast route into IBGP.  If it is the ASBR that
   originated the found Inter-AS I-PMSI A-D route in the first place,
   then the ASBR just re-advertises the C-multicast route into IBGP.

11.3.  Receiving C-Multicast Routes by a PE

   When a PE receives a C-multicast route the PE checks if any of the
   Route Target Extended Communities carried in the Extended Communities
   attribute of the route match any of the C-multicast Import RTs
   associated with the VRFs of any MVPN maintained by the PE.  If no
   match is found, the PE SHOULD discard the route.  Otherwise, (if a
   match is found), the PE checks if the address carried in the
   Multicast Source field of the C-multicast route matches one of the
   (unicast) VPN-IP routes advertised by PE from the VRF.  If no match
   is found the PE SHOULD discard the route.  Otherwise, (if a match is
   found), the PE proceeds as follows, depending on the multicast
   routing protocol between CE and PE (C-multicast protocol).

11.3.1.  Receiving Routes: PIM as the C-Multicast Protocol

   The following describes procedures when PIM is used as the multicast
   routing protocol between CE and PE (C-multicast protocol).

   Since C-multicast routing information is disseminated by BGP, PIM
   messages are never sent from one PE to another.

11.3.1.1.  Receiving Source Tree Join C-Multicast Route

   If the received route has the Route Type set to Source Tree Join,
   then the PE creates a new (C-S,C-G) state in its MVPN-TIB from the
   Multicast Source and Multicast Group fields in the MCAST-VPN NLRI of
   the route, if such a state does not already exist.

   If the local policy on the PE is to bind (C-S,C-G) to an S-PMSI, then
   the PE adds the S-PMSI to the outgoing interface list of the
   (C-S,C-G) state, if it is not already there.  Otherwise, the PE adds
   an I-PMSI to the outgoing interface list of the (C-S,C-G) state, if
   it is not already there.

   When, for a said VRF, the last Source Tree Join C-multicast route for
   (C-S,C-G) is withdrawn, resulting in the situation where the VRF
   contains no Source Tree Join C-multicast route for (C-S,C-G), the PE
   MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the
   (C-S,C-G) state.  Depending on the (C-S,C-G) state of the PE-CE
   interfaces, this may result in the PE using PIM procedures to prune
   itself off the (C-S,C-G) tree.  If C-G is not in the SSM range for
   the VRF, then removing the I-PMSI/S-PMSI from the outgoing interface
   list of the (C-S,C-G) 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 PE does not stop
   forwarding (C-S,C-G) onto a PMSI tunnel until all the PEs of the same
   MVPN have had time to receive the withdrawal of the Source Active A-D
   route for (C-S,C-G) (see Section 13.1), and the PE connected to C-RP
   starts forwarding (C-S,C-G) on the C-RPT.

   Note that before the PE stops forwarding (C-S,C-G), there is a
   possibility to have (C-S,C-G) packets being sent at the same time on
   the PMSI by both the local PE and the PE connected to the site that
   contains C-RP.  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].

11.3.1.2.  Receiving Shared Tree Join C-Multicast Route

   If the received route has the Route Type set to Shared Tree Join,
   then the PE creates a new (C-*,C-G) state in its MVPN-TIB with the RP
   address for that state taken from the Multicast Source, and C-G for
   that state taken from the Multicast Group fields of the MCAST-VPN
   NLRI of the route, if such a state does not already exist.  If there
   is no S-PMSI for (C-*,C-G), then the PE adds I-PMSI to the outgoing

   interface list of the state if it is not already there.  If there is
   an S-PMSI for (C-*,C-G), then the PE adds S-PMSI to the outgoing
   interface list of the state if it is not already there.

   When, for a said VRF, the last Shared Tree Join C-multicast route for
   (C-*,C-G) is withdrawn, resulting in the situation where the VRF
   contains no Shared Tree Join C-multicast route for (C-*,C-G), the PE
   MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the
   (C-*,C-G) state.  Depending on the (C-*,C-G) state of the PE-CE
   interfaces, this may result in the PE using PIM procedures to prune
   itself off the (C-*,C-G) tree.

11.3.2.  Receiving Routes: mLDP as the C-Multicast Protocol

   The following describes procedures when mLDP is used as the multicast
   routing protocol between CE and PE (C-multicast protocol).

   When mLDP is used as a C-multicast protocol, the only valid type of a
   C-multicast route that a PE could receive is a Source Tree Join
   C-multicast route.

   When the PE receives a Source Tree Join C-multicast route, the PE
   applies, in the scope of this VRF, the P2MP mLDP procedures for a
   transit node using the value carried in the Multicast Source field of
   the route as the C-Root Node Identifier, and the value carried in the
   Multicast Group of the route as the C-LDP MP Opaque Value Element.

   If there is no S-PMSI for <C-Root Node Identifier, C-LDP MP Opaque
   Value Element>, then the PE creates and advertises an S-PMSI as
   described in Section 12 using C-Root Node Identifier as the value for
   the Multicast Source field of the S-PMSI A-D route and C-LDP MP
   Opaque Value Element as the value for the Multicast Group field of
   the route.

   To improve scalability when mLDP is used as the C-Multicast protocol
   for a given MVPN, within each AS that has sites of that MVPN
   connected to the PEs of that AS, all the S-PMSIs of that MVPN MAY be
   aggregated into a single P-multicast tree (by using upstream-assigned
   labels).

11.4.  C-Multicast Routes Aggregation

   Note that C-multicast routes are "de facto" aggregated by BGP.  This
   is because the MCAST-VPN NLRIs advertised by multiple PEs, for a
   C-multicast route for a particular C-S and C-G (or a particular C-*
   and C-G) of a given MVPN are identical.

   Hence, a BGP route reflector or ASBR that receives multiple such
   routes with the same NLRI will re-advertise only one of these routes
   to other BGP speakers.

   This implies that 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.  For instance, if multiple PEs
   that are clients of a route reflector, have receivers for a specific
   SSM channel of a MVPN, they will all advertise an identical NLRI for
   the Source Tree Join C-multicast route.  However, only one
   C-multicast route will be advertised by the route reflector for this
   specific SSM channel of that MVPN, to other PEs and route reflectors
   that are clients of the route reflector.

   This also implies that an ASBR aggregates all the received
   C-multicast routes for a given (S,G) (or a given (*,G)) of a given
   MVPN into a single C-multicast route.

   To further reduce the routing churn due to C-multicast routes
   changes, a route reflector that re-advertises a C-multicast route
   SHOULD set the Next Hop field of the MP_REACH_NLRI attribute of the
   route to an IP address of the route reflector.  Likewise, an ASBR
   that re-advertises a C-multicast route SHOULD set the Next Hop field
   of the MP_REACH_NLRI attribute of the route to an IP address of the
   ASBR.

   Further, a BGP receiver, which receives multiple such routes with the
   same NLRI for the same C-multicast route, will potentially create
   forwarding state based on a single C-multicast route.  Per the
   procedures described in Section 11.3, this forwarding state will be
   the same as the state that would have been created based on another
   route with same NLRI.