Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7117

Multicast in Virtual Private LAN Service (VPLS)

Pages: 50
Proposed Standard
Errata
Part 2 of 3 – Pages 15 to 38
First   Prev   Next

Top   ToC   RFC7117 - Page 15   prevText

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
Top   ToC   RFC7117 - Page 16
   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
Top   ToC   RFC7117 - Page 17
   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].
Top   ToC   RFC7117 - Page 18

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
Top   ToC   RFC7117 - Page 19
   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).
Top   ToC   RFC7117 - Page 20

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.
Top   ToC   RFC7117 - Page 21
   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
Top   ToC   RFC7117 - Page 22
   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
Top   ToC   RFC7117 - Page 23
   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.
Top   ToC   RFC7117 - Page 24
   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).
Top   ToC   RFC7117 - Page 25
     + 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.
Top   ToC   RFC7117 - Page 26
   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.
Top   ToC   RFC7117 - Page 27
   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-
Top   ToC   RFC7117 - Page 28
   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.
Top   ToC   RFC7117 - Page 29
   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
Top   ToC   RFC7117 - Page 30
   "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.
Top   ToC   RFC7117 - Page 31
   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
Top   ToC   RFC7117 - Page 32
       (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
Top   ToC   RFC7117 - Page 33
       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.
Top   ToC   RFC7117 - Page 34
     + 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.
Top   ToC   RFC7117 - Page 35

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).
Top   ToC   RFC7117 - Page 36
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.
Top   ToC   RFC7117 - Page 37
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.
Top   ToC   RFC7117 - Page 38

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.


(page 38 continued on part 3)

Next Section