Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7117

Multicast in Virtual Private LAN Service (VPLS)

Pages: 50
Proposed Standard
Errata
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC7117 - Page 1
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.
Top   ToC   RFC7117 - Page 2
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.
Top   ToC   RFC7117 - Page 3

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
Top   ToC   RFC7117 - Page 4
           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]).
Top   ToC   RFC7117 - Page 5
   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.
Top   ToC   RFC7117 - Page 6

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.
Top   ToC   RFC7117 - Page 7
   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
Top   ToC   RFC7117 - Page 8
       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:
Top   ToC   RFC7117 - Page 9
     + 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
Top   ToC   RFC7117 - Page 10
   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.
Top   ToC   RFC7117 - Page 11
   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.
Top   ToC   RFC7117 - Page 12
   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
Top   ToC   RFC7117 - Page 13
   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.
Top   ToC   RFC7117 - Page 14

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)

Next Section