GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7117

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.

Aggarwal, et al. Standards Track [Page 1] RFC 7117 Multicast in VPLS February 2014

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.

Aggarwal, et al. Standards Track [Page 2] RFC 7117 Multicast in VPLS February 2014

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

Aggarwal, et al. Standards Track [Page 3] RFC 7117 Multicast in VPLS February 2014

         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]).

Aggarwal, et al. Standards Track [Page 4] RFC 7117 Multicast in VPLS February 2014

 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.

Aggarwal, et al. Standards Track [Page 5] RFC 7117 Multicast in VPLS February 2014

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.

Aggarwal, et al. Standards Track [Page 6] RFC 7117 Multicast in VPLS February 2014

 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

Aggarwal, et al. Standards Track [Page 7] RFC 7117 Multicast in VPLS February 2014

     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:

Aggarwal, et al. Standards Track [Page 8] RFC 7117 Multicast in VPLS February 2014

   + 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

Aggarwal, et al. Standards Track [Page 9] RFC 7117 Multicast in VPLS February 2014

 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.

Aggarwal, et al. Standards Track [Page 10] RFC 7117 Multicast in VPLS February 2014

 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.

Aggarwal, et al. Standards Track [Page 11] RFC 7117 Multicast in VPLS February 2014

 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

Aggarwal, et al. Standards Track [Page 12] RFC 7117 Multicast in VPLS February 2014

 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.

Aggarwal, et al. Standards Track [Page 13] RFC 7117 Multicast in VPLS February 2014

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.

Aggarwal, et al. Standards Track [Page 14] RFC 7117 Multicast in VPLS February 2014

5. Demultiplexing P-Multicast Tree Traffic

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

5.1. One P-Multicast Tree - One VPLS Mapping

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

5.2. One P-Multicast Tree - Many VPLS Mapping

 As traffic belonging to multiple VPLS instances can be carried over
 the same tree, there is a need to identify the VPLS to which the
 packet belongs.  This is done by using an inner label that determines
 the VPLS for which the packet is intended.  The ingress PE uses this
 label as the inner label while encapsulating a customer multicast
 data packet.  Each of the egress PEs must be able to associate this
 inner label with the same VPLS and use it to demultiplex the traffic
 received over the Aggregate Inclusive tree or the Aggregate Selective
 tree.
 If traffic from multiple VPLS instances is carried on a single tree,
 upstream-assigned labels [RFC5331] MUST be used.  Hence, the inner
 label is assigned by the ingress PE.  When the egress PE receives a
 packet over an Aggregate tree, the outer encapsulation (in the case
 of MPLS P2MP LSPs, the outer MPLS label) specifies the label space to
 perform the inner-label lookup.  The same label space MUST be used by
 the egress PE for all P-multicast trees that have the same root
 [RFC5331].
 If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the
 outer MPLS label and, optionally, the incoming interface provide the
 label space of the label beneath it.  This assumes that PHP is
 disabled.  The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT
 NULL for that tree once it is known to the egress PE that the tree is
 bound to one or more VPLS instances.  Once the label representing the

Aggarwal, et al. Standards Track [Page 15] RFC 7117 Multicast in VPLS February 2014

 tree is popped off the MPLS label stack, the next label is the
 demultiplexing information that allows the proper VPLS instance to be
 determined.
 The ingress PE informs the egress PEs about the inner label as part
 of the tree binding procedures described in the "BGP Extensions"
 section.

6. Establishing P-Multicast Trees

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

6.1. Common Procedures

 The following procedures apply to both RSVP-TE P2MP and mLDP P2MP
 LSPs.
 Demultiplexing the C-multicast data packets at the egress PE requires
 that the PE must be able to determine the P2MP LSP on which the
 packets are received.  This enables the egress PE to determine the
 VPLS instances to which the packet belongs.  To achieve this, the LSP
 MUST be signaled with PHP off and a non-special purpose MPLS label
 off as described in the "Demultiplexing P-Multicast Tree Traffic"
 section.  In other words, an egress PE MUST NOT advertise IMPLICIT
 NULL or EXPLICIT NULL for a P2MP LSP that is carrying traffic for one
 or more VPLS instances.  This is because the egress PE needs to rely
 on the MPLS label, that it advertises to its upstream neighbor, to
 determine the P2MP LSP on which a C-multicast data packet is
 received.
 The egress PE also needs to identify the ingress PE to perform MAC
 learning.  When P2MP LSPs are used as P2MP trees, determining the
 P2MP LSP on which the packets are received is sufficient to determine
 the ingress PE.  This is because the ingress PE is the root of the
 P2MP LSP.
 The egress PE relies on receiving the PMSI Tunnel attribute in BGP to
 determine the VPLS instance to P2MP LSP mapping.

6.2. RSVP-TE P2MP LSPs

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

Aggarwal, et al. Standards Track [Page 16] RFC 7117 Multicast in VPLS February 2014

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

6.2.1. P2MP TE LSP - VPLS Mapping

 P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP-
 based advertisements of the P2MP TE LSP - VPLS mapping.  They require
 that the root of the tree include in the BGP advertisements the P2MP
 TE LSP identifier as the P-multicast tree identifier.  This
 P-multicast tree identifier contains the following information
 elements:
  1. The type of the tunnel is set to RSVP-TE P2MP LSP
  2. RSVP-TE P2MP LSP's SESSION Object
 See the "Inclusive Tree/Selective Tree Identifier" section for more
 details on how this tree identifier is carried in BGP advertisements.
 Once the egress PE receives the P2MP TE LSP to VPLS mapping:
   + If the egress PE already has RSVP-TE state for the P2MP TE LSP,
     it MUST begin to assign an MPLS label from the non-special
     purpose label range, for the P2MP TE LSP and signal this to the
     previous hop of the P2MP TE LSP.  Further, it MUST create
     forwarding state to forward packets received on the P2MP LSP.
   + If the egress PE does not have RSVP-TE state for the P2MP TE LSP,
     it MUST retain this mapping.  Subsequently, when the egress PE
     receives the RSVP-TE P2MP signaling message, it creates the RSVP-
     TE P2MP LSP state.  It MUST then assign an MPLS label from the
     non-reserved label range, for the P2MP TE LSP, and signal this to
     the previous hop of the P2MP TE LSP.
     Note that if the signaling to set up an RSVP-TE P2MP LSP is
     completed before a given egress PE learns, via a PMSI Tunnel
     attribute, of the VPLS or set of VPLS instances to which the LSP
     is bound, the PE MUST discard any traffic received on that LSP
     until the binding is received.  In order for the egress PE to be
     able to discard such traffic, it needs to know that the LSP is
     associated with one or more VPLS instances and that the VPLS A-D
     route that binds the LSP to a VPLS has not yet been received.
     This is provided by extending [RFC4875] with [RFC6511].

Aggarwal, et al. Standards Track [Page 17] RFC 7117 Multicast in VPLS February 2014

6.3. Receiver-Initiated P2MP LSP

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

6.3.1. P2MP LSP - VPLS Mapping

 P2MP LSP to VPLS mapping is learned at the egress PEs using BGP-based
 advertisements of the P2MP LSP - VPLS mapping.  They require that the
 root of the tree include in the BGP advertisements the P2MP LSP
 identifier as the P-multicast tree identifier.  This P-multicast tree
 identifier contains the following information elements:
  1. The type of the tunnel is set to LDP P2MP LSP
  2. LDP P2MP FEC that includes an identifier generated by the root.
 See the "Inclusive Tree/Selective Tree Identifier" section for more
 details on how this tree identifier is carried in BGP advertisements.
 Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label
 mapping messages for the LDP P2MP FEC, that was learned in the BGP
 advertisement, using procedures described in [RFC6388].

6.4. Encapsulation of Aggregate P-multicast Trees

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

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

 As stated earlier, this document defines four models of inter-AS VPLS
 service, referred here as option (a), (b), (c), and (e).  This
 section contains procedures to support these models.
 For supporting option (a), (b), and (e), this section specifies a
 model where inter-AS VPLS service can be offered without requiring a
 single P-multicast tree to span multiple ASes.  This allows
 individual ASes to potentially use different P-tunneling
 technologies.  There are two variants of this model.  One that

Aggarwal, et al. Standards Track [Page 18] RFC 7117 Multicast in VPLS February 2014

 requires MAC lookup on the ASBRs and applies to option (a) and (e).
 The other is one that does not require MAC lookup on the ASBRs, and
 instead it builds segmented Inter-AS Inclusive or Selective trees.
 This applies only to option (b).
 For supporting option (c), this section specifies a model where
 Inter-AS VPLS service is offered by requiring a single Inclusive
 P-multicast tree to span multiple ASes.  This is referred to as a
 "non-segmented P-multicast tree".  This is because in the case of
 option (c), the ASBRs do not exchange BGP-VPLS NLRIs or VPLS A-D
 routes.  Support for Inter-AS Selective trees for option (c) may be
 segmented or non-segmented.
 An implementation MUST support options (a), (b), and (c), and MAY
 support option (e).  When there are multiple ways for implementing
 one of these options, this section specifies which one is mandatory.

7.1. VSIs on the ASBRs

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

