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

Versions: 00 01 02 03 04 05 06 07 RFC 7041

INTERNET-DRAFT                                         F. Balus (editor)
Intended Status: Informational                            Alcatel-Lucent
Expires: December 15, 2013                          Ali Sajassi (editor)
                                                                   Cisco
                                                    Nabil Bitar (editor)
                                                                 Verizon

                                                           June 13, 2013






       Extensions to VPLS PE model for Provider Backbone Bridging
               draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt


Abstract


   IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines
   an architecture and bridge protocols for interconnection of multiple
   Provider Bridge Networks (PBNs). PBB was defined in IEEE as a
   connectionless technology based on multipoint VLAN tunnels.  PBB can
   be used to attain better scalability in terms of number of customer
   MAC addresses and number of service instances that can be supported.

   Virtual Private LAN Service (VPLS) [RFC4664] provides a framework for
   extending Ethernet LAN services, using MPLS tunneling capabilities,
   through a routed MPLS backbone without running RSTP or MSTP across
   the backbone. As a result, VPLS has been deployed on a large scale in
   service provider networks.

   This draft discusses extensions to the VPLS Provider Edge (PE) model
   required to incorporate desirable PBB components while maintaining
   the Service Provider fit of the initial model.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.



Balus et al.           Expires December 15, 2013                [Page 1]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   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 and License Notice

   Copyright (c) 2013 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. General terminology . . . . . . . . . . . . . . . . . . . . . .  4
   3. PE Reference Model  . . . . . . . . . . . . . . . . . . . . . .  6
   4. Packet Walkthrough  . . . . . . . . . . . . . . . . . . . . . .  9
   5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6. Efficient Packet replication in PBB VPLS  . . . . . . . . . . . 11
   7. PBB VPLS OAM  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
   9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13




Balus et al.           Expires December 15, 2013                [Page 2]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


1. Introduction

   IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines
   an architecture and bridge protocols for interconnection of multiple
   Provider Bridge Networks (PBNs). PBB provides data plane hierarchy
   and new addressing designed to improve the scalability of MAC
   addresses and service instances in Provider Backbone Networks. A
   number of Ethernet control plane protocols such as Rapid Spanning
   Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP) and
   Shortest Path Bridging (SPB), could be deployed as the core control
   plane for loop avoidance and load balancing for PBB. The
   applicability of these control protocols is out of scope for this
   document.

   Virtual Private LAN Service (VPLS) provides a solution for extending
   Ethernet LAN services, using MPLS tunneling capabilities, through a
   routed MPLS backbone without requiring the use of an native Ethernet
   control plane protocol across the backbone. VPLS use of the
   structured FEC 129 [RFC4762] also allows for inter-domain, inter-
   provider connectivity and enables auto-discovery options across the
   network improving the service delivery options.

   A hierarchical solution for VPLS was introduced in [RFC4761] and
   [RFC4762] for the purpose of improved scalability and to provide
   efficient handling of packet replication. These improvements are
   achieved by reducing the number of Provider Edge (PE) devices
   connected in a full-mesh topology through the creation of two-tier
   PEs. A User-facing PE (U-PE) aggregates all the CE devices in a
   lower-tier access network and then connects to the Network-facing PE
   (N-PE) device(s) deployed around the core domain. In VPLS, Media
   Access Control (MAC) address learning and forwarding are done based
   on customer MAC addresses (C-MACs), which poses scalability issues on
   the N-PE devices as the number of VPLS instances (and thus customer
   MAC addresses) increases. Furthermore, since a set of PWs is
   maintained on a per customer service instance basis, the number of
   pseudowires (PWs) required at N-PE devices is proportional to the
   number of customer service instances multiplied by the number of N-PE
   devices in the full-mesh set. This can result in scalability issues
   (in terms of PW manageability and troubleshooting) as the number of
   customer service instances grows.

   This document describes how PBB can be integrated with VPLS to allow
   for useful PBB capabilities while continuing to avoid the use of MSTP
   in the backbone. The combined solution referred in this document as
   PBB-VPLS results in better scalability in terms of number of service
   instances, PWs and Customer MACs (C-MACs) that need to be handled in
   the VPLS PEs.




