Skip to main content

Transparent Interconnection of Lots of Links (TRILL) over an MPLS PSN (Packet Switched Network)
draft-yong-trill-trill-o-mpls-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Donald E. Eastlake 3rd , Jon Hudson , Lucy Yong , Sam Aldrin
Last updated 2011-10-23
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-yong-trill-trill-o-mpls-00
Network Working Group                                           L. Yong
Internet Draft                                              D. Eastlake
Intended status: Informational                                S. Aldrin
                                                                 Huawei
                                                              J. Hudson
                                                                Brocade
Expires: April 2012                                    October 23, 2011

     Transparent Interconnection of Lots of Links (TRILL) over an MPLS
                       PSN (Packet Switched Network)
                   draft-yong-trill-trill-o-mpls-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the DNSEXT working group mailing list: <rbridge@postel.org>.

   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/1id-abstracts.html

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

   Copyright Notice

   Copyright (c) 2011 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

Yong & Eastlake         Expires April 23, 2012                 [Page 1]
Internet-Draft             TRILL over MPLS                 October 2011

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

   Abstract

   This informational document describes ways to interconnect TRILL
   RBridges over WAN connections by using MPLS Pseudo Wire (PW) or
   Virtual Private LAN Service (VPLS) with existing TRILL and MPLS
   standards. It also describes the combination of RBridge and MPLS to
   provide a hierarchical scalable L2VPN.

Table of Contents

   1. Introduction...................................................2
   2. Use Cases......................................................3
      2.1. Point-To-Point Interconnection............................3
      2.2. Multi-Access Link Interconnection.........................6
      2.3. Hierarchical L2VPN with RBridges and MPLS.................8
   3. RBridge Behavior for MPLS Pseudo Wire.........................10
   4. Security Considerations.......................................11
   5. IANA Considerations...........................................11
   6. Acknowledgements..............................................11
   7. References....................................................11
      7.1. Normative References.....................................11
      7.2. Informative References...................................13

1. Introduction

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   standard [RFC6325] [RFC6326] provides optimal pair-wise data frame
   forwarding without configuration in multi-hop networks with
   arbitrary topology, and support for multipathing of both unicast and
   multicast traffic. TRILL enables a new method to construct a campus
   or data center network. Devices that implement TRILL are called
   RBridges.

   This document describes the use cases of TRILL over an MPLS PW or
   VPLS, and introduces a new hierarchical L2VPN architecture that uses
   RBridges and IP/MPLS and documents the related configurations and
   references for the proper interworking.

Yong & Eastlake         Expires April 23, 2012                 [Page 2]
Internet-Draft             TRILL over MPLS                 October 2011

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

   Acronyms used in this document include the following:

   AC - Attachment Circuit

   CE - Customer Edge

   IS-IS - Intermediate System to Intermediate System

   MPLS - Multi-Protocol Label Switching

   PE - Provider Edge

   PPP - Point to Point Protocol

   PW - Pseudo Wire

   RBridge - Routing Bridge

   TRILL - Transparent Interconnection of Lots of Links

   VPLS - Virtual Private LAN Service

   VSI - Virtual Service Instance

2. Use Cases

   RBridge campuses at different locations may interconnect by networks
   that are implemented with different technologies to form one RBridge
   campus. This section describes use cases assuming that IP/MPLS
   technology is available. From the MPLS network view, an RBridge
   device acts as a Customer Edge (CE) device and connects to PE via an
   attachment circuit (AC). RBridges [RFC6325] support both point-to-
   point links and multi-access links. Section 2.1 describes point-to-
   point link, i.e. TRILL over either Ethernet or PPP point-to-point
   link that is over an MPLS network. Section 2.2 describes TRILL over
   a bridged LAN that is implemented by MPLS/VPLS. Section 2.3
   introduces a new hierarchical L2VPN solution that uses the RBridges
   and MPLS tiered architecture.

2.1. Point-To-Point Interconnection

   Two RBridges are interconnected by either Ethernet or PPP link that
   is over a MPLS network. A Pseudo wire (PW) is configured between a

