Rfc7796
TitleEthernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)
AuthorY. Jiang, Ed., L. Yong, M. Paul
DateMarch 2016
Format:TXT, HTML
Status:PROPOSED STANDARD






1;2c.
Internet Engineering Task Force (IETF)                     Y. Jiang, Ed.
Request for Comments: 7796                                       L. Yong
Category: Standards Track                                         Huawei
ISSN: 2070-1721                                                  M. Paul
                                                        Deutsche Telekom
                                                              March 2016


  Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)

Abstract

   This document specifies a generic Virtual Private LAN Service (VPLS)
   solution, which uses VLANs to indicate root or leaf traffic to
   support Ethernet-Tree (E-Tree) services.  A VPLS Provider Edge (PE)
   model is illustrated as an example for the solution.  In the
   solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs),
   which carry the VLAN indicating the E-Tree attribute.  The MAC
   address-based Ethernet forwarding engine and the PW work in the same
   way as specified in RFC 4762 and RFC 4448, respectively.  A signaling
   mechanism is described to support E-Tree capability and VLAN mapping
   negotiation.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7796.














RFC 7796                 E-Tree Support in VPLS               March 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  PE Model with E-Tree Support  . . . . . . . . . . . . . . . .   5
     4.1.  Existing PE Models  . . . . . . . . . . . . . . . . . . .   5
     4.2.  A New PE Model with E-Tree Support  . . . . . . . . . . .   8
   5.  PW for E-Tree Support . . . . . . . . . . . . . . . . . . . .   9
     5.1.  PW Encapsulation  . . . . . . . . . . . . . . . . . . . .   9
     5.2.  VLAN Mapping  . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  PW Processing . . . . . . . . . . . . . . . . . . . . . .  11
       5.3.1.  PW Processing in the VLAN Mapping Mode  . . . . . . .  11
       5.3.2.  PW Processing in the Compatible Mode  . . . . . . . .  12
       5.3.3.  PW Processing in the Optimized Mode . . . . . . . . .  13
   6.  Signaling for E-Tree Support  . . . . . . . . . . . . . . . .  14
     6.1.  LDP Extensions for E-Tree Support . . . . . . . . . . . .  14
     6.2.  BGP Extensions for E-Tree Support . . . . . . . . . . . .  17
   7.  OAM Considerations  . . . . . . . . . . . . . . . . . . . . .  19
   8.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     11.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Appendix A.  Other PE Models for E-Tree . . . . . . . . . . . . .  23
     A.1.  A PE Model with a VSI and No Bridge . . . . . . . . . . .  23
     A.2.  A PE Model with External E-Tree Interface . . . . . . . .  24
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26





RFC 7796                 E-Tree Support in VPLS               March 2016


1.  Introduction

   The Ethernet-Tree (E-Tree) service is defined in the Metro Ethernet
   Forum (MEF) Technical Specification MEF 6.2 [MEF6.2] as a Rooted-
   Multipoint Ethernet Virtual Connection (EVC) service.  An MEF 6.2
   E-Tree solution must meet the following design requirements: the
   Ethernet frames from a root may be received by any other root or
   leaf, and the frames from a leaf may be received by any root, but
   must not be received by a leaf.  Further, an E-Tree service may
   include multiple roots and multiple leaves.  Although Virtual Private
   Multicast Service (VPMS) [VPMS] and Point-to-Multipoint (P2MP)
   multicast are somewhat simplified versions of this service, in fact,
   they are both multicast services and are different from an E-Tree
   service that may include both unicast and multicast traffic.

   [RFC7152] gives the requirements for providing E-Tree solutions in
   the VPLS and the need to filter leaf-to-leaf traffic.  [RFC7387]
   further describes a Multiprotocol Label Switching (MPLS) framework
   for providing E-Tree.  Though there were proposals for using the
   Pseudowire (PW) control word or PWs to indicate the root/leaf
   attribute of an E-Tree frame, both methods are limited in that they
   are only applicable to "VPLS only" networks.

   A VPLS PE usually consists of a bridge module itself (see [RFC4664]
   and [RFC6246]); and moreover, E-Tree services may cross both Ethernet
   and VPLS domains.  Therefore, it is necessary to develop an E-Tree
   solution both for "VPLS only" scenarios and for interworking between
   Ethernet and VPLS.

   IEEE 802.1 has incorporated the generic E-Tree solution into 802.1Q
   [IEEE-802.1Q-2014], which is an improvement on the traditional
   asymmetric VLAN mechanism.  In the asymmetric VLAN mechanism as
   described in Section B.1.3 of IEEE 802.1Q [IEEE-802.1Q-2003], a VLAN
   ID is used to indicate the traffic from a server, and multiple VLAN
   IDs are used to indicate the traffic from the clients (one VLAN ID
   per client).  In the new IEEE 802.1Q solution, only two VLANs are
   used to indicate root/leaf attributes of a frame: one VLAN ID is used
   to indicate the frames originated from the roots and another VLAN ID
   is used to indicate the frames originated from the leaves.  At a leaf
   port, the bridge can then filter out all the frames from other leaf
   ports based on the VLAN ID.  It is better to reuse the same mechanism
   in VPLS than to develop a new mechanism.  A new mechanism would
   introduce more complexity to interwork with the new IEEE 802.1Q
   solution.

   This document specifies how the Ethernet VLAN solution can be used to
   support generic E-Tree services in VPLS.  The solution specified here
   is fully compatible with the IEEE bridge architecture and with IETF



