tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7117

Proposed STD
Pages: 50
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: L2VPN

Multicast in Virtual Private LAN Service (VPLS)

Part 1 of 3, p. 1 to 14
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part