5.  Demultiplexing P-Multicast Tree Traffic

   Demultiplexing received VPLS traffic requires the receiving PE to
   determine the VPLS instance to which the packet belongs.  The egress
   PE can then perform a VPLS lookup to further forward the packet.  It
   also requires the egress PE to determine the identity of the ingress
   PE for MAC learning, as described in the "VPLS Data Packet Treatment"
   section.

5.1.  One P-Multicast Tree - One VPLS Mapping

   When a P-multicast tree is mapped to only one VPLS, determining the
   tree on which the packet is received is sufficient to determine the
   VPLS instance on which the packet is received.  The tree is
   determined based on the tree encapsulation.  If MPLS encapsulation is
   used, e.g., RSVP-TE P2MP LSPs, the outer MPLS label is used to
   determine the tree.  Penultimate Hop Popping (PHP) MUST be disabled
   on the MPLS LSP (RSVP-TE P2MP LSP or mLDP P2MP LSP).

5.2.  One P-Multicast Tree - Many VPLS Mapping

   As traffic belonging to multiple VPLS instances can be carried over
   the same tree, there is a need to identify the VPLS to which the
   packet belongs.  This is done by using an inner label that determines
   the VPLS for which the packet is intended.  The ingress PE uses this
   label as the inner label while encapsulating a customer multicast
   data packet.  Each of the egress PEs must be able to associate this
   inner label with the same VPLS and use it to demultiplex the traffic
   received over the Aggregate Inclusive tree or the Aggregate Selective
   tree.

   If traffic from multiple VPLS instances is carried on a single tree,
   upstream-assigned labels [RFC5331] MUST be used.  Hence, the inner
   label is assigned by the ingress PE.  When the egress PE receives a
   packet over an Aggregate tree, the outer encapsulation (in the case
   of MPLS P2MP LSPs, the outer MPLS label) specifies the label space to
   perform the inner-label lookup.  The same label space MUST be used by
   the egress PE for all P-multicast trees that have the same root
   [RFC5331].

   If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the
   outer MPLS label and, optionally, the incoming interface provide the
   label space of the label beneath it.  This assumes that PHP is
   disabled.  The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT
   NULL for that tree once it is known to the egress PE that the tree is
   bound to one or more VPLS instances.  Once the label representing the

   tree is popped off the MPLS label stack, the next label is the
   demultiplexing information that allows the proper VPLS instance to be
   determined.

   The ingress PE informs the egress PEs about the inner label as part
   of the tree binding procedures described in the "BGP Extensions"
   section.

6.  Establishing P-Multicast Trees

   This document supports only P2MP P-multicast trees wherein it is
   possible for egress PEs to identify the ingress PE to perform MAC
   learning.  Specific procedures are identified only for RSVP-TE P2MP
   LSPs and mLDP P2MP LSPs.  An implementation that supports this
   document MUST support RSVP-TE P2MP LSPs and mLDP P2MP LSPs.

6.1.  Common Procedures

   The following procedures apply to both RSVP-TE P2MP and mLDP P2MP
   LSPs.

   Demultiplexing the C-multicast data packets at the egress PE requires
   that the PE must be able to determine the P2MP LSP on which the
   packets are received.  This enables the egress PE to determine the
   VPLS instances to which the packet belongs.  To achieve this, the LSP
   MUST be signaled with PHP off and a non-special purpose MPLS label
   off as described in the "Demultiplexing P-Multicast Tree Traffic"
   section.  In other words, an egress PE MUST NOT advertise IMPLICIT
   NULL or EXPLICIT NULL for a P2MP LSP that is carrying traffic for one
   or more VPLS instances.  This is because the egress PE needs to rely
   on the MPLS label, that it advertises to its upstream neighbor, to
   determine the P2MP LSP on which a C-multicast data packet is
   received.

   The egress PE also needs to identify the ingress PE to perform MAC
   learning.  When P2MP LSPs are used as P2MP trees, determining the
   P2MP LSP on which the packets are received is sufficient to determine
   the ingress PE.  This is because the ingress PE is the root of the
   P2MP LSP.

   The egress PE relies on receiving the PMSI Tunnel attribute in BGP to
   determine the VPLS instance to P2MP LSP mapping.

6.2.  RSVP-TE P2MP LSPs

   This section describes procedures that are specific to the usage of
   RSVP-TE P2MP LSPs for instantiating a P-multicast tree.  Procedures
   in [RFC4875] are used to signal the P2MP LSP.  The LSP is signaled as

   the root of the P2MP LSP discovers the leaves.  The egress PEs are
   discovered using the procedures described in the "Intra-AS Inclusive
   P-Multicast Tree Auto-discovery/Binding" section.  Aggregation, as
   described in this document, is supported.