Balus et al.           Expires December 15, 2013                [Page 3]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   Section 2 gives a quick terminology reference. Section 3 covers the
   reference model for PBB VPLS PE. Section 4 describes the packet
   walkthrough. Section 5 to 7 discusses the PBB-VPLS usage of existing
   VPLS mechanisms - control plane, efficient packet replication,
   Operations, Administration, and Maintenance (OAM).


2. General terminology

   Some general terminology is defined here; most of the terminology
   used is from [IEEE.802.1Q-2011], [RFC4664] and [RFC4026]. Terminology
   specific to this memo is introduced as needed in later sections.

   802.1ad: See PB.

   802.1ah: See PBB.

   B-BEB: A backbone edge bridge positioned at the edge of a provider
   backbone bridged network. It contains a B-component that supports
   bridging in the provider backbone based on Backbone MAC (B-MAC) and
   B-TAG information

   B-MAC: The backbone source or destination MAC address fields defined
   in the PBB provider MAC encapsulation header.

   BEB: A backbone edge bridge positioned at the edge of a provider
   backbone bridged network. It can contain an I-component, B-component
   or both I and B components.

   B-component: A bridging component contained in backbone edge and core
   bridges that bridges in the backbone space (B-MAC addresses, B-VLAN)

   B-TAG:  field defined in the PBB provider MAC encapsulation header
   that conveys the backbone VLAN identifier information. The format of
   the B-TAG field is the same as that of an 802.1ad S-TAG field.

   B-Tagged Service Interface: This is the interface between a BEB and
   BCB in a provider backbone bridged network. Frames passed through
   this interface contain a B-TAG field.

   B-VID: The specific VLAN identifier carried inside a B-TAG

   B-VLAN: The backbone VLAN associated with a B-component.

   B-PW: The pseudowire used to interconnect B-component instances.

   CVID: The VLAN identifier in a customer VLAN.




Balus et al.           Expires December 15, 2013                [Page 4]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   DA: Destination Address

   I-component: A bridging component contained in a backbone edge bridge
   that bridges in the customer space (customer MAC addresses, S-VLAN)

   IB-BEB: A backbone edge bridge positioned at the edge of a provider
   backbone bridged network. It contains an I-component for bridging in
   the customer space (customer MAC addresses, service VLAN IDs) and a
   B-component for bridging the provider's backbone space (B-MAC, B-
   TAG).

   I-BEB: A backbone edge bridged positioned at the edge of a provider
   backbone bridged network. It contains an I-component for bridging in
   the customer space (customer MAC addresses, service VLAN IDs).

   I-SID: The 24-bit service instance field carried inside the I-TAG. I-
   SID defines the service instance that the frame should be "mapped
   to".

   I-TAG: A field defined in the PBB provider MAC encapsulation header
   that conveys the service instance information (I-SID) associated with
   the frame.

   I-Tagged Service Interface: This the interface defined between the I
   and B components inside an IB-BEB or between two B-BEB. Frames passed
   through this interface contain an I-TAG field

   PB: Provider Bridge IEEE amendment (802.1ad) to 802.1Q for "QinQ"
   encapsulation and bridging of Ethernet frames [IEEE.802.1Q-2011].

   PBB: Provider Backbone Bridge IEEE amendment (802.1ah) to 802.1Q for
   "MAC tunneling" encapsulation and bridging of frames across a
   provider network [IEEE.802.1Q-2011].

   PBBN: Provider Backbone Bridged Network

   PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ)
   technology.

   SA: Source Address

   S-TAG: A field defined in the 802.1ad QinQ encapsulation header that
   conveys the service VLAN identifier information (S-VLAN).

   S-Tagged Service Interface: This the interface defined between the
   customer (CE) and the I-BEB or IB-BEB components. Frames passed
   through this interface contain an S-TAG field.




