[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-serbest-l2vpn-vpls-mcast) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 7117

Network Working Group                               R. Aggarwal (Editor)
Internet Draft                                          Juniper Networks
Expiration Date: May 20, 2008
                                                               Y. Kamite
                                                      NTT Communications

                                                                 L. Fang
                                                      Cisco Systems, Inc

                                                       November 17, 2007


                           Multicast in VPLS


                   draft-ietf-l2vpn-vpls-mcast-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes a solution for overcoming a subset of the
   limitations of existing VPLS multicast solutions. It describes
   procedures for VPLS multicast that utilize multicast trees in the
   sevice provider (SP) network.  One such multicast tree can be shared
   between multiple VPLS instances.  Procedures by which a single
   multicast tree in the backbone can be used to carry traffic belonging



Raggarwa, Kamite & Fang                                         [Page 1]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   only to a specified set of one or more IP multicast streams from one
   or more VPLSs are also described.

















































Raggarwa, Kamite & Fang                                         [Page 2]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


Table of Contents

 1          Specification of requirements  .........................   4
 2          Contributors  ..........................................   4
 3          Terminology  ...........................................   5
 4          Introduction  ..........................................   5
 5          Existing Limitations of VPLS Multicast  ................   5
 6          Overview  ..............................................   6
 6.1        Inclusive and Selective Multicast Trees  ...............   6
 6.2        BGP-Based VPLS Membership Auto-Discovery  ..............   7
 6.3        IP Multicast Group Membership Discovery  ...............   7
 6.4        Advertising P-Tree to VPLS / C-Multicast Binding  ......   8
 6.5        Aggregation  ...........................................   8
 6.6        Inter-AS VPLS Multicast  ...............................   9
 7          VPLS Multicast/Broadcast/Unknown Unicast Data Packet Treatment  10
 8          Intra-AS Inclusive Multicast Tree Auto-Discovery/Binding  ..11
 8.1        Originating (intra-AS) auto-discovery routes  ..........  12
 8.2        Receiving (intra-AS) auto-discovery routes  ............  13
 9          Demultiplexing Multicast Tree Traffic  .................  14
 9.1        One Multicast Tree - One VPLS Mapping  .................  14
 9.1.1      One Multicast Tree - Many VPLS Mapping  ................  14
10          Establishing Multicast Trees  ..........................  15
10.1        RSVP-TE P2MP LSPs  .....................................  15
10.1.1      P2MP TE LSP - VPLS Mapping  ............................  15
10.1.2      Demultiplexing C-Multicast Data Packets  ...............  16
10.2        Receiver Initiated MPLS Trees  .........................  16
10.2.1      P2MP LSP - VPLS Mapping  ...............................  17
10.2.2      Demultiplexing C-Multicast Data Packets  ...............  17
10.3        Encapsulation of the Aggregate Inclusive and Selective Tree  17
11          Inter-AS Inclusive Multicast Tree Auto-Discovery/Binding  ..17
11.1        VSIs on the ASBRs  .....................................  18
11.1.0.1    VPLS Inter-AS Auto-Discovery Binding  ..................  18
11.2        Option (b) - Segmented Inter-AS Trees  .................  19
11.2.1      Segmented Inter-AS Trees VPLS Inter-AS Auto-Discovery/Binding  19
11.2.2      Propagating VPLS BGP Auto-Discovery routes to other ASes - Overview  20
11.2.2.1    Propagating Intra-AS VPLS Auto-Discovery routes in E-BGP  ..21
11.2.2.2    Auto-Discovery route received via E-BGP  ...............  22
11.2.2.3    Leaf Auto-Discovery Route received via E-BGP  ..........  24
11.2.2.4    Inter-AS Auto-Discovery Route received via I-BGP  ......  24
11.3        Option (c)  ............................................  25
12          Optimizing Multicast Distribution via Selective Trees  .  26
12.1        Protocol for Switching to Selective Trees  .............  27
12.2        Advertising C-(S, G) Binding to a Selective Tree using BGP  28



Raggarwa, Kamite & Fang                                         [Page 3]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


12.2.1      Explicit Tracking  .....................................  29
12.3        Inter-AS Selective Tree  ...............................  29
12.3.1      VSIs on the ASBRs  .....................................  30
12.3.1.1    VPLS Inter-AS Selective Tree Auto-Discovery Binding  ...  30
12.3.2      Inter-AS Segmented Selective Trees  ....................  30
12.3.3      Inter-AS Non-Segmented Selective Trees  ................  32
13          BGP Extensions  ........................................  32
13.1        Inclusive Tree/Selective Tree Identifier  ..............  32
13.2        MCAST-VPLS NLRI  .......................................  33
13.2.1      Selective Tree auto-discovery route  ...................  34
13.2.2      Leaf auto-discovery route  .............................  35
14          Aggregation Methodology  ...............................  35
15          Data Forwarding  .......................................  36
15.1        MPLS Tree Encapsulation  ...............................  36
16          Security Considerations  ...............................  37
17          IANA Considerations  ...................................  38
18          Acknowledgments  .......................................  38
19          Normative References  ..................................  38
20          Informative References  ................................  39
21          Author's Address  ......................................  40
22          Intellectual Property Statement  .......................  40
23          Full Copyright Statement  ..............................  41






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


2. Contributors

   Rahul Aggarwal
   Yakov Rekhter
   Juniper Networks
   Yuji Kamite
   NTT Communications
   Luyuan Fang
   AT&T
   Chaitanya Kodeboniya






Raggarwa, Kamite & Fang                                         [Page 4]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


3. Terminology

   This document uses terminology described in [RFC4761] and [RFC4762].


4. Introduction

   [RFC4761] and [RFC4762] describe a solution for VPLS multicast that
   relies on ingress replication. This solution has certain limitations
   for certain VPLS multicast traffic profiles.

   This document describes procedures for overcoming the limitations of
   existing VPLS multicast solutions. It describes procedures for VPLS
   multicast that utilize multicast trees in the Sevice Provider (SP)
   network. The procedures described in this document are applicable to
   both [RFC4761] and [RFC4762].

   It provides mechanisms that allow a single multicast distribution
   tree in the backbone to carry all the multicast traffic from a
   specified set of one or more VPLSs. Such a tree is referred to as an
   "Inclusive Tree" and more specifically as an "Aggregate Inclusive
   Tree" when the tree is used to carry multicast traffic from more than
   one VPLS.

   This document also provides procedures by which a single multicast
   distribution tree in the backbone can be used to carry traffic
   belonging only to a specified set of one or more IP multicast
   streams, from one or more VPLSs. Such a tree is referred to as a
   "Selective Tree" and more specifically as an "Aggregate Selective
   Tree" when the IP multicast streams belong to different VPLSs. So
   traffic from most multicast streams could be carried by an Inclusive
   Tree, while traffic from, e.g., high bandwidth streams could be
   carried in one of the "Selective Trees".