6.2.1.  P2MP TE LSP - VPLS Mapping

   P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP-
   based advertisements of the P2MP TE LSP - VPLS mapping.  They require
   that the root of the tree include in the BGP advertisements the P2MP
   TE LSP identifier as the P-multicast tree identifier.  This
   P-multicast tree identifier contains the following information
   elements:

           - The type of the tunnel is set to RSVP-TE P2MP LSP
           - RSVP-TE P2MP LSP's SESSION Object

   See the "Inclusive Tree/Selective Tree Identifier" section for more
   details on how this tree identifier is carried in BGP advertisements.

   Once the egress PE receives the P2MP TE LSP to VPLS mapping:

     + If the egress PE already has RSVP-TE state for the P2MP TE LSP,
       it MUST begin to assign an MPLS label from the non-special
       purpose label range, for the P2MP TE LSP and signal this to the
       previous hop of the P2MP TE LSP.  Further, it MUST create
       forwarding state to forward packets received on the P2MP LSP.

     + If the egress PE does not have RSVP-TE state for the P2MP TE LSP,
       it MUST retain this mapping.  Subsequently, when the egress PE
       receives the RSVP-TE P2MP signaling message, it creates the RSVP-
       TE P2MP LSP state.  It MUST then assign an MPLS label from the
       non-reserved label range, for the P2MP TE LSP, and signal this to
       the previous hop of the P2MP TE LSP.

       Note that if the signaling to set up an RSVP-TE P2MP LSP is
       completed before a given egress PE learns, via a PMSI Tunnel
       attribute, of the VPLS or set of VPLS instances to which the LSP
       is bound, the PE MUST discard any traffic received on that LSP
       until the binding is received.  In order for the egress PE to be
       able to discard such traffic, it needs to know that the LSP is
       associated with one or more VPLS instances and that the VPLS A-D
       route that binds the LSP to a VPLS has not yet been received.
       This is provided by extending [RFC4875] with [RFC6511].

6.3.  Receiver-Initiated P2MP LSP

   Receiver-initiated P2MP LSPs can also be used.  The mLDP procedures
   ([RFC6388]) MUST be used to signal such LSPs.  The LSP is signaled
   once the leaves receive the LDP FEC for the tree from the root, as
   described in the "Intra-AS Inclusive P-Multicast Tree Auto-
   discovery/Binding" section.  When aggregation is used, an ingress PE
   is required to discover the egress PEs (see the "Aggregation
   Considerations" section for the rationale), and this is achieved
   using the procedures in the "Intra-AS Inclusive P-Multicast Tree
   Auto-discovery/Binding" section.

6.3.1.  P2MP LSP - VPLS Mapping

   P2MP LSP to VPLS mapping is learned at the egress PEs using BGP-based
   advertisements of the P2MP LSP - VPLS mapping.  They require that the
   root of the tree include in the BGP advertisements the P2MP LSP
   identifier as the P-multicast tree identifier.  This P-multicast tree
   identifier contains the following information elements:

      - The type of the tunnel is set to LDP P2MP LSP
      - LDP P2MP FEC that includes an identifier generated by the root.

   See the "Inclusive Tree/Selective Tree Identifier" section for more
   details on how this tree identifier is carried in BGP advertisements.


   Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label
   mapping messages for the LDP P2MP FEC, that was learned in the BGP
   advertisement, using procedures described in [RFC6388].

6.4.  Encapsulation of Aggregate P-multicast Trees

   An Aggregate Inclusive P-multicast tree or an Aggregate Selective
   P-multicast tree MUST use MPLS encapsulation, as described in
   [RFC5332].

7.  Inter-AS Inclusive P-Multicast Tree A-D/Binding

   As stated earlier, this document defines four models of inter-AS VPLS
   service, referred here as option (a), (b), (c), and (e).  This
   section contains procedures to support these models.

   For supporting option (a), (b), and (e), this section specifies a
   model where inter-AS VPLS service can be offered without requiring a
   single P-multicast tree to span multiple ASes.  This allows
   individual ASes to potentially use different P-tunneling
   technologies.  There are two variants of this model.  One that

   requires MAC lookup on the ASBRs and applies to option (a) and (e).
   The other is one that does not require MAC lookup on the ASBRs, and
   instead it builds segmented Inter-AS Inclusive or Selective trees.
   This applies only to option (b).

   For supporting option (c), this section specifies a model where
   Inter-AS VPLS service is offered by requiring a single Inclusive
   P-multicast tree to span multiple ASes.  This is referred to as a
   "non-segmented P-multicast tree".  This is because in the case of
   option (c), the ASBRs do not exchange BGP-VPLS NLRIs or VPLS A-D
   routes.  Support for Inter-AS Selective trees for option (c) may be
   segmented or non-segmented.

   An implementation MUST support options (a), (b), and (c), and MAY
   support option (e).  When there are multiple ways for implementing
   one of these options, this section specifies which one is mandatory.

7.1.  VSIs on the ASBRs

   When VSIs are configured on ASBRs, the ASBRs MUST perform a MAC
   lookup, in addition to any MPLS lookups, to determine the forwarding
   decision on a VPLS packet.  The P-multicast trees are confined to an
   AS.  An ASBR on receiving a VPLS packet from another ASBR is required
   to perform a MAC lookup to determine how to forward the packet.
   Thus, an ASBR is required to keep a VSI for the VPLS instance and
   MUST be configured with its own VE-ID for the VPLS instance.  The BGP
   VPLS A-D routes generated by PEs in an AS MUST NOT be propagated
   outside the AS.

7.1.1.  Option (a): VSIs on the ASBRs

   In option (a), an ASBR acts as a PE for the VPLSs that span the AS of
   the ASBR and an AS to which the ASBR is connected.  The local ASBR
   views the ASBR in the neighboring AS as a CE connected to it by a
   link with separate VLAN sub-interfaces for each such VPLS.
   Similarly, the ASBR in the neighboring AS acts as a PE for such VPLS
   from the neighboring AS's point of view, and views the local ASBR as
   a CE.

   The local ASBR uses a combination of the incoming link and a
   particular VLAN sub-interface on that link to determine the VSI for
   the packets it receives from the ASBR in the neighboring AS.

   In option (a), the ASBRs do not exchange VPLS A-D routes.

   An implementation MUST support option (a).

7.1.2.  Option (e): VSIs on the ASBRs

   The VSIs on the ASBRs scheme can be used such that the interconnect
   between the ASBRs is a PW and MPLS encapsulation is used between the
   ASBRs.  An ASBR in one AS determines the VSI for packets received
   from an adjoining ASBR in another AS based on the incoming MPLS PW
   label.  This is referred to as "option (e)".  The only VPLS A-D
   routes that are propagated outside the AS are the ones originated by
   ASBRs.  This MPLS PW connects the VSIs on the ASBRs and MUST be
   signaled using the procedures defined in [RFC4761] or [RFC4762].

   The P-multicast trees for a VPLS are confined to each AS and the VPLS
   auto-discovery/binding MUST follow the intra-AS procedures described
   in the "Demultiplexing P-Multicast Tree Traffic" section.

   An implementation MAY support option (e).

7.2.  Option (b) - Segmented Inter-AS Trees

   In this model, an inter-AS P-multicast tree, rooted at a particular
   PE for a particular VPLS instance, consists of a number of
   "segments", one per AS, which are stitched together at ASBRs.  These
   are known as "segmented inter-AS trees".  Each segment of a segmented
   inter-AS tree may use a different multicast transport technology.  In
   this model, an ASBR is not required to keep a VSI for the VPLS
   instance, and is not required to perform a MAC lookup in order to
   forward the VPLS packet.  This implies that an ASBR is not required
   to be configured with a VE-ID for the VPLS.

   An implementation MUST support option (b) using this model.

   The construction of segmented inter-AS trees requires the BGP-VPLS
   A-D NLRI described in [RFC4761] and [RFC6074].  A BGP VPLS A-D route
   for an <RD, VE-ID> tuple advertised outside the AS, to which the
   originating PE belongs, will be referred to as an "Inter-AS VPLS A-D
   route" (though this route is originated by a PE as an intra-AS route,
   and is referred to as an "inter-AS route outside the AS").

   In addition to this, segmented inter-AS trees require support for the
   PMSI Tunnel attribute described in the "Inclusive Tree/Selective Tree
   Identifier" section.  They also require additional procedures in BGP
   to signal leaf A-D routes between ASBRs as explained in subsequent
   sections.