Balus et al.           Expires December 15, 2013                [Page 5]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   S-VLAN: The specific service VLAN identifier carried inside an S-TAG

   SVID: The VLAN identifier in a service VLAN.

   TAG: In Ethernet a header immediately following the Source MAC
   Address field of the frame.

3. PE Reference Model

   The following gives a short primer on Provider Backbone Bridge (PBB)
   before describing the PE reference model for PBB-VPLS. The internal
   components of a PBB bridge module are depicted in Figure 1.


              +-------------------------------+
              |       PBB Bridge Model        |
              |                               |
   +---+      |  +------+      +-----------+  |
   |CE |---------|I-Comp|------|           |  |
   +---+      |  |      |      |           |--------
              |  +------+      |           |  |
              |     o          |   B-Comp  |  |
              |     o          |           |--------
              |     o          |           |  |
   +---+      |  +------+      |           |  |
   |CE |---------|I-Comp|------|           |--------
   +---+  ^   |  |      |  ^   |           |  |   ^
          |   |  +------+  |   +-----------+  |   |
          |   +------------|------------------+   |
          |                |                      |
          |                |                      |
        S-tagged         I-tagged              B-tagged
        Service I/F      Service I/F           Service Interface (I/F)

                       Figure 1: PBB Bridge Model

   Provider Backbone Bridges (PBBs) [IEEE.802.1Q-2011] offers a scalable
   solution for service providers to build large bridged networks. The
   focus of PBB is primarily on improving two main areas with provider
   Ethernet bridged networks:

     - MAC-address table scalability
     - Service instance scalability

   To obviate the above two limitations, PBB introduces a hierarchical
   network architecture with associated new frame formats which extend
   the work completed by Provider Bridges (PB). In the PBBN
   architecture, customer networks (using PB) are aggregated into



Balus et al.           Expires December 15, 2013                [Page 6]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   Provider Backbone Bridge Networks (PBBNs) which utilize the IEEE PBB
   frame format. The frame format employs a MAC tunneling encapsulation
   scheme for tunneling customer Ethernet frames within provider
   Ethernet frames across the PBBN. A VLAN identifier (B-VID) is used to
   segregate the backbone into broadcast domains and a new 24-bit
   service identifier (I-SID) is defined and used to associate a given
   customer MAC frame with a provider service instance (also called the
   service delimiter). It should be noted that in [IEEE.802.1Q-2011]
   there is a clear segregation between provider service instances
   (represented by I-SIDs) and provider VLANs (represented by B-VIDs)
   which was not the case for PB.

   As shown in the figure 1, a PBB bridge may consist of a single B-
   component and one or more I-components. In simple terms, the B-
   component provides bridging in provider space (B-MAC, B-VLAN) and the
   I-component provides bridging in customer space (C-MAC, S-VLAN). The
   customer frame is first encapsulated with the provider backbone
   header (B-MAC, B-tag, I-tag); then, the bridging is performed in the
   provider backbone space (B-MAC, B-VLAN) through the network till the
   frame arrives at the destination BEB where it gets de-encapsulated
   and passed to the CE. If a PBB bridge consists of both I & B
   components, then it is called IB-BEB and if it only consists of
   either B-component or I-component, then it is called B-BEB or I-BEB
   respectively. The interface between an I-BEB or IB-BEB and a CE is
   called S-tagged service interface and the interface between an I-BEB
   and a B-BEB (or between two B-BEBs) is called I-tagged service
   interface. The interface between a B-BEB or IB-BEB and a Backbone
   Core Bridge (BCB) is called B-Tagged service interface.

   To accommodate the PBB components the VPLS model defined in [RFC4664]
   is extended as depicted in figure 1.




