7.1.1. Option (a): VSIs on the ASBRs

 In option (a), an ASBR acts as a PE for the VPLSs that span the AS of
 the ASBR and an AS to which the ASBR is connected.  The local ASBR
 views the ASBR in the neighboring AS as a CE connected to it by a
 link with separate VLAN sub-interfaces for each such VPLS.
 Similarly, the ASBR in the neighboring AS acts as a PE for such VPLS
 from the neighboring AS's point of view, and views the local ASBR as
 a CE.
 The local ASBR uses a combination of the incoming link and a
 particular VLAN sub-interface on that link to determine the VSI for
 the packets it receives from the ASBR in the neighboring AS.
 In option (a), the ASBRs do not exchange VPLS A-D routes.
 An implementation MUST support option (a).

Aggarwal, et al. Standards Track [Page 19] RFC 7117 Multicast in VPLS February 2014

7.1.2. Option (e): VSIs on the ASBRs

 The VSIs on the ASBRs scheme can be used such that the interconnect
 between the ASBRs is a PW and MPLS encapsulation is used between the
 ASBRs.  An ASBR in one AS determines the VSI for packets received
 from an adjoining ASBR in another AS based on the incoming MPLS PW
 label.  This is referred to as "option (e)".  The only VPLS A-D
 routes that are propagated outside the AS are the ones originated by
 ASBRs.  This MPLS PW connects the VSIs on the ASBRs and MUST be
 signaled using the procedures defined in [RFC4761] or [RFC4762].
 The P-multicast trees for a VPLS are confined to each AS and the VPLS
 auto-discovery/binding MUST follow the intra-AS procedures described
 in the "Demultiplexing P-Multicast Tree Traffic" section.
 An implementation MAY support option (e).

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

 In this model, an inter-AS P-multicast tree, rooted at a particular
 PE for a particular VPLS instance, consists of a number of
 "segments", one per AS, which are stitched together at ASBRs.  These
 are known as "segmented inter-AS trees".  Each segment of a segmented
 inter-AS tree may use a different multicast transport technology.  In
 this model, an ASBR is not required to keep a VSI for the VPLS
 instance, and is not required to perform a MAC lookup in order to
 forward the VPLS packet.  This implies that an ASBR is not required
 to be configured with a VE-ID for the VPLS.
 An implementation MUST support option (b) using this model.
 The construction of segmented inter-AS trees requires the BGP-VPLS
 A-D NLRI described in [RFC4761] and [RFC6074].  A BGP VPLS A-D route
 for an <RD, VE-ID> tuple advertised outside the AS, to which the
 originating PE belongs, will be referred to as an "Inter-AS VPLS A-D
 route" (though this route is originated by a PE as an intra-AS route,
 and is referred to as an "inter-AS route outside the AS").
 In addition to this, segmented inter-AS trees require support for the
 PMSI Tunnel attribute described in the "Inclusive Tree/Selective Tree
 Identifier" section.  They also require additional procedures in BGP
 to signal leaf A-D routes between ASBRs as explained in subsequent
 sections.

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

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

Aggarwal, et al. Standards Track [Page 20] RFC 7117 Multicast in VPLS February 2014

 An ASBR must be configured to support a particular VPLS as follows:
   + An ASBR MUST be configured with a set of (import) RTs that
     specify the set of VPLS instances supported by the ASBR.  These
     RTs control acceptance of BGP VPLS auto-discovery routes by the
     ASBR.  Note that instead of being configured, the ASBR MAY obtain
     this set of (import) RTs by using Route Target Constrain
     [RFC4684].
   + The ASBR MUST be configured with the tunnel types for the intra-
     AS segments of the VPLS instances supported by the ASBR, as well
     as (depending on the tunnel type) the information needed to
     create the PMSI Tunnel attribute for these tunnel types.  Note
     that instead of being configured, the ASBR MAY derive the tunnel
     types from the Intra-AS A-D routes received by the ASBR from the
     PEs in its own AS.
 If an ASBR is configured to support a particular VPLS instance, the
 ASBR MUST participate in the intra-AS VPLS auto-discovery/binding
 procedures for that VPLS instance within the ASBR's own AS, as
 defined in this document.
 Moreover, in addition to the above, the ASBR performs procedures
 specified in the "Propagating BGP VPLS A-D Routes to Other ASes:
 Overview" section.

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

 A BGP VPLS A-D route for a given VPLS, originated by a PE within a
 given AS, is propagated via BGP to other ASes.  The precise rules for
 distributing and processing the Inter-AS A-D routes are given in
 subsequent sections.
 Suppose that an ASBR "A" receives and installs a BGP VPLS A-D route
 for VPLS "X" and VE-ID "V" that originated at a particular PE "PE1"
 that is in the same AS as A.  The BGP next hop of that received route
 becomes A's "upstream neighbor" on a multicast distribution tree for
 (X, V) that is rooted at PE1.  Likewise, when A re-advertises this
 route to ASBRs in A's neighboring ASes, from the perspective of these
 ASBRs A becomes their "upstream neighbor" on the multicast
 distribution tree for (X, V) that is rooted at PE1.
 When the BGP VPLS A-D routes have been distributed to all the
 necessary ASes, they define a "reverse path" from any AS that
 supports VPLS X and VE-ID V back to PE1.  For instance, if AS2
 supports VPLS X, then there will be a reverse path for VPLS X and VE

Aggarwal, et al. Standards Track [Page 21] RFC 7117 Multicast in VPLS February 2014

 ID V from AS2 to AS1.  This path is a sequence of ASBRs, the first of
 which is in AS2 and the last of which is in AS1.  Each ASBR in the
 sequence is the BGP next hop of the previous ASBR in the sequence.
 This reverse path information can be used to construct a
 unidirectional multicast distribution tree for VPLS X and VE-ID V,
 containing all the ASes that support X, and having PE1 at the root.
 We call such a tree an "inter-AS tree".  Multicast data originating
 in VPLS sites for VPLS X connected to PE1 will travel downstream
 along the tree which is rooted at PE1.
 The path along an inter-AS tree is a sequence of ASBRs.  It is still
 necessary to specify how the multicast data gets from a given ASBR to
 the set of ASBRs that are immediately downstream of the given ASBR
 along the tree.  This is done by creating "segments".  ASBRs in
 adjacent ASes will be connected by inter-AS segments; ASBRs in the
 same AS will be connected by "intra-AS segments".
 For a given inter-AS tree and a given AS, there MUST be only one ASBR
 within that AS that accepts traffic flowing on that tree.  Further,
 for a given inter-AS tree and a given AS, there MUST be only one ASBR
 in that AS that sends the traffic flowing on that tree to a
 particular adjacent AS.  The precise rules for accomplishing this are
 given in subsequent sections.
 An ASBR initiates creation of an intra-AS segment when the ASBR
 receives an Inter-AS A-D route from an External BGP (EBGP) neighbor.
 Creation of the segment is completed as a result of distributing, via
 IBGP, this route within the ASBR's own AS.
 For a given inter-AS tunnel, each of its intra-AS segments could be
 constructed by its own independent mechanism.  Moreover, by using
 upstream-assigned labels within a given AS, multiple intra-AS
 segments of different inter-AS tunnels of either the same or
 different VPLS instances may share the same P-multicast tree.
 If the P-multicast tree instantiating a particular segment of an
 inter-AS tunnel is created by a multicast control protocol that uses
 receiver-initiated joins (e.g, mLDP), and this P-multicast tree does
 not aggregate multiple segments, then all the information needed to
 create that segment will be present in the Inter-AS A-D routes
 received by the ASBR from the neighboring ASBR.  But if the
 P-multicast tree instantiating the segment is created by a protocol
 that does not use receiver-initiated joins (e.g., RSVP-TE, ingress
 unicast replication), or if this P-multicast tree aggregates multiple
 segments (irrespective of the multicast control protocol used to

Aggarwal, et al. Standards Track [Page 22] RFC 7117 Multicast in VPLS February 2014

 create the tree), then the ASBR needs to learn the leaves of the
 segment.  These leaves are learned from A-D routes received from
 other PEs in the AS, for the same VPLS as the one to which the
 segment belongs.
 The following sections specify procedures for propagation of Inter-AS
 A-D routes across ASes in order to construct inter-AS segmented
 trees.

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

 For a given VPLS configured on an ASBR when the ASBR receives Intra-
 AS A-D routes originated by PEs in its own AS, the ASBR MUST
 propagate each of these route in EBGP.  This procedure MUST be
 performed for each of the VPLS instances configured on the ASBR.
 Each of these routes is constructed as follows:
   + The route carries a single BGP VPLS A-D NLRI with the RD and
     VE-ID being the same as the NLRI in the received Intra-AS A-D
     route.
   + The Next Hop field of the MP_REACH_NLRI attribute is set to a
     routable IP address of the ASBR.
   + The route carries the PMSI Tunnel attribute with the Tunnel Type
     set to Ingress Replication; the attribute carries no MPLS labels.
   + The route MUST carry the export RT used by the VPLS.

7.2.2.2. Inter-AS A-D Route Received via EBGP

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