7.2.1.  Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding

   This section specifies the procedures for inter-AS VPLS A-D/binding
   for segmented Inter-AS trees.

   An ASBR must be configured to support a particular VPLS as follows:

     + An ASBR MUST be configured with a set of (import) RTs that
       specify the set of VPLS instances supported by the ASBR.  These
       RTs control acceptance of BGP VPLS auto-discovery routes by the
       ASBR.  Note that instead of being configured, the ASBR MAY obtain
       this set of (import) RTs by using Route Target Constrain
       [RFC4684].

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

   If an ASBR is configured to support a particular VPLS instance, the
   ASBR MUST participate in the intra-AS VPLS auto-discovery/binding
   procedures for that VPLS instance within the ASBR's own AS, as
   defined in this document.

   Moreover, in addition to the above, the ASBR performs procedures
   specified in the "Propagating BGP VPLS A-D Routes to Other ASes:
   Overview" section.

7.2.2.  Propagating BGP VPLS A-D Routes to Other ASes: Overview

   A BGP VPLS A-D route for a given VPLS, originated by a PE within a
   given AS, is propagated via BGP to other ASes.  The precise rules for
   distributing and processing the Inter-AS A-D routes are given in
   subsequent sections.

   Suppose that an ASBR "A" receives and installs a BGP VPLS A-D route
   for VPLS "X" and VE-ID "V" that originated at a particular PE "PE1"
   that is in the same AS as A.  The BGP next hop of that received route
   becomes A's "upstream neighbor" on a multicast distribution tree for
   (X, V) that is rooted at PE1.  Likewise, when A re-advertises this
   route to ASBRs in A's neighboring ASes, from the perspective of these
   ASBRs A becomes their "upstream neighbor" on the multicast
   distribution tree for (X, V) that is rooted at PE1.

   When the BGP VPLS A-D routes have been distributed to all the
   necessary ASes, they define a "reverse path" from any AS that
   supports VPLS X and VE-ID V back to PE1.  For instance, if AS2
   supports VPLS X, then there will be a reverse path for VPLS X and VE

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

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

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

   For a given inter-AS tree and a given AS, there MUST be only one ASBR
   within that AS that accepts traffic flowing on that tree.  Further,
   for a given inter-AS tree and a given AS, there MUST be only one ASBR
   in that AS that sends the traffic flowing on that tree to a
   particular adjacent AS.  The precise rules for accomplishing this are
   given in subsequent sections.

   An ASBR initiates creation of an intra-AS segment when the ASBR
   receives an Inter-AS A-D route from an External BGP (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 VPLS instances may share the same P-multicast tree.

   If the P-multicast tree instantiating a particular segment of an
   inter-AS tunnel is created by a multicast control protocol that uses
   receiver-initiated joins (e.g, mLDP), and this P-multicast tree does
   not aggregate multiple segments, then all the information needed to
   create that segment will be present in the Inter-AS A-D routes
   received by the ASBR from the neighboring ASBR.  But if the
   P-multicast tree instantiating 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 the ASBR needs to learn the leaves of the
   segment.  These leaves are learned from A-D routes received from
   other PEs in the AS, for the same VPLS as the one to which the
   segment belongs.

   The following sections specify procedures for propagation of Inter-AS
   A-D routes across ASes in order to construct inter-AS segmented
   trees.

7.2.2.1.  Propagating Intra-AS VPLS A-D Routes in EBGP

   For a given VPLS configured on an ASBR when the ASBR receives Intra-
   AS A-D routes originated by PEs in its own AS, the ASBR MUST
   propagate each of these route in EBGP.  This procedure MUST be
   performed for each of the VPLS instances configured on the ASBR.
   Each of these routes is constructed as follows:

     + The route carries a single BGP VPLS A-D NLRI with the RD and
       VE-ID being the same as the NLRI in the received Intra-AS A-D
       route.

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

     + The route carries the PMSI Tunnel attribute with the Tunnel Type
       set to Ingress Replication; the attribute carries no MPLS labels.

     + The route MUST carry the export RT used by the VPLS.

7.2.2.2.  Inter-AS 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 A-D route, if (a) at least one of
   the RTs carried in the message matches one of the import RTs
   configured on the ASBR, and (b) the ASBR determines that the received
   route is the best route to the destination carried in the NLRI of the
   route, the ASBR re-advertises this Inter-AS A-D route to other PEs
   and ASBRs within its own AS.  The best route selection procedures
   MUST ensure that for the same destination, all ASBRs in an AS pick
   the same route as the best route.  The best route selection
   procedures are specified in [RFC4761] and clarified in
   [MULTI-HOMING].  The best route procedures ensure that if multiple
   ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP
   neighbors, only one of these ASBRs propagates this route in Internal
   BGP (IBGP).  This ASBR becomes the root of the intra-AS segment of
   the inter-AS tree and ensures that this is the only ASBR that accepts
   traffic into this AS from the inter-AS tree.

   When re-advertising an Inter-AS 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.

   Depending on the type of a P-multicast tunnel used to instantiate the
   intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of
   the re-advertised Inter-AS A-D route is constructed as follows:

     + If the ASBR uses ingress replication to instantiate the intra-AS
       segment of the inter-AS tunnel, the re-advertised route MUST NOT
       carry the PMSI Tunnel attribute.

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

     + An ASBR that uses a P-multicast tree to instantiate the intra-AS
       segment of the inter-AS tunnel MAY aggregate two or more VPLS
       instances present on the ASBR onto the same tree.  If the ASBR
       already advertises Inter-AS A-D routes for these VPLS instances,
       then aggregation requires the ASBR 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 ASBR has not
       previously advertised Inter-AS A-D routes for these VPLS
       instances, then the aggregation requires the ASBR to advertise
       (new) Inter-AS A-D routes for these VPLS instances.  The PMSI
       Tunnel attribute in the newly advertised/re-advertised routes
       MUST carry the identity of the P-multicast tree that aggregates
       the VPLS instances, as well as an MPLS upstream-assigned label
       [RFC5331].  Each newly advertised or re-advertised route MUST
       have a label that is distinct within the scope of the ASBR.

   In addition, the ASBR MUST send to the EBGP neighbor, from whom it
   receives the Inter-AS A-D route, a BGP Update message that carries a
   leaf A-D route.  The exact encoding of this route is described in the
   "BGP Extensions" section.  This route contains the following
   information elements:

     + The route carries a single NLRI with the Route Key field set to
       the <RD, VE-ID> tuple of the BGP VPLS A-D NLRI of the Inter-AS
       A-D route received from the EBGP neighbor.  The NLRI also carries
       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 to demultiplex the VPLS traffic received over
       a unicast tunnel by the advertising router.

     + The Next Hop field of the MP_REACH_NLRI attribute of the route
       SHOULD 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]).

     + The ASBR constructs an IP-address-specific RT by placing the IP
       address carried in the Next Hop field of the received Inter-AS
       VPLS A-D route in the Global Administrator field of the
       community, with the Local Administrator field of this community
       set to 0.  It also sets the Extended Communities attribute of the
       leaf A-D route to that community.  Note that this RT is the same
       as the ASBR Import RT of the EBGP neighbor from which the ASBR
       received the Inter-AS VPLS A-D route.