Balus et al.           Expires December 15, 2013                [Page 7]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


        +----------------------------------------+
        |       PBB-VPLS-capable PE model        |
        |   +---------------+          +------+  |
        |   |               |          |VPLS-1|------------
        |   |               |==========|Fwdr  |------------ PWs
   +--+ |   |     Bridge    ------------      |------------
   |CE|-|-- |               |          +------+  |
   +--+ |   |     Module    |             o      |
        |   |               |             o      |
        |   |   (PBB        |             o      |
        |   |    bridge)    |             o      |
        |   |               |             o      |
   +--+ |   |               |          +------+  |
   |CE|-|-- |               ------------VPLS-n|-------------
   +--+ |   |               |==========| Fwdr |------------- PWs
        |   |               |     ^    |      |-------------
        |   +---------------+     |    +------+  |
        |                         |              |
        +-------------------------|--------------+
                         LAN emulation Interface

                  Figure 2: PBB-VPLS capable PE Model



   The PBB Module as defined in [IEEE.802.1Q-2011] specification is
   expanded to interact with VPLS Forwarders. The VPLS Forwarders are
   used in [RFC4762] to build a PW mesh or a set of spoke-PWs
   (Hierarchical VPLS (HVPLS) topologies). The VPLS instances are
   represented externally in the MPLS context by a Layer 2 Forwarding
   Equivalence Class (L2FEC) which binds related VPLS instances
   together. VPLS Signaling advertises the mapping between the L2FEC and
   the PW labels and implicitly associates the VPLS bridging instance to
   the VPLS Forwarders [RFC4762].

   In the PBB-VPLS case the backbone service instance in the B-component
   space(B-VID) is represented in the backbone MPLS network using a VPLS
   instance. Same as for the regular VPLS case, existing signaling
   procedures are used to generate through PW labels the linkage between
   VPLS Forwarders and the backbone service instance.

   Similarly with the regular HVPLS, another L2FEC may be used to
   identify the customer service instance in the I-component space. This
   will be useful for example to address the PBB-VPLS N-PE case where
   HVPLS spokes are connecting the PBB-VPLS N-PE to a VPLS U-PE.

   It is important to note that the PBB-VPLS solution inherits the PBB
   service aggregation capability where multiple customer service



Balus et al.           Expires December 15, 2013                [Page 8]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   instances may be mapped to a backbone service instance. In the PBB-
   VPLS case this means multiple customer VPNs can be transported using
   a single VPLS instance corresponding to the backbone service
   instance, thus reducing substantially resource consumption in the
   VPLS core.

4. Packet Walkthrough

   Since the PBB bridge module inherently performs forwarding, the PE
   reference model of Figure 2 can be expanded as the one shown in
   Figure 3.

   Furthermore, the B-component is connected via several virtual
   interfaces to the PW Forwarder module. The function of PW Forwarder
   is defined in [RFC3985]. In this context, the PW Forwarder simply
   performs the mapping of the PWs to the Virtual Interface on the B-
   component without the need for any MAC lookup.

   This simplified model takes full advantage of PBB module where all
   the PBB[IEEE.802.1Q-2011] procedures including the C-MAC/B-MAC
   forwarding and PBB encapsulation/de-capsulation takes place and thus
   avoids specifying any of these functions in here.


   Because of text-based graphics, the Figure 3 only shows PWs on the
   core-facing side; however, in case of MPLS access with spoke PWs, the
   PE reference model is simply extended to include the same PW
   Forwarder function on the access-facing side. To avoid cluttering the
   figure, the access-side PW Forwarder (Fwdr) is not depicted without
   loss of any generality.





