Yong & Eastlake         Expires April 23, 2012                 [Page 3]
Internet-Draft             TRILL over MPLS                 October 2011

   pair of PEs to provide part of the point-to-point link between two
   RBridges. Figure 1 illustrates this architecture. Each RBridge
   device connects to a PE via AC and acts as a CE device. MPLS PSN is
   bordered at the PEs. The TRILL link across the IP/MPLS PSN makes the
   left site and right site into one RBridge campus.

   MPLS already supports many pseudo wire transport encapsulations.
   [RFC4446] Two types of TRILL links between RBridges have been
   standardized: Ethernet [RFC6325] and PPP [RFC6361]. PW
   encapsulations for these two interfaces are specified in [RFC4448]
   and [RFC4618], respectively. When an RBridge port connecting to AC
   is configured with a point-to-point Ethernet link type, two PEs can
   be configured as a PW with Ethernet encapsulation [RFC4448]. The PW
   between two PEs can be auto-configured [RFC4447] or manually
   configured; the two RBridges then appear directly interconnected
   with an Ethernet link. When an RBridge port connecting to AC is
   configured with the PPP link type, two PEs MUST be configured as a
   PW with PPP encapsulation.[RFC4618] After the PW is established
   between two PEs, the two RBridges then appear directly
   interconnected with a PPP link. The TRILL link is automatically
   configured over an Ethernet link or PPP link. The PW provides
   transparent transport between ACs.

   Note: 1) For Ethernet link configuration, PE SHOULD use the Raw mode
   and non-service-delimiting, which provides a transparent transport.
   2) The PPP link configuration will be more efficient than the
   Ethernet point-to-point configuration; it saves about 16 bytes per
   frame by replacing the TRILL Outer.MacDA, Outer.MacSA, Outer.VLAN,
   and outer Ethertype with a PPP code point. [RFC6361]

                    <----------TRILL Link---------->
           *-------*    <----------PW---------->    *-------*
           |       | AC +----+    +---+   +----+ AC |       |
           |  RB   +----| PE |----| P |---| PE |----+ RB    |
           |Site A |    +----+    +---+   +----+    |Site B |
           |       |    {        PSN           }    |       |
           *-------*                                *-------*
           {              One RBridge Campus                }

            Figure 1 P2P TRILL Link over IP/MPLS PSN Use Case I

   An RBridge is a router and could support PE capabilities. As the
   networks converg, it is possible that one operator runs both an
   RBridge campus as well as the core MPLS network. Figure 2

Yong & Eastlake         Expires April 23, 2012                 [Page 4]
Internet-Draft             TRILL over MPLS                 October 2011

   illustrates this use case, in which RBridges are also MPLS PE
   enabled devices. The interworking between the RBridge network and
   the MPLS PSN is within the device. This has a similar architecture
   to MPLS/VPLS [RFC4762]. In this case, a virtual Ethernet interface
   is configured at the RBridge component; an Ethernet encapsulated PW
   is configured between two interfaces, which brings up an TRILL link
   between two RBridge components. The outer MAC address can be a local
   Ethernet address. In this case, the Campus RBridges run in the
   client layer and MPLS runs in the Server Layer; RB/PE devices
   support both client and server layer control plane and data plane
   functions.

            *---------*                        *---------*
            |         |<---- TRILL Link------->|         |
            |RB Site A|      (Client Layer)    |RB Site B|
            |     +-------+     +---+      +-------+     |
            |     | RB/PE |-----| P |------| PE/RB |     |
            |     +-------+     +---+      +-------+     |
            |         |<---------PW ---------->|         |
            |         |      (Server Layer)    |         |
            *---------*                        *---------*
                      {           PSN          }
            {              One RBridge Campus            }

           Figure 2 P2P TRILL-Link over IP/MPLS PSN Use Case II

   In both case I and II, the PE treats an RBridge as a generic CE and
   has no awareness of TRILL capability on the CE. Use case I enables
   the business models when the RBridge campus and Core MPLS may be
   operated by different operators or the same operator. In the case of
   different operators, the core MPLS operator can sell a VPWS service
   to RBridge operator. Use case II provides the model when the RBridge
   campus and the core network are operated by the same operator but
   use different technologies in each network.

   Technically speaking, it is possible to create a specially
   designated TRILL encapsulated pseudo wire for point-to-point TRILL
   over MPLS. However, the authors think that this is not worth the
   effort because of available technologies as mentioned above,
   particularly the highly-efficient PPP link technology.

   A PW may cross multiple MPLS domains.[RFC5659] In this case,
   RBridges connect to T-PEs and it works in the same way as a single
   domain. The PSN can provide transport resiliency for a PW. The dual
   homing (two ACs) can be used for AC protection. In this case, two