7.2.2.3.  Leaf A-D Route Received via EBGP

   When an ASBR receives, via EBGP, a leaf A-D route, the ASBR accepts
   the route only if (a) at least one of the RTs carried in the message
   matches one of the import RTs configured on the ASBR and (b) the ASBR
   determines that the received route is the best route to the
   destination carried in the NLRI of the route.

   If the ASBR accepts the leaf A-D route, the ASBR looks for an
   existing A-D route whose BGP-VPLS A-D NLRI has the same value as the
   <RD, VE-ID> field of the leaf A-D route just accepted.  If such an
   A-D route is found, then the MPLS label carried in the PMSI Tunnel
   attribute of the leaf A-D route is used to stitch a one hop ASBR-ASBR
   LSP to the tail of the intra-AS tunnel segment associated with the
   found A-D route.

7.2.2.4.  Inter-AS 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.

   Note that a given Inter-AS A-D route is advertised within a given AS
   by only one ASBR, as described above.

   When a PE/ASBR router receives, from one of its IBGP neighbors, a BGP
   Update message that carries an Inter-AS A-D route, if (a) at least
   one of the RTs carried in the message matches one of the import RTs
   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.
   The best route determination is as described in [RFC4761] and
   clarified in [MULTI-HOMING].

   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 A-D route carries the PMSI Tunnel attribute
   with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR SHOULD join the
   P-multicast tree whose identity is carried in the PMSI Tunnel
   attribute.

   If the received Inter-AS 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 A-D route carries the PMSI Tunnel attribute
   with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP LSP, 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 <VPLS, VE-ID> advertised
   by the Inter-AS A-D route and rooted at the PE that originated the
   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 ASBR-ASBR inter-AS
   segment of the inter-AS tunnel.  If the PE/ASBR has local receivers
   in the VPLS, packets received over the intra-AS segment must be
   forwarded to the local receivers using the local VSI.

