INTERNET-DRAFT
Internet Engineering Task Force (IETF)                     F. Balus (editor)
Intended Status: Informational Balus, Ed.
Request for Comments: 7041                                Alcatel-Lucent
Expires: December 15, 2013                          Ali Sajassi (editor)
Category: Informational                                  A. Sajassi, Ed.
ISSN: 2070-1721                                                    Cisco
                                                    Nabil Bitar (editor)
                                                           N. Bitar, Ed.
                                                                 Verizon

                                                           June 13,
                                                           November 2013

           Extensions to VPLS PE model the Virtual Private LAN Service (VPLS)
          Provider Edge (PE) Model for Provider Backbone Bridging
               draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt

Abstract

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

   The 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 the Rapid Spanning
   Tree Protocol (RSTP) or MSTP the Multiple Spanning Tree Protocol (MSTP)
   across the backbone.  As a result, VPLS has been deployed on a large
   scale in service provider networks.

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

Status of this This Memo

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

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product 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
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents at
   approved by the IESG are a candidate for any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html
   http://www.rfc-editor.org/info/rfc7041.

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 ....................................................3
   2. General terminology . . . . . . . . . . . . . . . . . . . . . .  4 Terminology .............................................4
   3. PE Reference Model  . . . . . . . . . . . . . . . . . . . . . .  6 ..............................................6
   4. Packet Walkthrough  . . . . . . . . . . . . . . . . . . . . . .  9 ..............................................9
   5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . 11 ..................................................11
   6. Efficient Packet replication Replication in PBB VPLS  . . . . . . . . . . . 11 .......................12
   7. PBB VPLS OAM  . . . . . . . . . . . . . . . . . . . . . . . . . 12 ...................................................12
   8. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 ........................................12
   9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. .....................................................13
      9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. ......................................13
      9.2. Informative References . . . . . . . . . . . . . . . . . . 13
   11. ....................................13
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   12. ..................................................14
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 ...............................................15

1.  Introduction

   The IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] specification [PBB] defines
   an architecture and bridge protocols for interconnection of multiple
   Provider Bridge Bridged Networks (PBNs).  PBB can be used to attain better
   scalability than Provider Bridges [PB] in terms of the number of
   customer Media Access Control (MAC) addresses and the number of
   service instances that can be supported.  PBB provides data plane a data-plane
   hierarchy and new addressing designed to improve the achieve such better
   scalability of MAC
   addresses and service instances in Provider Backbone Networks.  A number of Ethernet control plane protocols
   control-plane protocols, such as the Rapid Spanning Tree Protocol
   (RSTP), the Multiple Spanning Tree Protocol (MSTP) (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.

   The 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 a native
   Ethernet
   control plane control-plane protocol across the backbone.  VPLS use of
   the structured FEC 129 [RFC4762] also allows for inter-domain, inter-
   provider
   inter-provider connectivity and enables auto-discovery options across
   the
   network network, improving the service delivery options.

   A hierarchical solution for VPLS was introduced in [RFC4761] and
   [RFC4762] for the purpose of to provide 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 Customer Edge (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
   Customer MAC addresses (C-MACs), which (C-MACs); this poses scalability issues on the
   N-PE devices as the number of VPLS instances (and thus customer
   MAC addresses) C-MACs)
   increases.  Furthermore, since a set of PWs pseudowires (PWs) is
   maintained on a per "per customer service instance instance" basis, the number of
   pseudowires (PWs)
   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 to in this document
   as PBB-VPLS results in better scalability in terms of the number of
   service instances, PWs PWs, and Customer MACs (C-MACs) C-MACs that need to be handled in the
   VPLS PEs.

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

2.  General terminology Terminology

   Some general terminology is defined here; most of the terminology
   used is from [IEEE.802.1Q-2011], [RFC4664] [PBB], [PB], [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-tag information.

   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
      B-VLAN).

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

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

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

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

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

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

   CVID:

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

   C-VID: The VLAN identifier in a customer VLAN.

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

   I-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: IDs).

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

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

   I-TAG:

   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 The interface defined between the I
      I-components and B components B-components inside an IB-BEB or between two B-BEB.
      B-BEBs.  Frames passed through this interface contain an I-TAG field

   PB: I-tag
      field.

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

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

   PBB: [PB]).

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

   PBBN: Provider Backbone Bridged Network Network.

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

   SA: Source Address

   S-TAG:

   PSN: Packet-Switched Network.

   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 The interface defined between the
      customer (CE) and the I-BEB or IB-BEB components.  Frames passed
      through this interface contain an S-TAG S-tag field.

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

   SVID: The S-tag.

   SA: Source Address.

   S-VID: The VLAN identifier in a service VLAN.

   TAG:

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