Yong & Eastlake         Expires April 23, 2012                 [Page 5]
Internet-Draft             TRILL over MPLS                 October 2011

   TRILL links are established; RBridge device perform load balance
   over two links.

2.2. Multi-Access Link Interconnection

   Multiple RBridges may interconnect via an 802.1Q Bridged LAN that
   acts as a hub. The bridged LAN simply forwards on the outer Ethernet
   header of the TRILL frames. This configuration creates what appears
   to each connected RBridge as a multi-access link. In other words,
   each RBridge connecting to a bridged LAN has connectivity to every
   other RBridges connecting to the same LAN.

   MPLS/VPLS can provide the same capability when multiple parts of an
   RBridge campus are interconnected over an IP/MPLS PSN and make each
   RBridge attaching to the VPLS to appear as having a multi-access
   TRILL link. Figure 3 shows the use of MPLS/VPLS for RBridge
   interconnection. One RBridge campus is split between three different
   sites. One VPLS instance is configured on three PEs and the PWs are
   configured for the VPLS instance. Each RBridge Site connects to the
   VSI on a PE via an AC (Ethernet Type). The VSI on a PE forwards
   TRILL frames based on the outer Ethernet header of the frames.
   [RFC6325] Either BGP [RFC4761] or LDP [RFC4762] protocol can be used
   to automatically construct the VPLS instance on the PEs. A PE may
   connect to several different RBridge campuses that belong to
   different customers. Separated VPLS instances are configured for
   individual customers and customer traffic is completely isolated by
   VPLS instance. The PE treats an RBridge as a generic CE and has no
   awareness of TRILL.

Yong & Eastlake         Expires April 23, 2012                 [Page 6]
Internet-Draft             TRILL over MPLS                 October 2011

         *-------*      ...........................    *-------*
         |       |      .             MPLS/VPLS   .    |       |
         | RB    |AC +----+       PW           +----+AC| RB    |
         | Site 1+---|VSI ********************** VSI|--+ Site 2|
         |       |   | PE *****            ***** PE |  |       |
         |       |   +----+    ****    ****    +----+  |       |
         |       |      .         +*--*+          .    *-------*
         *-------*      ..........|VSI |...........
                                  | PE |
                                  +----+
                                    |AC
                                    |
                               *---------*
                               |         |
                               |RB Site 3|
                               |         |
                               *---------*

              Figure 3 Multi-Access TRILL Link over MPLS/VPLS

   The outer Ethernet MAC of TRILL frames may be either a next-hop
   RBridge MAC address (for unicast frames) or one of TRILL defined
   multicast addresses (ALL-IS-IS-RBridges and All-RBridges).[RFC6325]
   The VSI at each PE learns the source MAC addresses on each VSI
   interface and forward the frame based on the destination MAC. For
   the multicast frames, the VSI replicates the frames to all PWs it
   associates. If a VPLS is configured with some optimization
   capability [VPLS-BCAST], the multicast frames can be delivered over
   a point-to-multipoint PW while unicast frames are carried over a
   point-to-point PW.

   The scenario in Figure 3 can also be extended to multiple RBridges
   interconnections when a device serves both RBridge and PE functions.
   This use case is discussed in the following section.

   Note: If the CEs associated with one VPLS instances happen to
   include some RBridges and some end stations or IEEE 802.1Q bridges
   to end stations, TRILL will, by default, be able to handle this by
   providing both through service and end station service. However, the
   end station addresses will be visible to the VPLS instance. If, in
   such a case, all the RBridge ports connected to the VPLS are
   configured as trunk ports (see Section 4.9.2 of [RFC6325]), then
   they will not provide any end station service.