7.3.  Option (c): Non-segmented Tunnels

   In this model, there is a multi-hop EBGP peering between the PEs (or
   BGP Route Reflector) in one AS and the PEs (or BGP Route Reflector)
   in another AS.  The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI,
   along with the PMSI Tunnel attribute, as in the intra-AS case
   described in the "Demultiplexing P-Multicast Tree Traffic" section.

   The PEs in different ASes use a non-segmented inter-AS P2MP tunnel
   for VPLS multicast.  A non-segmented inter-AS tunnel is a single
   tunnel that spans AS boundaries.  The tunnel technology cannot change
   from one point in the tunnel to the next, so all ASes through which
   the tunnel passes must support that technology.  In essence, AS
   boundaries are of no significance to a non-segmented inter-AS P2MP
   tunnel.

   This model requires no VPLS A-D routes in the control plane or VPLS
   MAC address learning in the data plane on the ASBRs.  The ASBRs only
   need to participate in the non-segmented P2MP tunnel setup in the
   control plane and do MPLS label forwarding in the data plane.

   When the tunneling technology is P2MP LSP signaled with mLDP, and one
   does not use [RFC6512], the setup of non-segmented inter-AS P2MP
   tunnels requires the P-routers in one AS to have IP reachability to
   the loopback addresses of the PE routers in another AS.  That is, the
   reachability to the loopback addresses of PE routers in one AS MUST
   be present in the IGP in another AS.

   The data forwarding in this model is the same as in the intra-AS case
   described in the "Demultiplexing P-Multicast Tree Traffic" section.

   An implementation MUST support this model.

8.  Optimizing Multicast Distribution via Selective Trees

   Whenever a particular multicast stream is being sent on an Inclusive
   P-multicast tree, it is likely that the data of that stream is being
   sent to PEs that do not require it, as the sites connected to these
   PEs may have no receivers for the stream.  If a particular stream has
   a significant amount of traffic, it may be beneficial to move it to a
   Selective P-multicast tree that has, at its leaves, only those PEs,
   connected to sites that have receivers for the multicast stream (or
   at least includes fewer PEs that are attached to sites with no
   receivers compared to an Inclusive tree).

   A PE connected to the multicast source of a particular multicast
   stream may be performing explicit tracking; that is, it may know the
   PEs that have receivers in the multicast stream.  The "Receiving
   S-PMSI A-D Routes by PEs" section describes procedures that enable
   explicit tracking.  If this is the case, Selective P-multicast trees
   can also be triggered on other criteria.  For instance, there could
   be a "pseudo-wasted bandwidth" criterion: switching to a Selective
   tree would be done if the bandwidth multiplied by the number of
   "uninterested" PEs (PEs that are receiving the stream but have no
   receivers) is above a specified threshold.  The motivation is that
   (a) the total bandwidth wasted by many sparsely subscribed low-

   bandwidth groups may be large and (b) there's no point to moving a
   high-bandwidth group to a Selective tree if all the PEs have
   receivers for it.

   Switching a (C-S, C-G) stream to a Selective P-multicast tree may
   require the root of the tree to determine the egress PEs that need to
   receive the (C-S, C-G) traffic.  This is true in the following cases:

     + If the tunnel is a P2MP tree, such as an RSVP-TE P2MP Tunnel, the
       PE needs to know the leaves of the tree before it can instantiate
       the Selective tree.

     + If a PE decides to send traffic for multicast streams, belonging
       to different VPLS instances, using one P-multicast Selective
       tree, such a tree is called an "Aggregate tree with a selective
       mapping".  The setting up of such an Aggregate tree requires the
       ingress PE to know all the other PEs that have receivers for
       multicast groups that are mapped onto the tree (see the
       "Aggregation Considerations" section for the rationale).

     + If ingress replication is used and the ingress PE wants to send
       traffic for (C-S, C-G)s to only those PEs that are on the path to
       receivers to the (C-S, C-G)s.

   For discovering the IP multicast group membership, for the above
   cases, this document describes procedures that allow an ingress PE to
   enable explicit tracking.  Thus, an ingress PE can request the IP
   multicast membership from egress PEs for one or more C-multicast
   streams.  These procedures are described in the "Receiving S-PMSI A-D
   Routes by PEs" section.

   The root of the Selective P-multicast tree MAY decide to do explicit
   tracking of the IP multicast stream only after it has decided to move
   the stream to a Selective tree, or it MAY have been doing explicit
   tracking all along.  This document also describes explicit tracking
   for a wildcard source and/or group in the "Receiving S-PMSI A-D
   Routes by PEs" section, which facilitates a Selective P-multicast
   tree only mode in which IP multicast streams are always carried on a
   Selective P-multicast tree.  In the description on Selective
   P-multicast trees, the notation C-S is intended to represent either a
   specific source address or a wildcard.  Similarly, C-G is intended to
   represent either a specific group address or a wildcard.

   The PE at the root of the tree MUST signal the leaves of the tree
   that the (C-S, C-G) stream is now bound to the Selective tree.  Note
   that the PE could create the identity of the P-multicast tree prior
   to the actual instantiation of the tunnel.

   If the Selective tree is instantiated by an RSVP-TE P2MP LSP, the PE
   at the root of the tree MUST establish the P2MP RSVP-TE LSP to the
   leaves.  This LSP MAY have been established before the leaves receive
   the Selective tree binding, or it MAY be established after the leaves
   receive the binding.  A leaf MUST NOT switch to the Selective tree
   until it receives the binding and the RSVP-TE P2MP LSP is set up to
   the leaf.