RFC 7796                 E-Tree Support in VPLS               March 2016


   Pseudowire Emulation Edge-to-Edge (PWE3) technology, thus it will not
   change the FIB (such as installing E-Tree attributes in the FIB) or
   need any specially tailored implementation.  Furthermore, VPLS
   scalability and simplicity are also maintained.  With this mechanism,
   it is also convenient to deploy a converged E-Tree service across
   both Ethernet and MPLS networks.

   A typical VPLS PE model is introduced as an example; the model is
   then extended in which a Tree VSI is connected to a VLAN bridge with
   a dual-VLAN interface.

   This document then discusses the PW encapsulation and PW processing
   such as VLAN mapping options for transporting E-Tree services in
   VPLS.

   Finally, this document describes the signaling extensions and
   processing procedures for E-Tree support in VPLS.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   AC:  Attachment Circuit

   B-VLAN:  Backbone VLAN

   C-VLAN:  Customer VLAN

   E-Tree:  Ethernet Tree, a Rooted-Multipoint EVC service as defined in
      [MEF6.2]

   EVC:  Ethernet Virtual Connection, as defined in [MEF4]

   FIB:  Forwarding Information Base, also known as "forwarding table"

   I-SID:  Backbone Service Instance Identifier, as defined in IEEE
      802.1ah [IEEE-802.1Q-2014]

   Leaf AC:  An AC attached with a leaf

   Leaf VLAN:  A VLAN Identifier (ID) used to indicate all the frames
      that are originated at a leaf AC.  It may be a C-VLAN, an S-VLAN,
      or a B-VLAN




RFC 7796                 E-Tree Support in VPLS               March 2016


   OAM:  Operations, Administration, and Maintenance

   PBB:  Provider Backbone Bridge

   PE:  Provider Edge

   PW:  Pseudowire

   Root AC:  An AC attached with a root

   Root VLAN:  A VLAN ID used to indicate all the frames that are
      originated at a root AC.  It may be a C-VLAN, an S-VLAN, or a
      B-VLAN

   S-VLAN:  Service VLAN

   T-VSI:  Tree VSI, a VSI with E-Tree support

   VLAN:  Virtual Local Area Network

   VPLS:  Virtual Private LAN Service

   VSI:  Virtual Switching Instance as defined in [RFC4664], also known
      as "VPLS Forwarder" in [RFC7041]

4.  PE Model with E-Tree Support

   The problem scenario of E-Tree as shown in Figure 1 of [RFC7152] is a
   simplification of the L2VPN architecture.  Several common VPLS PE
   architectures are discussed in more detail in [RFC4664] and
   [RFC6246].

   Below, an E-Tree solution in VPLS is demonstrated with the help of a
   typical VPLS PE model.  Its use in other PE models is discussed in
   Appendix A.

4.1.  Existing PE Models

   According to [RFC4664], there are at least three models possible for
   a VPLS PE, including:

   o  A single bridge module, a single VSI;

   o  A single bridge module, multiple VSIs;

   o  Multiple bridge modules, each attaches to a VSI.





RFC 7796                 E-Tree Support in VPLS               March 2016


   The second PE model is commonly used.  A typical example is further
   depicted in Figure 1 and Figure 2 (both figures are extracted from
   [RFC6246]), where an S-VLAN bridge module is connected to multiple
   VSIs each with a single VLAN virtual interface.

                      +-------------------------------+
                      |  802.1ad Bridge Module Model  |
                      |                               |
           +---+  AC  |  +------+      +-----------+  |
           |CE |---------|C-VLAN|------|           |  |
           +---+      |  |bridge|------|           |  |
                      |  +------+      |           |  |
                      |     o          |   S-VLAN  |  |
                      |     o          |           |  | ---> to VSI
                      |     o          |   Bridge  |  |
           +---+  AC  |  +------+      |           |  |
           |CE |---------|C-VLAN|------|           |  |
           +---+      |  |bridge|------|           |  |
                      |  +------+      +-----------+  |
                      +-------------------------------+

                Figure 1: A Model of 802.1ad Bridge Module

           +----------------------------------------+
           |           VPLS-Capable PE Model        |
           |   +---------------+          +------+  |
           |   |               |          |VSI-1 |------------
           |   |               |==========|      |------------ PWs
           |   |     Bridge    ------------      |------------
           |   |               | S-VLAN-1 +------+  |
           |   |     Module    |             o      |
           |   |               |             o      |
           |   |   (802.1ad    |             o      |
           |   |    bridge)    |             o      |
           |   |               |             o      |
           |   |               | S-VLAN-n +------+  |
           |   |               ------------VSI-n |-------------
           |   |               |==========|      |------------- PWs
           |   |               |     ^    |      |-------------
           |   +---------------+     |    +------+  |
           |                         |              |
           +-------------------------|--------------+
                            LAN Emulation Interface

                     Figure 2: A VPLS-Capable PE Model