5. Existing Limitations of VPLS Multicast

   One of the limitations of existing VPLS multicast solutions described
   in [RFC4761] and [RFC4762] is that they rely on ingress replication.
   Thus the ingress PE replicates the multicast packet for each egress
   PE and sends it to the egress PE using a unicast tunnel.

   This is a reasonable model when the bandwidth of the multicast
   traffic is low or/and the number of replications performed on an
   average on each outgoing interface for a particular customer VPLS
   multicast packet is small. If this is not the case it is desirable to
   utilize multicast trees in the SP network to transmit VPLS multicast
   packets [MCAST-VPLS-REQ]. Note that unicast packets that are flooded



Raggarwa, Kamite & Fang                                         [Page 5]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   to each of the egress PEs, before the ingress PE performs learning
   for those unicast packets, MAY still use ingress replication.


6. Overview

   This document describes procedures for using multicast trees in the
   SP network to transport VPLS multicast data packets. RSVP-TE P2MP
   LSPs described in [RFC4875] are an example of such multicast trees.
   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 by the ingress. This comes at a cost of state in the SP
   network to build multicast trees and overhead to maintain this state.
   This document describes procedures for using multicast trees for VPLS
   multicast when the provider tunneling technology is either P2MP RSVP-
   PE or mLDP [MLDP]. The protocol architecture described herein is
   considered to be flexible to support other P-tunneling technologies
   as well.

   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, group tuple is abbreviated to (S,
   G).


6.1. Inclusive and Selective Multicast Trees

   Multicast trees used for VPLS can be of two types:

       1. Inclusive Trees. A single multicast distribution tree in the
   SP network is used to carry all the multicast traffic from a
   specified set of one or more VPLSs. A particular multicast
   distribution tree can be set up to carry the traffic of a single
   VPLS, or to carry the traffic of multiple VPLSs. The ability to carry
   the traffic of more than one VPLS on the same tree is termed
   'Aggregation'. The tree will include every PE that is a member of any
   of the VPLSs 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 on the path of that stream.

   An Inclusive tree as defined in this document is a source tree. A
   source tree is used to carry traffic only for VPLS sites that are
   connected to the PE that is the root.

       2. Selective Trees. A Selective Tree is used by a PE to send IP
   multicast traffic for one or more multicast streams, that belong to
   the same or different VPLSs, to a subset of the PEs that belong to



Raggarwa, Kamite & Fang                                         [Page 6]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   those VPLSs. 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. The ability to use the same tree for multicast streams that
   belong to different VPLSs is termed have the ability to create
   separate SP multicast trees for high bandwidth multicast groups. This
   allows traffic for these multicast groups to reach only those PE
   routers that have receivers in these groups. This avoids flooding
   other PE routers in the VPLS.

   A SP can use both Inclusive Trees and Selective Trees or either of
   them for a given VPLS on a PE, based on local configuration.
   Inclusive Trees can be used for both IP and non-IP data multicast
   traffic, while Selective Trees can be used only for IP multicast data
   traffic.

   A variety of transport technologies may be used in the backbone. For
   inclusive trees, these transport technologies include point-to-
   multipoint LSPs created by RSVP-TE or mLDP. For selective trees, only
   unicast PE-PE tunnels (using MPLS or IP/GRE encapsulation) and
   unidirectional single-source trees are supported, and the supported
   tree signaling protocols are RSVP-TE, and mLDP.

   This document also describes the data plane encapsulations for
   supporting the various SP multicast transport options.


6.2. BGP-Based VPLS Membership Auto-Discovery

   In order to establish Inclusive P-trees for one or more VPLSs, when
   Aggregation is performed or when the tunneling technology is P2MP
   RSVP-TE, the root of the tree must be able to discover the other PEs
   that have membership in one or more of these VPLSs. This document
   uses the BGP-based procedures described in [RFC4761] and [L2VPN-SIG]
   for discovering the VPLS membership of all PEs.


6.3. IP Multicast Group Membership Discovery

   The setup of a Selective P-tree for one or more IP multicast (S, G)s,
   when aggregation is used or when the tunneling technology is P2MP
   RSVP-TE, requires the ingress PE to learn the PEs that have receivers
   in one or more of these (S, G)s. For discovering the IP multicast
   group membership, procedures described in [VPLS-CTRL] should be used.
   Procedures in [VPLS-CTRL] can also be used with ingress replication
   to send traffic for an IP multicast stream to only those PEs that are
   on the path to receivers for that stream.





Raggarwa, Kamite & Fang                                         [Page 7]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


6.4. Advertising P-Tree to VPLS / C-Multicast Binding

   This document also describes procedures based on BGP VPLS Auto-
   Discovery that are used by the root of an Aggregate Tree to advertise
   the Inclusive or Selective tree binding and the de-multiplexing
   information to the leaves of the tree. A new BGP attribute called the
   PMSI Tunnel Attribute is introduced for this purpose.

   Once a PE decides to bind a set of VPLSes or customer multicast
   groups to an Inclusive Tree or a Selective Tree, it needs to announce
   this binding to other PEs in the network. This procedure is referred
   to as Inclusive Tree or Selective Tree binding distribution and is
   performed using BGP.

   For an Inclusive Tree this discovery implies announcing the binding
   of all VPLSs bound to the Inclusive Tree. The inner label assigned by
   the ingress PE for each VPLS MUST be included, if more than one VPLS
   is bound to the same tree. The Inclusive Tree Identifier MUST be
   included.

   For a Selective Tree this discovery implies announcing all the
   specific <C-Source, C-Group> entries bound to this tree along with
   the Selective Tree Identifier. The inner label assigned for each <C-
   Source, C-Group> MUST be included if <C-Source, C-Group>s from
   different VPLSes are bound to the same tree. The labels MUST be
   distinct on a per VPLS basis and MAY be distinct on a per <C-Source,
   C-Group> basis. The Selective Tree Identifier MUST be included.


6.5. Aggregation

   As described above the ability to carry the traffic of more than one
   VPLS on the same tree is termed 'Aggregation'. Both Inclusive and
   Selective trees support aggregation.

   Aggregation enables the SP to place a bound on the amount of
   multicast tree forwarding and control plane state which the P routers
   must have.  Let us call the number of VPLSes aggregated onto a single
   P-tree as the "Aggregation Factor". When Inclusive source trees are
   used the number of trees that a PE is the root of is proportional to:

     + (Number of VPLSes on the PE / Aggregation Factor).


   In this case the state maintained by P routers is proportional to:






Raggarwa, Kamite & Fang                                         [Page 8]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


     + (Average number of VPLSes on a PE / Aggregation Factor) * number
       of PEs


   Thus the state does not grow linearly with the number of VPLSes.

   Aggregation requires a mechanism for the egresses of the tree to
   demultiplex the multicast traffic received over the tree. This
   document describes how upstream-assigned labels can be assigned and
   distributed by the root of aggregate tree and then used by the
   egresses to perform this demultiplexing.