3.  PE Reference Model

   The following gives a short primer on the 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 Interface   Service I/F          Service Interface I/F
     (I/F)

                        Figure 1: PBB Bridge Model
   Provider Backbone Bridges (PBBs) [IEEE.802.1Q-2011] offers [PBB] offer 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 that extend
   the work completed by Provider Bridges (PB). (PBs).  In the PBBN
   architecture, customer networks (using PB) PBs) are aggregated into
   Provider Backbone Bridge Networks (PBBNs)
   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 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] [PBB] there is a clear segregation between
   provider service instances (represented by I-SIDs) and provider VLANs
   (represented by B-VIDs) B-VIDs), which was not the case for PB. PBs.

   As shown in the figure Figure 1, a PBB bridge may consist of a single B-
   component
   B-component and one or more I-components.  In simple terms, the B-
   component
   B-component provides bridging in the provider space (B-MAC, B-VLAN) B-VLAN),
   and the I-component provides bridging in the 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 BEB, where it gets de-encapsulated
   decapsulated and passed to the CE.  If a PBB bridge consists of both I & B
   components,
   I-components and B-components, then it is called IB-BEB an IB-BEB, and if it
   only consists of either B-component B-components or I-component, I-components, then it is
   called a B-BEB or I-BEB an I-BEB, respectively.  The interface between an
   I-BEB or IB-BEB and a CE is called an S-tagged service interface interface, and
   the interface between an I-BEB and a B-BEB (or between two B-BEBs) is
   called an I-tagged service interface.  The interface between a B-BEB
   or IB-BEB and a Backbone Core Bridge (BCB) is called B-Tagged a B-tagged
   service interface.

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

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

                    Figure 2: PBB-VPLS capable PBB-VPLS-Capable PE Model

   The PBB Module module as defined in [IEEE.802.1Q-2011] the [PBB] 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 spoke PWs (Hierarchical VPLS (HVPLS)
   (H-VPLS) topologies).  The VPLS instances are represented externally
   in the MPLS context by a Layer 2 Forwarding Equivalence Class (L2FEC) which
   that 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 case, the backbone service instance in the
   B-component
   space(B-VID) space (B-VID) is represented in the backbone MPLS network
   using a VPLS instance. Same  In the same way 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

   Similarly, with the regular HVPLS, H-VPLS, another L2FEC may be used to
   identify the customer service instance in the I-component space.
   This will be useful useful, for example example, to address the PBB-VPLS N-PE case
   where
   HVPLS H-VPLS 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
   instances may be mapped to a backbone service instance.  In the PBB-
   VPLS case
   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 reducing 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 the PW
   Forwarder is defined in [RFC3985].  In this context, the PW Forwarder
   simply performs the mapping of the PWs to the Virtual Interface virtual interface on
   the B-
   component B-component, without the need for any MAC lookup.

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

   Because of text-based graphics, the Figure 3 only shows PWs on the
   core-facing side; however, in the 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, but without losing any generality, the access-side PW
   Forwarder (Fwdr) is not depicted without
   loss of any generality. depicted.

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

    +----------+                                      +------------+
    |CMAC DA,SA|

    +---------------+                                +--------------+
    | C-MAC DA,SA   |                                | PSN header Header   |
    |---------------|                                |--------------|
    | S-VID, C-VID  |
    |----------|                                      |------------|
    |SVID, CVID|                                | PW Label     |
    |----------|                                      |------------|
    |---------------|                                |--------------|
    |    Payload    |                                | BMAC B-MAC DA,SA  |
    +----------+                                      |------------|
    +---------------+                                |--------------|
                                                     | PBB I-tag    |
                                                      |------------|
                                                     |--------------|
                                                     | CMAC C-MAC DA,SA  |
                                                      |------------|
                                                     |--------------|
                                                     | SVID, CVID S-VID, C-VID |
                                                      |------------|
                                                     |--------------|
                                                     |   Payload    |
                                                      +------------+
                                                     +--------------+

                Figure 3: Packet Walkthrough for PBB VPLS PE

   In order to better understand the data plane walkthrough 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 label will point to
   the related Backbone Service Instance (B-SI), in the same way as for
   regular VPLS.  The PW Label label has in this case an equivalent role with
   the
   Backbone backbone VLAN id identifier on the PBB B-tagged interface.

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

   1. The packet is forwarded to a physical interface on the B-
       component.
      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. B-component.
      This is not typically the case 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
      I-tagged service interfaces connected to the corresponding I-
       components.
      I-components.  In this scenario, case, the I-component removes the B-MAC
      header according to PBB [IEEE.802.1Q-2011] [PBB] and bridges the packet using the
      C-MAC DA.

     4.

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