RFC 7796                 E-Tree Support in VPLS               March 2016


   In this PE model, Ethernet frames from Customer Edges (CEs) will
   cross multiple stages of bridge modules (i.e., C-VLAN and S-VLAN
   bridge), and a VSI in a PE before being sent on the PW to a remote
   PE.  Therefore, the association between an AC port and a PW on a VSI
   is difficult.

   This model could be further enhanced: when Ethernet frames arrive at
   an ingress PE, a root VLAN or a leaf VLAN tag is added.  At an egress
   PE, the frames with the root VLAN tag are transmitted both to the
   roots and the leaves, while the frames with the leaf VLAN tag are
   transmitted to the roots but dropped for the leaves (these VLAN tags
   are removed before the frames are transmitted over the ACs).  It was
   demonstrated in [IEEE-802.1Q-2014] that the E-Tree service in
   Ethernet networks can be well supported with this mechanism.

   Assuming this mechanism is implemented in the bridge module, it is
   quite straightforward to infer a VPLS PE model with two VSIs to
   support the E-Tree (as shown in Figure 3).  But this model will
   require two VSIs per PE and two sets of PWs per E-Tree service, which
   is poorly scalable in a large MPLS/VPLS network; in addition, both of
   these VSIs have to share their learned MAC addresses.

           +----------------------------------------+
           |           VPLS-Capable PE Model        |
           |   +---------------+          +------+  |
           |   |               |          |VSI-1 |------------
           |   |               |==========|      |------------ PWs
           |   |     Bridge    ------------      |------------
           |   |               | Root     +------+  |
           |   |     Module    | S-VLAN             |
           |   |               |                    |
           |   |   (802.1ad    |                    |
           |   |    bridge)    |                    |
           |   |               | Leaf               |
           |   |               | S-VLAN   +------+  |
           |   |               ------------VSI-2 |-------------
           |   |               |==========|      |------------- PWs
           |   |               |     ^    |      |-------------
           |   +---------------+     |    +------+  |
           |                         |              |
           +-------------------------|--------------+
                            LAN Emulation Interface

              Figure 3: A VPLS PE Model for E-Tree with 2VSIs







RFC 7796                 E-Tree Support in VPLS               March 2016


4.2.  A New PE Model with E-Tree Support

   In order to support the E-Tree in a more scalable way, a new VPLS PE
   model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is
   specified.  As depicted in Figure 4, the bridge module is connected
   to the T-VSI with a dual-VLAN virtual interface, i.e., both the root
   VLAN and the leaf VLAN are connected to the same T-VSI, and they
   share the same FIB and work in shared VLAN learning.  In this way,
   only one VPLS instance and one set of PWs is needed per E-Tree
   service, and the scalability of VPLS is improved.

            +----------------------------------------+
            |           VPLS-Capable PE Model        |
            |   +---------------+          +------+  |
            |   |               |==========|TVSI-1|------------
   +---+ AC |   |               ------------      |------------ PWs
   |CE |--------|     Bridge    ------------      |------------
   +---+    |   |               | Root &   +------+  |
            |   |     Module    | Leaf VLAN   o      |
            |   |               |             o      |
            |   |               |             o      |
            |   |               |             o      |
            |   |               |             o      |
   +---+ AC |   |               |   VLAN-n +------+  |
   |CE |--------|               ------------VSI-n |-------------
   +---+    |   |               |==========|      |------------- PWs
            |   |               |     ^    |      |-------------
            |   +---------------+     |    +------+  |
            |                         |              |
            +-------------------------|--------------+
                            LAN Emulation Interface

         Figure 4: A VPLS PE Model for E-Tree with a Single T-VSI

   For an untagged AC port (frames over this port are untagged) or a
   VLAN unaware port (VLAN tags in the frames are ignored), where the
   bridge module is a C-VLAN bridge, the Ethernet frames received from
   the root ACs MUST be tagged with a root C-VLAN.  When the bridge
   module is an 802.1ad bridge [IEEE-802.1Q-2014], the Ethernet frames
   received from the root ACs MUST be tagged with a root S-VLAN.  Note,
   this can be done by adding a root C-VLAN first in a C-VLAN bridge,
   but this is out of the scope of this document.

   For a C-VLAN tagged port, the Ethernet frames received from the root
   ACs MUST be tagged with a root S-VLAN.






RFC 7796                 E-Tree Support in VPLS               March 2016


   For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames
   received from the root ACs SHOULD be translated to the root S-VLAN in
   the VPLS network domain.

   Alternatively, for an S-VLAN tagged port, the PBB VPLS PE model
   (where an IEEE 802.1ah bridge module is embedded in the PE) as
   described in [RFC7041] MAY be used.  A root B-VLAN or a leaf B-VLAN
   MAY be added.  The E-Tree attribute may also be indicated with two
   I-SID tags in the bridge module, and the frames are then encapsulated
   and transported transparently over a single B-VLAN.  Thus, the PBB
   VPLS works in the same way as described in [RFC7041] and will not be
   discussed further in this document.  When many S-VLANs are
   multiplexed in a single AC, PBB VPLS has the advantages of both VLAN
   scalability and MAC address scalability.

   In a similar way, the traffic from the leaf ACs is tagged and
   transported on the leaf C-VLAN, S-VLAN, or B-VLAN.

   In all cases, the outermost VLAN in the resulting Ethernet header is
   used to indicate the E-Tree attribute of an Ethernet frame; this
   document uses VLAN to refer to this outermost VLAN for simplicity in
   the latter sections.

5.  PW for E-Tree Support