Yong & Eastlake         Expires April 23, 2012                 [Page 7]
Internet-Draft             TRILL over MPLS                 October 2011

2.3. Hierarchical L2VPN with RBridges and MPLS

   H-VPLS in [RFC4762] describes a two-tier hierarchical solution for
   the purpose of pseudo wire (PW) scalability improvement. This
   improvement is achieved by reducing the number of PE devices
   connected in a full-mesh topology through connecting CE devices via
   the lower-tier access network, which in turn is connected to the
   top-tier core network. However, H-VPLS solutions in [RFC4762]
   require learning and forwarding based on customer MAC addresses,
   which poses scalability issues as the number of VPLS instances and
   customer MAC addresses increase. [PBB-VPLS] describes how to use PBB
   (Provider Backbone Bridges) at the lower-tier access network to
   solve the scalability issue, in which the transit network nodes only
   learn and forward on PBB port MAC addresses instead of customer MAC
   addresses.

   RBridges over IP/MPLS provide an alternative solution for a scalable
   L2VPN over WAN networks. Figure 4 depicts the hierarchical L2VPN
   architecture with RBridge/MPLS technologies. An IP/MPLS network
   serves as the top-tier core network function while an RBridge campus
   serves as the low-tier access network function. A RB/PE enabled
   device is placed at the boundary between the two-tier networks. A PW
   is configured between each pair of PE components in the top-tier
   IP/MPLS network, which constructs a full mesh TRILL links among the
   RB/PE devices. The RBridge component on a RB/PE device and other
   RBridges at the same site serves as the low-tier access network.
   Customer CEs connect to RBridges at each site directly. This
   architecture provides E-LAN or E-VLAN connectivity among customer
   CEs connecting to the RBridge campus sites. The transit RBridge node
   only forwards and learns other RBridge addresses and the number of
   PWs in the top-tier core network is not relate to the number of
   devices connecting to Customer CEs.  This makes the solution scale
   very well. In addition, TRILL technology already supports multi-
   TRILL links from one RBridge to one or multiple RBridges and
   prevents loops, which provides the flexibility to construct the
   networks based on their network condition. Figure 4 shows that one
   RBridge in site 1 connects two RB/PE devices and one RB/PE device
   connects two RBridges at Site 2 via Ethernet links.

Yong & Eastlake         Expires April 23, 2012                 [Page 8]
Internet-Draft             TRILL over MPLS                 October 2011

       +---------+      ...........................    +--------+
       |         |      .       IP/MPLS Core      .    |        |
       |         |      .                         .    |        +--
   CE--+         |Eth+----+        PW          +----+  |        |
       | RBridge +---| RB/|********************| RB/|--+RBridge |CEs
   . --+         +-+ | PE |****            ****| PE |\ |        +--
   .   |  Site 1 | | +----+    ****    ****    +----+ -+ Site 2 |
   . --+         | |    .         +*--*+          .    |        |
       |         | |    ..........| RB/|...........    +--------+
   CE--+         | +--------------| PE |
       |         |   Eth. Itfc    +----+
       +---------+                  |Eth. Itfc
                                    |
                                +---------+
                                | RBrdige |
                                |         |
                                |  Site 3 |
                                +-+----+--+
                                  |... |
                                   CEs

             Figure 4 Hierarchical L2VPN with RBridge and MPLS

   The following advantages of using RBridge/MPLS based L2VPN: 1)
   Scalability improvement; 2) Auto-configuration; 3) Good efficiency
   and loop prevention; and 4) Multipath support.

   The solution also has the following advantages: 1) Since RBridge
   terminates customer spanning tree protocol (STP), individual STPs in
   attached customer bridged LANs will be separated and will converge
   faster. 2) low over head per frame in number of added bytes and
   scalable routing computations; 3) MPLS just provides P2P PWs, MAC
   forwarding and learning does not exist within the MPLS network, thus
   multi-homing issue does not exist.

   Note: it is good to mention another scenario when the device has
   both RB/PE capabilities, i.e. configure a VPLS instance among PE
   components in the top-tier network to provide a multi-access link to
   RBridge component on the RB/PE devices. Although this solution can
   also provide scalability, it requires both the RBridge component and
   VSI/PE component on a device to perform the same MAC forwarding and
   learning functions, which is redundant. The number of PWs configured
   in this case is the same as of the number of PWs in Figure 4. Thus,
   authors do not recommend this configuration. For the same reason,
   the use case in Section 2.2 is not viewed as the recommended L2VPN
   solution for the WAN networks. Instead, it is useful when a Core