Balus et al.           Expires December 15, 2013                [Page 9]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


        +------------------------------------------------+
        |               PBB-VPLS-capable PE model        |
        |             +---------------+      +------+    |
        |             |               |      |      |    |
        |   +------+  |               ========      ---------
   +--+ |   |      |  |               |      |      --------- PWs
   |CE|-|-- | I-   ====               ========  PW  ---------
   +--+ |   | comp |  |               |      | Fwdr |
        |   +------+  |               |      |      --------- PWs
        |             |    B-Comp     ========      ---------
        |             |               |  ^   |      |    |
        |   +------+  |               |  |   +------+    |
   +--+ |   | I-   |  |               OOOOOOOOOOOOOOOOOOOOOOOO B-tag
   |CE|-|-- | comp ====               |  |               |     I/Fs
   +--+ |   |      |^ |               OOOOOOOOOOOOOOOOOOOOOOOO
        |   +------+| |               |  |               |
        |           | +---------------+  |               |
        |           |                    |               |
        +-----------|--------------------|---------------+
                    |                    |
              Internal I-tag I/Fs   Virtual Interfaces (I/Fs)

    +----------+                                      +------------+
    |CMAC DA,SA|                                      | PSN header |
    |----------|                                      |------------|
    |SVID, CVID|                                      | PW Label   |
    |----------|                                      |------------|
    | Payload  |                                      | BMAC DA,SA |
    +----------+                                      |------------|
                                                      | PBB I-tag  |
                                                      |------------|
                                                      | CMAC DA,SA |
                                                      |------------|
                                                      | SVID, CVID |
                                                      |------------|
                                                      |  Payload   |
                                                      +------------+

              Figure 3: Packet Walkthrough for PBB VPLS PE

   In order to better understand the data plane walkthrough let us
   consider the example of a PBB packet arriving over a Backbone
   pseudowire (B-PW). The PSN header is used to carry the PBB
   encapsulated frame over the backbone while the PW Label will point to
   the related Backbone Service Instance (B-SI), same as for regular
   VPLS. The PW Label has in this case an equivalent role with the
   Backbone VLAN id on the PBB B-tagged interface.




Balus et al.           Expires December 15, 2013               [Page 10]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   An example of the PBB packet for regular Ethernet PW is depicted in
   Figure 3 on the right hand side. The MPLS packet from MPLS core
   network is received by the PBB-VPLS PE. The PW Forwarder function of
   the PE uses PW label to derive the virtual interface-id on the B-
   component and then after removing the PSN and PW encapsulation, it
   passes the packet to the B-component. From there on, the processing
   and forwarding is performed according to the PBB [IEEE.802.1Q-2011]
   where bridging based on backbone MAC (B-MAC) Destination Address DA
   is performed which result in one of the three outcomes:

     1. The packet is forwarded to a physical interface on the B-
       component. In this case, the PBB Ethernet frame is forwarded as
       is.

     2. The packet is forwarded to a virtual interface on the B-
       component. This is not typically the case because of a single
       split-horizon group within a VPLS instance; however, if there is
       more than one split-horizon group, then such forwarding takes
       place. In this case, the PW Forwarder module adds the PSN and PW
       labels before sending the packet out.

     3. The packet is forwarded toward the access side via one of the I-
       tagged service interfaces connected to the corresponding I-
       components. In this scenario, the I-component removes the B-MAC
       header according to PBB [IEEE.802.1Q-2011] and bridges the packet
       using C-MAC DA.

     4. If the destination B-MAC is an unknown or a Group MAC address
       (Multicast or Broadcast), then the B-component floods the
       packet to one or more of the three destinations described above.

5. Control Plane

   The control plane procedures described in [RFC6074], [RFC4761] and
   [RFC4762] can be re-used in a PBB-VPLS to setup the PW infrastructure
   in the service provider and/or customer bridging space. This allows
   porting the existing control plane procedures (e.g. BGP Auto-
   discovery (BGP-AD), PW setup, VPLS MAC Flush, PW OAM) for each
   domain.)


