RFC 7117
Multicast in Virtual Private LAN Service (VPLS)
Internet Engineering Task Force (IETF) R. Aggarwal, Ed. Request for Comments: 7117 Juniper Networks Category: Standards Track Y. Kamite ISSN: 2070-1721 NTT Communications L. Fang Microsoft Y. Rekhter Juniper Networks C. Kodeboniya February 2014 Multicast in Virtual Private LAN Service (VPLS)Abstract
RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported. This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7117.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction ....................................................4 2. Terminology .....................................................5 2.1. Specification of Requirements ..............................6 3. Overview ........................................................6 3.1. Inclusive and Selective Multicast Trees ....................7 3.2. BGP-Based VPLS Membership Auto-discovery ...................8 3.3. IP Multicast Group Membership Discovery ....................8 3.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding ...9 3.5. Aggregation ...............................................10 3.6. Inter-AS VPLS Multicast ...................................11 4. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding .....12 4.1. Originating Intra-AS VPLS A-D Routes ......................13 4.2. Receiving Intra-AS VPLS A-D Routes ........................14 5. Demultiplexing P-Multicast Tree Traffic ........................15 5.1. One P-Multicast Tree - One VPLS Mapping ...................15 5.2. One P-Multicast Tree - Many VPLS Mapping ..................15 6. Establishing P-Multicast Trees .................................16 6.1. Common Procedures .........................................16 6.2. RSVP-TE P2MP LSPs .........................................16 6.2.1. P2MP TE LSP - VPLS Mapping .........................17 6.3. Receiver-Initiated P2MP LSP ...............................18 6.3.1. P2MP LSP - VPLS Mapping ............................18 6.4. Encapsulation of Aggregate P-Multicast Trees ..............18 7. Inter-AS Inclusive P-Multicast Tree A-D/Binding ................18 7.1. VSIs on the ASBRs .........................................19 7.1.1. Option (a): VSIs on the ASBRs ......................19 7.1.2. Option (e): VSIs on the ASBRs ......................20 7.2. Option (b) - Segmented Inter-AS Trees .....................20 7.2.1. Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding ........................................20 7.2.2. Propagating BGP VPLS A-D Routes to Other ASes: Overview .....................................21 7.2.2.1. Propagating Intra-AS VPLS A-D Routes in EBGP ............................23 7.2.2.2. Inter-AS A-D Route Received via EBGP ......23 7.2.2.3. Leaf A-D Route Received via EBGP ..........25 7.2.2.4. Inter-AS A-D Route Received via IBGP ......25 7.3. Option (c): Non-segmented Tunnels .........................26 8. Optimizing Multicast Distribution via Selective Trees ..........27 8.1. Protocol for Switching to Selective Trees .................29 8.2. Advertising (C-S, C-G) Binding to a Selective Tree ........30 8.3. Receiving S-PMSI A-D Routes by PEs ........................32 8.4. Inter-AS Selective Tree ...................................34 8.4.1. VSIs on the ASBRs ..................................35 8.4.1.1. VPLS Inter-AS Selective Tree A-D Binding ..35
8.4.2. Inter-AS Segmented Selective Trees .................35
8.4.2.1. Handling S-PMSI A-D Routes by ASBRs .......36
8.4.2.1.1. Merging Selective Tree
into an Inclusive Tree .........37
8.4.3. Inter-AS Non-segmented Selective Trees .............38
9. BGP Extensions .................................................38
9.1. Inclusive Tree/Selective Tree Identifier ..................38
9.2. MCAST-VPLS NLRI ...........................................39
9.2.1. S-PMSI A-D Route ...................................40
9.2.2. Leaf A-D Route .....................................41
10. Aggregation Considerations ....................................41
11. Data Forwarding ...............................................43
11.1. MPLS Tree Encapsulation ..................................43
11.1.1. Mapping Multiple VPLS Instances to a P2MP LSP .....43
11.1.2. Mapping One VPLS Instance to a P2MP LSP ...........44
12. VPLS Data Packet Treatment ....................................45
13. Security Considerations .......................................46
14. IANA Considerations ...........................................47
15. References ....................................................47
15.1. Normative References .....................................47
15.2. Informative References ...................................48
16. Acknowledgments ...............................................50
1. Introduction
[RFC4761] and [RFC4762] describe a solution for VPLS
multicast/broadcast that relies on the use of pseudowires transported
over unicast point-to-point (P2P) RSVP Traffic Engineering (RSVP-TE)
or multipoint-to-point (MP2P) LDP Label Switched Paths (LSPs)
([RFC3209] [RFC5036]). In this document, we refer to this solution
as "ingress replication".
With ingress replication, when an ingress Provider Edge (PE) of a
given VPLS instance receives a multicast/broadcast packet from one of
the Customer Edges (CEs) that belong to that instance, the ingress PE
replicates the packet for each egress PE that belong to that
instance, and it sends the packet to each such egress PE using
unicast tunnels.
The solution based on ingress replication has certain limitations for
certain VPLS multicast/broadcast traffic profiles. For example, it
may result in highly non-optimal bandwidth utilization in the MPLS
network when a large amount of multicast/broadcast traffic is to be
transported (for more see [RFC5501]).
Ingress replication may be an acceptable model when the bandwidth of the multicast/broadcast traffic is low and/or there is a small number of replications performed on each outgoing interface for a particular VPLS customer multicast stream. If this is not the case, it is desirable to utilize multicast trees in the SP network to transmit VPLS multicast and/or broadcast packets [RFC5501]. This document describes procedures for overcoming the limitations of existing VPLS multicast solutions. It describes procedures for using MPLS point-to-multipoint (P2MP) LSPs in the SP network to transport VPLS multicast and/or broadcast packets, where these LSPs are signaled by either P2MP RSVP-TE [RFC4875] or Multipoint LDP (mLDP) [RFC6388]. The procedures described in this document are applicable to both [RFC4761] and [RFC4762].2. Terminology
This document uses terminology described in [RFC4761] and [RFC4762]. In this document, we refer to various auto-discovery routes, as "A-D routes". This document uses the prefix 'C' to refer to the customer control or data packets and 'P' to refer to the provider control or data packets. An IP (multicast source, multicast group) tuple is abbreviated to (S, G). An "Inclusive tree" is a single multicast distribution tree in the SP network that carries all the multicast traffic from one VPLS instance on a given PE. An "Aggregate Inclusive tree" is a single multicast distribution tree in the SP network that carries all the multicast traffic from more than one VPLS instance on a given PE. A "Selective tree" is a single multicast distribution tree in the SP network that carries multicast traffic belonging only to a specified set of IP multicast streams, and all these streams belong to the same VPLS instance on a given PE. A Selective tree differs from an Inclusive tree in that it may reach a subset of the PEs reached by an Inclusive tree. An "Aggregate Selective tree" is a single multicast distribution tree in the SP network that carries multicast traffic belonging only to a specified set of IP multicast streams, and all these streams belong to more than one VPLS instance on a given PE.
2.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].3. Overview
Procedures described in this document provide mechanisms that allow a single multicast distribution tree in the SP network to carry all the multicast traffic from one or more VPLS sites connected to a given PE, irrespective of whether these sites belong to the same or different VPLS instances. We refer to such a tree as an "Inclusive tree" if it carries multicast traffic from one VPLS instance on a given PE. We refer to such a tree as an "Aggregate Inclusive tree" if it carries multicast traffic from more than one VPLS instance on a given PE. See the "Inclusive and Selective Multicast Trees" section for further discussion on Inclusive trees. To further improve bandwidth utilization for IP multicast streams, this document also provides procedures by which a single multicast distribution tree in the SP network can be used to carry traffic belonging only to a specified set of IP multicast streams, originated in one or more VPLS sites connected to a given PE, irrespective of whether these sites belong to the same or different VPLS instances. We refer to such a tree as a "Selective tree" if it carries the IP multicast stream(s) that belongs to the same VPLS instance on a given PE. We refer to such a tree as an "Aggregate Selective tree" if it carries the IP multicast streams that belong to different VPLS instances on a given PE. Use of Selective and/or Aggregate Selective trees allows multicast traffic, by default, to be carried on an Inclusive tree, while traffic from some specific IP multicast streams, e.g., high-bandwidth streams, could be carried on one of the Selective trees. See the "Inclusive and Selective Multicast Trees" section for further discussion on Selective trees. Note that this document covers the use of Selective trees only for carrying IP multicast streams. Any other use of such trees is outside the scope of this document. Unicast packets destined to unknown Media Access Control (MAC) addresses (i.e., not learned yet at the ingress PE) in a given VPLS instance are flooded to remote PEs participating in the same VPLS instance. This flooding MAY still use ingress replication (as specified in [RFC4761] and [RFC4762]), or MAY use the procedures defined in this document to optimize flooding across the SP core.
While the use of multicast trees in the SP network can be beneficial when the bandwidth of the multicast traffic is high, or when it is desirable to optimize the number of copies of a multicast packet transmitted on a given link, this benefit comes at a cost of state in the SP network to build multicast trees and overhead to maintain this state.3.1. Inclusive and Selective Multicast Trees
Multicast trees used for VPLS can be of two types: + Inclusive trees. This option supports the use of a single multicast distribution tree, referred to as an "Inclusive P-multicast tree", in the SP network to carry all the multicast traffic from a specified set of VPLS sites connected to a given PE. There is no assumption made with respect to whether or not this traffic is IP encapsulated. A particular P-multicast tree can be set up to carry the traffic originated by sites belonging to a single VPLS instance or to carry the traffic originated by sites belonging to different VPLS instances. In the context of this document, the ability to carry the traffic of more than one VPLS instance on the same P-multicast tree is called "aggregation". The tree includes every PE that is a member of any of the VPLS instances that are using the tree. This implies that a PE may receive multicast traffic for a multicast stream even if it doesn't have any receivers that are interested in receiving traffic for that stream. An Inclusive P-multicast tree, as defined in this document, is a P2MP tree. Thus, a P2MP tree is used to carry traffic only from VPLS sites that are connected to the PE that is the root of the tree. + Selective trees. A Selective P-multicast tree is used by a PE to send IP multicast traffic for one or more specific IP multicast streams, received by the PE over PE-CE interfaces that belong to the same or different VPLS instances, to a subset of the PEs that belong to those VPLS instances. Each of the PEs in the subset should be on the path to a receiver of one or more multicast streams that are mapped onto the tree. In the context of this document, the ability to use the same P-multicast tree for multicast streams that belong to different VPLS instances is called "aggregation". The reason for having Selective P-multicast trees is to provide a PE the ability to create separate SP multicast trees for specific multicast streams, e.g., high-bandwidth multicast streams. This allows traffic for these
multicast streams to reach only those PE routers that have
receivers for these streams. This avoids flooding other PE
routers in the VPLS instance.
An SP can use both Inclusive P-multicast trees and Selective
P-multicast trees or either of them for a given VPLS on a PE, based
on local configuration. Inclusive P-multicast trees can be used for
both IP and non-IP data multicast traffic, while Selective
P-multicast trees, as previously stated, must be used only for IP
multicast data traffic. The use of Selective P-multicast trees for
non-IP multicast traffic is outside the scope of this document.
P-multicast trees in the SP network can be realized via a variety of
technologies. For both Inclusive and Selective P-multicast trees,
these technologies include P2MP LSPs created by RSVP-TE or mLDP.
This document also describes the data plane encapsulations for
supporting these technologies. Other technologies for realizing
P-multicast trees are outside the scope of this document.
3.2. BGP-Based VPLS Membership Auto-discovery
Inclusive P-multicast trees may be established for one or more VPLS
instances. In this case, aggregation can be performed (using either
mLDP or P2MP RSVP-TE as the tunneling technology) or simple tunneling
can be performed (using P2MP RSVP-TE tunneling). If either of these
approaches is used, the PE acting as the root of a P2MP LSP must be
able to discover the other PEs that have membership of each of the
VPLS instances. Once the root PE discovers these other PEs, it
includes them as leaves in the P-multicast tree (i.e., P2MP LSP).
This document uses the BGP-based procedures described in [RFC4761]
and [RFC6074] for discovering the VPLS membership of all PEs. For
more on aggregation, see the "Aggregation Considerations" section.
When no aggregation is performed and the tunneling technology is
mLDP, then the root of the P2MP LSP need not discover the other PEs
that are the leaves of that LSP tree.
The leaves of the Inclusive P-multicast tree must also be able to
auto-discover the identifier of the tree (note that this applies when
the tree is established by either mLDP or P2MP RSVP-TE). Procedures
to accomplish this are described in the "Advertising P-Multicast Tree
to VPLS/C-Multicast Binding" section.
3.3. IP Multicast Group Membership Discovery
The setup of a Selective P-multicast tree for one or more IP
multicast (C-S, C-G)s, requires the ingress PE to learn the PEs that
have receivers in one or more of these (C-S, C-G)s, in the following
cases:
+ When aggregation is used (with either mLDP or P2MP RSVP-TE as the
tunneling technology), OR
+ When the tunneling technology is P2MP RSVP-TE
+ 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 for the (C-S, C-G)s.
For more on aggregation, see the "Aggregation Considerations"
section.
For discovering the IP multicast group membership, this document
describes procedures that allow an ingress PE to enable explicit
tracking of IP multicast membership. 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
"Optimizing Multicast Distribution via Selective Trees" section.
These procedures are applicable when IGMP ([RFC2236] [RFC3376]) or
MLD ([RFC2710] [RFC3810]) is used as the multicast signaling protocol
between the VPLS CEs. They are also applicable when PIM ([RFC4601])
in either the Any-Source Multicast (ASM) or the Source-Specific
Multicast (SSM) service model is used as the multicast routing
protocol between the VPLS CEs, and PIM join suppression is disabled
on all the CEs.
However, these procedures do not apply when PIM is used as the
multicast routing protocol between the VPLS CEs and PIM join
suppression is not disabled on all the CEs. This is because when PIM
join suppression is not disabled on all the CEs, PEs connected to
these CEs can not rely on PIM to determine IP multicast membership of
the receivers behind these CEs. Procedures for this case are outside
the scope of this document.
The leaves of the Selective P-multicast trees must also be able to
discover the identifier of these trees. Procedures to accomplish
this are described in the "Advertising P-Multicast Tree to
VPLS/C-Multicast Binding" section.
3.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding
This document describes procedures based on BGP VPLS Auto-Discovery
(A-D) routes ([RFC4761] [RFC6074]) that are used by the root of an
Aggregate P-multicast tree to advertise the Inclusive or Selective
P-multicast tree binding and the demultiplexing information to the
leaves of the tree. This document uses the Provider Multicast Service Interface (PMSI) Tunnel attribute defined [RFC6514] for this purpose. Once an ingress PE decides to bind a set of VPLS instances or customer multicast groups to an Inclusive P-multicast tree or a Selective P-multicast tree, the PE needs to announce this binding to other PEs in the network. This procedure is referred to as "Inclusive P-multicast tree binding distribution" or "Selective P-multicast tree binding distribution" and is performed using BGP. The decision to bind a set of VPLS instances or customer multicast groups is a local matter to the ingress, and is controlled via provisioning/configuration on that PE. When an Aggregated Inclusive P-multicast tree is used by an ingress PE, this binding distribution implies that (a) an ingress PE MUST announce the binding of all VPLS instances bound to the Inclusive P-multicast tree and (b) other PEs that have these instances receive these announcements. The inner label assigned by the ingress PE for each VPLS MUST be included if more than one VPLS is bound to the same P-multicast tree. The Inclusive P-multicast tree Identifier MUST be included. For a Selective P-multicast tree, this binding distribution implies announcing all the specific <C-S, C-G> entries bound to this P-multicast tree along with the Selective P-multicast tree Identifier. The inner label assigned for each <C-S, C-G> MUST be included if <C-S, C-G> from different VPLS instances are bound to the same P-multicast tree. The labels MUST be distinct on a per-VPLS basis and MAY be distinct per <C-S, C-G> entry. The Selective P-multicast tree Identifier MUST be included.3.5. Aggregation
As described earlier in this document, the ability to carry the traffic of more than one VPLS on the same P-multicast tree is called aggregation. Aggregation enables the SP to place a bound on the amount of multicast tree forwarding and control plane state that the P-routers must have. Let us call the number of VPLS instances aggregated onto a single P-multicast tree the "Aggregation Factor". When Inclusive source P-multicast trees are used, the number of trees that a PE is the root of is proportional to the number of VPLS instances on the PE divided by the Aggregation Factor.
In this case, the state maintained by a P-router is proportional to:
AveVPLS NPE
------- X --------
Aggr AvePTree
Where:
AveVPLS is the average number of VPLS instances on a PE
Aggr is the Aggregation Factor
NPE is the number of PEs
AvePTree is the average number of P-multicast that transit a given
P-router
Thus, the state does not grow linearly with the number of VPLS
instances.
Aggregation requires a mechanism for the egresses of the P-multicast
tree to demultiplex the multicast traffic received over the
P-multicast tree. To enable the egress nodes to perform this
demultiplexing, upstream-assigned labels [RFC5331] MUST be assigned
and distributed by the root of the aggregate P-multicast tree.
Aggregation procedures would require two MPLS labels in the label
stack. This does not introduce any new implications on MTU, as even
VPLS multicast supported by ingress replication requires two MPLS
labels in the label stack.
3.6. Inter-AS VPLS Multicast
This document defines four models of inter-AS (Autonomous System)
VPLS service, referred here as options (a), (b), (c), and (e).
Options (a), (b), and (c) defined in this document are very similar
to methods (a), (b), and (c), described in the "Multi-AS VPLS"
section of [RFC4761], which in turn extends the concepts of [RFC4364]
to inter-AS VPLS.
For option (a) and option (b) support, this document specifies a
model where inter-AS VPLS service can be offered without requiring a
single P-multicast tree to span multiple ASes. There are two
variants of this model, and they are described in the "Inter-AS
Inclusive P-Multicast Tree A-D/Binding" section.
For option (c) support, this document specifies a model where inter- AS VPLS service is offered by requiring a single P-multicast tree to span multiple ASes. This is because in the case of option (c), the Autonomous System Border Routers (ASBRs) do not exchange BGP-VPLS Network Layer Reachability Information (NLRI) or A-D routes. In addition to options (a), (b), and (c), this document also specifies option (e), which one may think of as a variant of option (a). For more on these inter-AS options, see the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section.4. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding
This section specifies procedures for the intra-AS auto-discovery of VPLS membership and the distribution of information used to instantiate P-multicast Tunnels. VPLS auto-discovery/binding consists of two components: intra-AS and inter-AS. The former provides VPLS auto-discovery/binding within a single AS. The latter provides VPLS auto-discovery/binding across multiple ASes. Inter-AS auto-discovery/binding is described in the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section. VPLS auto-discovery using BGP, as described in [RFC4761] and [RFC6074], enables a PE to learn the VPLS instance membership of other PEs. A PE that belongs to a particular VPLS instance announces a BGP NLRI that identifies the Virtual Switch Instance (VSI). This NLRI is constructed from the <Route Distinguisher (RD), VPLS Edge Device Identifier (VE-ID)> tuple. The NLRI defined in [RFC4761] comprises the <RD, VE-ID> tuple and label blocks for pseudowire (PW) signaling. The VE-ID in this case is a two-octet number encoded in the VE-ID of NLRI defined in [RFC4761]. The NLRI defined in [RFC6074] comprises only the <RD, PE_addr>. The VE-ID in this case is a four-octet number encoded in the PE_addr of the NLRI defined in [RFC6074]. The procedures for constructing Inclusive Intra-AS and Inter-AS trees, as specified in this document, require the BGP A-D NLRI to carry only the <RD, VE-ID>. Hence, these procedures can be used for both BGP-VPLS and LDP-VPLS with BGP A-D. It is to be noted that BGP A-D is an inherent feature of BGP-VPLS. However, it is not an inherent feature of LDP-VPLS. In fact, there are deployments and/or implementations of LDP-VPLS that require configuration to enable a PE in a particular VPLS to determine other PEs in the VPLS and exchange PW labels using Forwarding Equivalence
Class (FEC) 128 (PWid FEC) [RFC4447]. The use of BGP A-D for LDP- VPLS [RFC6074], to enable automatic setup of PWs, requires FEC 129 (Generalized PWid FEC) [RFC4447]. However, FEC 129 is not required in order to use procedures in this document for LDP-VPLS. An LDP- VPLS implementation that supports this document MUST support the BGP A-D procedures to set up P-multicast trees, as described here, and it MAY support FEC 129 to automate the signaling of PWs.4.1. Originating Intra-AS VPLS A-D Routes
To participate in the VPLS auto-discovery/binding, a PE router that has a given VSI of a given VPLS instance originates a BGP VPLS Intra- AS A-D route and advertises this route in Multiprotocol (MP) IBGP. The route is constructed as described in [RFC4761] and [RFC6074]. The route carries a single Layer 2 Virtual Private Network (L2VPN) NLRI with the RD set to the RD of the VSI and the VE-ID set to the VE-ID of the VSI. The route also carries one or more Route Targets (RTs), as specified in [RFC4761] and [RFC6074]. If an Inclusive P-multicast tree is used to instantiate the provider tunnel for VPLS multicast on the PE, the advertising PE MUST advertise the type and the identity of the P-multicast tree in the PMSI Tunnel attribute. This attribute is described in the "Inclusive Tree/Selective Tree Identifier" section. A PE that uses an Inclusive P-multicast tree to instantiate the provider tunnel MAY aggregate two or more VPLS instances present on the PE onto the same tree. If the PE decides to perform aggregation after it has already advertised the intra-AS VPLS A-D routes for these VPLS instances, 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 (the re-advertised route will replace the previously advertised route). If the PE has not previously advertised Intra-AS A-D routes for these VPLS instances, then the aggregation requires the PE to advertise (new) Intra-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 re-advertised or newly advertised route MUST have a label that is distinct within the scope of the PE that advertises the route. Discovery of PE capabilities in terms of what tunnel types they support is outside the scope of this document. Within a given AS, PEs participating in a VPLS are expected to advertise tunnel bindings whose tunnel types are supported by all other PEs that are participating in this VPLS and are part of the same AS.
4.2. Receiving Intra-AS VPLS A-D Routes
When a PE receives a BGP Update message that carries an Intra-AS A-D route such that (a) the route was originated by some other PE within the same AS as the local PE, (b) at least one of the RTs of the route matches one of the import RTs configured for a particular VSI on the local PE, (c) the BGP route selection determines that this is the best route with respect to the NLRI carried by the route, and (d) the route carries the PMSI Tunnel attribute, the PE performs the following: + If the Tunnel Type in the PMSI Tunnel attribute is set to LDP P2MP LSP, the PE SHOULD join the P-multicast tree whose identity is carried in the PMSI Tunnel attribute. + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE P2MP LSP, the receiving PE has to establish the appropriate state to properly handle the traffic received over that LSP. The PE that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE as a leaf. This LSP MAY have been established before the local PE receives the route. + If the PMSI Tunnel attribute does not carry a label, then all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, are forwarded using the VSIs that have at least one of their import RTs that matches one of the RTs of the received A-D route. + If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS label, then the egress PE MUST treat this as an upstream-assigned label, and all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, with that upstream label are forwarded using the VSIs that have at least one of their import RTs that matches one of the RTs of the received Intra-AS A-D route. Furthermore, if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic, originated by VPLS sites connected to the PE, to the sites attached to other PEs, then the local PE MUST use the Originating Router's IP Address information carried in the Intra-AS A-D route to add the PE, that originated the route, as a leaf node to the LSP. This MUST be done irrespective of whether or not the received Intra-AS A-D route carries the PMSI Tunnel attribute.
(next page on part 2)