Yong & Eastlake         Expires April 23, 2012                 [Page 9]
Internet-Draft             TRILL over MPLS                 October 2011

   Service Provider provides a VPLS service to the customer who needs
   to interconnect the RBridge campus sites over IP/MPLS PSN.

   It is possible to construct a Tiered L2VPN in the combination of
   Figure 4 and 3, i.e. some locations use RB/PE enabled device and
   some location use separated RBridge and PE devices in a Hierarchical
   L2VPN. When using separated RBridge and PE devices at some
   locations, the MPLS network has to run a VPLS instance, which makes
   RB/PE devices perform MAC forwarding and learning function two
   times. In addition, it becomes operator responsibility to ensure
   that the top tiered MPLS core is fully surrounded by an RBridge
   campus. Missing configuration may increase the scalability problem
   in the core network.

   Auto configuration for the Hierarchical L2VPN will be addressed in
   another draft.

3. RBridge Behavior for MPLS Pseudo Wire

   This section describes RBridge behaviors for TRILL Ethernet or TRILL
   PPP links over MPLS pseudo wire (PW) as described in Sections 2.1 .

   1. For two RBridge ports connecting via a PPP PW, the ports MUST be
      configured as IS-IS point-to-point. Thus TRILL will use IS-IS P2P
      Hellos that, per "Point-to-Point IS to IS Hello PDU" (section 9.7
      of [IS-IS]), do not use Neighbor TLVs in the same manner as on a
      multi-access link. However, per section 4.2.4.1 of [RFC6325],
      three-way IS-IS handshake using extended circuit IDs is required.

   2. For two RBridge ports connecting via an Ethernet PW, it is
      RECOMMENED that the ports be configured as IS-IS point-to-point
      for the same reason able. Note: an RBridge port by default
      supports multi-access links.

   3. Any MPLS forwarder within an MPLS PSN does not change the TRILL
      Header Hop Count. RBridges is never aware of the packet
      forwarders in MPLS PSN.

   4. If it is desired for MPLS PSN to perform QoS in the same way as
      in the RBridge campus, RBridges MUST be configured to send an
      Outer.VLAN tag on the RBridge port. The PE can then copy the
      priority value from the Outer.VLAN tag to the COS filed of the PW
      label prior to the forwarding. [RFC5462]

Yong & Eastlake         Expires April 23, 2012                [Page 10]
Internet-Draft             TRILL over MPLS                 October 2011

   5. TRILL MTU-probe and TRILL MTU-ack messages (section 4.3.2 of
      [RFC6325]) are not needed on a pseudo wire link.  Implementations
      MUST NOT send MTU-probe and SHOULD NOT reply to these messages.
      The MTU pseudo wire interface parameter SHOULD be used instead.
      PE Must configure the MTU size as the originating RBridges Size
      specified in Section 4.3.1 of [RFC6325].

4. Security Considerations

   The IS-IS authentication mechanism [RFC5304] [RFC5310], at the TRILL
   IS-IS layer, can be used to prevent fabrication of link-state
   control messages over TRILL links including those discussed in this
   document.

   For general TRILL protocol security considerations, see [RFC6325].

   The use case does not introduce any security considerations for MPLS
   network.

5. IANA Considerations

   No IANA action is required by this document.