6. Efficient Packet replication in PBB VPLS

   The PBB VPLS architecture takes advantage of the existing VPLS
   features addressing packet replication efficiency. HVPLS hierarchy
   may be used in both customer and backbone service instances to reduce
   the redundant distribution of packets over the core. IGMP and PIM
   snooping may be applied on a per customer service instance to control



Balus et al.           Expires December 15, 2013               [Page 11]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   the distribution of the Multicast traffic to non-member sites.

   IEEE 802.1Q [IEEE.802.1Q-2011] specifies the use of Multiple MAC
   registration (MMRP) protocol for flood containment in the backbone
   instances. The same solution can be ported in the PBB-VPLS solution.

   Further optimizations of the packet replication in PBB-VPLS are out
   of the scope of this draft.

7. PBB VPLS OAM

   The existing VPLS, PW and MPLS OAM procedures may be used in each
   customer or backbone service instance to verify the status of the
   related connectivity components.

   PBB OAM procedures make use of the IEEE Ethernet Connectivity Fault
   Management (CFM) [IEEE.802.1Q-2011] and ITU-T Y.1731 [Y.1731] tools
   in both I-component and B-component.

   Both set of tools (PBB and VPLS) may be used for the combined PBB-
   VPLS solution.

8. Security Considerations

   No new security issues are introduced beyond those that are described
   in [RFC4761] and [RFC4762].

9. IANA Considerations

   IANA does not need to take any action for this draft.

10. References

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


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

   [RFC6074] E. Rosen, et Al. "Provisioning, Autodiscovery and Signaling
             in L2VPNs", RFC 6074, January 2011






Balus et al.           Expires December 15, 2013               [Page 12]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


10.2. Informative References

   [RFC3985] Bryant, S. and Pate, P. (Editors)," Pseudo Wire Emulation
             Edge-to-Edge (PWE3) Architecture", RFC 3985, May 2005.

   [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer
             2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006

   [IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan
             area networks -- Media Access Control (MAC) Bridges and
             Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
             2011.

   [Y.1731] Y.1731 (2006), ITU-T Recommendation, OAM functions and
             mechanisms for Ethernet based networks

   [RFC4026] Andersson, L. et Al., "Provider Provisioned Virtual Private
             Network (VPN) Terminology", RFC 4026, May 2005.

11. Contributors

   The following authors contributed to this document: John Hoffmans
   (KPN), Geraldine Calvignac (France Telecom), Olen Stokes (Extreme
   Networks), Raymond Zhang and Matthew Bocci (Alcatel-Lucent).


12. Acknowledgments

   The authors would like to thank Wim Henderickx, Mustapha Aissaoui,
   Dimitri Papadimitriou, Pranjal Dutta, Jorge Rabadan, Maarten Vissers
   and Don Fedyk for their insightful comments and probing questions.

Authors' Addresses

   Ali Sajassi
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134, U.S.
   Email: sajassi@cisco.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   Email: nabil.bitar@verizon.com

   Florin Balus
   Alcatel-Lucent



Balus et al.           Expires December 15, 2013               [Page 13]

INTERNET DRAFT    Extensions to VPLS PE model for PBB      June 13, 2013


   701 E. Middlefield Road
   Mountain View, CA, USA 94043
   Email: florin.balus@alcatel-lucent.com

   Matthew Bocci
   Alcatel-Lucent,
   Voyager Place
   Shoppenhangers Road
   Maidenhead
   Berks, UK
   e-mail: matthew.bocci@alcatel-lucent.com

   Raymond Zhang
   Alacatel-Lucent
   EMail: raymond.zhang@alcatel.com

   Geraldine Calvignac
   Orange
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   Email: geraldine.calvignac@orange.com

   John Hoffmans
   KPN
   Regulusweg 1
   2516 AC Den Haag
   Nederland
   Email: john.hoffmans@kpn.com

   Olen Stokes
   Extreme Networks
   PO Box 14129
   RTP, NC 27709
   USA
   Email: ostokes@extremenetworks.com















Balus et al.           Expires December 15, 2013               [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/