8.1.  Protocol for Switching to Selective Trees

   Selective trees provide a PE the ability to create separate
   P-multicast trees for certain (C-S, C-G) streams.  The source PE,
   which originates the Selective tree, and the egress PEs MUST use the
   Selective tree for the (C-S, C-G) streams that are mapped to it.
   This may require the source and egress PEs to switch to the Selective
   tree from an Inclusive tree if they were already using an Inclusive
   tree for the (C-S, C-G) streams mapped to the Selective tree.

   Once a source PE decides to set up a Selective tree, it MUST announce
   the mapping of the (C-S, C-G) streams (which may be in different VPLS
   instances) that are mapped to the tree to the other PEs using BGP.
   After the egress PEs receive the announcement, they set up their
   forwarding path to receive traffic on the Selective tree if they have
   one or more receivers interested in the (C-S, C-G) streams mapped to
   the tree.  Setting up the forwarding path requires setting up the
   demultiplexing forwarding entries based on the top MPLS label (if
   there is no inner label) or the inner label (if present) as described
   in the "Establishing P-Multicast Trees" section.

   When the P2MP LSP is established using mLDP, the egress PEs MAY
   perform this switch to the Selective tree once the announcement from
   the ingress PE is received, or they MAY wait for a preconfigured
   timer to do so after receiving the announcement.

   When the P2MP LSP protocol is P2MP RSVP-TE, an egress PE MUST perform
   this switch to the Selective tree only after the announcement from
   the ingress PE is received and the RSVP-TE P2MP LSP has been set up
   to the egress PE.  This switch MAY be done after waiting for a
   preconfigured timer after these two steps have been accomplished.

   A source PE MUST use the following approach to decide when to start
   transmitting data on the Selective tree, if it is currently using an
   Inclusive tree.  After announcing the (C-S, C-G) stream mapping to a
   Selective tree, the source PE MUST wait for a "switchover" delay
   before sending (C-S, C-G) stream on the Selective tree.  It is
   RECOMMENDED to allow this delay to be configurable.  Once the

   "switchover" delay has elapsed, the source PE MUST send (C-S, C-G)
   stream on the Selective tree.  In no case is any (C-S, C-G) packet
   sent on both Selective and Inclusive trees.

   When a (C-S, C-G) stream is switched from an Inclusive to a Selective
   tree, the purpose of running a switchover timer is to minimize packet
   loss without introducing packet duplication.  However, jitter may be
   introduced due to the difference in transit delays between the
   Inclusive and Selective trees.

   For best effect, the switchover timer should be configured to a value
   that is "just long enough" (a) to allow all the PEs to learn about
   the new binding of (C-S, C-G) to a Selective tree and (b) to allow
   the PEs to construct the P-tunnel associated with the Selective tree,
   if it doesn't already exist.

8.2.  Advertising (C-S, C-G) Binding to a Selective Tree

   The ingress PE informs all the PEs that are on the path to receivers
   of the (C-S, C-G) of the binding of the Selective tree to the (C-S,
   C-G), using BGP.  The BGP announcement is done by sending update for
   the MCAST-VPLS address family using what we referred to as an "S-PMSI
   A-D route".  The format of the NLRI of this route is described in the
   "Inclusive Tree/Selective Tree Identifier" section.  The NLRI MUST be
   constructed as follows:

     + The Route Distinguisher (RD) MUST be set to the RD configured
       locally for the VPLS.  This is required to uniquely identify the
       <C-S, C-G> as the addresses could overlap between different VPLS
       instances.  This MUST be the same RD value used in the VPLS auto-
       discovery process.

     + 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.  If the source
       address is a wildcard, the source address is set to 0.

     + 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.  If the group
       address is a wildcard, the group address is set to 0.

     + The Originating Router's IP Address field MUST be set to the IP
       address that the (local) PE places in the BGP Next Hop of the
       BGP-VPLS A-D routes.  Note that the <RD, Originating Router's IP
       Address> tuple uniquely identifies a given VPLS instance on a PE.

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

   Depending on the type of a 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.  This enables explicit tracking for the multicast
       stream(s) advertised by the S-PMSI A-D route.

     + 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 RT, 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 the "Receiving S-PMSI A-D Routes by
       PEs" section.)

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

       If the PE supports Route Target Constrain [RFC4684], the PE
       SHOULD advertise this import RT within its own AS using Route
       Target Constrain.  To constrain distribution of the Route Target
       Constrain 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 VPLS instances, then all
       these routes MUST carry an MPLS upstream-assigned label
       [RFC5331].  If all these aggregated S-PMSIs belong to the same
       VPLS, then the routes MAY carry an MPLS upstream-assigned label
       [RFC5331].  The labels MUST be distinct on a per-VPLS-instance
       basis, and they MAY be distinct on a per-route basis.

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

   By default, the set of RTs carried by the route MUST be the same as
   the RTs carried in the BGP-VPLS A-D route originated from the VSI.
   The default could be modified via configuration.