6. Acknowledgements

   The authors sincerely acknowledge the contributions of Ben Mack-
   Crane and Sue Hares.

7. References

7.1. Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels," BCP 14 and RFC 2119, March 1997

   [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
             Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

   [RFC4447] Martini, L., etc, "Pseudowire Setup and Maintenance Using
             the Label Distribution Protocol (LDP)", RFC4447, April
             2006.

   [RFC4448] Martini, L., "Encapsulation Methods for Transport of
             Ethernet over MPLS Networks", BCP 116, RFC 4446, April
             2006.

Yong & Eastlake         Expires April 23, 2012                [Page 11]
Internet-Draft             TRILL over MPLS                 October 2011

   [RFC4618] Martini, L., "Encapsulation Methods for Transport of
             PPP/High-Level Data Link Control (HDLC) over MPLS
             Networks", BCP 116, RFC 4618, September 2006.

   [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
             (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
             4761, January 2007.

   [RFC4762] Lasserre, M. and Kompella, V, "Virtual Private LAN Service
             (VPLS) Using Label Distribution Protocol (LDP) Signaling",
             RFC4762, January 2007

   [RFC5304] Li, T. and Atkinson, R, "IS-IS Cryptographic
             Authentication," RFC 5304, October 2008

   [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
             and M. Fanto, "IS-IS Generic Cryptographic
             Authentication", RFC 5310, February 2009

   [RFC5462] Andersson, L. and Asati, R., "Multiprotocol Label
             Switching (MPLS)Label Stack entry: "Exp" Field Rename to
             "Traffic Class" Field", RFC5462, February 2009

   [RFC5659] Bocci, M and Bryant, S, "An Architecture for Multi-Segment
             Pseudowire Emulation Edge-to-Edge", RFC 5659, October
             2009.

   [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and
             A.Ghanwani, "Routing Bridges (RBridges): Base Protocol
             Specification", RFC6325, July 2011.

   [RFC6326] Eastlake 3rd, D., Banerjee, A., Dutt, D., Perlman, R., and
             Ghanwani, A. "Transparent Interconnection of Lots of Links
             (TRILL) Use of IS-IS", RFC6326, July 2011.

   [RFC6361] Carlson, J., and D. Eastlake, "PPP Transparent
             Interconnection of Lots of Links (TRILL) Protocol Control
             Protocol", RFC6361, August 2011.

Yong & Eastlake         Expires April 23, 2012                [Page 12]
Internet-Draft             TRILL over MPLS                 October 2011

7.2. Informative References

   [IS-IS]  International Organization for Standardization,
             "Intermediate system to Intermediate system intra-domain
             routing information exchange protocol for use in
             conjunction with the protocol for providing the
             connectionless-mode Network Service (ISO 8473)", ISO/IEC
             10589:2002, Second Edition, Nov 2002

   [VPLS-BCAST] Delord, S, and Key, R., "Extension to LDP-VPLS for
             Ethernet Broadcast and Multicast", draft-ietf-l2vpn-ldp-
             vpls-broadcast-exten-02, work in progress, 2011.

   [PBB-VPLS] Sajarssi, A, etc, "VPLS Interoperability with Provider
             Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop, work
             in progress, 2011

Yong & Eastlake         Expires April 23, 2012                [Page 13]
Internet-Draft             TRILL over MPLS                 October 2011

Authors' Addresses

   Lucy Yong
   Huawei Technologies (USA)
   5340 Legacy Drive
   Plano, TX 75025

   Phone: +1-469-277-5837
   Email: lucy.yong@huawei.com

   Donald E. Eastlake, 3rd
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com

   Sam Aldrin
   Huawei Technologies
   2330 Centeral Expressway
   Santa Clara, CA 95050

   Phone: +1-408-330-4517
   Email: sam.aldrin@huawei.com

   Jon Hudson
   Brocade
   130 Holger Way
   San Jose, CA 95134

   Phone: +1-408-333-4062
   jon.hudson@brocade.com

Yong & Eastlake         Expires April 23, 2012                [Page 14]