Aggarwal, et al. Standards Track [Page 23] RFC 7117 Multicast in VPLS February 2014

 When re-advertising an Inter-AS A-D route, the ASBR MUST set the Next
 Hop field of the MP_REACH_NLRI attribute to a routable IP address of
 the ASBR.
 Depending on the type of a P-multicast tunnel used to instantiate the
 intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of
 the re-advertised Inter-AS A-D route is constructed as follows:
   + If the ASBR uses ingress replication to instantiate the intra-AS
     segment of the inter-AS tunnel, the re-advertised route MUST NOT
     carry the PMSI Tunnel attribute.
   + If the ASBR uses a P-multicast tree to instantiate the intra-AS
     segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST
     contain the identity of the tree that is used to instantiate the
     segment (note that the ASBR could create the identity of the tree
     prior to the actual instantiation of the segment).  If, in order
     to instantiate the segment, the ASBR needs to know the leaves of
     the tree, then the ASBR obtains this information from the A-D
     routes received from other PEs/ASBRs in the ASBR's own AS.
   + An ASBR that uses a P-multicast tree to instantiate the intra-AS
     segment of the inter-AS tunnel MAY aggregate two or more VPLS
     instances present on the ASBR onto the same tree.  If the ASBR
     already advertises Inter-AS A-D routes for these VPLS instances,
     then aggregation requires the ASBR to re-advertise these routes.
     The re-advertised routes MUST be the same as the original ones,
     except for the PMSI Tunnel attribute.  If the ASBR has not
     previously advertised Inter-AS A-D routes for these VPLS
     instances, then the aggregation requires the ASBR to advertise
     (new) Inter-AS A-D routes for these VPLS instances.  The PMSI
     Tunnel attribute in the newly advertised/re-advertised routes
     MUST carry the identity of the P-multicast tree that aggregates
     the VPLS instances, as well as an MPLS upstream-assigned label
     [RFC5331].  Each newly advertised or re-advertised route MUST
     have a label that is distinct within the scope of the ASBR.
 In addition, the ASBR MUST send to the EBGP neighbor, from whom it
 receives the Inter-AS A-D route, a BGP Update message that carries a
 leaf A-D route.  The exact encoding of this route is described in the
 "BGP Extensions" section.  This route contains the following
 information elements:
   + The route carries a single NLRI with the Route Key field set to
     the <RD, VE-ID> tuple of the BGP VPLS A-D NLRI of the Inter-AS
     A-D route received from the EBGP neighbor.  The NLRI also carries
     the IP address of the ASBR (this MUST be a routable IP address).

Aggarwal, et al. Standards Track [Page 24] RFC 7117 Multicast in VPLS February 2014

   + The leaf A-D route MUST include the PMSI Tunnel attribute with
     the Tunnel Type set to Ingress Replication, and the Tunnel
     Identifier set to a routable address of the advertising router.
     The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS
     label that is used to demultiplex the VPLS traffic received over
     a unicast tunnel by the advertising router.
   + The Next Hop field of the MP_REACH_NLRI attribute of the route
     SHOULD be set to the same IP address as the one carried in the
     Originating Router's IP Address field of the route.
   + To constrain the distribution scope of this route, the route MUST
     carry the NO_ADVERTISE BGP Community ([RFC1997]).
   + The ASBR constructs an IP-address-specific RT by placing the IP
     address carried in the Next Hop field of the received Inter-AS
     VPLS A-D route in the Global Administrator field of the
     community, with the Local Administrator field of this community
     set to 0.  It also sets the Extended Communities attribute of the
     leaf A-D route to that community.  Note that this RT is the same
     as the ASBR Import RT of the EBGP neighbor from which the ASBR
     received the Inter-AS VPLS A-D route.

7.2.2.3. Leaf A-D Route Received via EBGP

 When an ASBR receives, via EBGP, a leaf A-D route, the ASBR accepts
 the route only if (a) at least one of the RTs carried in the message
 matches one of the import RTs configured on the ASBR and (b) the ASBR
 determines that the received route is the best route to the
 destination carried in the NLRI of the route.
 If the ASBR accepts the leaf A-D route, the ASBR looks for an
 existing A-D route whose BGP-VPLS A-D NLRI has the same value as the
 <RD, VE-ID> field of the leaf A-D route just accepted.  If such an
 A-D route is found, then the MPLS label carried in the PMSI Tunnel
 attribute of the leaf A-D route is used to stitch a one hop ASBR-ASBR
 LSP to the tail of the intra-AS tunnel segment associated with the
 found A-D route.

7.2.2.4. Inter-AS A-D Route Received via IBGP

 In the context of this section, we use the term "PE/ASBR router" to
 denote either a PE or an ASBR router.
 Note that a given Inter-AS A-D route is advertised within a given AS
 by only one ASBR, as described above.

Aggarwal, et al. Standards Track [Page 25] RFC 7117 Multicast in VPLS February 2014

 When a PE/ASBR router receives, from one of its IBGP neighbors, a BGP
 Update message that carries an Inter-AS A-D route, if (a) at least
 one of the RTs carried in the message matches one of the import RTs
 configured on the PE/ASBR and (b) the PE/ASBR determines that the
 received route is the best route to the destination carried in the
 NLRI of the route, the PE/ASBR performs the following operations.
 The best route determination is as described in [RFC4761] and
 clarified in [MULTI-HOMING].
 If the router is an ASBR, then the ASBR propagates the route to its
 EBGP neighbors.  When propagating the route to the EBGP neighbors,
 the ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute
 to a routable IP address of the ASBR.
 If the received Inter-AS A-D route carries the PMSI Tunnel attribute
 with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR SHOULD join the
 P-multicast tree whose identity is carried in the PMSI Tunnel
 attribute.
 If the received Inter-AS A-D route carries the PMSI Tunnel attribute
 with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR
 that originated the route MUST establish an RSVP-TE P2MP LSP with the
 local PE/ASBR as a leaf.  This LSP MAY have been established before
 the local PE/ASBR receives the route, or it MAY be established after
 the local PE receives the route.
 If the received Inter-AS A-D route carries the PMSI Tunnel attribute
 with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP LSP, but
 the attribute does not carry a label, then the P-multicast tree, as
 identified by the PMSI Tunnel attribute, is an intra-AS LSP segment
 that is part of the inter-AS tunnel for the <VPLS, VE-ID> advertised
 by the Inter-AS A-D route and rooted at the PE that originated the
 A-D route.  If the PMSI Tunnel attribute carries a (upstream-
 assigned) label, then a combination of this tree and the label
 identifies the intra-AS segment.  If the receiving router is an ASBR,
 this intra-AS segment may further be stitched to ASBR-ASBR inter-AS
 segment of the inter-AS tunnel.  If the PE/ASBR has local receivers
 in the VPLS, packets received over the intra-AS segment must be
 forwarded to the local receivers using the local VSI.

7.3. Option ©: Non-segmented Tunnels

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

Aggarwal, et al. Standards Track [Page 26] RFC 7117 Multicast in VPLS February 2014

 The PEs in different ASes use a non-segmented inter-AS P2MP tunnel
 for VPLS multicast.  A non-segmented inter-AS tunnel is a single
 tunnel that spans AS boundaries.  The tunnel technology cannot change
 from one point in the tunnel to the next, so all ASes through which
 the tunnel passes must support that technology.  In essence, AS
 boundaries are of no significance to a non-segmented inter-AS P2MP
 tunnel.
 This model requires no VPLS A-D routes in the control plane or VPLS
 MAC address learning in the data plane on the ASBRs.  The ASBRs only
 need to participate in the non-segmented P2MP tunnel setup in the
 control plane and do MPLS label forwarding in the data plane.
 When the tunneling technology is P2MP LSP signaled with mLDP, and one
 does not use [RFC6512], the setup of non-segmented inter-AS P2MP
 tunnels requires the P-routers in one AS to have IP reachability to
 the loopback addresses of the PE routers in another AS.  That is, the
 reachability to the loopback addresses of PE routers in one AS MUST
 be present in the IGP in another AS.
 The data forwarding in this model is the same as in the intra-AS case
 described in the "Demultiplexing P-Multicast Tree Traffic" section.
 An implementation MUST support this model.

8. Optimizing Multicast Distribution via Selective Trees

 Whenever a particular multicast stream is being sent on an Inclusive
 P-multicast tree, it is likely that the data of that stream is being
 sent to PEs that do not require it, as the sites connected to these
 PEs may have no receivers for the stream.  If a particular stream has
 a significant amount of traffic, it may be beneficial to move it to a
 Selective P-multicast tree that has, at its leaves, only those PEs,
 connected to sites that have receivers for the multicast stream (or
 at least includes fewer PEs that are attached to sites with no
 receivers compared to an Inclusive tree).
 A PE connected to the multicast source of a particular multicast
 stream may be performing explicit tracking; that is, it may know the
 PEs that have receivers in the multicast stream.  The "Receiving
 S-PMSI A-D Routes by PEs" section describes procedures that enable
 explicit tracking.  If this is the case, Selective P-multicast trees
 can also be triggered on other criteria.  For instance, there could
 be a "pseudo-wasted bandwidth" criterion: switching to a Selective
 tree would be done if the bandwidth multiplied by the number of
 "uninterested" PEs (PEs that are receiving the stream but have no
 receivers) is above a specified threshold.  The motivation is that
 (a) the total bandwidth wasted by many sparsely subscribed low-

