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

Versions: (draft-sajassi-l2vpn-vpls-bridge-interop) 00 01 02 03 04 05 06 RFC 6246

   Internet Working Group                            Ali Sajassi, Ed.
   Internet Draft                                     Frank Brockners
   Category: Informational                              Cisco Systems
  
                                                    Dinesh Mohan, Ed.
  
                                                        Yetik Serbest
  
   Expires: April 24, 2010                           October 24, 2010
  
  
                   VPLS Interoperability with CE Bridges
                draft-ietf-l2vpn-vpls-bridge-interop-06.txt
  
   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.
  
   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
  
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
  
  
   Copyright and License Notice
  
   Copyright (c) 2010 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.
  
   This document may contain material from IETF Documents or IETF
  
  
   Sajassi, et. al.                                           [Page 1]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.
  
   Abstract
  
   One of the main motivations behind VPLS is its ability to provide
   connectivity not only among customer routers and servers/hosts but
   also among customer IEEE bridges. VPLS is expected to deliver the
   same level of service that current enterprise users are accustomed
   to from their own enterprise bridged networks or their Ethernet
   Service Providers.
  
   When CE devices are IEEE bridges, then there are certain issues and
   challenges that need to be accounted for in a VPLS network. The
   majority of these issues have been addressed in the IEEE 802.1ad
   standard for provider bridges and they can be leveraged for VPLS
   networks. This draft extends the PE model described in [RFC-4664]
   based on IEEE 802.1ad bridge module, and illustrates a clear
   demarcation between the IEEE bridge module and IETF LAN emulation
   module. By doing so, it shows that the majority of interoperability
   issues with CE bridges can be delegated to the 802.1ad bridge
   module, thus removing the burden on the IETF LAN emulation module
   within a VPLS PE.
  
  
   Conventions
  
   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 [RFC-2119].
  
  
   Table of Contents
  
   1. Introduction.................................................... 3
   2. Ethernet Service Instance....................................... 4
   3. VPLS-Capable PE Model with Bridge Module........................ 5
   4. Mandatory Issues................................................ 7
   4.1. Service Mapping............................................... 7
   4.2. CE Bridge Protocol Handling................................... 9
   4.3. Partial-mesh of Pseudowires.................................. 10
  
  
   Sajassi, et al.                                            [Page 2]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   4.4. Multicast Traffic............................................ 11
   5. Optional Issues................................................ 12
   5.1. Customer Network Topology Changes............................ 13
   5.2. Redundancy................................................... 14
   5.3. MAC Address Learning......................................... 16
   6. Interoperability with 802.1ad Networks......................... 17
   7. Acknowledgments................................................ 17
   8. IANA Considerations............................................ 17
   9. Security Considerations........................................ 17
   10. Normative References.......................................... 18
   11. Informative References........................................ 18
   Authors' Addresses................................................ 19
  
  
   1.
      Introduction
  
   Virtual Private LAN Service (VPLS) is a LAN emulation service
   intended for providing connectivity between geographically dispersed
   customer sites across MAN/WAN (over MPLS/IP) network(s), as if they
   were connected using a LAN. One of the main motivations behind VPLS
   is its ability to provide connectivity not only among customer
   routers and servers/hosts but also among IEEE customer bridges. If
   only connectivity among customer IP routers/hosts was desired, then
   an IPLS solution [IPLS] could have been used. The strength of the
   VPLS solution is that it can provide connectivity to both bridge and
   non-bridge types of CE devices. VPLS is expected to deliver the same
   level of service that current enterprise users are accustomed to
   from their own enterprise bridged networks [802.1D/802.1Q] today or
   the same level of service that they receive from their Ethernet
   Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or
   its predecessor, QinQ-based network).
  
   When CE devices are IEEE bridges, then there are certain issues and
   challenges that need to be accounted for in a VPLS network. The
   majority of these issues have been addressed in the IEEE 802.1ad
   standard for provider bridges and they can be leveraged for VPLS
   networks. This draft extends the PE model described in [RFC-4664]
   based on IEEE 802.1ad bridge module and illustrates a clear
   demarcation between IEEE bridge module and IETF LAN emulation
   module. By doing so, it describes that the majority of
   interoperability issues with CE bridges can be delegated to 802.1ad
   bridge module, thus removing the burden on IETF LAN emulation module
   within a VPLS PE. This document discusses these issues and wherever
   possible suggests areas to be explored in rectifying these issues.
   The detailed solution specification for these issues is outside of
   the scope of this document.
  
  
  
   Sajassi, et al.                                            [Page 3]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   It also discusses interoperability issues between VPLS and IEEE
   802.1ad networks when the end-to-end service spans across both types
   of networks, as outlined in [RFC-4762].
  
   This draft categorizes the CE-bridge issues into two groups: 1)
   Mandatory and 2) Optional. The issues in group (1) need to be
   addressed in order to ensure the proper operation of CE bridges. The
   issues in group (2) would provide additional operational improvement
   and efficiency and may not be required for interoperability with CE
   bridges. Sections five and six discuss the mandatory and optional
   issues respectively.
  
  
   2.
      Ethernet Service Instance
  
   Before starting the discussion of bridging issues, it is important
   to clarify the Ethernet Service definition. The term VPLS has
   different meanings in different contexts. In general, VPLS is used
   in the following contexts [Eth-OAM]: a) as an end-to-end bridged-LAN
   service over one or more network (one of which being MPLS/IP
   network), b) as an MPLS/IP network supporting these bridged LAN
   services, and c) as (V)LAN emulation. For better clarity, we
   differentiate between its usage as network versus service by using
   the terms VPLS network and VPLS instance respectively. Furthermore,
   we confine VPLS (both network and service) to only the portion of
   the end-to-end network that spans across an MPLS/IP network. For an
   end-to-end service (among different sites of a given customer), we
   use the term "Ethernet Service Instance" or ESI.
  
   [MFA-Ether] defines the Ethernet Service Instance (ESI) as an
   association of two or more Attachment Circuits (ACs) over which an
   Ethernet service is offered to a given customer. An AC can be either
   a UNI or a NNI; furthermore, it can be an Ethernet interface or a
   VLAN, it can be an ATM or FR VC, or it can be a PPP/HDLC interface.
   If an ESI is associated with more than two ACs, then it is a
   multipoint ESI. In this document, where ever the keyword ESI is
   used, it means multipoint ESI, unless it is stated otherwise.
  
   An ESI can correspond to a VPLS instance if its associated ACs are
   only connected to a VPLS network or an ESI can correspond to a
   Service VLAN if its associated ACs are only connected to a Provider-
   Bridged network [P802.1ad]. Furthermore, an ESI can be associated
   with both a VPLS instance and a Service VLAN when considering an
   end-to-end service that spans across both VPLS and Provider-Bridged
   networks. An ESI can span across different networks (e.g., IEEE
   802.1ad and VPLS) belonging to the same or different administrative
   domains.
  
   An ESI most often represents a customer or a specific service
   requested by a customer. Since traffic isolation among different
   customers (or their associated services) is of paramount importance
  
  
   Sajassi, et al.                                            [Page 4]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   in service provider networks, its realization shall be done such
   that it provides a separate MAC address domain and broadcast domain
   per ESI. A separate MAC address domain is provided by using a
   separate MAC forwarding table (e.g., FIB - also known as filtering
   database [IEEE 802.1D]) per ESI (for both VPLS and IEEE 802.1ad
   networks) and separate broadcast domain is provided by using a full-
   mesh of pseudowires per ESI over the IP/MPLS core in a VPLS network
   and/or a dedicated Service VLAN per ESI in an IEEE 802.1ad network.
  
  
   3.
      VPLS-Capable PE Model with Bridge Module
  
   [RFC-4664] defines three models for VPLS-capable PE (VPLS-PE) based
   on the bridging functionality that needs to be supported by the PE.
   If the CE devices can be routers/hosts or IEEE bridges, the second
   model from [RFC-4664] is the most suitable, and it is both adequate
   to provide the VPLS level of service and consistent with the IEEE
   standards for Provider Bridges [P802.1ad]. We briefly describe the
   second model and then expand upon this model to show its sub-
   components based on [P802.1ad] Provider Bridge model.
  
   As described in [RFC-4664], the second model for VPLS-PE contains a
   single bridge module supporting all the VPLS instances on that PE
   where each VPLS instance is represented by a unique VLAN inside that
   bridge module (also known as Service VLAN or S-VLAN). The bridge
   module has a single "Emulated LAN" interface over which it
   communicates with all VPLS forwarders and each VPLS instance is
   represented by a unique S-VLAN tag. Each VPLS instance can consist
   of a set of pseudowires and its associated forwarder corresponding
   to a single Virtual LAN (VLAN) as depicted in Figure 1 below. Thus,
   sometimes it is referred to as VLAN emulation.
  
  
        +----------------------------------------+
        |           VPLS-capable PE model        |
        |   +---------------+          +------+  |
        |   |               |          |VPLS-1|------------
        |   |               |=======+  |Fwdr  |------------ PWs
        |   |     Bridge    --------|---      |------------
        |   |               | SVID-1|  +------+  |
        |   |     Module    |       |     o      |
        |   |               |       |     o      |
        |   |   (802.1ad    |       |     o      |
        |   |    bridge)    |       |     o      |
        |   |               |       |     o      |
        |   |               | SVID-n|  +------+  |
        |   |               --------|---VPLS-n|-------------
        |   |               |=======+  | Fwdr |------------- PWs
        |   |               |   ^      |      |-------------
        |   +---------------+   |      +------+  |
        |                       |                |
  
  
   Sajassi, et al.                                            [Page 5]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
        +-----------------------|----------------+
                                |
                LAN emulation (multi-access) Interface
  
                      Figure 1. VPLS-capable PE Model
  
   Customer frames associated with a given ESI, carry the S-VLAN ID for
   that ESI over the LAN emulation interface. The S-VLAN ID is stripped
   before transmitting the frames over the set of pseudowires
   associated with that VPLS instance (assuming raw mode PWs are used
   as specified in [RFC-4448]).
  
   The bridge module can itself consist of one or two sub-components
   depending on the functionality that it needs to perform. The
   following Figure 2 depicts the model for the bridge module based on
   [P802.1ad].
  
  
  
  
                   +-------------------------------+
                   |  802.1ad Bridge Module Model  |
                   |                               |
        +---+  AC  |  +------+      +-----------+  |
        |CE |---------|C-VLAN|------|           |  |
        +---+      |  |bridge|------|           |  |
                   |  +------+      |           |  |
                   |     o          |   S-VLAN  |  |
                   |     o          |           |  | ---> to VPLS Fwdr
                   |     o          |   Bridge  |  |
        +---+  AC  |  +------+      |           |  |
        |CE |---------|C-VLAN|------|           |  |
        +---+      |  |bridge|------|           |  |
                   |  +------+      |           |  |
        +---+  AC  |                |           |  |
        |CE |-----------------------|           |  |
        +---+      |                +-----------+  |
                   +-------------------------------+
  
               Figure 2. The Model of 802.1ad Bridge Module
  
   The S-VLAN bridge component is always required and it is responsible
   for tagging customer frames with S-VLAN tags in the ingress
   direction (from customer UNIs) and removing S-VLAN tags in the
   egress direction (toward customer UNIs). It is also responsible for
   running the provider's bridge protocol such as RSTP, MSTP, GVRP,
   GMRP, etc. among provider bridges within a single administrative
   domain.
  
   The C-VLAN bridge component is required when the customer Attachment
   Circuits are VLANs (aka C-VLANs). In such cases, the VPLS-capable PE
  
  
   Sajassi, et al.                                            [Page 6]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   needs to participate in some of the customer's bridging protocol
   such as RSTP and MSTP. The reason that such participation is
   required is because a customer VLAN (C-VLAN) at one site can be
   mapped into a different C-VLAN at a different site or in case of
   asymmetric mapping, a customer Ethernet port at one site can be
   mapped into a customer VLAN (or group of C-VLANs) at a different
   site.
  
   The C-VLAN bridge component does service selection and
   identification based on C-VLAN tags. Each frame from the customer
   device is assigned to a C-VLAN and presented at one or more internal
   port-based interfaces, each supporting a single service instance
   that the customer desires to carry that C-VLAN. Similarly frames
   from the provider network are assigned to an internal interface or
   'LAN' (e.g, between C-VLAN and S-VLAN components) on the basis of
   the S-VLAN tag. Since each internal interface supports a single
   service instance, the S-VLAN tag can be, and is, removed at this
   interface by the S-VLAN bridge component. If multiple C-VLANs are
   supported by this service instance (e.g., VLAN bundling or port-
   based), then the frames will have already been tagged with C-VLAN
   tags. If a single C-VLAN is supported by this service instance
   (e.g., VLAN-based), then the frames will not have been tagged with a
   C-VLAN tag since C-VLAN can be derived from the S-VLAN (e.g., one to
   one mapping). The C-VLAN aware bridge component applies a port VLAN
   ID (PVID) to untagged frames received on each internal 'LAN',
   allowing full control over the delivery of frames for each C-VLAN
   through the Customer UNI Port.
  
  
  
   4.
      Mandatory Issues
  
   4.1.
        Service Mapping
  
   Different Ethernet AC types can be associated with a single Ethernet
   Service Instance (ESI). For example, an ESI can be associated with
   only physical Ethernet ports, VLANs, or a combination of the two
   (e.g., one end of the service could be associated with physical
   Ethernet ports and the other end could be associated with VLANs). In
   [RFC-4762], unqualified and qualified learning are used to refer to
   port-based and VLAN-based operation respectively and [RFC-4762] does
   not describe the possible mappings between different types of
   Ethernet ACs (e.g., 802.1D, 802.1Q or 802.1ad frames). In general,
   the mapping of a customer port or VLAN to a given service instance
   is a local function performed by the local PE and the service
   provisioning shall accommodate it. In other words, there is no
   reason to restrict and limit an ESI to have only port-based ACs or
   to have only VLAN-based ACs. [P802.1ad] allows for each customer AC
   (either a physical port, or a VLAN, or a group of VLANs) to be
   mapped independently to an ESI which provides better service
   offering to Enterprise customers. For better and more flexible
  
  
   Sajassi, et al.                                            [Page 7]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   service offerings and for interoperability purposes between VPLS and
   802.1ad networks, it is imperative that both networks offer the same
   capabilities in terms of customer ACs mapping to the customer
   service instance.
  
   The following table lists possible mappings that can exist between
   customer ACs and its associated ESI - this table is extracted from
   [MFA-Ether]. As it can be seen, there are several possible ways to
   perform such mapping. In the first scenario, it is assumed that an
   Ethernet physical port only carries untagged traffic and all the
   traffic is mapped to the corresponding service instance or ESI. This
   is referred to as "port-based with untagged traffic". In the second
   scenario, it is assumed that an Ethernet physical port carries both
   tagged and untagged traffic and all that traffic is mapped to the
   corresponding service instance or ESI. This is referred to as "port-
   based with tagged and untagged traffic". In the third scenario, it
   is assumed that only a single VLAN is mapped to the corresponding
   service instance or ESI (referred to as VLAN-based). Finally, in the
   fourth scenario, it is assumed that a group of VLANs from the
   Ethernet physical interface is mapped to the corresponding service
   instance or ESI.
  
  
  
   ===================================================================
               Ethernet I/F & Associated Service Instance(s)
   -------------------------------------------------------------------
              Port-based       Port-based       VLAN-based    VLAN
              untagged         tagged &                       bundling
                               untagged
   -------------------------------------------------------------------
   Port-based    Y               N               Y(Note-1)    N
   untagged
  
   Port-based    N               Y               Y(Note-2)    Y
   tagged &
   untagged
  
   VLAN-based    Y(Note-1)       Y(Note-2)       Y            Y(Note-3)
  
  
   VLAN          N               Y               Y(Note-3)    Y
   Bundling
   ===================================================================
  
   Note-1: In this asymmetric mapping scenario, it is assumed that the
   CE device with "VLAN-based" AC is a device capable of supporting
   [802.1Q] frame format.
  
   Note-2: In this asymmetric mapping scenario, it is assumed that the
   CE device with "VLAN-based" AC is a device that can support
  
  
   Sajassi, et al.                                            [Page 8]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   [P802.1ad] frame format because it will receive Ethernet frames with
   two tags; where the outer tag is S-VLAN and the inner tag is C-VLAN
   received from "port-based" AC. One application example for such CE
   device is in a BRAS for DSL aggregation over Metro Ethernet network.
  
   Note-3: In this asymmetric mapping scenario, it is assumed that the
   CE device with "VLAN-based" AC can support the [P802.1ad] frame
   format because it will receive Ethernet frames with two tags; where
   the outer tag is S-VLAN and the inner tag is C-VLAN received from
   "VLAN bundling" AC.
  
   If a PE uses an S-VLAN tag for a given ESI (either by adding an S-
   VLAN tag to customer traffic or by replacing a C-VLAN tag with a S-
   VLAN tag), then the frame format and EtherType for S-VLAN SHALL
   adhere to [P802.1ad].
  
   As mentioned before, the mapping function between the customer AC
   and its associated ESI is a local function and thus when the AC is a
   single customer VLAN, it is possible to map different customer VLANs
   at different sites to a single ESI without coordination among those
   sites.
  
   When a port-based mapping or a VLAN-bundling mapping is used, then
   the PE may use an additional S-VLAN tag to mark the customer traffic
   received over that AC as belonging to a given ESI. If the PE uses
   the additional S-VLAN tag, then in the opposite direction the PE
   SHALL strip the S-VLAN tag before sending the customer frames over
   the same AC. However, when VLAN-mapping mode is used at an AC and if
   the PE uses S-VLAN tag locally, then if the Ethernet interface is a
   UNI, the tagged frames over this interface SHALL have a frame format
   based on [802.1Q] and the PE SHALL translate the customer tag (C-
   VLAN) into the provider tag (S-VLAN) upon receiving a frame from the
   customer and in the opposite direction, the PE shall translate from
   provider frame format (802.1ad) back to customer frame format
   (802.1Q).
  
   All the above asymmetric services can be supported via the PE model
   with the bridge module depicted in Figure 2 (based on [802.1ad]).
  
   4.2.
        CE Bridge Protocol Handling
  
   When a VPLS-capable PE is connected to a CE bridge, then depending
   on the type of Attachment Circuit, different protocol handling may
   be required by the bridge module of the PE. [P802.1ad] states that
   when a PE is connected to a CE bridge, then the service offered by
   the PE may appear to specific customer protocols running on the CE
   in one of the four ways:
  
  
  
   Sajassi, et al.                                            [Page 9]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
     a) Transparent to the operation of the protocol among CEs of
        different sites using the service provided, appearing as an
        individual LAN without bridges; or,
     b) Discarding frames, acting as a non-participating barrier to the
        operation of the protocol; or,
     c) Peering, with a local protocol entity at the point of provider
        ingress and egress, participating in and terminating the
        operation of the protocol; or,
     d) Participation in individual instances of customer protocols.
  
   All the above CE bridge protocol handling can be supported via the
   PE model with the bridge module depicted in figure-2 (based on
   [802.1ad]). For example, when an Attachment Circuit is port-based,
   then the bridge module of the PE can operate transparently with
   respect to the CE's RSTP/MSTP protocols (and thus no C-VLAN
   component is required for that customer UNI). However, when an
   Attachment Circuit is VLAN-based (either VLAN-based or VLAN
   bundling), then the bridge module of the PE needs to peer with the
   RSTP/MSTP protocols running on the CE (and thus the C-VLAN bridge
   component is required). In other words, when the AC is VLAN-based,
   then protocol peering between CE and PE devices may be needed. There
   are also protocols that require peering but are independent from the
   type of Attachment Circuit. An example of such protocol is the link
   aggregation protocol [802.3ad]; however, this is a media-dependent
   protocol as its name implies.
  
   [P802.1ad] reserves a block of 16 MAC addresses for the operation of
   C-VLAN and S-VLAN bridge components and it shows which of these
   reserved MAC addresses are only for C-VLAN bridge component and
   which ones are only for S-VLAN bridge component and which ones apply
   to both C-VLAN and S-VLAN components.
  
  
   4.3.
        Partial-mesh of Pseudowires
  
   A VPLS service depends on a full mesh of pseudowires, so a
   pseudowire failure reduces the underlying connectivity to a partial
   mesh and this can have adverse effects on the VPLS service. If the
   CE devices belonging to an ESI are routers running link state
   routing protocols that use LAN procedures over that ESI, then a
   partial-mesh of PWs can result in "black holing" traffic among the
   selected set of routers. And if the CE devices belonging to an ESI
   are IEEE bridges, then a partial-mesh of PWs can cause broadcast
   storms in the customer and provider networks. Furthermore, it can
   cause multiple copies of a single frame to be received by the CE
   and/or PE devices. Therefore, it is of paramount importance to be
   able to detect PW failure and to take corrective action to prevent
   creation of partial-mesh of PWs.
  
  
  
   Sajassi, et al.                                           [Page 10]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   When the PE model depicted in Figure 2 is used, then [P802.1ag]
   procedures could be used for detection of partial-mesh of PWs.
   [p802.1ag] defines a set of procedures for fault detection,
   verification, isolation, and notification per ESI.
  
   The fault detection mechanism of [p8021.ag] can be used to perform
   connectivity check among PEs belonging to a given VPLS instance. It
   checks the integrity of a service instance end-to-end within an
   administrative domain - e.g., from one AC at one end of the network
   to another AC at the other end of the network. Therefore, its path
   coverage includes bridge module within a PE and it is not limited to
   just PWs. Furthermore, [P802.1ag] operates transparently over the
   full-mesh of PWs for a given service instance since it operates at
   the Ethernet level (and not at PW level). It should be noted that
   since a PW consists of two uni-directional LSPs, then one direction
   can fail independently of the other. Even in this case, the
   procedures of [p802.1ag] can provide a consistent view of the full-
   mesh to the participating PEs by relying on remote defect indication
   (RDI).
  
   Another, less preferred, option is to define a procedure for
   detection of partial mesh in which each PE keeps track of the status
   of PW Endpoint Entities (EEs - e.g., VPLS forwarders) for itself as
   well as the ones reported by other PEs. Therefore, upon a PW
   failure, the PE that detects the failure not only takes notice
   locally but it notifies other PEs belonging to that service instance
   of such failure so that all the participant PEs have a consistent
   view of the PW mesh. Such a procedure is for the detection of
   partial mesh per service instance and in turn it relies on
   additional procedure for PW failure detection such as BFD or VCCV.
   Given that there can be tens (or even hundreds) of thousands of PWs
   in a PE, there can be scalability issues with such fault
   detection/notification procedures.
  
   4.4.
        Multicast Traffic
  
   VPLS follows a centralized model for multicast replication within an
   ESI. VPLS relies on ingress replication. The ingress PE replicates
   the multicast packet for each egress PE and sends it to the egress
   PE using PtP PW over a unicast tunnel. VPLS operates on an overlay
   topology formed by the full mesh of pseudo-wires. Thus, depending on
   the underlying topology, the same datagram can be sent multiple
   times down the same physical link. VPLS currently does not offer any
   mechanisms to restrict the distribution of multicast or broadcast
   traffic of an ESI throughout the network causing an additional
   burden on the ingress PE through unnecessary packet replication,
   causing additional load on the MPLS core network, and causing
   additional processing at the receiving PE where extraneous multicast
   packets are discarded.
  
  
  
   Sajassi, et al.                                           [Page 11]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   One possible approach, to delivering multicast more efficiently over
   a VPLS network, is to include the use of IGMP snooping in order to
   send the packet only to the PEs that have receivers for that
   traffic, rather than to all the PEs in the VPLS instance. If the
   customer bridge or its network has dual-home connectivity, then for
   proper operation of IGMP snooping, the PE must generate a "General
   Query" over that customer's UNIs upon receiving a customer topology
   change notification as described in Section 7 of [RFC-4541]. A
   "General Query" by the PE results in proper registration of the
   customer multicast MAC address(s) at the PE when there is customer
   topology change. It should be noted that IGMP snooping provides a
   solution for IP multicast packets and is not applicable to general
   multicast data.
  
   Using the IGMP-snooping as described, the ingress PE can select a
   sub-set of PWs for packet replication; therefore, avoiding sending
   multicast packets to the egress PEs that don't need them. However,
   the replication is still performed by the ingress PE. In order to
   avoid, replication at the ingress PE, one may want to use multicast
   distribution trees (MDTs) in the provider core network; however,
   this brings with it some potential pitfalls. If the MDT is used for
   all multicast traffic of a given customer, then this results in
   customer multicast and unicast traffic being forwarded on different
   PWs and even on a different physical topology within the provider
   network. This is a serious issue for customer bridges because
   customer BPDUs, which are multicast data, can take a different path
   through the network than the unicast data. Situations might arise
   where either unicast OR multicast connectivity is lost. If unicast
   connectivity is lost, but multicast forwarding continues to work,
   the customer spanning tree would not take notice which results in
   loss of its unicast traffic. Similarly, if multicast connectivity is
   lost, but unicast is working, then the customer spanning tree will
   activate the blocked port which may result in a loop within the
   customer network. Therefore, the MDT cannot be used for both
   customer multicast control and data traffic. If it is used, it
   should only be limited to customer data traffic. However, there can
   be a potential issue even when it is used for customer data traffic
   since the MDT doesn't fit the PE model described in Figure 1 (it
   operates independently from the full-mesh of PWs that correspond to
   an S-VLAN). It is also not clear how CFM procedures (802.1ag) used
   for ESI integrity check (e.g., per service instance) can be applied
   to check the integrity of the customer multicast traffic over the
   provider MDT. Because of these potential issues, the specific
   applications of the provider MDT to customer multicast traffic shall
   be documented and its limitations be clearly specified.
  
  
  
  
   5.
      Optional Issues
  
  
  
   Sajassi, et al.                                           [Page 12]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   5.1.
        Customer Network Topology Changes
  
   A single CE or a customer network can be connected to a provider
   network using more than one User-Network Interface (UNI).
   Furthermore, a single CE or a customer network can be connected to
   more than one provider network. [RFC-4665] provides some examples of
   such customer network connectivity that are depicted in Figure 3
   below. Such network topologies are designed to protect against the
   failure or removal of network components from the customer network
   and it is assumed that the customer leverages the spanning tree
   protocol to protect against these cases. Therefore, in such
   scenarios, it is important to flush customer MAC addresses in the
   provider network upon the customer topology change to avoid black
   holing of customer frames.
  
  
  
  
                      +-----------                     +---------------
                      |                                |
     +------+     +------+            +------+     +------+
     |  CE  |-----|  PE  |            |  CE  |-----|  PE  |
     |device|     |device|            |device|     |device| SP network
     +------+\    +------+            +------+\    +------+
        |     \       |                  |     \       |
        |Back  \      |                  |Back  \      +---------------
        |door   \     |   SP network     |door   \     +---------------
        |link    \    |                  |link    \    |
     +------+     +------+            +------+     +------+
     |  CE  |     |  PE  |            |  CE  |     |  PE  |
     |device|-----|device|            |device|-----|device| SP network
     +------+     +------+            +------+     +------+
                      |                                |
                      +------------                    +---------------
                     (a)                                 (b)
  
      Figure 3. Combination of Dual-Homing and Backdoor Links for CE
                                  Devices
  
   The customer networks use their own instances of the spanning tree
   protocol to configure and partition their active topology, so that
   the provider connectivity doesn't result in a data loop.
   Reconfiguration of a customer's active topology can result in the
   apparent movement of customer end stations from the point of view of
   the PEs. However, the requirement for mutual independence of the
   distinct ESIs that can be supported by a single provider spanning
   tree active topology does not permit either the direct receipt of
   provider topology change notifications from the CEs or the use of
   received customer spanning tree protocol topology change
   notifications to stimulate topology change signaling on a provider
   spanning tree.
  
  
   Sajassi, et al.                                           [Page 13]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
  
   To address this issue, [P802.1ad] requires that customer topology
   change notification to be detected at the ingress of the S-VLAN
   bridge component and the S-VLAN bridge transmits a Customer Change
   Notification (CCN) message with the S-VLAN ID associated with that
   service instance and a destination MAC address as specified in the
   block of 16 reserved multicast MAC addresses. Upon receiving the
   CCN, the provider bridge will flush all the customer MAC addresses
   associated with that S-VLAN ID on all the provider bridge interfaces
   except the one that the CCN message is received from.
  
   Based on the provider bridge model depicted in Figure 1, there are
   two methods of propagating the CCN message over the VPLS network.
   The first method is to translate the in-band CCN message into an
   out-of-band "MAC Address Withdrawal" message as specified in [RFC-
   4762] and the second method is to treat the CCN message as customer
   data and pass it transparently over the set of PWs associated with
   that VPLS instance. The second method is recommended because of ease
   of interoperability between the bridge and the LAN emulation modules
   of the PE.
  
  
   5.2.
        Redundancy
  
   [RFC-4762] talks about dual-homing of a given u-PE to two n-PEs over
   a provider MPLS access network to provide protection against link
   and node failure - e.g., in case the primary n-PE fails or the
   connection to it fails, then the u-PE uses the backup PWs to reroute
   the traffic to the backup n-PE. Furthermore, it discusses the
   provision of redundancy when a provider Ethernet access network is
   used and how any arbitrary access network topology (not just limited
   to hub-and-spoke) can be supported using the provider's MSTP
   protocol and how the provider MSTP for a given access network can be
   confined to that access network and operate independently from MSTP
   protocols running in other access networks.
  
   In both types of redundancy mechanism (Ethernet versus MPLS access
   networks), only one n-PE is active for a given VPLS instance at any
   time. In case of an Ethernet access network, core-facing PWs (for a
   VPLS instance) at the n-PE are blocked by the MSTP protocol;
   whereas, in case of a MPLS access network, the access-facing PW is
   blocked at the u-PE for a given VPLS instance.
  
  
  
  
  
  
  
  
  
  
  
   Sajassi, et al.                                           [Page 14]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
  
      -------------------------+  Provider  +-----------------------
                               .   Core     .
                   +------+    .            .    +------+
                   | n-PE |======================| n-PE |
        Provider   | (P)  |---------\    /-------| (P)  |  Provider
        Access     +------+    ._    \  /   .    +------+  Access
        Network                .      \/    .              Network
          (1)      +------+    .      /\    .    +------+     (2)
                   | n-PE |----------/  \--------| n-PE |
                   |  (B) |----------------------| (B)  |_
                   +------+    .            .    +------+
                               .            .
       ------------------------+            +-----------------------
  
                       Figure 4. Bridge Module Model
  
   Figure 4 shows two provider access networks each with two n-PEs
   where the n-PEs are connected via a full mesh of PWs for a given
   VPLS instance. As shown in the figure, only one n-PE in each access
   network is serving as a Primary PE (P) for that VPLS instance and
   the other n-PE is serving as the backup PE (B). In this figure, each
   primary PE has two active PWs originating from it. Therefore, when a
   multicast, broadcast, and unknown unicast frame arrives at the
   primary n-PE from the access network side, the n-PE replicates the
   frame over both PWs in the core even though it only needs to send
   the frames over a single PW (shown with "==" in Figure 4) to the
   primary n-PE on the other side. This is an unnecessary replication
   of the customer frames that consumes core-network bandwidth (half of
   the frames get discarded at the receiving n-PE). This issue gets
   aggravated when there are more than two n-PEs per provider access
   network - e.g., if there are three n-PEs or four n-PEs per access
   network, then 67% or 75% of core-BW for multicast, broadcast and
   unknown unicast are respectively wasted.
  
   Therefore, it is recommended to have a protocol among n-PEs that can
   disseminate the status of PWs (active or blocked) among themselves
   and furthermore to have it tied up with the redundancy mechanism
   such that per VPLS instance the status of active/backup n-PE gets
   reflected on the corresponding PWs emanating from that n-PE.
  
   The above discussion was centered on the lack of efficiency with
   regards to packet replication over MPLS core network for current
   VPLS redundancy mechanism. Another important issue to consider is
   the interaction between customer and service provider redundancy
   mechanisms especially when customer devices are IEEE bridges. If CEs
   are IEEE bridges, then they can run RSTP/MSTP protocols, RSTP
   convergence and detection time is much faster than its predecessor
   (IEEE 802.1D STP which is obsolete). Therefore, if the provider
   network offers VPLS redundancy mechanism, then it should provide
   transparency to the customer's network during a failure within its
  
  
   Sajassi, et al.                                           [Page 15]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   network - e.g., the failure detection and recovery time within the
   service provider network to be less than the one in the customer
   network. If this is not the case, then a failure within the provider
   network can result in unnecessary switch-over and temporary
   flooding/loop within the customer's network that is dual homed.
  
  
  
   5.3.
        MAC Address Learning
  
   When customer devices are routers, servers, or hosts, then the
   number of MAC addresses per customer sites is very limited (most
   often one MAC address per CE). However, when CEs are bridges, then
   there can be many customer MAC addresses (e.g., hundreds of MAC
   addresses) associated with each CE.
  
   [P802.1ad] has devised a mechanism to alleviate MAC address learning
   within provider Ethernet networks that can equally be applied to
   VPLS networks. This mechanism calls for disabling MAC address
   learning for an S-VLAN (or a service instance) within a provider
   bridge (or PE) when there is only one ingress and one egress port
   associated with that service instance on that PE. In such cases,
   there is no need to learn customer MAC addresses on that PE since
   the path through that PE for that service instance is fixed. For
   example, if a service instance is associated with four CEs at four
   different sites, then the maximum number of provider bridges (or
   PEs), that need to participate in that customer MAC address
   learning, is only three regardless of how many PEs are in the path
   of that service instance. This mechanism can reduce the number of
   MAC addresses learned in a H-VPLS with QinQ access configuration.
  
   If the provider access network is of type Ethernet (e.g., IEEE
   802.1ad-based network), then the MSTP protocol can be used to
   partition the access network into several loop-free spanning tree
   topologies where Ethernet service instances (S-VLANs) are
   distributed among these tree topologies. Furthermore, GVRP can be
   used to limit the scope of each service instance to a subset of its
   associated tree topology (and thus limiting the scope of customer
   MAC address learning to that sub-tree). Finally, the MAC address
   disabling mechanism (described above) can be applied to that sub-
   tree, to further limit the number of nodes (PEs) on that sub-tree
   that need to learn customer MAC addresses for that service instance.
  
   Furthermore, [p802.1ah] provides the capability of encapsulating
   customers' MAC addresses within the provider MAC header. A u-PE
   capable of this functionality can reduce the number of MAC addressed
   learned significantly within the provider network for H-VPLS with
   QinQ access as well as H-VPLS with MPLS access.
  
  
  
  
  
   Sajassi, et al.                                           [Page 16]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   6.
      Interoperability with 802.1ad Networks
  
   [RFC-4762] discusses H-VPLS provider-network topologies with both
   Ethernet [P802.1ad] as well as MPLS access networks. Therefore, it is
   important to ensure seamless interoperability between these two types
   of networks.
  
   Provider bridges as specified in [P802.1ad] are intended to operate
   seamlessly with customer bridges and provide the required services.
   Therefore, if a PE is modeled based on Figures 1 and 2 which includes
   a [802.1ad] bridge module, then it should operate seamlessly with
   Provider Bridges given that the issues discussed in this draft have
   been taken into account.
  
  
   7.
      Acknowledgments
  
   The authors would like to thank Norm Finn and Samer Salam for their
   comments and valuable feedbacks.
  
  
   8.
      IANA Considerations
  
   This document has no actions for IANA.
  
  
  
   9.
      Security Considerations
  
   In addition to the security issues described in [RFC-4762], the
   following considerations apply:
  
   - When a CE that is a customer bridge is connected to the VPLS
   network, it may be desirable to secure the end-to-end communication
   between the customer bridge nodes across the VPLS network. This can
   be accomplished by running [802.1AE] MAC Security between the C-VLAN
   components of the customer bridges. In this case, the VPLS PEs must
   ensure transparent delivery of the encryption/security protocol
   datagrams using the Bridge Group Address [802.1ad].
  
   - When a CE that is a customer bridge is connected to the VPLS
   network, it may be desirable to secure the communication between the
   customer bridge and its directly connected PE. If the PE is modeled
   to include a [802.1ad] bridge module, then this can be achieved by
   running MAC Security between the customer bridge and the S-VLAN
   Component of the VPLS PE as described in section 7.7.2 of [802.1AX].
  
   - When and 802.1ad network is connected to a VPLS network, it is
   possible to secure the NNI between the two networks using the
   procedures of [802.1AE] and [802.1AX] between the S-VLAN Components
  
  
   Sajassi, et al.                                           [Page 17]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   of the Provider Edge Bridge and the VPLS PE connecting to it, as
   long as the PE is modeled to include a [802.1ad] bridge module.
  
  
  
  
  
   10.
       Normative References
  
   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.
  
   [RFC-4762] Lasserre, M. and et al, "Virtual Private LAN Services
   over MPLS", RFC 4762, January 2007
  
  
   [P802.1ad] IEEE Draft P802.1ad/D2.4 "Virtual Bridged Local Area
   Networks: Provider Bridges", Work in progress, September 2004
  
   [P802.1ag] IEEE Draft P802.1ag/D0.1 "Virtual Bridge Local Area
   Networks: Connectivity Fault Management", Work in Progress, October
   2004
  
  
   11.
       Informative References
  
   [RFC-4665] Agustyn, W. et al, "Service Requirements for Layer-2
   Provider Provisioned Virtual Provider Networks", RFC 4665, September
   2006
  
   [RFC-4664] Andersson, L. and et al, "Framework for Layer 2 Virtual
   Private Networks (L2VPNs)", RFC 4664, September 2006
  
   [IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS)", draft-ietf-
   l2vpn-ipls-09.txt, work in progress, February 2009
  
   [MFA-Ether] Sajassi, A. and et al, "Ethernet Service Interworking
   Over MPLS", Work in Progress, September 2004
  
   [RFC-4448] "Encapsulation Methods for Transport of Ethernet Frames
   Over IP/MPLS Networks", RFC 4448, April 2006
  
   [802.1D-REV] IEEE Std. 802.1D-2003 "Media Access Control (MAC)
   Bridges".
  
   [802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area
   Networks".
  
   [RFC-4541] Christensen, M. and et al, "Considerations for IGMP and
   MLD Snooping Switches", Work in progress, May 2004
  
  
  
   Sajassi, et al.                                           [Page 18]
  

   Internet Draft draft-ietf-l2vpn-vpls-bridge-interop.txt October 2010
  
   [Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, "L2VPN OAM
   Requirements and Framework", draft-ietf-l2vpn-oam-req-frmk-10.txt,
   Work in progress, November 2010
  
  
  
  Authors' Addresses
  
   Ali Sajassi
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   Email: sajassi@cisco.com
  
   Yetik Serbest
   SBC Labs
   9505 Arboretum Blvd.
   Austin, TX 78759
   Email: yetik_serbest@labs.sbc.com
  
   Frank Brockners
   Cisco Systems, Inc.
   Hansaallee 249
   40549 Duesseldorf
   Germany
   Email: fbrockne@cisco.com
  
   Dinesh Mohan
   Nortel Networks
   3500 Carling Ave
   Ottawa, ON K2H8E9
   Email: mohand@nortel.com
  
  
  
  
  
  
  
  
   Sajassi, et al.                                           [Page 19]
  

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