5.1.  PW Encapsulation

   To support an E-Tree service, T-VSIs in a VPLS MUST be interconnected
   with a bidirectional Ethernet PW.  The Ethernet PW SHOULD work in the
   tagged mode (PW type 0x0004) as described in [RFC4448], in which case
   a VLAN tag MUST be carried in each frame in the PW to indicate the
   frame originated from either root or leaf (the VLAN tag indicating
   the frame originated from either root or leaf can be translated by a
   bridge module in the PE or added by an outside Ethernet edge device,
   even by a customer device).  In the tagged PW mode, two service-
   delimiting VLANs MUST be allocated in the VPLS domain for an E-Tree.
   PW processing for the tagged PW will be described in Section 5.3 of
   this document.

   A raw mode PW (PW type 0x0005 in [RFC4448]) MAY also be used to carry
   an E-Tree service for a PW in Compatible mode as shown in
   Section 5.3.2.  As defined in [RFC4448], for a raw mode PW, an
   Ethernet frame's 802.1Q VLAN tag is not meaningful to the PEs and it
   passes transparently through them.







RFC 7796                 E-Tree Support in VPLS               March 2016


5.2.  VLAN Mapping

   There are two ways of manipulating VLANs for an E-Tree in VPLS:

   o  Global VLAN based, that is, provisioning two global VLANs (Root
      VLAN and Leaf VLAN) across the VPLS network, thus no VLAN mapping
      is needed at all, or the VLAN mapping is done completely in the
      Ethernet domains.

   o  Local VLAN based, that is, provisioning two local VLANs for each
      PE (that participates in the E-Tree) in the VPLS network
      independently.

   The first method requires no VLAN mapping in the PW, but two unique
   service-delimiting VLANs must be allocated across the VPLS domain.

   The second method is more scalable in the use of VLANs, but needs a
   VLAN mapping mechanism in the PW similar to what is already described
   in Section 4.3 of [RFC4448].

   Global or local VLANs can be manually configured or provisioned by an
   Operational Support System.  Alternatively, some automatic VLAN
   allocation algorithm may be provided in the management plane, but it
   is out of scope of this document.

   For both methods, VLAN mapping parameters from a remote PE can be
   provisioned or determined by a signaling protocol as described in
   Section 6 when a PW is being established.























RFC 7796                 E-Tree Support in VPLS               March 2016


5.3.  PW Processing

5.3.1.  PW Processing in the VLAN Mapping Mode

   In the VLAN mapping mode, two VPLS PEs with E-Tree capability are
   inter-connected with a PW (for example, the scenario of Figure 5
   depicts the interconnection of two PEs attached with both root and
   leaf nodes).

                  +----------------------------+
                  |  VPLS PE with T-VSI        |
                  |                            |
        +----+    | +------+ Root VLAN +-----+ |    PW
        |Root|------| VLAN |-----------|T-VSI|----------
        +----+    | | BRG  | Leaf VLAN |     |----------
        +----+    | |      |-----------|     |----------
        |Leaf|------|      |           |     |-----+
        +----+    | +------+           +-----+ |   |
                  |                            |   |
                  +----------------------------+   |
                                                   |
                  +----------------------------+   |
                  |  VPLS PE with T-VSI        |   |
                  |                            |   |
        +----+    | +------+ Root VLAN +-----+ |   | PW
        |Root|------| VLAN |-----------|T-VSI|-----+
        +----+    | | BRG  | Leaf VLAN |     |----------
        +----+    | |      |-----------|     |----------
        |Leaf|------|      |           |     |----------
        +----+    | +------+           +-----+ |
                  |                            |  BRG: Bridge Module
                  +----------------------------+

             Figure 5: T-VSI Interconnected in the Normal Mode

   If a PE is in the VLAN mapping mode for a PW, then in the data plane,
   the PE MUST map the VLAN in each frame as follows:

   o  Upon transmitting frames on the PW, map from the local VLAN to the
      remote VLAN (i.e., the local leaf VLAN in a frame is translated to
      the remote leaf VLAN; the local root VLAN in a frame is translated
      to the remote root VLAN).

   o  Upon receiving frames on the PW, map from the remote VLAN to the
      local VLAN, and the frames are further forwarded or dropped in the
      egress bridge module using the filtering mechanism as described in
      [IEEE-802.1Q-2014].




RFC 7796                 E-Tree Support in VPLS               March 2016


   The signaling for VLANs used by E-Tree is specified in Section 6.

5.3.2.  PW Processing in the Compatible Mode

   The new VPLS PE model can work in a traditional VPLS network
   seamlessly in the compatibility mode.  As shown in Figure 6, the VPLS
   PE with T-VSI can be attached with root and/or leaf nodes, while the
   VPLS PE with a traditional VSI can only be attached with root nodes.
   A raw PW SHOULD be used to connect them.

                  +------------------------+
                  |  VPLS PE with T-VSI    |
                  |                        |
        +----+    | +------+       +-----+ |  PW
        |Root|------| VLAN |-------|T-VSI|----------
        +----+    | | BRG  |       |     |----------
        +----+    | |      |-------|     |----------
        |Leaf|------|      |       |     |---------+
        +----+    | +------+       +-----+ |       |
                  |                        |       |
                  +------------------------+       |
                                                   |
                  +------------------------+       |
                  |  VPLS PE with VSI      |       |
                  |                        |       |
        +----+    | +------+       +-----+ |  PW   |
        |Root|------| VLAN |-------|VSI  |---------+
        +----+    | | BRG  |       |     |----------
        +----+    | |      |       |     |----------
        |Root|------|      |       |     |----------
        +----+    | +------+       +-----+ |
                  |                        |
                  +------------------------+

            Figure 6: T-VSI Interconnected with Traditional VSI

   If a PE is in the Compatible mode for a PW, then in the data plane,
   the PE MUST process the frame as follows:

   o  Upon transmitting frames on the PW, remove the root or leaf VLAN
      in the frames.

   o  Upon receiving frames on the PW, add a VLAN tag with a value of
      the local root VLAN to the frames.