8.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 VSIs on the PE have their import RTs that contain one or more of
   the RTs carried by the received S-PMSI A-D route, then for each such
   VSI, 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 the "Inter-AS A-D Route Received via IBGP" section,
   except that (a) instead of Inter-AS A-D routes the procedures apply
   to S-PMSI A-D routes, (b) the rules for determining whether the
   received S-PMSI A-D route is the best route to the destination
   carried in the NLRI of the route are the same as BGP path selection
   rules and may be modified by policy, and (c) a PE performs procedures
   specified in that section only if in addition to the criteria
   specified in that section the following is true:

     + If, as a result of multicast state snooping on the PE-CE
       interfaces, the PE has snooped state for at least one multicast
       join that matches the multicast source and group advertised in
       the S-PMSI A-D route.  Further, the oifs (outgoing interfaces)
       for this state contain one or more interfaces to the locally
       attached CEs.  When the multicast signaling protocol among the
       CEs is IGMP, then snooping and associated procedures are defined
       in [RFC4541].  The snooped state is determined using these
       procedures.  When the multicast signaling protocol among the CEs
       is PIM, the procedures in [RFC4541] are not sufficient to
       determine the snooped state.  The additional details required to

       determine the snooped state when CE-CE protocol is PIM are for
       further study.  When such procedures are defined, it is expected
       that the procedures in this section will apply to the snooped
       state created as a result of PIM as PE-CE protocol.

   The snooped state is said to "match" the S-PMSI A-D route if any of
   the following is true:

     + The S-PMSI A-D route carries (C-S, C-G) and the snooped state is
       for (C-S, C-G) or for (C-*, C-G), OR

     + The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped state
       is for (C-*, C-G) OR (b) the snooped state is for at least one
       multicast join with the multicast group address equal to C-G and
       there doesn't exist another S-PMSI A-D route that carries (C-S,
       C-G) where C-S is the source address of the snooped state.

     + The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped state
       is for at least one multicast join with the multicast source
       address equal to C-S, and (b) there doesn't exist another S-PMSI
       A-D route that carries (C-S, C-G) where C-G is the group address
       of the snooped state.

     + The S-PMSI A-D route carries (C-*, C-*) and there is no other
       S-PMSI A-D route that matches the snooped state as per the above
       conditions.

   Note if the above conditions are true, and 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, constructed
   as follows:

     + The route carries a single MCAST-VPLS NLRI with the Route Key
       field set to the MCAST-VPLS NLRI of the received S-PMSI A-D
       route.

     + The Originating Router's IP Address set to the IP address of the
       PE (this MUST be a routable IP address).

     + The PE constructs an IP-address-specific RT by placing the IP
       address carried in the Next Hop field of the received S-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], except for the inter-AS
       scenario with option (c).

   Once the leaf A-D route is constructed, the PE advertises this route
   into IBGP.

   In addition to the procedures specified in the "Inter-AS A-D Route
   Received via IBGP" section, the PE MUST set up its forwarding path to
   receive traffic, for each multicast stream in the matching snooped
   state, from the tunnel advertised by the S-PMSI A-D route (the PE
   MUST switch to the Selective tree).

   When a new snooped state is created by a PE, then the PE MUST first
   determine if there is an S-PMSI A-D route that matches the snooped
   state as per the conditions described above.  If such an S-PMSI A-D
   route is found, then the PE MUST follow the procedures described in
   this section, for that particular S-PMSI A-D route.  If later on the
   snooped state ages out and is deleted from the PE, the PE SHOULD
   withdraw the leaf A-D route that it had originated in response to the
   S-PMSI A-D route.

8.4.  Inter-AS Selective Tree

   Inter-AS Selective trees support all three options of inter-AS VPLS
   service, option (a), (b), and (c), that are supported by Inter-AS
   Inclusive trees.  They are constructed in a manner that is very
   similar to Inter-AS Inclusive trees.

   For option (a) and option (b), support Inter-AS Selective trees are
   constructed without requiring a single P-multicast tree to span
   multiple ASes.  This allows individual ASes to potentially use
   different P-tunneling technologies.  There are two variants of this.
   One that requires MAC and IP multicast lookup on the ASBRs and
   another that does not require MAC/IP multicast lookup on the ASBRs
   and instead builds segmented Inter-AS Selective trees.

   Segmented Inter-AS Selective trees can also be used with option (c),
   unlike Segmented Inter-AS Inclusive trees.  This is because the
   S-PMSI A-D routes can be exchanged via ASBRs (even though BGP VPLS
   A-D routes are not exchanged via ASBRs).

   In the case of Option (c), an Inter-AS Selective tree may also be a
   non-segmented P-multicast tree that spans multiple ASes.

8.4.1.  VSIs on the ASBRs

   The requirements on ASBRs, when VSIs are present on the ABSRs,
   include the requirements presented in the "Inter-AS Inclusive
   P-Multicast Tree A-D/Binding" section.  The source ASBR (that
   receives traffic from another AS) may independently decide whether or
   not it wishes to use Selective trees.  If it uses Selective trees,
   the source ASBR MUST perform a MAC lookup to determine the Selective
   tree to forward the VPLS packet on.