Aggarwal, et al. Standards Track [Page 27] RFC 7117 Multicast in VPLS February 2014

 bandwidth groups may be large and (b) there's no point to moving a
 high-bandwidth group to a Selective tree if all the PEs have
 receivers for it.
 Switching a (C-S, C-G) stream to a Selective P-multicast tree may
 require the root of the tree to determine the egress PEs that need to
 receive the (C-S, C-G) traffic.  This is true in the following cases:
   + If the tunnel is a P2MP tree, such as an RSVP-TE P2MP Tunnel, the
     PE needs to know the leaves of the tree before it can instantiate
     the Selective tree.
   + If a PE decides to send traffic for multicast streams, belonging
     to different VPLS instances, using one P-multicast Selective
     tree, such a tree is called an "Aggregate tree with a selective
     mapping".  The setting up of such an Aggregate tree requires the
     ingress PE to know all the other PEs that have receivers for
     multicast groups that are mapped onto the tree (see the
     "Aggregation Considerations" section for the rationale).
   + If ingress replication is used and the ingress PE wants to send
     traffic for (C-S, C-G)s to only those PEs that are on the path to
     receivers to the (C-S, C-G)s.
 For discovering the IP multicast group membership, for the above
 cases, this document describes procedures that allow an ingress PE to
 enable explicit tracking.  Thus, an ingress PE can request the IP
 multicast membership from egress PEs for one or more C-multicast
 streams.  These procedures are described in the "Receiving S-PMSI A-D
 Routes by PEs" section.
 The root of the Selective P-multicast tree MAY decide to do explicit
 tracking of the IP multicast stream only after it has decided to move
 the stream to a Selective tree, or it MAY have been doing explicit
 tracking all along.  This document also describes explicit tracking
 for a wildcard source and/or group in the "Receiving S-PMSI A-D
 Routes by PEs" section, which facilitates a Selective P-multicast
 tree only mode in which IP multicast streams are always carried on a
 Selective P-multicast tree.  In the description on Selective
 P-multicast trees, the notation C-S is intended to represent either a
 specific source address or a wildcard.  Similarly, C-G is intended to
 represent either a specific group address or a wildcard.
 The PE at the root of the tree MUST signal the leaves of the tree
 that the (C-S, C-G) stream is now bound to the Selective tree.  Note
 that the PE could create the identity of the P-multicast tree prior
 to the actual instantiation of the tunnel.

Aggarwal, et al. Standards Track [Page 28] RFC 7117 Multicast in VPLS February 2014

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

8.1. Protocol for Switching to Selective Trees

 Selective trees provide a PE the ability to create separate
 P-multicast trees for certain (C-S, C-G) streams.  The source PE,
 which originates the Selective tree, and the egress PEs MUST use the
 Selective tree for the (C-S, C-G) streams that are mapped to it.
 This may require the source and egress PEs to switch to the Selective
 tree from an Inclusive tree if they were already using an Inclusive
 tree for the (C-S, C-G) streams mapped to the Selective tree.
 Once a source PE decides to set up a Selective tree, it MUST announce
 the mapping of the (C-S, C-G) streams (which may be in different VPLS
 instances) that are mapped to the tree to the other PEs using BGP.
 After the egress PEs receive the announcement, they set up their
 forwarding path to receive traffic on the Selective tree if they have
 one or more receivers interested in the (C-S, C-G) streams mapped to
 the tree.  Setting up the forwarding path requires setting up the
 demultiplexing forwarding entries based on the top MPLS label (if
 there is no inner label) or the inner label (if present) as described
 in the "Establishing P-Multicast Trees" section.
 When the P2MP LSP is established using mLDP, the egress PEs MAY
 perform this switch to the Selective tree once the announcement from
 the ingress PE is received, or they MAY wait for a preconfigured
 timer to do so after receiving the announcement.
 When the P2MP LSP protocol is P2MP RSVP-TE, an egress PE MUST perform
 this switch to the Selective tree only after the announcement from
 the ingress PE is received and the RSVP-TE P2MP LSP has been set up
 to the egress PE.  This switch MAY be done after waiting for a
 preconfigured timer after these two steps have been accomplished.
 A source PE MUST use the following approach to decide when to start
 transmitting data on the Selective tree, if it is currently using an
 Inclusive tree.  After announcing the (C-S, C-G) stream mapping to a
 Selective tree, the source PE MUST wait for a "switchover" delay
 before sending (C-S, C-G) stream on the Selective tree.  It is
 RECOMMENDED to allow this delay to be configurable.  Once the

Aggarwal, et al. Standards Track [Page 29] RFC 7117 Multicast in VPLS February 2014

 "switchover" delay has elapsed, the source PE MUST send (C-S, C-G)
 stream on the Selective tree.  In no case is any (C-S, C-G) packet
 sent on both Selective and Inclusive trees.
 When a (C-S, C-G) stream is switched from an Inclusive to a Selective
 tree, the purpose of running a switchover timer is to minimize packet
 loss without introducing packet duplication.  However, jitter may be
 introduced due to the difference in transit delays between the
 Inclusive and Selective trees.
 For best effect, the switchover timer should be configured to a value
 that is "just long enough" (a) to allow all the PEs to learn about
 the new binding of (C-S, C-G) to a Selective tree and (b) to allow
 the PEs to construct the P-tunnel associated with the Selective tree,
 if it doesn't already exist.

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

 The ingress PE informs all the PEs that are on the path to receivers
 of the (C-S, C-G) of the binding of the Selective tree to the (C-S,
 C-G), using BGP.  The BGP announcement is done by sending update for
 the MCAST-VPLS address family using what we referred to as an "S-PMSI
 A-D route".  The format of the NLRI of this route is described in the
 "Inclusive Tree/Selective Tree Identifier" section.  The NLRI MUST be
 constructed as follows:
   + The Route Distinguisher (RD) MUST be set to the RD configured
     locally for the VPLS.  This is required to uniquely identify the
     <C-S, C-G> as the addresses could overlap between different VPLS
     instances.  This MUST be the same RD value used in the VPLS auto-
     discovery process.
   + The Multicast Source field MUST contain the source address
     associated with the C-multicast stream, and the Multicast Source
     Length field is set appropriately to reflect this.  If the source
     address is a wildcard, the source address is set to 0.
   + The Multicast Group field MUST contain the group address
     associated with the C-multicast stream, and the Multicast Group
     Length field is set appropriately to reflect this.  If the group
     address is a wildcard, the group address is set to 0.
   + The Originating Router's IP Address field MUST be set to the IP
     address that the (local) PE places in the BGP Next Hop of the
     BGP-VPLS A-D routes.  Note that the <RD, Originating Router's IP
     Address> tuple uniquely identifies a given VPLS instance on a PE.