5.  Control Plane

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

6.  Efficient Packet replication Replication in PBB VPLS

   The PBB VPLS architecture takes advantage of the existing VPLS
   features addressing packet replication efficiency. HVPLS  The H-VPLS
   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 "per customer service instance instance"
   basis to control the distribution of the Multicast multicast traffic to
   non-member sites.

   IEEE 802.1Q [IEEE.802.1Q-2011]

   [IEEE-802.1Q] specifies the use of the Multiple MAC
   registration Registration
   Protocol (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. document.

7.  PBB VPLS OAM

   The existing VPLS, PW PW, and MPLS OAM procedures may be used in each
   customer service instance 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] [CFM] and ITU-T Y.1731 [Y.1731] tools in both I-component I-components
   and B-component. B-components.

   Both set sets of tools (PBB and VPLS) may be used for the combined PBB-
   VPLS
   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.

9.1.  Normative References

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

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

   [RFC6074] E. Rosen, et Al. E., Davie, B., Radoaca, V., and W. Luo,
             "Provisioning, Autodiscovery Auto-Discovery, and Signaling in L2VPNs", Layer 2
             Virtual Private Networks (L2VPNs)", RFC 6074, January 2011

10.2. 2011.

9.2.  Informative References

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

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

   [IEEE.802.1Q-2011] IEEE,
             September 2006.

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

   [PB]      Clauses 15 and 16 of "IEEE Standard for Local and
             metropolitan area networks - Media Access Control (MAC)
             Bridges and Virtual Bridged Local Area Networks", IEEE
             Std 802.1Q-REV, 2013.

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

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

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

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

11.

10.  Contributors

   The following authors contributed people made significant contributions to this document: John Hoffmans
   (KPN),

      Matthew Bocci
      Alcatel-Lucent
      Voyager Place
      Shoppenhangers Road
      Maidenhead
      Berks, UK

      EMail: matthew.bocci@alcatel-lucent.com

      Raymond Zhang
      Alcatel-Lucent

      EMail: raymond.zhang@alcatel.com

      Geraldine Calvignac (France Telecom),
      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), Raymond Zhang and Matthew Bocci (Alcatel-Lucent).

12.
      Extreme Networks
      PO Box 14129
      RTP, NC  27709
      USA

      EMail: ostokes@extremenetworks.com

11.  Acknowledgments

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

Authors' Addresses

   Florin Balus (editor)
   Alcatel-Lucent
   701 E. Middlefield Road
   Mountain View, CA  94043
   USA

   EMail: florin.balus@alcatel-lucent.com

   Ali Sajassi (editor)
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134, U.S.
   Email:  95134
   USA

   EMail: sajassi@cisco.com

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

   Florin Balus
   Alcatel-Lucent
   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 nabil.n.bitar@verizon.com