8.4.1.1.  VPLS Inter-AS Selective Tree A-D Binding

   The mechanisms for propagating S-PMSI A-D routes are the same as the
   intra-AS case described in the "MCAST-VPLS NLRI" section.  The BGP
   Selective tree A-D routes generated by PEs in an AS MUST NOT be
   propagated outside the AS.

8.4.2.  Inter-AS Segmented Selective Trees

   Inter-AS Segmented Selective trees MUST be implemented when option
   (b) is used to provide the inter-AS VPLS service.  They MAY be used
   when option (c) is implemented to provide the inter-AS VPLS service.

   A Segmented inter-AS Selective Tunnel is constructed similar to an
   inter-AS Segmented Inclusive Tunnel.  Namely, such a tunnel is
   constructed as a concatenation of tunnel segments.  There are two
   types of tunnel segments: an intra-AS tunnel segment (a segment that
   spans ASBRs within the same AS) and inter-AS tunnel segment (a
   segment that spans adjacent ASBRs in adjacent ASes).  ASes that are
   spanned by a tunnel are not required to use the same tunneling
   mechanism to construct the tunnel -- each AS may pick up a tunneling
   mechanism to construct the intra-AS tunnel segment of the tunnel, in
   its AS.

   The PE that decides to set up a Selective tree advertises the
   Selective tree to multicast stream binding using an S-PMSI A-D route,
   as per procedures in the "Advertising (C-S, C-G) Binding to a
   Selective Tree" section, to the routers in its own AS.

   An S-PMSI A-D route advertised outside the AS, to which the
   originating PE belongs, will be referred to as an Inter-AS S-PMSI
   tree A-D route (although this route is originated by a PE as an
   intra-AS S-PMSI A-D route, it is referred to as an Inter-AS route
   outside the AS).

8.4.2.1.  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 the "Propagating BGP VPLS A-D Routes to Other ASes"
   section, except that instead of Inter-AS A-D routes and their NLRI,
   these procedures apply to S-PMSI A-D routes and their NLRI.

   In addition to these procedures, an ASBR advertises a leaf A-D route
   in response to an S-PMSI A-D route only if:

     + The S-PMSI A-D route was received via EBGP from another ASBR and
       the ASBR merges the S-PMSI A-D route into an Inter-AS BGP VPLS
       A-D route as described in the next section.  OR

     + The ASBR receives a leaf A-D route from a downstream PE or ASBR
       in response to the S-PMSI A-D route, received from an upstream PE
       or ASBR, that the ASBR propagated inter-AS to downstream ASBRs
       and PEs.

     + The ASBR has snooped state from local CEs that matches the NLRI
       carried in the S-PMSI A-D route as per the following rules:

      i) The NLRI encodes (C-S, C-G), which is the same as the snooped
         (C-S, C-G)

     ii) The NLRI encodes (*, C-G), there is snooped state for at least
         one (C-S, C-G), and there is no other matching S-PMSI A-D route
         for (C-S, C-G) OR there is snooped state for (*, C-G)

    iii) The NLRI encodes (*, *), there is snooped state for at least
         one (C-S, C-G) or (*, C-G), and there is no other matching
         S-PMSI A-D route for that (C-S, C-G) or (*, C-G), respectively.

   The C-multicast data traffic is sent on the Selective tree by the
   originating PE.  When it reaches an ASBR that is on the inter-AS
   segmented tree, it is delivered to local receivers, if any.  It is
   then forwarded on any inter-AS or intra-AS segments that exist on the
   Inter-AS Selective segmented tree.  If the Inter-AS Selective
   segmented tree is merged onto an Inclusive tree, as described in the
   next section, the data traffic is forwarded onto the Inclusive tree.

8.4.2.1.1.  Merging Selective Tree into an Inclusive Tree

   Consider the situation where:

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

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

   This situation may arise if the upstream providers have a policy of
   using Selective trees but the downstream providers have a policy of
   using Inclusive trees.  To support this situation, an ASBR MAY, under
   certain conditions, merge one or more upstream Selective trees into a
   downstream Inclusive tree.  Note that this can be the case only for
   option (b) and not for option (c) as, for option (c), the ASBRs do
   not have Inclusive tree state.

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

     + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route
       originate in the same AS.  The Inter-AS BGP VPLS A-D route
       carries the originating AS 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 BGP VPLS A-D route have
       exactly the same set of RTs.

   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 BGP VPLS A-D route
   re-advertised by the ASBR.

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

8.4.3.  Inter-AS Non-segmented Selective Trees

   Inter-AS Non-segmented Selective trees MAY be used in the case of
   option (c).

   In this method, there is a multi-hop EBGP peering between the PEs (or
   a Route Reflector) in one AS and the PEs (or Route Reflector) in
   another AS.  The PEs exchange BGP Selective tree A-D routes, along
   with PMSI Tunnel attribute, as in the intra-AS case described in the
   "Option (c): Non-segmented Tunnels" section.

   The PEs in different ASes use a non-segmented Selective inter-AS P2MP
   tunnel for VPLS multicast.

   This method requires no VPLS information (in either the control or
   the data plane) on the ASBRs.  The ASBRs only need to participate in
   the non-segmented P2MP tunnel setup in the control plane and do MPLS
   label forwarding in the data plane.

   The data forwarding in this model is the same as in the intra-AS case
   described in the "Establishing P-Multicast Trees" section.