Aggarwal, et al. Standards Track [Page 30] RFC 7117 Multicast in VPLS February 2014

 The PE constructs the rest of the Selective A-D route as follows.
 Depending on the type of a P-multicast tree used for the P-tunnel,
 the PMSI Tunnel attribute of the S-PMSI A-D route is constructed as
 follows:
   + The PMSI Tunnel attribute MUST contain the identity of the
     P-multicast tree (note that the PE could create the identity of
     the tree prior to the actual instantiation of the tree).
   + If, in order to establish the P-multicast tree, the PE needs to
     know the leaves of the tree within its own AS, then the PE
     obtains this information from the leaf A-D routes received from
     other PEs/ASBRs within its own AS (as other PEs/ASBRs originate
     leaf A-D routes in response to receiving the S-PMSI A-D route) by
     setting the Leaf Information Required flag in the PMSI Tunnel
     attribute to 1.  This enables explicit tracking for the multicast
     stream(s) advertised by the S-PMSI A-D route.
   + If a PE originates S-PMSI A-D routes with the Leaf Information
     Required flag in the PMSI Tunnel attribute set to 1, then the PE
     MUST be (auto-)configured with an import RT, which controls
     acceptance of leaf A-D routes by the PE.  (Procedures for
     originating leaf A-D routes by the PEs that receive the S-PMSI
     A-D route are described in the "Receiving S-PMSI A-D Routes by
     PEs" section.)
     This RT is IP address specific.  The Global Administrator field
     of this RT MUST be set to the IP address carried in the Next Hop
     field of all the S-PMSI A-D routes advertised by this PE (if the
     PE uses different Next Hop fields, then the PE MUST be
     (auto-)configured with multiple import RTs, one per each such
     Next Hop field).  The Local Administrator field of this Route
     Target MUST be set to 0.
     If the PE supports Route Target Constrain [RFC4684], the PE
     SHOULD advertise this import RT within its own AS using Route
     Target Constrain.  To constrain distribution of the Route Target
     Constrain routes to the AS of the advertising PE these routes
     SHOULD carry the NO_EXPORT Community ([RFC1997]).
   + A PE MAY aggregate two or more S-PMSIs originated by the PE onto
     the same P-multicast tree.  If the PE already advertises S-PMSI
     A-D routes for these S-PMSIs, then aggregation requires the PE to
     re-advertise these routes.  The re-advertised routes MUST be the
     same as the original ones, except for the PMSI Tunnel attribute.
     If the PE has not previously advertised S-PMSI A-D routes for
     these S-PMSIs, then the aggregation requires the PE to advertise

Aggarwal, et al. Standards Track [Page 31] RFC 7117 Multicast in VPLS February 2014

     (new) S-PMSI A-D routes for these S-PMSIs.  The PMSI Tunnel
     attribute in the newly advertised/re-advertised routes MUST carry
     the identity of the P-multicast tree that aggregates the S-PMSIs.
     If at least some of the S-PMSIs aggregated onto the same
     P-multicast tree belong to different VPLS instances, then all
     these routes MUST carry an MPLS upstream-assigned label
     [RFC5331].  If all these aggregated S-PMSIs belong to the same
     VPLS, then the routes MAY carry an MPLS upstream-assigned label
     [RFC5331].  The labels MUST be distinct on a per-VPLS-instance
     basis, and they MAY be distinct on a per-route basis.
 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
 be set to the same IP address as the one carried in the Originating
 Router's IP Address field.
 By default, the set of RTs carried by the route MUST be the same as
 the RTs carried in the BGP-VPLS A-D route originated from the VSI.
 The default could be modified via configuration.

8.3. Receiving S-PMSI A-D Routes by PEs

 Consider a PE that receives an S-PMSI A-D route.  If one or more of
 the VSIs on the PE have their import RTs that contain one or more of
 the RTs carried by the received S-PMSI A-D route, then for each such
 VSI, the PE performs the following.
 Procedures for receiving an S-PMSI A-D route by a PE (both within and
 outside of the AS of the PE that originates the route) are the same
 as specified in the "Inter-AS A-D Route Received via IBGP" section,
 except that (a) instead of Inter-AS A-D routes the procedures apply
 to S-PMSI A-D routes, (b) the rules for determining whether the
 received S-PMSI A-D route is the best route to the destination
 carried in the NLRI of the route are the same as BGP path selection
 rules and may be modified by policy, and (c) a PE performs procedures
 specified in that section only if in addition to the criteria
 specified in that section the following is true:
   + If, as a result of multicast state snooping on the PE-CE
     interfaces, the PE has snooped state for at least one multicast
     join that matches the multicast source and group advertised in
     the S-PMSI A-D route.  Further, the oifs (outgoing interfaces)
     for this state contain one or more interfaces to the locally
     attached CEs.  When the multicast signaling protocol among the
     CEs is IGMP, then snooping and associated procedures are defined
     in [RFC4541].  The snooped state is determined using these
     procedures.  When the multicast signaling protocol among the CEs
     is PIM, the procedures in [RFC4541] are not sufficient to
     determine the snooped state.  The additional details required to

Aggarwal, et al. Standards Track [Page 32] RFC 7117 Multicast in VPLS February 2014

     determine the snooped state when CE-CE protocol is PIM are for
     further study.  When such procedures are defined, it is expected
     that the procedures in this section will apply to the snooped
     state created as a result of PIM as PE-CE protocol.
 The snooped state is said to "match" the S-PMSI A-D route if any of
 the following is true:
   + The S-PMSI A-D route carries (C-S, C-G) and the snooped state is
     for (C-S, C-G) or for (C-*, C-G), OR
   + The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped state
     is for (C-*, C-G) OR (b) the snooped state is for at least one
     multicast join with the multicast group address equal to C-G and
     there doesn't exist another S-PMSI A-D route that carries (C-S,
     C-G) where C-S is the source address of the snooped state.
   + The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped state
     is for at least one multicast join with the multicast source
     address equal to C-S, and (b) there doesn't exist another S-PMSI
     A-D route that carries (C-S, C-G) where C-G is the group address
     of the snooped state.
   + The S-PMSI A-D route carries (C-*, C-*) and there is no other
     S-PMSI A-D route that matches the snooped state as per the above
     conditions.
 Note if the above conditions are true, and if the received S-PMSI A-D
 route has a PMSI Tunnel attribute with the Leaf Information Required
 flag set to 1, then the PE originates a leaf A-D route, constructed
 as follows:
   + The route carries a single MCAST-VPLS NLRI with the Route Key
     field set to the MCAST-VPLS NLRI of the received S-PMSI A-D
     route.
   + The Originating Router's IP Address set to the IP address of the
     PE (this MUST be a routable IP address).
   + The PE constructs an IP-address-specific RT by placing the IP
     address carried in the Next Hop field of the received S-PMSI A-D
     route in the Global Administrator field of the Community, with
     the Local Administrator field of this Community set to 0 and
     setting the Extended Communities attribute of the leaf A-D route
     to that Community.

Aggarwal, et al. Standards Track [Page 33] RFC 7117 Multicast in VPLS February 2014

   + The Next Hop field of the MP_REACH_NLRI attribute of the route
     MUST be set to the same IP address as the one carried in the
     Originating Router's IP Address field of the route.
   + To constrain the distribution scope of this route, the route MUST
     carry the NO_EXPORT Community [RFC1997], except for the inter-AS
     scenario with option (c).
 Once the leaf A-D route is constructed, the PE advertises this route
 into IBGP.
 In addition to the procedures specified in the "Inter-AS A-D Route
 Received via IBGP" section, the PE MUST set up its forwarding path to
 receive traffic, for each multicast stream in the matching snooped
 state, from the tunnel advertised by the S-PMSI A-D route (the PE
 MUST switch to the Selective tree).
 When a new snooped state is created by a PE, then the PE MUST first
 determine if there is an S-PMSI A-D route that matches the snooped
 state as per the conditions described above.  If such an S-PMSI A-D
 route is found, then the PE MUST follow the procedures described in
 this section, for that particular S-PMSI A-D route.  If later on the
 snooped state ages out and is deleted from the PE, the PE SHOULD
 withdraw the leaf A-D route that it had originated in response to the
 S-PMSI A-D route.

8.4. Inter-AS Selective Tree

 Inter-AS Selective trees support all three options of inter-AS VPLS
 service, option (a), (b), and (c), that are supported by Inter-AS
 Inclusive trees.  They are constructed in a manner that is very
 similar to Inter-AS Inclusive trees.
 For option (a) and option (b), support Inter-AS Selective trees are
 constructed without requiring a single P-multicast tree to span
 multiple ASes.  This allows individual ASes to potentially use
 different P-tunneling technologies.  There are two variants of this.
 One that requires MAC and IP multicast lookup on the ASBRs and
 another that does not require MAC/IP multicast lookup on the ASBRs
 and instead builds segmented Inter-AS Selective trees.
 Segmented Inter-AS Selective trees can also be used with option (c),
 unlike Segmented Inter-AS Inclusive trees.  This is because the
 S-PMSI A-D routes can be exchanged via ASBRs (even though BGP VPLS
 A-D routes are not exchanged via ASBRs).
 In the case of Option (c), an Inter-AS Selective tree may also be a
 non-segmented P-multicast tree that spans multiple ASes.

Aggarwal, et al. Standards Track [Page 34] RFC 7117 Multicast in VPLS February 2014

8.4.1. VSIs on the ASBRs

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

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

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

8.4.2. Inter-AS Segmented Selective Trees

 Inter-AS Segmented Selective trees MUST be implemented when option
 (b) is used to provide the inter-AS VPLS service.  They MAY be used
 when option (c) is implemented to provide the inter-AS VPLS service.
 A Segmented inter-AS Selective Tunnel is constructed similar to an
 inter-AS Segmented Inclusive Tunnel.  Namely, such a tunnel is
 constructed as a concatenation of tunnel segments.  There are two
 types of tunnel segments: an intra-AS tunnel segment (a segment that
 spans ASBRs within the same AS) and inter-AS tunnel segment (a
 segment that spans adjacent ASBRs in adjacent ASes).  ASes that are
 spanned by a tunnel are not required to use the same tunneling
 mechanism to construct the tunnel -- each AS may pick up a tunneling
 mechanism to construct the intra-AS tunnel segment of the tunnel, in
 its AS.
 The PE that decides to set up a Selective tree advertises the
 Selective tree to multicast stream binding using an S-PMSI A-D route,
 as per procedures in the "Advertising (C-S, C-G) Binding to a
 Selective Tree" section, to the routers in its own AS.
 An S-PMSI A-D route advertised outside the AS, to which the
 originating PE belongs, will be referred to as an Inter-AS S-PMSI
 tree A-D route (although this route is originated by a PE as an
 intra-AS S-PMSI A-D route, it is referred to as an Inter-AS route
 outside the AS).

Aggarwal, et al. Standards Track [Page 35] RFC 7117 Multicast in VPLS February 2014

8.4.2.1. Handling S-PMSI A-D Routes by ASBRs

 Procedures for handling an S-PMSI A-D route by ASBRs (both within and
 outside of the AS of the PE that originates the route) are the same
 as specified in the "Propagating BGP VPLS A-D Routes to Other ASes"
 section, except that instead of Inter-AS A-D routes and their NLRI,
 these procedures apply to S-PMSI A-D routes and their NLRI.
 In addition to these procedures, an ASBR advertises a leaf A-D route
 in response to an S-PMSI A-D route only if:
   + The S-PMSI A-D route was received via EBGP from another ASBR and
     the ASBR merges the S-PMSI A-D route into an Inter-AS BGP VPLS
     A-D route as described in the next section.  OR
   + The ASBR receives a leaf A-D route from a downstream PE or ASBR
     in response to the S-PMSI A-D route, received from an upstream PE
     or ASBR, that the ASBR propagated inter-AS to downstream ASBRs
     and PEs.
   + The ASBR has snooped state from local CEs that matches the NLRI
     carried in the S-PMSI A-D route as per the following rules:
    i) The NLRI encodes (C-S, C-G), which is the same as the snooped
       (C-S, C-G)
   ii) The NLRI encodes (*, C-G), there is snooped state for at least
       one (C-S, C-G), and there is no other matching S-PMSI A-D route
       for (C-S, C-G) OR there is snooped state for (*, C-G)
  iii) The NLRI encodes (*, *), there is snooped state for at least
       one (C-S, C-G) or (*, C-G), and there is no other matching
       S-PMSI A-D route for that (C-S, C-G) or (*, C-G), respectively.
 The C-multicast data traffic is sent on the Selective tree by the
 originating PE.  When it reaches an ASBR that is on the inter-AS
 segmented tree, it is delivered to local receivers, if any.  It is
 then forwarded on any inter-AS or intra-AS segments that exist on the
 Inter-AS Selective segmented tree.  If the Inter-AS Selective
 segmented tree is merged onto an Inclusive tree, as described in the
 next section, the data traffic is forwarded onto the Inclusive tree.