6.6. Inter-AS VPLS Multicast

   This document supports three models of inter-AS VPLS service, option
   (a), (b) and (c) which are very similar conceptually to option (a),
   (b) and (c) specified in [RFC4364] for IP VPNs. The three options
   described here are also similar to the three options described in in
   [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.

   In the first variant, the Autonomous System Border Routers (ASBRs)
   perform a MAC lookup, in addition to any MPLS lookups, to determine
   the forwarding decision on a VPLS packet. In this variant the
   multicast trees are confined to an AS. Hence each AS may use a
   different P-tunneling technology. 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 VPLS
   Switching Instance (VSI) for the VPLS. This variant is applicable to
   option (a). In the case of option (a) an ASBR in one AS treats an
   adjoining ASBR in another AS as a CE and determines the VSI for
   packets received from another ASBR based on the incoming ethernet
   interface. It is possible to extend this model by using a PW, per
   VPLS instance, to interconnect the adjoining ASBRs.

   In the second variant, an inter-AS 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 Autonomous
   System Border Routers (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 variant, an ASBR is
   not required to keep a a VSI for the VPLS and is not required to



Raggarwa, Kamite & Fang                                         [Page 9]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   perform a MAC lookup in order to forward the VPLS packet. This
   variant is applicable to option (b) as in the case of option (b) the
   BGP-VPLS NLRIs or Auto-Discovery routes are redistributed by the
   ASBRs.

   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 ASs. This is because in the case of option (c) the
   ASBRs do not exchange BGP-VPLS NLRIs or Auto-Discovery routes.


7. VPLS Multicast/Broadcast/Unknown Unicast Data Packet Treatment

   If the destination MAC address of a VPLS packet received by a PE from
   a VPLS site is a multicast adddress, a 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 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 Inclusive tree is already established, PE
   SHOULD flood over it. If Inclusive Tree cannot be used for some
   reason, PE MUST flood over multiple PWs, based on [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 multicast trees 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 multicast tree.  This further
   implies that the MPLS 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,
   that has not yet been learned, on a 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 multicast tree
   learns the PW to use for forwarding packets destined to this unicast
   MAC address, it might immediately switch to transport such packets



Raggarwa, Kamite & Fang                                        [Page 10]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   over this particular PW. Since the packets were initially being
   forwarded using a multicast tree, this could lead to packet
   reordering. This constraint should be taken into consideration if
   unknown unicast frames are forwarded using a Inclusive Tree, instead
   of multiple PWs based on [RFC4761] or [RFC4762].

   An implementation MUST support the ability to transport unknown
   unicast traffic over Inclusive multicast trees. Further an
   implementation MUST support the ability to perform MAC address
   learning for packets received on a multicast tree.


8. Intra-AS Inclusive Multicast Tree Auto-Discovery/Binding

   This section specifies procedures for the intra-AS auto-discovery (A-
   D) 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
   section 11.

   VPLS auto-discovery using BGP as described in [RFC4761, L2VPN-SIG]
   enables a PE to learn the VPLS membership of other PEs. A PE that
   belongs to a particular VPLS announces a BGP Network Layer
   Reachability Information (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 PW signaling. The VE-ID in this case is a two octet
   number. While the NLRI defined in [L2VPN-SIG] comprises only the <RD,
   VE-ID> where the VE-ID is a four octet number.

   The procedures for constructing Inclusive intra-AS and inter-AS trees
   as specified in this document require the BGP Auto-Discovery NLRI to
   carry only the <RD, VE-ID>. Hence these procedures can be used for
   both BGP-VPLS and LDP-VPLS with BGP Auto-Discovery.












Raggarwa, Kamite & Fang                                        [Page 11]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


8.1. Originating (intra-AS) auto-discovery routes

   To participate in the VPLS auto-discovery/binding a PE router that
   has a given VSI of a given VPLS originates an auto-discovery route
   and advertises this route in I-BGP. The route is constructed as
   described in [RFC4761] and [L2VPN-SIG].

   The route carries a single L2VPN NLRI with the RD set to the RD of
   the VSI, and the VE-ID set to the VE-ID of the VSI.

   If a P-Multicast tree is used to instantiate the provider tunnel for
   VPLS multicast on the PE, and either (a) this tree exists at the time
   of discovery, or (b) the PE doesn't need to know the leaves of the
   tree before hand in order to advertise the P-Multicast tree
   identifier, then the advertising PE MUST advertise the type and the
   identity of the P-Multicast tree in a new BGP attribute called the
   the PMSI Tunnel attribute. This attribute is described in section
   13.1.

   If a P-Multicast tree is used to instantiate the provider tunnel for
   VPLS multicast on the PE, and in order to advertise the P-Multicast
   tree identifier the advertising PE needs to know the leaves of the
   tree beforehand, then the PE obtains this information from the intra-
   AS auto-discovery routes received from other PEs. Once the PE obtains
   the information about the leaves (this information is obtained from
   the auto-discovery routes received by the PE), the PE then advertises
   the binding of the tree to the VPLS using the same route as the one
   used for the auto-discovery, with the addition of carrying in the
   route the PMSI Tunnel attribute that contains the type and the
   identity of the P-Multicast tree. If at some later point a new PE
   advertises participation in the same VPLS, the initial binding P-
   Tunnel binding information SHOULD NOT change (though the leaves of
   the corresponding P-Multicast tree may change).

   A PE that uses a P-Multicast tree to instantiate the provider tunnel
   MAY aggregate two or more VPLSs present on the PE onto the same tree.
   If the PE already advertises intra-AS auto-discovery routes for these
   VPLSs, 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 intra-AS auto-discovery routes for these VPLSs, then the
   aggregation requires the PE to advertise (new) intra-AS auto-
   discovery routes for these VPLSs.  The P-Tunnel attribute in the
   newly advertised/re-advertised routes MUST carry the identity of the
   P-Multicast tree that aggregates the VPLSs, as well as an MPLS
   upstream-assigned label [MPLS-UPSTREAM]. Each re-advertised route
   MUST have a distinct label.




Raggarwa, Kamite & Fang                                        [Page 12]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   Discovery of PE capabilities in terms of what tunnels 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.


8.2. Receiving (intra-AS) auto-discovery routes

   When a PE receives a BGP Update message that carries an auto-
   discovery 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 Route
   Targets of the route matches one of the import Route Targets
   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 route carries the PMSI Tunnel attribute then:

     + 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 VSI that
       has at least one of its import Route Targets that matches one of
       the Route Targets of the received auto-discovery 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 VSI that has at least one of its
       import Route Target that matches one of the Route Targets of the
       received auto-discovery route.

       Irrespective of whether the route carries the PMSI Tunnel
       attribute, if the local PE uses RSVP-TE P2MP LSP for sending



Raggarwa, Kamite & Fang                                        [Page 13]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


       (multicast) traffic from the VRF to the sites attached to other
       PEs, then the local PE uses the Originating Router's IP address
       information carried in the route to add the PE that originated
       the route as a leaf node to the LSP.


9. Demultiplexing Multicast Tree Traffic

   Demultiplexing received VPLS traffic requires the receiving PE to
   determine the VPLS instance the packet belongs to. 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 section 7.


9.1. One Multicast Tree - One VPLS Mapping

   When a 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, eg:
   RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the
   tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP (RSVP-
   TE P2MP LSP or LDP P2MP LSP).


9.1.1. One Multicast Tree - Many VPLS Mapping

   As traffic belonging to multiple VPLSs can be carried over the same
   tree, there is a need to identify the VPLS the packet belongs to.
   This is done by using an inner label that determines to 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 demultimplex the traffic received
   over the Aggregate Inclusive Tree or the Aggregate Selective Tree. If
   downstream label assignment were used this would require all the
   egress PEs in the VPLS to agree on a common label for the VPLS.

   This document requires the use of upstream label assignment by the
   ingress PE [MPLS-UPSTREAM]. Hence the inner label is assigned by the
   ingress PE. Each egress PE maintains a separate label space for every
   other PE that is the root of an Aggregate Tree. The egress PEs create
   a forwarding entry for the inner VPLS label, assigned by the ingress
   PE, in this label space.  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



Raggarwa, Kamite & Fang                                        [Page 14]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   PE for all P-multicast trees that have the same root [MPLS-UPSTREAM].

   If the tree uses MPLS encapsulation the outer MPLS label and the
   incoming interface provides the label space of the label beneath it.
   This assumes that penultimate-hop-popping is disabled. An example of
   this is RSVP-TE P2MP LSPs.  The outer label and incoming interface
   effectively identifies the Tree [MPLS-UPSTREAM, MPLS-MCAST].

   The ingress PE informs the egress PEs about the inner label as part
   of the tree binding procedures described in section 12.


10. Establishing Multicast Trees

   This document does not place any fundamental restrictions on the
   multicast technology used to setup P-multicast trees. However
   specific procedures are specified currently only for RSVP-TE P2MP
   LSPs and LDP P2MP LSPs. An implementation that supports this document
   MUST support RSVP-TE P2MP LSPs and MAY support LDP P2MP LSPs.

   The P-multicast trees supported in this document are source trees. A
   source tree is used to carry traffic only for the VPLSs that exist
   locally on the root of the tree i.e. for which the root has local
   CEs.


10.1. RSVP-TE P2MP LSPs

   This section describes procedures that are specific to the usage of
   RSVP-TE P2MP LSPs for instantiating a multicast tree. Procedures in
   [RFC4875] are used to signal the P2MP LSP. The LSP is signaled after
   the root of the P2MP LSP discovers the leaves. The egress PEs are
   discovered using the procedures described in section 9. Aggregation
   as described in this document is supported.


10.1.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 the P2MP TE LSP identifier as the
   tunnel identifier in the BGP advertisements. This identifier contains
   the following information elements:
         - The type of the tunnel is set to RSVP-TE P2MP LSP
         - RSVP-TE P2MP LSP's SESSION Object

   This Tunnel Identifier is described in section 13.1.




Raggarwa, Kamite & Fang                                        [Page 15]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


10.1.2. Demultiplexing C-Multicast Data Packets

   Demultiplexing the C-multicast data packets at the egress PE requires
   that the PE must be able to determine the P2MP TE LSP that the
   packets are received on. The egress PE needs to determine the P2MP
   LSP to determine the VPLS that the packet belongs to, as described in
   section 10. To achieve this the LSP MUST be signaled with
   penultimate-hop-popping (PHP) off. 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 that a C-multicast data packet is
   received on.

   The egress PE also needs to identify the ingress PE to perform MAC
   learning.  When P2MP LSPs are used, as source trees, determining the
   P2MP LSP that the packets are received on, 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 TE LSP mapping.

   Once the egress PE receives this mapping:

     + If the egress PE already has RSVP-TE state for the P2MP TE LSP,
       it MUST begin to assign a 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.  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 a 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.


10.2. Receiver Initiated MPLS Trees

   Receiver initiated MPLS trees can also be used. An example of such
   trees are LDP setup P2MP MPLS Trees [MLDP].

   Procedures in [MLDP] are used to signal the LSP. The LSP is signaled
   once the leaves receive the LDP FEC for the tree from the root. The
   egress PEs are discovered using the procedures described in section
   9. Aggregation as described in this document is supported.





Raggarwa, Kamite & Fang                                        [Page 16]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


10.2.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 the P2MP LSP identifier as the tunnel
   identifier in the BGP advertisements. This identifier contains the
   following information elements:
         - The type of the tunnel is set to LDP P2MP LSP
         - LDP P2MP FEC which includes an identifier generated by the
   root.

   Each egress PE "joins" 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 [MLDP].


10.2.2. Demultiplexing C-Multicast Data Packets

   This follows the same procedures described above for RSVP-TE P2MP
   LSPs.


10.3. Encapsulation of the Aggregate Inclusive and Selective Tree

   An Aggregate Inclusive Tree or an Aggregate Selective Tree MUST use a
   MPLS encapsulation. The protocol type in the data link header is as
   described in [MPLS-MCAST].


11. Inter-AS Inclusive Multicast Tree Auto-Discovery/Binding

   This document supports three models of inter-AS VPLS service, option
   (a), (b) and (c) which are very similar conceptually to option (a),
   (b) and (c) specified in [RFC4364] for IP VPNs. The three options
   described here are also similar to the three options described in
   [RFC4761], which in turn extends the concepts of [RFC4364] to inter-
   AS VPLS. An implementation MUST support all three of these models.
   When there are multiple options for implementing one of these models,
   this section specifies which option is mandatory.

   For option (a) and option (b) support 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 requires MAC lookup on the ASBRs and
   another that does not require MAC lookup on the ASBRs and instead
   builds segmented inter-AS trees. This applies to both Inclusive and
   Selective trees.



Raggarwa, Kamite & Fang                                        [Page 17]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   For option (c) support this document specifies a model where Inter-AS
   VPLS service is offered by requiring a single Inclusive P-multicast
   tree to span multiple ASs. 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 Auto-Discovery routes. Selective
   inter-AS trees for option (c) support may be segmented or non-
   segmented.


11.1. VSIs on the ASBRs

   In this variant, the ASBRs MUST perform a MAC lookup, in addition to
   any MPLS lookups, to determine the forwarding decision on a VPLS
   packet. The 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 and MUST be configured with its
   own VE ID for the VPLS. When this variant is used with option (a) an
   ASBR in one AS treats an adjoining ASBR in another AS as a CE and
   determines the VSI for packets received from another ASBR based on
   the incoming ethernet interface.

   An implementation MUST support this variant for option (a).


11.1.0.1. VPLS Inter-AS Auto-Discovery Binding

   In this variant the BGP A-D routes generated by PEs in an AS MUST NOT
   be propagated outside the AS. In the case of option (a) the ASBRs do
   not exchange A-D routes.

   If the interconnect between the ASBRs is a PW, that maps to a VPLS
   instance at the ASBR, then the only 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 multicast trees for a VPLS are confined to each AS and the VPLS
   auto-discovery/binding MUST follow the intra-AS procedures described
   in section 8.











Raggarwa, Kamite & Fang                                        [Page 18]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


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

   In this variant, an inter-AS 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 variant, an ASBR is not required to keep a VSI for the VPLS 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. This variant is applicable to option (b).
   An implementation MUST support this variant.

   The construction of segmented Inter-AS trees requires the BGP-VPLS
   Auto-Discovery NLRI described in [RFC4761, RFC4762]. A BGP-VPLS A-D
   route for a <RD, VE ID> tuple advertised outside the AS, to which the
   originating PE belongs, will be referred to as an inter-AS auto-
   discovery 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 section 13.1. They also require
   additional procedures in BGP to signal leaf A-D routes between ASBRs
   as explained in subsequent sections.


11.2.1. Segmented Inter-AS Trees VPLS Inter-AS Auto-Discovery/Binding

   This section specifies the procedures for inter-AS VPLS Auto-
   Discovery/binding for segmented inter-AS trees.

   An ASBR must be configured to support a particular VPLS as follows:

     + An ASBR MUST be be configured with a set of (import) Route
       Targets (RTs) that specifies the set of VPLSes supported by the
       ASBR. These Route Targets 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) Route
       Targets (RTs) by using Route Target Constrain [RFC4684].


     + The ASBR MUST be configured with the tunnel types for the intra-
       AS segments of the VPLSes 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 auto-discovery routes received by the ASBR from
       the PEs in its own AS.



Raggarwa, Kamite & Fang                                        [Page 19]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   If an ASBR is configured to support a particular VPLS, the ASBR MUST
   participate in the intra-AS VPLS auto-discovery/binding procedures
   for that VPLS within the ASBR's own AS, as defined in this document.

   Moreover, in addition to the above the ASBR performs procedures
   specified in the next section.


11.2.2. Propagating VPLS BGP Auto-Discovery routes to other ASes -
   Overview

   An auto-discovery route for a given VPLS, originated by an ASBR
   within a given AS, is propagated via BGP to other ASes. The precise
   rules for distributing and processing the inter-AS auto-discovery
   routes are given in subsequent sections.

   Suppose that an ASBR A receives and installs an auto-discovery route
   for VPLS "X" and VE ID "V" that originated at a particular PE, PE1.
   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. When the auto-discovery 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
   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 on
   the given auto-discovery route.

   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 which 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, there MUST be only one ASBR that accepts
   traffic into a given AS. Further there MUST be only one ASBR that
   sends traffic from a particular AS on the tree to another adjacent
   AS.  The precise rules for accomplishing this are given in subsequent
   sections.



Raggarwa, Kamite & Fang                                        [Page 20]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   An ASBR initiates creation of an intra-AS segment when the ASBR
   receives an auto-discovery route from an E-BGP neighbor.  Creation of
   the segment is completed as a result of distributing, via I-BGP, 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 VPLSs
   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 auto-discovery
   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
   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 (i.e. same VE-ID) as the one that
   the segment belongs to.

   The following sections specify procedures for propagation of auto-
   discovery routes across ASes in order to construct inter-AS segmented
   trees.


11.2.2.1. Propagating Intra-AS VPLS Auto-Discovery routes in E-BGP

   For a given VPLS configured on an ASBR when the ASBR determines
   (using the intra-AS auto-discovery procedures) that one or more PEs
   of its own AS has (directly) connected site(s) of the VPLS, the ASBR
   MUST originate an BGP VPLS auto-discovery route and advertise it in
   E-BGP. This procedure MUST be performed for each of the VPLSs
   configurd 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 received NLRI.

     + The Next Hop field of the MP_REACH_NLRI attribute is set to a
       routable IP address of the ASBR.





Raggarwa, Kamite & Fang                                        [Page 21]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


     + 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 Route Target used by the VPLS.


11.2.2.2. Auto-Discovery route received via E-BGP

   When an ASBR receives from one of its E-BGP neighbors a BGP Update
   message that carries an auto-discovery route, if (a) at least one of
   the Route Targets carried in the message matches one of the import
   Route Targets 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 auto-discovery
   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. This ensures
   that if multiple ASBRs, in an AS, receive the same inter-AS A-D route
   from their E-BGP neighbors, only one of these ASBRs propagates this
   route in I-BGP. 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.

   When re-advertising an inter-AS auto-discovery 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 tree used to instantiate the
   intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of
   the re-advertised inter-AS auto-discovery 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 auto-
       discovery routes received from other PEs/ASBRs in ASBR's own AS.







Raggarwa, Kamite & Fang                                        [Page 22]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


     + An ASBR that uses a P-Multicast tree to instantiate the intra-AS
       segment of the inter-AS tunnel MAY aggregate two or more VPLSs
       present on the ASBR onto the same tree. If the ASBR already
       advertises inter-AS auto-discovery routes for these VPLSs, 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 auto-discovery routes for these
       VPLSs, then the aggregation requires the ASBR to advertise (new)
       inter-AS auto-discovery routes for these VPLSs. The PMSI Tunnel
       attribute in the newly advertised/re-advertised routes MUST carry
       the identity of the P-Multicast tree that aggregates the VPLSs,
       as well as an MPLS upstream-assigned label [MPLS-UPSTREAM].  Each
       re-advertised route MUST have a distinct label.


   In addition the ASBR MUST send to the E-BGP neighbor, from whom it
   receives the inter-AS auto-discovery route, a BGP Update message that
   carries a "leaf auto-discovery route". The exact encoding of this
   route is described in section 13. 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 Auto-Discovery NLRI of the
       inter-AS auto-discovery route received from that neighbor. The
       NLRI also carries the IP address of the ASBR (this MUST be a
       routable IP address).

     + The leaf auto-discovery 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 Route Targets associated with the VPLS MUST be included in
       the route.






Raggarwa, Kamite & Fang                                        [Page 23]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


11.2.2.3. Leaf Auto-Discovery Route received via E-BGP

   When an ASBR receives via E-BGP a leaf auto-discovery route, the ASBR
   accepts the route only if if (a) at least one of the Route Targets
   carried in the message matches one of the import Route Targets
   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 auto-discovery route, the ASBR finds an
   auto-discovery route whose BGP-VPLS A-D NLRI has the same value as
   the <RD, VE-ID> field of the the leaf auto-discovery route.

   The MPLS label carried in the PMSI Tunnel attribute of the leaf auto-
   discovery route is used to stitch a one hop ASBR-ASBR LSP to the tail
   of the intra-AS tunnel segment associated with the found auto-
   discovery route.


11.2.2.4. Inter-AS Auto-Discovery Route received via I-BGP

   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 auto-discovery route is advertised within
   a given AS by only one ASBR as described above.

   When a PE/ASBR router receives from one of its I-BGP neighbors a BGP
   Update message that carries an inter-AS auto-discovery route, if (a)
   at least one of the Route Targets carried in the message matches one
   of the import Route Targets 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.

   If the router is an ASBR then the ASBR propagates the route to its E-
   BGP neighbors. When propagating the route to the E-BGP 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 auto-discovery 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 auto-discovery 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



Raggarwa, Kamite & Fang                                        [Page 24]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   with the local PE/ASBRas a leaf. This LSP MAY have been established
   before the local PE/ASBR receives the route, or MAY be established
   after the local PE receives the route.

   If the received inter-AS auto-discovery 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 auto-discovery route and rooted at the PE
   that originated the auto-discovery 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
   received 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.


11.3. Option (c)

   In this method, there is a multi-hop E-BGP peering between the PEs
   (or a Route Reflector) in one AS and the PEs (or Route Reflector) in
   another AS. The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI,
   along with PMSI Tunnel Attribute, as in the intra-AS case described
   in section 8. An implementation MUST support this method.

   The PEs in different ASs use a non-segmented inter-AS P2MP tunnel for
   VPLS multicast. A non-segmented inter-AS tunnel is a single tunnel
   which 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

   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 setup of non-segmented inter-AS P2MP tunnels MAY require the P-
   routers in one AS to have IP reachability to the loopback addresses
   of the PE routers in another AS, depending on the tunneling
   technology chosen. If this is the case, 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



Raggarwa, Kamite & Fang                                        [Page 25]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   described in section 8.


12. Optimizing Multicast Distribution via Selective Trees

   Whenever a particular multicast stream is being sent on an Inclusive
   Tree, it is likely that the data of that stream is being sent to PEs
   that do not require it. If a particular stream has a significant
   amount of traffic, it may be beneficial to move it to a Selective
   Tree which has at its leaves only those PEs that have receivers for
   the multicast stream (or at least includes fewer PEs that have no
   receivers compared to an Inclusive tree).

   If the PE connected to the multicast source is performing explicit
   tracking Selective Trees can also be triggered on other criteria. For
   instance there could be a "pseudo wasted bandwidth" criteria:
   switching to a Selective Tree would be done if the bandwidth
   multiplied by the number of uninterested PEs (PE 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-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 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 source initiated tree, such as a 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 VPLSs, using one P-multicast Selective Tree, such a
       tree is termed 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.

       For discovering the IP multicast group membership, for the above
       two cases, procedures described in [VPLS-CTRL] SHOULD be used.
       These cases require that explicit tracking be done for the (C-S,
       C-G) stream. The root of the Selective P-tree MAY decide to do
       explicit tracking of this stream only after it has determined to
       move the stream to a Selective tree, or it MAY have been doing
       explicit tracking all along.

       The PE at the root of the tree MUST signal the leaves of the tree



Raggarwa, Kamite & Fang                                        [Page 26]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


       that the (C-S, C-G) stream is now bound to the 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.

       If the Selective Tree is instantiated by a source-initiated P-
       multicast tree (e.g., an RSVP-TE P2MP tunnel), the PE at the root
       of the tree MUST establish the source-initiated P-multicast tree
       to the leaves.  This tree MAY have been established before the
       leaves receive the Selective Tree binding, or MAY be established
       after the leaves receives the binding.  The leaves MUST not
       switch to the Selective Tree until they receive both the binding
       and the tree signaling message.


12.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, that
   originates the Selective Tree, and the egress PEs, MUST switch to the
   Selective Tree for the <C-S, C-G> streams that are mapped to it.

   Once a source PE decides to setup an Selective Tree, it MUST announce
   the mapping of the <C-S, C-G> streams (which may be in different
   VPLSs) that are mapped to the tree to the other PEs using BGP.
   Depending on the P-multicast technology used, this announcement may
   be done before or after setting up the Selective Tree. After the
   egress PEs receive the announcement they setup 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 section 9. The
   egress PEs may perform this switch to the Selective Tree once the
   advertisement from the ingress PE is received or wait for a
   preconfigured timer to do so.

   A source PE MUST use the following approach to decide when to start
   transmitting data on the Selective tree. A certain pre-configured
   delay after advertising the <C-S, C-G> streams mapped to an Selective
   Tree, the source PE begins to send traffic on the Selective Tree. At
   this point it stops to send traffic for the <C-S, C-G> streams, that
   are mapped on the Selective Tree, on the Inclusive Tree. This traffic
   is instead transmitted on the Selective Tree.








Raggarwa, Kamite & Fang                                        [Page 27]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


12.2. Advertising C-(S, G) Binding to a Selective Tree using BGP

   The ingress PE informs all the PEs that are on the path to receivers
   of the C-(S, G) of the binding of the Selective Tree to the C-(S, G).
   The BGP announcement is done by sending update for the MCAST-VPLS
   address family. A Selective Tree A-D route is used, containing the
   following information:

     +  a) IP address of the originating PE

       b) The RD configured locally for the MVPN. This is required to
       uniquely identify the <C-Source, C-Group> as the addresses could
       overlap between different VPLSs.  This is the same RD value used
       in the VPLS auto-discovery process.

       c) The C-Source address.

       d) The C-Group address.

       e) A PE MAY aggregate two or more (C-S, C-G)s  originated by the
       PE onto the same P-Multicast tree. If the PE already advertises
       Selective Tree auto-discovery routes for these Selective Trees,
       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 Selective Tree auto-discovery routes for
       these (C-S, C-G)s, then the aggregation requires the PE to
       advertise (new) Selective Tree auto-discovery routes for these
       (C-S, C-G)s. The PMSI Tunnel attribute in the newly
       advertised/re-advertised routes MUST carry the identity of the P-
       Multicast tree that aggregates the (C-S, C-G)s. If at least some
       of the (C-S, C-G)s aggregated onto the same P-Multicast tree
       belong to different VPLSs, then all these routes MUST carry an
       MPLS upstream assigned label [MPLS-UPSTREAM]. If all these
       aggregated (C-S, C-G)s belong to the same VPLS, then the routes
       MAY carry an MPLS upstream assigned label [MPLS-UPSTREAM].  The
       labels MUST be distinct on a per VPLS basis, and MAY be distinct
       on a per route basis.


   When a PE distributes this information via BGP, it must include the
   following:
     + 1. A PMSI Tunnel Attribute to identify the Selective Tree to
       which the stream is bound.