RFC 7796                 E-Tree Support in VPLS               March 2016


5.3.3.  PW Processing in the Optimized Mode

   When two PEs (both with E-Tree capability) are inter-connected with a
   PW and one of them (e.g., PE2) is attached with only leaf nodes, as
   shown in the scenario of Figure 7, its peer PE (e.g., PE1) should
   then work in the Optimized mode for this PW.  In this case, PE1
   should not send the frames originated from the local leaf VLAN to
   PE2, i.e., these frames are dropped rather than transported over the
   PW.  The bandwidth efficiency of the VPLS can thus be improved.  The
   signaling for the PE attached with only leaf nodes is specified in
   Section 6.

                  +------------------------+
                  |VPLS PE with T-VSI (PE1)|
                  |                        |
        +----+    | +------+       +-----+ |  PW
        |Root|------| VLAN |-------|T-VSI|----------
        +----+    | | BRG  |       |     |----------
        +----+    | |      |-------|     |----------
        |Leaf|------|      |       |     |---------+
        +----+    | +------+       +-----+ |       |
                  |                        |       |
                  +------------------------+       |
                                                   |
                  +------------------------+       |
                  |VPLS PE with T-VSI (PE2)|       |
                  |                        |       |
        +----+    | +------+       +-----+ |  PW   |
        |Leaf|------| VLAN |-------|T-VSI|---------+
        +----+    | | BRG  |       |     |----------
        +----+    | |      |-------|     |----------
        |Leaf|------|      |       |     |----------
        +----+    | +------+       +-----+ |
                  |                        |
                  +------------------------+

   Figure 7: T-VSI Interconnected with PE Attached with Only Leaf Nodes

   If a PE is in the Optimized Mode for a PW, upon transmit, the PE
   SHOULD drop a frame if its VLAN ID matches the local leaf VLAN ID.











RFC 7796                 E-Tree Support in VPLS               March 2016


6.  Signaling for E-Tree Support

6.1.  LDP Extensions for E-Tree Support

   In addition to the signaling procedures as specified in Section 5.3.3
   of [RFC4447], this document specifies a new interface parameter sub-
   TLV to provision an E-Tree service and negotiate the VLAN mapping
   function, as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  E-Tree(0x1A) |   Length=8    |           Reserved        |P|V|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MBZ  |   Root VLAN ID        |  MBZ  |   Leaf VLAN ID        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 8: E-Tree Sub-TLV

   Where:

   o  E-Tree is the sub-TLV identifier (0x1A) as assigned by IANA.

   o  Length is the length of the sub-TLV in octets.

   o  Reserved, bits MUST be set to zero on transmit and be ignored on
      receive.

   o  P is a leaf-only bit, it is set to 1 to indicate that the PE is
      attached with only leaf nodes, and set to 0 otherwise.

   o  V is a bit indicating the sender's VLAN mapping capability.  A PE
      capable of VLAN mapping MUST set this bit, and clear it otherwise.

   o  Must Be Zero (MBZ), 4 bits MUST be set to zero on transmit and be
      ignored on receive.

   o  Root VLAN ID is the value of the local root VLAN.

   o  Leaf VLAN ID is the value of the local leaf VLAN.

   When setting up a PW for the E-Tree based VPLS, two peer PEs
   negotiate the E-Tree support using the above E-Tree sub-TLV.  Note
   that the PW type of 0x0004 SHOULD be used during the PW negotiation.

   A PE that wishes to support an E-Tree service MUST include an E-Tree
   sub-TLV in its PW Label Mapping message and include its local root
   VLAN ID and leaf VLAN ID in the TLV.  A PE that has the VLAN mapping



RFC 7796                 E-Tree Support in VPLS               March 2016


   capability MUST set the V bit to 1, and a PE attached with only leaf
   nodes SHOULD set the P bit to 1.

   A PE that receives a PW Label Mapping message with an E-Tree sub-TLV
   from its peer PE, after saving the VLAN information for the PW, MUST
   process it as follows:

      1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and
         Optimized-Mode to FALSE.

      2) If either the root VLAN ID in the message is not equal to the
         local root VLAN ID, or the leaf VLAN ID in the message is not
         equal to the local leaf VLAN ID {

             If the bit V is cleared {

                   If the PE is capable of VLAN mapping, it MUST set
                   VLAN-Mapping-Mode to TRUE;

                   Else {

                        A Label Release message with the error code "E-
                        Tree VLAN mapping not supported" is sent to the
                        peer PE and exit the process;

                        }

             }

             If the bit V is set, and the PE is capable of VLAN mapping,
             the PE with the minimum IP address MUST set
             VLAN-Mapping-Mode to TRUE;

         }

      3) If the P bit is set

         {

             If the PE is a leaf-only node itself, a Label Release
             message with a status code "Leaf-to-Leaf PW released" is
             sent to the peer PE and exits the process;

             Else the PE SHOULD set the Optimized-Mode to TRUE.

         }