Aggarwal, et al. Standards Track [Page 36] RFC 7117 Multicast in VPLS February 2014

8.4.2.1.1. Merging Selective Tree into an Inclusive Tree

 Consider the situation where:
   + An ASBR is receiving (or expecting to receive) inter-AS
     (C-S, C-G) data from upstream via a Selective tree.
   + The ASBR is sending (or expecting to send) the inter-AS
     (C-S, C-G) data downstream via an Inclusive tree.
 This situation may arise if the upstream providers have a policy of
 using Selective trees but the downstream providers have a policy of
 using Inclusive trees.  To support this situation, an ASBR MAY, under
 certain conditions, merge one or more upstream Selective trees into a
 downstream Inclusive tree.  Note that this can be the case only for
 option (b) and not for option (c) as, for option (c), the ASBRs do
 not have Inclusive tree state.
 A Selective tree (corresponding to a particular S-PMSI A-D route) MAY
 be merged by a particular ASBR into an Inclusive tree (corresponding
 to a particular Inter-AS BGP VPLS A-D route) if and only if the
 following conditions all hold:
   + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route
     originate in the same AS.  The Inter-AS BGP VPLS A-D route
     carries the originating AS in the AS_PATH attribute of the route.
     The S-PMSI A-D route carries the originating AS in the AS_PATH
     attribute of the route.
   + The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route have
     exactly the same set of RTs.
 An ASBR performs merging by stitching the tail end of the P-tunnel,
 as specified in the PMSI Tunnel attribute of the S-PMSI A-D route
 received by the ASBR, to the head of the P-tunnel, as specified in
 the PMSI Tunnel attribute of the Inter-AS BGP VPLS A-D route
 re-advertised by the ASBR.
 An ASBR that merges an S-PMSI A-D route into an Inter-AS BGP VPLS A-D
 route MUST NOT re-advertise the S-PMSI A-D route.

Aggarwal, et al. Standards Track [Page 37] RFC 7117 Multicast in VPLS February 2014

8.4.3. Inter-AS Non-segmented Selective Trees

 Inter-AS Non-segmented Selective trees MAY be used in the case of
 option (c).
 In this method, there is a multi-hop EBGP peering between the PEs (or
 a Route Reflector) in one AS and the PEs (or Route Reflector) in
 another AS.  The PEs exchange BGP Selective tree A-D routes, along
 with PMSI Tunnel attribute, as in the intra-AS case described in the
 "Option (c): Non-segmented Tunnels" section.
 The PEs in different ASes use a non-segmented Selective inter-AS P2MP
 tunnel for VPLS multicast.
 This method requires no VPLS information (in either the control or
 the data plane) on the ASBRs.  The ASBRs only need to participate in
 the non-segmented P2MP tunnel setup in the control plane and do MPLS
 label forwarding in the data plane.
 The data forwarding in this model is the same as in the intra-AS case
 described in the "Establishing P-Multicast Trees" section.

9. BGP Extensions

 This section describes the encoding of the BGP extensions required by
 this document.

9.1. Inclusive Tree/Selective Tree Identifier

 Inclusive P-multicast tree and Selective P-multicast tree
 advertisements carry the P-multicast tree identifier.  For the
 purpose of carrying this identifier, this document reuses the BGP
 attribute, called "PMSI_TUNNEL" that is defined in [RFC6514].
 This document supports only the following Tunnel Types when the PMSI
 Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes:
   + 0 - No tunnel information present
   + 1 - RSVP-TE P2MP LSP
   + 2 - LDP P2MP LSP
   + 6 - Ingress Replication

Aggarwal, et al. Standards Track [Page 38] RFC 7117 Multicast in VPLS February 2014

9.2. MCAST-VPLS NLRI

 This document defines a new BGP NLRI, called the "MCAST-VPLS NLRI".
 Following is the format of the MCAST-VPLS NLRI:
              +-----------------------------------+
              |    Route Type (1 octet)           |
              +-----------------------------------+
              |     Length (1 octet)              |
              +-----------------------------------+
              |    Route Type specific (variable) |
              +-----------------------------------+
 The Route Type field defines encoding of the Route Type specific
 field of MCAST-VPLS NLRI.
 The Length field indicates the length in octets of the Route Type
 specific field of MCAST-VPLS NLRI.
 This document defines the following route types for A-D routes:
   + 3 - Selective Tree A-D route;
   + 4 - Leaf A-D route.
 The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol
 Extensions [RFC4760] with an Address Family Identifier (AFI) of 25
 (L2VPN AFI), and a Subsequent Address Family Identifier (SAFI) of
 MCAST-VPLS.  The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI
 attribute contains the MCAST-VPLS NLRI (encoded as specified above).
 In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI,
 they must use BGP Capabilities Advertisement to ensure that they both
 are capable of properly processing such NLRI.  This is done as
 specified in [RFC4760], by using capability code 1 (multiprotocol
 BGP) with an AFI of 25 and a SAFI of MCAST-VPLS.
 The following describes the format of the Route Type specific field
 of MCAST-VPLS NLRI for various route types defined in this document.

Aggarwal, et al. Standards Track [Page 39] RFC 7117 Multicast in VPLS February 2014

9.2.1. S-PMSI A-D Route

 The Route Type specific field of MCAST-VPLS NLRI of an S-PMSI A-D
 route consists of the following:
              +-----------------------------------+
              |      RD   (8 octets)              |
              +-----------------------------------+
              | Multicast Source Length (1 octet) |
              +-----------------------------------+
              |  Multicast Source (Variable)      |
              +-----------------------------------+
              |  Multicast Group Length (1 octet) |
              +-----------------------------------+
              |  Multicast Group   (Variable)     |
              +-----------------------------------+
              |   Originating Router's IP Addr    |
              +-----------------------------------+
 The RD is encoded as described in [RFC4364].
 The Multicast Source field contains the C-S address, i.e., the
 address of the multicast source.  If the Multicast Source field
 contains an IPv4 address, then the value of the Multicast Source
 Length field is 32.  If the Multicast Source field contains an IPv6
 address, then the value of the Multicast Source Length field is 128.
 The value of the Multicast Source Length field may be set to 0 to
 indicate a wildcard.
 The Multicast Group field contains the C-G address, i.e., the address
 of the multicast group.  If the Multicast Group field contains an
 IPv4 address, then the value of the Multicast Group Length field is
 32.  If the Multicast Group field contains an IPv6 address, then the
 value of the Multicast Group Length field is 128.  The Multicast
 Group Length field may be set to 0 to indicate a wildcard.
 Whether the Originating Router's IP Address field carries an IPv4 or
 IPv6 address is determined by the value of the Length field of the
 MCAST-VPLS NLRI.  If the Multicast Source field contains an IPv4
 address and the Multicast Group field contains an IPv4 address, then
 the value of the Length field is 22 bytes if the Originating Router's
 IP Address carries an IPv4 address and 34 bytes if it is an IPv6
 address.  If the Multicast Source and Multicast Group fields contain
 IPv6 addresses, then the value of the Length field is 46 bytes if the
 Originating Router's IP Address carries an IPv4 address and 58 bytes
 if it is an IPv6 address.  The following table summarizes the above.

Aggarwal, et al. Standards Track [Page 40] RFC 7117 Multicast in VPLS February 2014

    Multicast   Multicast                Originating Router's   Length
    Source      Group                       IP Address
      IPv4      IPv4                        IPv4                  22
      IPv4      IPv4                        IPv6                  34
      IPv6      IPv6                        IPv4                  46
      IPv6      IPv6                        IPv6                  58
 Usage of Selective Tree A-D routes is described in the "Optimizing
 Multicast Distribution via Selective Trees" section.

9.2.2. Leaf A-D Route

 The Route Type specific field of MCAST-VPLS NLRI of a leaf A-D route
 consists of the following:
              +-----------------------------------+
              |      Route Key (variable)         |
              +-----------------------------------+
              |   Originating Router's IP Addr    |
              +-----------------------------------+
 Whether the Originating Router's IP Address field carries an IPv4 or
 IPv6 address is determined by the Length field of the MCAST-VPLS NLRI
 and the length of the Route Key field.  From these two length fields,
 one can compute the length of the Originating Router's IP Address.
 If this computed length is 4, then the address is an IPv4 address; if
 its 16, then the address is an IPv6 address.
 Usage of leaf A-D routes is described in the "Inter-AS Inclusive
 P-Multicast Tree A-D/Binding" and "Optimizing Multicast Distribution
 via Selective Trees" sections.