Raggarwa, Kamite & Fang                                        [Page 28]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


     + Route Target Extended Communities attribute. This is used as
       described in section 8.


12.2.1. Explicit Tracking

   If the PE wants to enable explicit tracking for the specified flow,
   it also indicates this in the A-D route it uses to bind the flow to a
   particular Selective Tree.  Then any PE which receives the A-D route
   will respond with a "Leaf A-D Route" in which it identifies itself as
   a receiver of the specified flow. The Leaf A-D route will be
   withdrawn when the PE is no longer a receiver for the flow.

   If the PE needs to enable explicit tracking for a flow before binding
   the flow to an Selective Tree, it can do so by sending an A-D route
   identifying the flow but not specifying an Selective Tree.  This will
   elicit the Leaf A-D Routes.  This is useful when the PE needs to know
   the receivers before selecting an Selective Tree.


12.3. Inter-AS Selective Tree

   Inter-AS Selective Trees support all three models 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
   model. 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
   Selective tree A-D routes can be exchanged via ASBRs (even though
   BGP-VPLS NLRI or 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 ASs.









Raggarwa, Kamite & Fang                                        [Page 29]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


12.3.1. VSIs on the ASBRs

   The requirements on ASBRs in this model include the requirements
   presented in section 11. The source ASBR (that receives traffic from
   another AS) may independently decide whether it wishes to use
   Selective Trees or not. If it uses Selective Trees the source ASBR
   MUST perform an IP multicast lookup to determine the Selective Tree
   to forward the VPLS packet on.


12.3.1.1. VPLS Inter-AS Selective Tree Auto-Discovery Binding

   The mechanisms for propagating Selective Tree A-D routes are the same
   as the intra-AS case described in section 12.2. The BGP Selective
   Tree A-D routes generated by PEs in an AS MUST NOT be propagated
   outside the AS.


12.3.2. Inter-AS Segmented Selective Trees

   Inter-AS Segmented Selective trees MUST be used when option (b) is
   used to provide the inter-AS VPLS service. They MAY be used when
   option (c) is used 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 (C-S, C-G) binding using a Selective Tree A-D route
   as per procedures in section 12.2, to the routers in its own AS.

   A Selective Tree A-D route advertised outside the AS, to which the
   originating PE belongs, will be referred to as an inter-AS Selective
   Tree A-D route (Although this route is originated by a PE as an
   intra-AS route it is referred to as an inter-AS route outside the
   AS).

   An ASBR that receives the information from its upstream ASBR using E-
   BGP sends back a tunnel binding for AS <C-S, C-G> information if:




Raggarwa, Kamite & Fang                                        [Page 30]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


      a) At least one of the Route Targets carried in the message
         matches one of the import Route Targets 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 instantiates a Selective Tree for the AS <C-S, C-G> it
   sends back a downstream label that is used to forward the packet
   along its intra-AS Selective Tree segment for <C-S, C-G>. However, in
   the case of option (b) the ASBR may decide to use an AS Inclusive
   Tree segment instead, in which case it sends back the same label that
   it advertised for the AS-AS segment of the inter-AS segmented
   Inclusive tree. (This is not possible in option (c) as in option (c)
   the ASBRs do not participate in inter-AS Inclusive tree setup). If
   the downstream ASBR instantiates a Selective Tree, it further
   propagates the <C-S, C-G> membership to its downstream ASes, else it
   does not.

   An AS can instantiate an intra-AS Selective Tree segment for the
   inter-AS Selective tunnel only if the upstream AS instantiates a
   Selective Tree. The procedures allow each AS to determine whether it
   wishes to setup a Selective Tree or not and the AS is not forced to
   setup a Selective Tree just because the upstream AS decides to do so.

   The leaves of an intra-AS Selective Tree will be the PEs that have
   local receivers that are interested in <C-S, C-G> and the ASBRs that
   have received VPLS control information for <C-S, C-G>.

   The C-multicast data traffic is sent on the Selective Tree by the
   originating PE. When it reaches an ASBR that is on the spanning tree,
   it is delivered to local receivers, if any, and is also forwarded to
   the neighbor ASBR after being encapsulated in the label advertised by
   the neighbor. The neighbor ASBR either transports this packet on the
   Selective Tree segment for the multicast stream or an Inclusive Tree
   segment, delivering it to the ASBRs in its own AS. These ASBRs in
   turn repeat the procedures of the origin AS ASBRs and the multicast
   packet traverses the spanning tree.

   The (C-S, C-G) membership for which the Selective Tree is
   instantiated, is propagated inter-AS using procedures in [VPLS-CTRL].