RFC 7796                 E-Tree Support in VPLS               March 2016


   A PE SHOULD send a Label Mapping message with an E-Tree sub-TLV as
   per Section 5.3.3 of [RFC4447].  A PE MUST send a Label Mapping
   message with an updated E-Tree sub-TLV to all other PEs over
   corresponding LDP sessions when its role changes from leaf-only to
   not leaf-only (i.e., when a root node is added to a PE attached with
   only leaf nodes).

   If a PE has sent a Label Mapping message with an E-Tree sub-TLV but
   does not receive any E-Tree sub-TLV in its peer's PW Label Mapping
   message, the PE SHOULD then establish a raw PW with this peer as in
   traditional VPLS and set Compatible-Mode to TRUE for this PW.

   Data plane processing for this PW is as follows:

   o  If Optimized-Mode is TRUE, then data plane processing as described
      in Section 5.3.3 applies.

   o  If VLAN-Mapping-Mode is TRUE, then data plane processing as
      described in Section 5.3.1 applies.

   o  If Compatible-Mode is TRUE, then data plane processing as
      described in Section 5.3.2 applies.

   o  PW processing as described in [RFC4448] proceeds as usual for all
      cases.

   When VPLS is set up using the Pseudowire ID (PWid) Forwarding
   Equivalence Class (FEC) Element (see Appendix A of [RFC4762]), its
   E-Tree signaling is similar to the above process.  Dynamic
   re-configuration of E-Tree should be avoided for this case.  However,
   when re-configuration of E-Tree is forced on a PE for some reason
   (e.g., a configuration error), the PE may close the LDP sessions with
   its peer PEs for this VPLS instance and re-install its PW labels, so
   that its peer PEs can send out the LDP Label Mapping messages again.

















RFC 7796                 E-Tree Support in VPLS               March 2016


6.2.  BGP Extensions for E-Tree Support

   A new E-Tree extended community (0x800b) has been allocated by IANA
   for E-Tree signaling in BGP VPLS:

                  +------------------------------------+
                  | Extended community type (2 octets) |
                  +------------------------------------+
                  |  MBZ  |   Root VLAN (12 bits)      |
                  +------------------------------------+
                  |  MBZ  |   Leaf VLAN (12 bits)      |
                  +------------------------------------+
                  |  Reserved                      |P|V|
                  +------------------------------------+

                    Figure 9: E-Tree Extended Community

   Where:

   o  Must Be Zero (MBZ), 4 bits MUST be set to zero on transmit and be
      ignored on receive.

   o  Root VLAN ID is the value of the local root VLAN.

   o  Leaf VLAN ID is the value of the local leaf VLAN.

   o  Reserved, 14 bits MUST be set to zero on transmit and be ignored
      on receive.

   o  P is a leaf-only bit, it is set to 1 to indicate that the PE is
      attached with only leaf nodes, and set to 0 otherwise.

   o  V is a bit indicating the sender's VLAN mapping capability.  A PE
      capable of VLAN mapping MUST set this bit, and clear it otherwise.

   The PEs attached with both leaf and root nodes MUST support BGP
   E-Tree signaling as described in this document, and SHOULD support
   VLAN mapping in their data planes.  The traditional PE attached with
   only root nodes may also participate in an E-Tree service.  If some
   PEs don't support VLAN mapping, global VLANs as per Section 5.2 MUST
   be provisioned for an E-Tree service.

   In BGP VPLS signaling, besides attaching a Layer2 Info Extended
   Community as detailed in [RFC4761], an E-Tree Extended Community MUST
   be further attached if a PE wishes to participate in an E-Tree
   service.  The PE MUST include its local root VLAN ID and leaf VLAN ID





RFC 7796                 E-Tree Support in VPLS               March 2016


   in the E-Tree Extended Community.  A PE attached with only leaf nodes
   of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to
   1.

   A PE that receives a BGP UPDATE message with an E-Tree Extended
   Community from its peer PE, after saving the VLAN information for the
   PW, MUST process it as follows (after processing procedures as
   specified in Section 3.2 of [RFC4761]):

   1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and
      Optimized-Mode to FALSE.

   2) If either the root VLAN ID in the E-Tree Extended Community is
      not equal to the local root VLAN ID, or the leaf VLAN ID in the
      E-Tree Extended Community is not equal to the local leaf VLAN ID {

          If the bit V is cleared {

                If the PE is capable of VLAN mapping, it MUST set VLAN-
                Mapping-Mode to TRUE;

                Else {

                     Log with a message "E-Tree VLAN mapping not
                     supported" and exit the process;

                     }

          }

          If the bit V is set, and the PE is capable of VLAN mapping,
          the PE with the minimum IP address MUST set VLAN-Mapping-Mode
          to TRUE;

      }

   3) If the P bit is set {

          If the PE is a leaf-only PE itself, forbids any traffic on the
          PW;

          Else the PE SHOULD set the Optimized-Mode to TRUE.

      }

   A PE that does not recognize this attribute SHALL ignore it silently.
   If a PE has sent an E-Tree Extended Community but does not receive
   any E-Tree Extended Community from its peer, the PE SHOULD then



RFC 7796                 E-Tree Support in VPLS               March 2016


   establish a raw PW with this peer as in traditional VPLS and set
   Compatible-Mode to TRUE for this PW.

   The data plane in the VPLS is the same as described in Section 4.2 of
   [RFC4761], and data plane processing for a PW is the same as
   described at the end of Section 6.1 in this document.