10. Aggregation Considerations

 This document does not specify the mandatory implementation of any
 particular set of rules for determining whether or not the Inclusive
 or Selective trees of two particular VPLS instances are to be
 instantiated by the same Aggregate Inclusive/Selective tree.  This
 determination can be made by implementation-specific heuristics, by
 configuration, or even perhaps by the use of offline tools.
 This section discusses potential methodologies with respect to
 aggregation.

Aggarwal, et al. Standards Track [Page 41] RFC 7117 Multicast in VPLS February 2014

 In general, the heuristic used to decide which VPLS instances or
 <C-S, C-G> entries to aggregate is implementation dependent.  It is
 also conceivable that offline tools can be used for this purpose.
 This section discusses some trade-offs with respect to aggregation.
 The "congruency" of aggregation is defined by the amount of overlap
 in the leaves of the client trees that are aggregated on an SP tree.
 For Aggregate Inclusive trees, the congruency depends on the overlap
 in the membership of the VPLS instances that are aggregated on the
 Aggregate Inclusive tree.  If there is complete overlap, aggregation
 is perfectly congruent.  As the overlap between the VPLS instances
 that are aggregated reduces, the congruency reduces.
 From the above definition of "congruency", it follows that in order
 for a given PE to determine the congruency of the client trees that
 this PE could aggregate, the PE has to know the leaves of these
 client trees.  This is irrespective of whether the aggregated SP tree
 is established using mLDP or RSVP-TE.
 If aggregation is done such that it is not perfectly congruent, a PE
 may receive traffic for VPLS instances to which it doesn't belong.
 As the amount of multicast traffic in these unwanted VPLS instances
 increases, aggregation becomes less optimal with respect to delivered
 traffic.  Hence, there is a trade-off between reducing multicast
 state in the core and delivering unwanted traffic.
 An implementation should provide knobs to control aggregation based
 on the congruency of the tree to be aggregated.  This will allow an
 SP to deploy aggregation depending on the VPLS membership and traffic
 profiles in its network.  If different PEs are setting up Aggregate
 Inclusive trees, this will also allow an SP to engineer the maximum
 amount of unwanted VPLS instances for which a particular PE may
 receive traffic.
 The state/bandwidth optimality trade-off can be further improved by
 having a versatile many-to-many association between client trees and
 provider trees.  Thus, a VPLS instance can be mapped to multiple
 Aggregate trees.  The mechanisms for achieving this are for further
 study.  Also, it may be possible to use both ingress replication and
 an Aggregate tree for a particular VPLS.  Mechanisms for achieving
 this are also for further study.

Aggarwal, et al. Standards Track [Page 42] RFC 7117 Multicast in VPLS February 2014

11. Data Forwarding

11.1. MPLS Tree Encapsulation

11.1.1. Mapping Multiple VPLS Instances to a P2MP LSP

 The following diagram shows the progression of the VPLS multicast
 packet as it enters and leaves the SP network when MPLS trees are
 being used for multiple VPLS instances.  RSVP-TE P2MP LSPs are
 examples of such trees.
    Packets received        Packets in transit      Packets forwarded
    at ingress PE           in the service          by egress PEs
                            provider network
                            +---------------+
                            |MPLS Tree Label|
                            +---------------+
                            | VPLS Label    |
    ++=============++       ++=============++       ++=============++
    ||C-Ether Hdr  ||       || C-Ether Hdr ||       || C-Ether Hdr ||
    ++=============++ >>>>> ++=============++ >>>>> ++=============++
    || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
    ++=============++ >>>>> ++=============++ >>>>> ++=============++
    || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
    ++=============++       ++=============++       ++=============++
 When an ingress PE receives a packet, the ingress PE using the
 procedures defined in [RFC4761] and [RFC4762] determines the VPLS
 instance associated with the packet.  If the packet is an IP
 multicast packet, and the ingress PE uses an Aggregate Selective tree
 for the (C-S, C-G) carried in the packet, then the ingress PE pushes
 the VPLS Label associated with the VPLS instance on the ingress PE
 and the MPLS Tree Label associated with the Aggregate Selective tree,
 and it sends the packet over the P2MP LSP associated with the
 Aggregate Selective tree.  Otherwise, if the ingress PE does not use
 an Aggregate Selective tree for the (C-S, C-G), or the packet is
 either non-IP multicast or broadcast, the ingress PE pushes the VPLS
 label associated with the VPLS instance on the ingress PE and the
 MPLS Tree Label associated with the Aggregate Inclusive tree, and it
 sends the packet over the P2MP LSP associated with the Aggregate
 Inclusive tree.
 The egress PE does a lookup on the outer MPLS tree label, and
 determines the MPLS forwarding table in which to look up the inner
 MPLS label (VPLS label).  This table is specific to the tree label
 space (as identified by the MPLS Tree Label).  The inner label (VPLS
 label) is unique within the context of the root of the tree (as it is

Aggarwal, et al. Standards Track [Page 43] RFC 7117 Multicast in VPLS February 2014

 assigned by the root of the tree, without any coordination with any
 other nodes).  Thus, it is not unique across multiple roots.  So, to
 unambiguously identify a particular VPLS, one has to know the VPLS
 label, and the context within which that label is unique.  The
 context is provided by the outer MPLS label (MPLS Tree Label)
 [RFC5331].
 The outer MPLS label is popped.  The lookup of the resulting MPLS
 label determines the VSI in which the egress PE needs to do the
 C-multicast data packet lookup.  It then pops the inner MPLS label
 and sends the packet to the VSI for multicast data forwarding.

11.1.2. Mapping One VPLS Instance to a P2MP LSP

 The following diagram shows the progression of the VPLS multicast
 packet as it enters and leaves the SP network when a given MPLS tree
 is being used for a single VPLS instance.  RSVP-TE P2MP LSPs are
 examples of such trees.
    Packets received        Packets in transit      Packets forwarded
    at ingress PE           in the service          by egress PEs
                            provider network
                            +---------------+
                            |MPLS Tree Label|
    ++=============++       ++=============++       ++=============++
    ||C-Ether Hdr  ||       || C-Ether Hdr ||       || C-Ether Hdr ||
    ++=============++ >>>>> ++=============++ >>>>> ++=============++
    || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
    ++=============++ >>>>> ++=============++ >>>>> ++=============++
    || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
    ++=============++       ++=============++       ++=============++
 When an ingress PE receives a packet, the ingress PE using the
 procedures defined in [RFC4761] and [RFC4762] determines the VPLS
 instance associated with the packet.  If the packet is an IP
 multicast packet, and the ingress PE uses a Selective tree for the
 (C-S, C-G) carried in the packet, then the ingress PE pushes the MPLS
 Tree Label associated with the Selective tree, and it sends the
 packet over the P2MP LSP associated with the Selective tree.
 Otherwise, if the ingress PE does not use a Selective tree for the
 (C-S, C-G), or the packet is either non-IP multicast or broadcast,
 the ingress PE pushes the MPLS Tree Label associated with the
 Inclusive tree, and it sends the packet over the P2MP LSP associated
 with the Inclusive tree.

Aggarwal, et al. Standards Track [Page 44] RFC 7117 Multicast in VPLS February 2014

 The egress PE does a lookup on the MPLS tree label and determines the
 VSI in which the receiver PE needs to do the C-multicast data packet
 lookup.  It then pops the MPLS label and sends the packet to the VSI
 for multicast data forwarding.

12. VPLS Data Packet Treatment

 If the destination MAC address of a VPLS packet received by an
 ingress PE from a VPLS site is a multicast address, a P-multicast
 tree SHOULD be used to transport the packet, if possible.  If the
 packet is an IP multicast packet and a Selective tree exists for that
 multicast stream, the Selective tree MUST be used.  Else, if a
 (C-*, C-*) Selective tree exists for the VPLS it SHOULD be used.
 Else, if an Inclusive tree exists for the VPLS, it SHOULD be used.
 If the destination MAC address of a VPLS packet is a broadcast
 address, it is flooded.  If a (C-*, C-*) Selective tree exists for
 the VPLS, the PE SHOULD flood over it.  Else, if an Inclusive tree
 exists for the VPLS, the PE SHOULD flood over it.  Else, the PE MUST
 flood the packet using the procedures in [RFC4761] or [RFC4762].
 If the destination MAC address of a packet is a unicast address and
 it has not been learned, the packet MUST be sent to all PEs in the
 VPLS.  Inclusive P-multicast trees or a Selective P-multicast tree
 bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC
 packets to all PEs.  When this is the case, the receiving PEs MUST
 support the ability to perform MAC address learning for packets
 received on a multicast tree.  In order to perform such learning, the
 receiver PE MUST be able to determine the sender PE when a VPLS
 packet is received on a P-multicast tree.  This further implies that
 the MPLS P-multicast tree technology MUST allow the egress PE to
 determine the sender PE from the received MPLS packet.
 When a receiver PE receives a VPLS packet with a source MAC address,
 which has not yet been learned, on a P-multicast tree, the receiver
 PE determines the PW to the sender PE.  The receiver PE then creates
 forwarding state in the VPLS instance with a destination MAC address
 being the same as the source MAC address being learned, and the PW
 being the PW to the sender PE.
 It should be noted that when a sender PE that is sending packets
 destined to an unknown unicast MAC address over a P-multicast tree
 learns the PW to use for forwarding packets destined to this unicast
 MAC address, it might immediately switch to transport such packets
 over this particular PW.  Since the packets were initially being
 forwarded using a P-multicast tree, this could lead to packet