Raggarwa, Kamite & Fang                                        [Page 31]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


12.3.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 E-BGP 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
   section 12.2.

   The PEs in different ASs 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 section 9.


13. BGP Extensions

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


13.1. Inclusive Tree/Selective Tree Identifier

   Inclusive Tree and Selective Tree advertisements carry the Tree
   identifier.

   This document defines and uses a new BGP attribute, called PMSI
   Tunnel Attribute. This is an optional transitive BGP attribute. The
   format of this attribute is defined as follows:

                +---------------------------------+
                |  Flags (1 octet)                |
                +---------------------------------+
                |  Tunnel Type (1 octets)         |
                +---------------------------------+
                |  MPLS Label (3 octets)          |
                +---------------------------------+
                |  Tunnel Identifier (variable)   |
                +---------------------------------+




Raggarwa, Kamite & Fang                                        [Page 32]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   The Flags field has the following format:

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |  reserved   |L|
                +-+-+-+-+-+-+-+-+

   This document defines the following flags:

     + Leaf Information Required (L)

   The Tunnel Type identifies the type of the tunneling technology used
   to establish the P-tunnel. The type determines the syntax and
   semantics of the Tunnel Identifier field. This document defines the
   following Tunnel Types:

     + 1 - RSVP-TE P2MP LSP
     + 2 - LDP P2MP LSP
     + 6 - Ingress Replication

       If the MPLS Label field is non-zero, then it contains an MPLS
       label encoded as 3 octets, where the high-order 20 bits contain
       the label value. Absence of MPLS Label is indicated by setting
       the MPLS Label field to zero.

       When the type is set to RSVP-TE P2MP LSP, the Tunnel Identifier
       contains the RSVP-TE P2MP LSP's SESSION Object.

       When the type is set to LDP P2MP LSP, the Tunnel Identifier is
       <P-Root Node Address, Variable length opaque identifier>.

       When the type is set to Ingress Replication the Tunnel Identifier
       carries the unicast tunnel endpoint.


13.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)    |
                +-----------------------------------+



Raggarwa, Kamite & Fang                                        [Page 33]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   The Route Type field defines encoding of the rest of MCAST-VPLS NLRI
   (Route Type specific 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 auto-discovery
   routes:
     + 1 - Selective Tree auto-discovery route;
     + 2 - Leaf auto-discovery route.

   The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol
   Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and an 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 an SAFI of MCAST-VPLS.

   The following describes the format of the Route Type specific MCAST-
   VPLS NLRI for various Route Types defined in this document.


13.2.1. Selective Tree auto-discovery route

   An Selective Tree A-D route type specific MCAST-VPLS NLRI 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. If the Multicast



Raggarwa, Kamite & Fang                                        [Page 34]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   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 Multicast Group field contains the C-G address.  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.

   Usage of Selective Tree auto-discovery routes is described in Section
   12.


13.2.2. Leaf auto-discovery route

   A leaf auto-discovery route type specific MCAST-VPLS NLRI consists of
   the following:

                +-----------------------------------+
                |      Route Key (variable)         |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   Usage of Leaf auto-discovery routes is described in sections "Inter-
   AS Inclusive Multicast Tree Auto-Discovery/Binding" and "Optimizing
   Multicast Distribution via Selective Trees".


14. Aggregation Methodology

   In general the herustics 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 tradeoffs 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 a SP tree.
   For Aggregate Inclusive Trees the congruency depends on the overlap
   in the membership of the VPLSs that are aggregated on the Aggregate
   Inclusive Tree. If there is complete overlap aggregation is perfectly
   congruent. As the overlap between the VPLSs that are aggregated
   reduces, the congruency reduces.

   If aggregation is done such that it is not perfectly congruent a PE
   may receive traffic for VPLSs to which it doesn't belong. As the



Raggarwa, Kamite & Fang                                        [Page 35]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   amount of multicast traffic in these unwanted VPLSs increases
   aggregation becomes less optimal with respect to delivered traffic.
   Hence there is a tradeoff between reducing state and delivering
   unwanted traffic.

   An implementation should provide knobs to control the congruency of
   aggregation. This will allow a SP to deploy aggregation depending on
   the VPLS membership and traffic profiles in its network.  If
   different PEs or shared roots' are setting up Aggregate Inclusive
   Trees this will also allow a SP to engineer the maximum amount of
   unwanted VPLSs that a particular PE may receive traffic for.

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


15. Data Forwarding

15.1. MPLS Tree Encapsulation

   The following diagram shows the progression of the VPLS IP 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   ||
      ++=============++       ++=============++       ++=============++



Raggarwa, Kamite & Fang                                        [Page 36]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   The receiver PE does a lookup on the outer MPLS tree label and
   determines the MPLS forwarding table in which to lookup the inner
   MPLS label. This table is specific to the tree label space. The inner
   label is unique within the context of the root of the tree (as it is
   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 label,
   and the context within which that label is unique. The context is
   provided by the outer MPLS label [MPLS-UPSTREAM].

   The outer MPLS label is stripped. The lookup of the resulting MPLS
   label determines the VSI in which the receiver PE needs to do the C-
   multicast data packet lookup. It then strips the inner MPLS label and
   sends the packet to the VSI for multicast data forwarding.


16. 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 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
   blackholing VPLS multicast data, or even sending it to an
   eavesdropper; none of which are acceptable from a data privacy point
   of view. The mechanisms in this document use BGP for the control
   plane. Hence techniques such as in [RFC2385] help authenticate BGP
   messages, making it harder to spoof updates (which can be used to
   divert VPLS traffic to the wrong VPLS) or withdraws (denial-of-
   service attacks).  In the multi-AS methods (b) and (c) described in
   Section 11, this also means protecting the inter-AS BGP sessions,
   between the ASBRs, the PEs, or the Route Reflectors.

   Note that [RFC2385] 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 a Service
   Provider network.

   One of the requirements for protecting the data plane is that the
   MPLS labels are accepted only from valid interfaces. This applies
   both to MPLS labels associated with P2MP LSPs and also applies to the
   upstream assigned MPLS labels. For a PE, valid interfaces comprise
   links from P routers. For an ASBR, a valid interface is a link from
   another ASBR in an AS that is part of a given VPLS. It is especially
   important in the case of multi-AS VPLSs that one accept VPLS packets



Raggarwa, Kamite & Fang                                        [Page 37]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   only from valid interfaces.


17. IANA Considerations

   This document defines a new NLRI, called MCAST-VPLS, to be carried in
   BGP using multiprotocol extensions. It requires assignment of a new
   SAFI. This is to be assigned by IANA.

   This document defines a BGP optional transitive attribute, called
   PMSI Attribute. This is the same attribute as the one defined in
   [BGP-MVPN] 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.


18. Acknowledgments

   Many thanks to Thomas Morin for his support of this work. We would
   also like to thank authors of [BGP-MVPN] and [MVPN] as the details of
   the inter-AS segmented tree procedures in this document have
   benefited from those in [BGP-MVPN] and [MVPN].


19. Normative References

   [RFC2119] "Key words for use in RFCs to Indicate Requirement
   Levels.", Bradner, March 1997

   [RFC4761] K. Kompella, Y. Rekther, "Virtual Private LAN Service",
   draft-ietf-l2vpn-vpls-bgp-02.txt

   [RFC4762] M. Lasserre, V. Kompella, "Virtual Private LAN Services
   over MPLS", draft-ietf-l2vpn-vpls-ldp-03.txt

   [RFC4760] T. Bates, et. al., "Multiprotocol Extensions for BGP-4",
   January 2007

   [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream
   Label Assignment and Context Specific Label Space", draft-ietf-mpls-
   upstream-label-00.txt










Raggarwa, Kamite & Fang                                        [Page 38]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


20. Informative References

   [VPLS-CTRL] R. Aggarwal, Y. Kamite, L. Fang, "Propagation of VPLS IP
   Multicast Group Membership Information", draft-raggarwa-l2vpn-vpls-
   mcast-ctrl-00.txt

   [L2VPN-SIG] E. Rosen et. al., "Provisioning, Autodiscovery, and
   Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt

   [MPLS-MCAST] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS
   Multicast Encapsulations", draft-ietf-mpls-multicast-encaps-00.txt

   [MVPN] E. Rosen, R. Aggarwal, "Multicast in 2547 VPNs", draft-ietf-
   l3vpn-2547bis-mcast-05.txt"

   [BGP-MVPN] R. Aggarwal, E. Rosen, Y. Rekhter, T. Morin, C.
   Kodeboniya.  "BGP Encodings for Multicast in 2547 VPNs", draft-ietf-
   l3vpn-2547bis-mcast-bgp-03.txt

   [RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to
   Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-07.txt

   [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for
   Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
   Paths", draft-ietf-mpls-ldp-p2mp-02.txt

   [RFC4364] "BGP MPLS VPNs", E. Rosen, Y.Rekhter, February 2006

   [MCAST-VPLS-REQ] Y. kamite, et. al., "Requirements for Multicast
   Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls-
   mcast-reqts-05.txt

   [RFC1997] R. Chandra, et. al., "BGP Communities Attribute", August
   1996

   [BGP-IANA] http://www.iana.org/assignments/bgp-parameters

   [RFC4684] P. Marques et. al., "Constrained Route Distribution for
   Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
   Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
   November 2006

   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
   Signature Option", RFC 2385, August 1998.







Raggarwa, Kamite & Fang                                        [Page 39]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


21. Author's Address

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   USA
   Phone: +1-408-936-2720
   Email: rahul@juniper.net

   Yuji Kamite
   NTT Communications Corporation
   Tokyo Opera City Tower
   3-20-2 Nishi Shinjuku, Shinjuku-ku,
   Tokyo 163-1421,
   Japan

   Email: y.kamite@ntt.com

   Luyuan Fang
   Cisco Systems
   300 Beaver Brook Road
   BOXBOROUGH, MA 01719
   USA

   Email: lufang@cisco.com

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   USA

   Email: yakov@juniper.net

   Chaitanya Kodeboniya



22. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be



Raggarwa, Kamite & Fang                                        [Page 40]

Internet Draft     draft-ietf-l2vpn-vpls-mcast-03.txt      November 2007


   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.



23. Full Copyright Statement

   Copyright (C) The IETF Trust (2007).  This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





















Raggarwa, Kamite & Fang                                        [Page 41]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/