7.  OAM Considerations

   The VPLS OAM requirements and framework as specified in [RFC6136] are
   applicable to E-Tree, as both Ethernet OAM frames and data traffic
   are transported over the same PW.

   Ethernet OAM for E-Tree including both service OAM and segment OAM
   frames SHALL undergo the same VLAN mapping as the data traffic; and
   root VLAN SHOULD be applied to segment OAM frames so that they are
   not filtered.

8.  Applicability

   The solution specified in this document is applicable to both LDP
   VPLS [RFC4762] and BGP VPLS [RFC4761].

   This solution is applicable to both "VPLS Only" networks and VPLS
   with Ethernet aggregation networks.

   This solution is also applicable to PBB VPLS networks.

9.  IANA Considerations

   IANA allocated the following value for E-Tree in the "Pseudowire
   Interface Parameters Sub-TLV type Registry".

   Parameter ID   Length       Description
   =======================================
   0x1A            8            E-Tree

   IANA allocated the two following new LDP status codes in the "Status
   Code Name Space" registry.

   Range/Value     E     Description
   ------------- -----   ----------------------
   0x20000003      1     E-Tree VLAN mapping not supported
   0x20000004      0     Leaf-to-Leaf PW released







RFC 7796                 E-Tree Support in VPLS               March 2016


   IANA allocated the following value for E-tree in the "Generic
   Transitive Experimental Use Extended Community Sub-Types" registry
   within the BGP Extended Community registry.

   Type Value   Sub-Type Value   Name
   ==========   ==============   ============
   0x80         0x0b             E-Tree Info

10.  Security Considerations

   This solution requires implementations to prevent leaf-to-leaf
   communication in the data plane of VPLS when its PEs are
   interconnected with PWs.  If all PEs enforce that, then network
   attacks from one leaf to another leaf are avoided, and security can
   be enhanced for customers with this solution.  However, if a PE is
   compromised or inappropriately configured, a leaf node may be taken
   as a root node and may receive traffic from other leaf nodes
   inappropriately.  Authenticity and integrity measures for LDP need to
   be considered as in RFC 5036 [RFC5036].  Security considerations as
   described in [RFC4448], [RFC4761], and [RFC4762] also apply.

11.  References

11.1.  Normative References

   [IEEE-802.1Q-2014]
              IEEE, "Bridges and Bridged Networks", IEEE 802.1Q,
              DOI 10.1109/ieeestd.2014.6991462, November 2014.

   [MEF6.2]   Metro Ethernet Forum 6.2, "EVC Ethernet Services
              Definitions Phase 3", August 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447,
              DOI 10.17487/RFC4447, April 2006,
              <http://www.rfc-editor.org/info/rfc4447>.

   [RFC4448]  Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
              "Encapsulation Methods for Transport of Ethernet over MPLS
              Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
              <http://www.rfc-editor.org/info/rfc4448>.




RFC 7796                 E-Tree Support in VPLS               March 2016


   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <http://www.rfc-editor.org/info/rfc4761>.

   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
              <http://www.rfc-editor.org/info/rfc4762>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <http://www.rfc-editor.org/info/rfc5036>.

11.2.  Informative References

   [IEEE-802.1Q-2003]
              IEEE, "Virtual Bridged Local Area Networks", IEEE 802.1,
              DOI 10.1109/IEEESTD.2003.94280, May 2003.

   [MEF4]     Metro Ethernet Forum 4, "Metro Ethernet Network
              Architecture Framework - Part 1: Generic Framework", May
              2004.

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <http://www.rfc-editor.org/info/rfc3985>.

   [RFC4664]  Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
              2 Virtual Private Networks (L2VPNs)", RFC 4664,
              DOI 10.17487/RFC4664, September 2006,
              <http://www.rfc-editor.org/info/rfc4664>.

   [RFC6136]  Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual
              Private Network (L2VPN) Operations, Administration, and
              Maintenance (OAM) Requirements and Framework", RFC 6136,
              DOI 10.17487/RFC6136, March 2011,
              <http://www.rfc-editor.org/info/rfc6136>.

   [RFC6246]  Sajassi, A., Ed., Brockners, F., Mohan, D., Ed., and Y.
              Serbest, "Virtual Private LAN Service (VPLS)
              Interoperability with Customer Edge (CE) Bridges",
              RFC 6246, DOI 10.17487/RFC6246, June 2011,
              <http://www.rfc-editor.org/info/rfc6246>.






RFC 7796                 E-Tree Support in VPLS               March 2016


   [RFC7041]  Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
              "Extensions to the Virtual Private LAN Service (VPLS)
              Provider Edge (PE) Model for Provider Backbone Bridging",
              RFC 7041, DOI 10.17487/RFC7041, November 2013,
              <http://www.rfc-editor.org/info/rfc7041>.

   [RFC7152]  Key, R., Ed., DeLord, S., Jounay, F., Huang, L., Liu, Z.,
              and M. Paul, "Requirements for Metro Ethernet Forum (MEF)
              Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private
              Network (L2VPN)", RFC 7152, DOI 10.17487/RFC7152, March
              2014, <http://www.rfc-editor.org/info/rfc7152>.

   [RFC7387]  Key, R., Ed., Yong, L., Ed., Delord, S., Jounay, F., and
              L. Jin, "A Framework for Ethernet Tree (E-Tree) Service
              over a Multiprotocol Label Switching (MPLS) Network",
              RFC 7387, DOI 10.17487/RFC7387, October 2014,
              <http://www.rfc-editor.org/info/rfc7387>.

   [VPMS]     Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
              and L. Jin, "Framework and Requirements for Virtual
              Private Multicast Service (VPMS)", Work in Progress,
              draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012.





























RFC 7796                 E-Tree Support in VPLS               March 2016


Appendix A.  Other PE Models for E-Tree

A.1.  A PE Model with a VSI and No Bridge

   If there is no bridge module in a PE, the PE may consist of Native
   Service Processors (NSPs) as shown in Figure 10 (adapted from
   Figure 5 of [RFC3985]) where any transformation operation for VLANs
   (e.g., VLAN insertion/removal or VLAN mapping) may be applied.  Thus,
   a root VLAN or leaf VLAN can be added by the NSP depending on the
   User Network Interface (UNI) type (root/leaf) associated with the AC
   over which the packet arrives.

   Further, when a packet with a leaf VLAN exits a forwarder and arrives
   at the NSP, the NSP must drop the packet if the egress AC is
   associated with a leaf UNI.

   Tagged PW and VLAN mapping work in the same way as in the typical PE
   model.

              +----------------------------------------+
              |                PE Device               |
      Multiple+----------------------------------------+
      AC      |      |          |        Single        | PW Instance
      <------>o  NSP #          +      PW Instance     X<---------->
              |      |          |                      |
              |------|  VSI     |----------------------|
              |      |          |        Single        | PW Instance
      <------>o  NSP #Forwarder +      PW Instance     X<---------->
              |      |          |                      |
              |------|          |----------------------|
              |      |          |        Single        | PW Instance
      <------>o  NSP #          +      PW Instance     X<---------->
              |      |          |                      |
              +----------------------------------------+

           Figure 10: A PE Model with a VSI and No Bridge Module

   This PE model may be used by a Multi-Tenant Unit switch (MTU-s) in a
   Hierarchical VPLS (H-VPLS) network or a Network-facing PE (N-PE) in
   an H-VPLS network with non-bridging edge devices, wherein a spoke PW
   can be treated as an AC in this model.










RFC 7796                 E-Tree Support in VPLS               March 2016


A.2.  A PE Model with External E-Tree Interface

             +----------------------------------------+
              |                PE Device               |
      Root    +----------------------------------------+
      VLAN    |                 |        Single        | PW Instance
      <------>o                 +      PW Instance     X<---------->
              |                 |                      |
              |       VSI       |----------------------|
              |                 |        Single        | PW Instance
              |    Forwarder    +      PW Instance     X<---------->
              |                 |                      |
      Leaf    |                 |----------------------|
      VLAN    |                 |        Single        | PW Instance
      <------>o                 +      PW Instance     X<---------->
              |                 |                      |
              +----------------------------------------+

           Figure 11: A PE Model with External E-Tree Interface

   A more simplified PE model is depicted in A.2, where Root/Leaf VLANs
   are directly or indirectly connected over a single PW to the same VSI
   forwarder in a PE, any transformation of E-Tree VLANs, e.g., VLAN
   insertion/removal or VLAN mapping, can be performed by some outer
   equipment, and the PE may further translate these VLANs into its own
   local VLANs.  This PE model may be used by an N-PE in an H-VPLS
   network with bridging-capable devices, or scenarios such as providing
   E-Tree Network-to-Network interfaces.























RFC 7796                 E-Tree Support in VPLS               March 2016


Acknowledgements

   The authors would like to thank Stewart Bryant, Lizhong Jin, Deborah
   Brungard, Russ Housley, Stephen Farrell, Sheng Jiang, Alvaro Retana,
   and Ben Campbell for their detailed reviews and suggestions, and
   Adrian Farrel, Susan Hares, Shane Amante, and Andrew Malis for their
   valuable advice.  In addition, the authors would like to thank Ben
   Mack-crane, Edwin Mallette, Donald Fedyk, Dave Allan, Giles Heron,
   Raymond Key, Josh Rogers, Sam Cao, and Daniel Cohn for their valuable
   comments and discussions.

Contributors

   The following people made significant contributions to this document:

   Frederic Jounay
   Salt Mobile SA
   Rue du Caudray 4
   1020 Renens
   Switzerland

   Email: frederic.jounay@salt.ch

   Florin Balus
   Alcatel-Lucent
   701 East Middlefield Road
   Mountain View, CA 94043
   United States

   Email: florin.balus@alcatel-lucent.com

   Wim Henderickx
   Alcatel-Lucent
   Copernicuslaan 50
   2018 Antwerp
   Belgium

   Email: wim.henderickx@alcatel-lucent.com

   Ali Sajassi
   Cisco
   170 West Tasman Drive
   San Jose, CA 95134
   United States

   Email: sajassi@cisco.com





RFC 7796                 E-Tree Support in VPLS               March 2016


Authors' Addresses

   Yuanlong Jiang (editor)
   Huawei
   Bantian, Longgang district
   Shenzhen  518129
   China

   Email: jiangyuanlong@huawei.com


   Lucy Yong
   Huawei
   207 Estrella Xing
   Georgetown, TX  78628
   United States

   Email: lucyyong@huawei.com


   Manuel Paul
   Deutsche Telekom
   Winterfeldtstrasse 21
   Berlin  10781
   Germany

   Email: manuel.paul@telekom.de