Aggarwal, et al. Standards Track [Page 45] RFC 7117 Multicast in VPLS February 2014

 reordering.  This constraint should be taken into consideration if
 unknown unicast frames are forwarded using a P-multicast tree,
 instead of multiple PWs based on [RFC4761] or [RFC4762].
 An implementation SHOULD support the ability to transport unknown
 unicast traffic over Inclusive P-multicast trees.  Furthermore, an
 implementation MUST support the ability to perform MAC address
 learning for packets received on a P-multicast tree.

13. Security Considerations

 Security considerations discussed in [RFC4761] and [RFC4762] apply to
 this document.  This section describes additional considerations.
 As mentioned in [RFC4761], there are two aspects to achieving data
 privacy and protecting against denial-of-service attacks in a VPLS:
 securing the control plane and protecting the forwarding path.
 Compromise of the control plane could result in a PE sending
 multicast data belonging to some VPLS to another VPLS, or black-
 holing VPLS multicast data, or even sending it to an eavesdropper;
 none of which are acceptable from a data privacy point of view.  In
 addition, compromise of the control plane could result in black-
 holing VPLS multicast data and could provide opportunities for
 unauthorized VPLS multicast usage (e.g., exploiting traffic
 replication within a multicast tree to amplify a denial-of-service
 attack based on sending large amounts of traffic).
 The mechanisms in this document use BGP for the control plane.
 Hence, techniques such as in [RFC5925] help authenticate BGP
 messages, making it harder to spoof updates (which can be used to
 divert VPLS traffic to the wrong VPLS) or withdrawals (denial-of-
 service attacks).  In the multi-AS methods (b) and (c) described in
 the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section, this
 also means protecting the inter-AS BGP sessions, between the ASBRs,
 the PEs, or the Route Reflectors.
 Note that [RFC5925] will not help in keeping MPLS labels, associated
 with P2MP LSPs or the upstream MPLS labels used for aggregation,
 private -- knowing the labels, one can eavesdrop on VPLS traffic.
 However, this requires access to the data path within an SP network,
 which is assumed to be composed of trusted nodes/links.
 One of the requirements for protecting the data plane is that the
 MPLS labels be accepted only from valid interfaces.  This applies
 both to MPLS labels associated with P2MP LSPs and to the upstream-
 assigned MPLS labels.  For a PE, valid interfaces comprise links from
 other routers in the PE's own AS.  For an ASBR, valid interfaces
 comprise links from other routers in the ASBR's own AS, and links

Aggarwal, et al. Standards Track [Page 46] RFC 7117 Multicast in VPLS February 2014

 from other ASBRs in ASes that have instances of a given VPLS.  It is
 especially important in the case of multi-AS VPLS instances that one
 accept VPLS packets only from valid interfaces.

14. IANA Considerations

 This document defines a new NLRI, called "MCAST-VPLS", to be carried
 in BGP using multiprotocol extensions.  IANA has assigned it a SAFI
 value of 8.
 This document defines a BGP-optional transitive attribute called
 "PMSI_TUNNEL".  This is the same attribute as the one defined in
 [RFC6514] and the code point for this attribute has already been
 assigned by IANA as 22 [BGP-IANA].  Hence, no further action is
 required from IANA regarding this attribute.

15. References

15.1. Normative References

 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.
 [RFC4760]   Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
             "Multiprotocol Extensions for BGP-4", RFC 4760, January
             2007.
 [RFC4761]   Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
             LAN Service (VPLS) Using BGP for Auto-Discovery and
             Signaling", RFC 4761, January 2007.
 [RFC4762]   Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
             LAN Service (VPLS) Using Label Distribution Protocol
             (LDP) Signaling", RFC 4762, January 2007.
 [RFC5036]   Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
             "LDP Specification", RFC 5036, October 2007.
 [RFC5331]   Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
             Label Assignment and Context-Specific Label Space", RFC
             5331, August 2008.

Aggarwal, et al. Standards Track [Page 47] RFC 7117 Multicast in VPLS February 2014

 [RFC6511]   Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
             Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
             Label Switched Paths", RFC 6511, February 2012.
 [RFC6512]   Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
             "Using Multipoint LDP When the Backbone Has No Route to
             the Root", RFC 6512, February 2012.

15.2. Informative References

 [RFC6514]   Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
             Encodings and Procedures for Multicast in MPLS/BGP IP
             VPNs", RFC 6514, February 2012.
 [RFC6513]   Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
             MPLS/BGP IP VPNs", RFC 6513, February 2012.
 [RFC6388]   Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
             Thomas, "Label Distribution Protocol Extensions for
             Point-to-Multipoint and Multipoint-to-Multipoint Label
             Switched Paths", RFC 6388, November 2011.
 [RFC6074]   Rosen, E., Davie, B., Radoaca, V., and W. Luo,
             "Provisioning, Auto-Discovery, and Signaling in Layer 2
             Virtual Private Networks (L2VPNs)", RFC 6074, January
             2011.
 [RFC5925]   Touch, J., Mankin, A., and R. Bonica, "The TCP
             Authentication Option", RFC 5925, June 2010.
 [RFC5501]   Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L.
             Fang, "Requirements for Multicast Support in Virtual
             Private LAN Services", RFC 5501, March 2009.
 [RFC5332]   Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
             "MPLS Multicast Encapsulations", RFC 5332, August 2008.
 [RFC4684]   Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
             R., Patel, K., and J. Guichard, "Constrained Route
             Distribution for Border Gateway Protocol/MultiProtocol
             Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
             Private Networks (VPNs)", RFC 4684, November 2006.
 [RFC4875]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
             Yasukawa, Ed., "Extensions to Resource Reservation
             Protocol - Traffic Engineering (RSVP-TE) for Point-to-
             Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
             2007.

Aggarwal, et al. Standards Track [Page 48] RFC 7117 Multicast in VPLS February 2014

 [RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
             "Protocol Independent Multicast - Sparse Mode (PIM-SM):
             Protocol Specification (Revised)", RFC 4601, August 2006.
 [RFC4541]   Christensen, M., Kimball, K., and F. Solensky,
             "Considerations for Internet Group Management Protocol
             (IGMP) and Multicast Listener Discovery (MLD) Snooping
             Switches", RFC 4541, May 2006.
 [RFC4447]   Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
             G. Heron, "Pseudowire Setup and Maintenance Using the
             Label Distribution Protocol (LDP)", RFC 4447, April 2006.
 [RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", RFC 4364, February 2006.
 [RFC3810]   Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
             Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June
             2004.
 [RFC3376]   Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
             Thyagarajan, "Internet Group Management Protocol, Version
             3", RFC 3376, October 2002.
 [RFC2710]   Deering, S., Fenner, W., and B. Haberman, "Multicast
             Listener Discovery (MLD) for IPv6", RFC 2710, October
             1999.
 [RFC2236]   Fenner, W., "Internet Group Management Protocol, Version
             2", RFC 2236, November 1997.
 [RFC1997]   Chandra, R., Traina, P., and T. Li, "BGP Communities
             Attribute", RFC 1997, August 1996.
 [MULTI-HOMING]
             Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
             Uttaro, J., Palislamovic, S., and W. Lin, "BGP based
             Multi-homing in Virtual Private LAN Service", Work in
             Progress, July 2013.
 [BGP-IANA]  IANA, "Border Gateway Protocol (BGP) Parameters",
             <http://www.iana.org/assignments/bgp-parameters>.

Aggarwal, et al. Standards Track [Page 49] RFC 7117 Multicast in VPLS February 2014

16. Acknowledgments

 Many thanks to Thomas Morin for his support of this work.
 We would also like to thank authors of [RFC6514] and [RFC6513], as
 the details of the inter-AS segmented tree procedures in this
 document, as well as some text that describes these procedures have
 benefited from those in [RFC6514] and [RFC6513].  The same applies to
 the notion of Inclusive and Selective trees, as well as the
 procedures for switching from Inclusive to Selective trees.
 We would also like to thank Nabil Bitar, Stewart Bryant, Wim
 Henderickx, and Eric Rosen for their review and comments.

Authors' Addresses

 Rahul Aggarwal
 998 Lucky Avenue
 Menlo Park, CA 94025
 USA
 Phone: +1-415-806-5527
 EMail: raggarwa_1@yahoo.com
 Yuji Kamite
 NTT Communications Corporation
 Granpark Tower
 3-4-1 Shibaura, Minato-ku
 Tokyo  108-8118
 Japan
 EMail: y.kamite@ntt.com
 Luyuan Fang
 Microsoft
 EMail: lufang@microsoft.com
 Yakov Rekhter
 Juniper Networks
 1194 North Mathilda Ave.
 Sunnyvale, CA 94089
 USA
 EMail: yakov@juniper.net
 Chaitanya Kodeboniya
 EMail: chaitk@yahoo.com

Aggarwal, et al. Standards Track [Page 50]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7117.txt · Last modified: 2014/02/11 21:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki