doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc6246.txt b/doc/rfc/rfc6246.txt
new file mode 100644
index 0000000..74142b4
--- /dev/null
+++ b/doc/rfc/rfc6246.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   A. Sajassi, Ed.
+Request for Comments: 6246                                  F. Brockners
+Category: Informational                                    Cisco Systems
+ISSN: 2070-1721                                            D. Mohan, Ed.
+                                                                  Nortel
+                                                              Y. Serbest
+                                                                    AT&T
+                                                               June 2011
+
+
+          Virtual Private LAN Service (VPLS) Interoperability
+                    with Customer Edge (CE) Bridges
+
+Abstract
+
+   One of the main motivations behind Virtual Private LAN Service (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 customer edge (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 document extends the provider edge (PE)
+   model described in RFC 4664 based on IEEE 802.1ad bridge module, and
+   it 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sajassi, et al.               Informational                     [Page 1]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6246.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   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
+   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.
+
+
+
+
+
+
+
+
+
+Sajassi, et al.               Informational                     [Page 2]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions ................................................4
+   2. Ethernet Service Instance .......................................4
+   3. VPLS-Capable PE Model with Bridge Module ........................5
+   4. Mandatory Issues ................................................8
+      4.1. Service Mapping ............................................8
+      4.2. CE Bridge Protocol Handling ...............................10
+      4.3. Partial Mesh of Pseudowires ...............................11
+      4.4. Multicast Traffic .........................................12
+   5. Optional Issues ................................................13
+      5.1. Customer Network Topology Changes .........................13
+      5.2. Redundancy ................................................15
+      5.3. MAC Address Learning ......................................16
+   6. Interoperability with 802.1ad Networks .........................17
+   7. Acknowledgments ................................................17
+   8. Security Considerations ........................................17
+   9. Normative References ...........................................18
+   10. Informative References ........................................19
+
+1.  Introduction
+
+   Virtual Private LAN Service (VPLS) is a LAN emulation service
+   intended for providing connectivity between geographically dispersed
+   customer sites across MANs/WANs (over MPLS/IP), 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 is desired, then an IP-
+   only LAN Service [IPLS] solution could be 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 [802.1ad] (or its
+   predecessor, QinQ-based networks).
+
+   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 document extends the PE model described in [RFC4664]
+   based on the 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 the 802.1ad bridge module,
+
+
+
+Sajassi, et al.               Informational                     [Page 3]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   thus removing the burden on the 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.
+
+   This document 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 [RFC4762].
+
+   This document 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 5 and 6 discuss these mandatory and optional
+   issues, respectively.
+
+1.1.  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 [RFC2119].
+
+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 [RFC6136]: a) as an end-to-end bridged LAN service
+   over one or more networks (one of which is an 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 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.
+
+   We define 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 User-Network
+   Interface (UNI) or a Network-Network Interface (NNI); furthermore, it
+   can be an Ethernet interface or a VLAN, it can be an ATM or Frame
+   Relay Virtual Circuit, or it can be a PPP/HDLC (PPP/High-Level Data
+
+
+
+
+
+Sajassi, et al.               Informational                     [Page 4]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   Link Control) interface.  If an ESI is associated with more than two
+   ACs, then it is a multipoint ESI.  In this document, wherever the
+   keyword ESI is used, it means multipoint ESI unless 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 [802.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
+   in service provider networks, its realization shall be done such that
+   it provides a separate Media Access Control (MAC) address domain and
+   broadcast domain per ESI.  A separate MAC address domain is provided
+   by using a separate MAC forwarding table (e.g., Forwarding
+   Information Base (FIB), also known as filtering database [802.1D])
+   per ESI (for both VPLS and IEEE 802.1ad networks).  A 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
+
+   [RFC4664] 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 [RFC4664] 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 [802.1ad].  We briefly describe the
+   second model and then expand upon this model to show its sub-
+   components based on the [802.1ad] Provider Bridge model.
+
+   As described in [RFC4664], 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 a 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 can correspond
+   to a single VLAN as depicted in Figure 1 below.  Thus, sometimes it
+   is referred to as VLAN emulation.
+
+
+
+Sajassi, et al.               Informational                     [Page 5]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+      +----------------------------------------+
+      |           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
+      |   |               |   ^      |      |-------------
+      |   +---------------+   |      +------+  |
+      |                       |                |
+      +-----------------------|----------------+
+                              |
+              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 (PWs)
+   associated with that VPLS instance (assuming raw mode PWs are used as
+   specified in [RFC4448]).
+
+   The bridge module can itself consist of one or two sub-components,
+   depending on the functionality that it needs to perform.  Figure 2
+   depicts the model for the bridge module based on [802.1ad].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sajassi, et al.               Informational                     [Page 6]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+                 +-------------------------------+
+                 |  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.  Model of the 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 Rapid Spanning Tree Protocol
+   (RSTP), Multiple Spanning Tree Protocol (MSTP), Generic VLAN
+   Registration Protocol (GVRP), GARP Multicast Registration Protocol
+   (GMRP), etc. -- among provider bridges within a single administrative
+   domain.
+
+   The customer VLAN (C-VLAN) bridge component is required when the
+   customer Attachment Circuits are VLANs (aka C-VLANs).  In such cases,
+   the VPLS-capable PE needs to participate in some of the customer's
+   bridging protocol such as RSTP and MSTP.  Such participation is
+   required because a 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 C-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
+
+
+
+Sajassi, et al.               Informational                     [Page 7]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   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., via VLAN bundling or port-based service), 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
+   [RFC4762], unqualified and qualified learning are used to refer to
+   port-based and VLAN-based operation, respectively.  [RFC4762] 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.  [802.1ad] allows for each customer AC
+   (either a physical port, a VLAN, or a group of VLANs) to be mapped
+   independently to an ESI that provides better service offerings to
+   enterprise customers.  For better and more flexible 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 their associated ESIs.  As can be seen, there are
+   several possible ways to perform such mappings.  In the first
+   scenario, it is assumed that an Ethernet physical port only carries
+   untagged traffic and all 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
+
+
+
+Sajassi, et al.               Informational                     [Page 8]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   VLAN is mapped to the corresponding service instance or ESI.  This is
+   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.  This is
+   referred to as "VLAN bundling".
+
+   ===================================================================
+               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 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 can support [802.1ad] frame format
+   because it will receive Ethernet frames with two tags, where the
+   outer tag is an S-VLAN and the inner tag is a C-VLAN received from
+   "port-based" AC.  One application example for such CE device is in a
+   Broadband Remote Access Server (BRAS) for DSL aggregation over a
+   Metro Ethernet network.
+
+   Note-3: In this asymmetric mapping scenario, it is assumed that the
+   CE device with "VLAN-based" AC can support the [802.1ad] frame format
+   because it will receive Ethernet frames with two tags, where the
+   outer tag is an S-VLAN and the inner tag is a C-VLAN received from
+   "VLAN bundling" AC.
+
+
+
+
+
+
+
+Sajassi, et al.               Informational                     [Page 9]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   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 [802.1ad].
+
+   As mentioned before, the mapping function between the customer AC and
+   its associated ESI is a local function; 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 the 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].  In such a case, the PE SHALL translate the
+   customer tag (C-VLAN) into the provider tag (S-VLAN) upon receiving a
+   frame from the customer.  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.  [802.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:
+
+      a) Transparent to the operation of the protocol among CEs of
+         different sites using the service provided, appearing as an
+         individual LAN without bridges;
+
+      b) Discarding frames, acting as a non-participating barrier to the
+         operation of the protocol;
+
+      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
+
+
+
+
+Sajassi, et al.               Informational                    [Page 10]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+      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 RSTPs or MSTPs (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 RSTPs or MSTPs 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.1AX];
+   however, this is a media-dependent protocol as its name implies.
+
+   [802.1ad] reserves a block of 16 MAC addresses for the operation of
+   C-VLAN and S-VLAN bridge components.  Also, it shows which of these
+   reserved MAC addresses are only for C-VLAN bridge components, which
+   are only for S-VLAN bridge components, and which 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, which
+   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.
+
+   When the PE model depicted in Figure 2 is used, then [802.1ag]
+   procedures could be used for detection of partial mesh of PWs.
+   [802.1ag] defines a set of procedures for fault detection,
+   verification, isolation, and notification per ESI.
+
+   The fault detection mechanism of [802.1ag] 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
+
+
+
+Sajassi, et al.               Informational                    [Page 11]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   coverage includes the bridge module within a PE and it is not limited
+   to just PWs.  Furthermore, [802.1ag] operates transparently over the
+   full mesh of PWs for a given service instance since it operates at
+   the Ethernet level (and not at the PW level).  It should be noted
+   that since a PW consists of two unidirectional Label Switched Paths
+   (LSPs), then one direction can fail independently of the other.  Even
+   in this case, the procedures of [802.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 this procedure, each PE keeps track of
+   the status of its PW Endpoint Entities (EEs, e.g., VPLS forwarders)
+   as well as the EEs reported by other PEs.  Therefore, upon a PW
+   failure, the PE that detects the failure not only takes notice
+   locally but also notifies other PEs belonging to that service
+   instance 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 Bidirectional Forward Detection
+   (BFD) or Virtual Circuit Connectivity Verification (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 point-to-point 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, which causes an
+   additional burden on the ingress PE through unnecessary packet
+   replication.  This in turn causes additional load on the MPLS core
+   network and additional processing at the receiving PE where
+   extraneous multicast packets are discarded.
+
+   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
+
+
+
+Sajassi, et al.               Informational                    [Page 12]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   notification as described in [RFC4541].  A "General Query" by the PE
+   results the customer multicast MAC address(es) being properly
+   registered at the PE when there are customer topology changes.  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
+   subset of PWs for packet replication, thus 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 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 Bridge Protocol
+   Data Units (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 connectivity fault management
+   (CFM) procedures (802.1ag) used for the 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
+
+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.  [RFC4665] provides some examples of
+   such customer network connectivity; they are depicted in Figure 3
+
+
+
+Sajassi, et al.               Informational                    [Page 13]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   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 in order 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.  There
+   are two methods for addressing this issue based on the provider
+   bridge model depicted in Figure 1.  In the first method, the Topology
+   Change Notification (TCN) message received from the CE device is
+   translated into one or more out-of-band "MAC Address Withdrawal"
+   messages as specified in [RFC4762].  In the second method, the TCN
+   message received from the CE device is translated into one or more
+   in-band "Flush" messages per [p802.1Qbe].  The second method is
+   recommended because of ease of interoperability between the bridge
+   and LAN emulation modules of the PE.
+
+
+
+
+
+
+
+
+Sajassi, et al.               Informational                    [Page 14]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+5.2.  Redundancy
+
+   [RFC4762] talks about dual-homing of a given Multi-Tenant Unit switch
+   (MTU-s) to two PEs over a provider MPLS access network to provide
+   protection against link and node failure.  For example, in case the
+   primary PE fails or the connection to it fails, then the MTU-s uses
+   the backup PWs to reroute the traffic to the backup 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 hub-and-spoke) can be supported using the provider's MSTP
+   protocol.  It also discusses 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 and MPLS access
+   networks), only one 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 PE are blocked by the MSTP; whereas, in case of
+   a MPLS access network, the access-facing PW is blocked at the MTU-s
+   for a given VPLS instance.
+
+      ------------------------+  Provider  +-----------------------
+                              .   Core     .
+                  +------+    .            .    +------+
+                  |  PE  |======================|  PE  |
+       Provider   |  (P) |---------\    /-------|  (P) |  Provider
+       Access     +------+    .     \  /   .    +------+  Access
+       Network                .      \/    .              Network
+         (1)      +------+    .      /\    .    +------+     (2)
+                  |  PE  |----------/  \--------|  PE  |
+                  |  (B) |----------------------|  (B) |
+                  +------+    .            .    +------+
+                              .            .
+      ------------------------+            +-----------------------
+
+                      Figure 4.  Bridge Module Model
+
+   Figure 4 shows two provider access networks each with two PEs that
+   are connected via a full mesh of PWs for a given VPLS instance.  As
+   shown in the figure, only one PE in each access network serves as a
+   Primary PE (P) for that VPLS instance and the other PE serves 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 PE from the access
+   network side, the PE replicates the frame over both PWs in the core
+   even though it only needs to send the frame over a single PW (shown
+   with "==" in Figure 4) to the primary PE on the other side.  This is
+   an unnecessary replication of the customer frames and consumes core-
+
+
+
+Sajassi, et al.               Informational                    [Page 15]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   network bandwidth (half of the frames get discarded at the receiving
+   PE).  This issue is aggravated when there are more than two PEs per
+   provider access network -- e.g., if there are three PEs or four PEs
+   per access network, then 67% or 75%, respectively, of core-network
+   bandwidth for multicast, broadcast, and unknown unicast are
+   respectively wasted.
+
+   Therefore, it is recommended to have a protocol among PEs that can
+   disseminate the status of PWs (active or blocked) among themselves.
+   Furthermore, it is recommended to have the protocol tied up with the
+   redundancy mechanism such that (per VPLS instance) the status of
+   active/backup PE gets reflected on the corresponding PWs emanating
+   from that PE.
+
+   The above discussion was centered on the inefficiency regarding
+   packet replication over MPLS core networks 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 RSTPs or MSTPs.  RSTP
+   convergence and detection time is much faster than its predecessor
+   (IEEE 802.1D STP, which is obsolete).  Therefore, if the provider
+   network offers a VPLS redundancy mechanism, then it should provide
+   transparency to the customer's network during a failure within its
+   network, e.g., the failure detection and recovery time within the
+   service provider network should 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.
+
+   [802.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
+
+
+
+Sajassi, et al.               Informational                    [Page 16]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   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
+   hierarchical VPLS (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 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 (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, [802.1ah] provides the capability of encapsulating
+   customers' MAC addresses within the provider MAC header.  A MTU-s
+   capable of this functionality can significantly reduce the number of
+   MAC addresses learned within the provider network for H-VPLS with
+   QinQ access, as well as H-VPLS with MPLS access.
+
+6.  Interoperability with 802.1ad Networks
+
+   [RFC4762] discusses H-VPLS provider-network topologies with both
+   Ethernet [802.1ad] and MPLS access networks.  Therefore, it is
+   important to ensure seamless interoperability between these two types
+   of networks.
+
+   Provider bridges as specified in [802.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 include
+   a [802.1ad] bridge module, then it should operate seamlessly with
+   Provider Bridges given that the issues discussed in this document
+   have been taken into account.
+
+7.  Acknowledgments
+
+   The authors would like to thank Norm Finn and Samer Salam for their
+   comments and valuable feedback.
+
+8.  Security Considerations
+
+   In addition to the security issues described in [RFC4762], the
+   following considerations apply:
+
+
+
+
+
+Sajassi, et al.               Informational                    [Page 17]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   - 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 an 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
+     of the Provider Edge Bridge and the attached VPLS PE, as long as
+     the PE is modeled to include an [802.1ad] bridge module.
+
+9.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4762]   Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
+               LAN Service (VPLS) Using Label Distribution Protocol
+               (LDP) Signaling", RFC 4762, January 2007.
+
+   [802.1ad]   IEEE 802.1ad-2005, "Amendment to IEEE 802.1Q-2005. IEEE
+               Standard for Local and Metropolitan Area Networks -
+               Virtual Bridged Local Area Networks Revision-Amendment 4:
+               Provider Bridges".
+
+   [802.1AE]   IEEE 802.1AE-2006, "IEEE Standard for Local and
+               Metropolitan Area Networks - Media Access Control (MAC)
+               Security".
+
+   [802.1ag]   IEEE 802.1ag-2007, "IEEE Standard for Local and
+               Metropolitan Area Networks - Virtual Bridged Local Area
+               Networks Amendment 5: Connectivity Fault Management".
+
+   [802.1ah]   IEEE 802.1ah-2008, "IEEE Standard for Local and
+               Metropolitan Area Networks - Virtual Bridged Local Area
+               Networks Amendment 7: Provider Backbone Bridges".
+
+
+
+
+Sajassi, et al.               Informational                    [Page 18]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+   [802.1AX]   IEEE 802.1AX-2008 "IEEE Standard for Local and
+               Metropolitan Area Networks - Link Aggregation".
+
+10.  Informative References
+
+   [IPLS]      Shah, H., Rosen, E., Le Faucheur, F., and G. Heron, "IP-
+               Only LAN Service (IPLS)", Work in Progress, February
+               2010.
+
+   [RFC4448]   Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
+               "Encapsulation Methods for Transport of Ethernet over
+               MPLS Networks", RFC 4448, April 2006.
+
+   [RFC4541]   Christensen, M., Kimball, K., and F. Solensky,
+               "Considerations for Internet Group Management Protocol
+               (IGMP) and Multicast Listener Discovery (MLD) Snooping
+               Switches", RFC 4541, May 2006.
+
+   [RFC4664]   Andersson, L., Ed., and E. Rosen, Ed., "Framework for
+               Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
+               September 2006.
+
+   [RFC4665]   Augustyn, W., Ed., and Y. Serbest, Ed., "Service
+               Requirements for Layer 2 Provider-Provisioned Virtual
+               Private Networks", RFC 4665, September 2006.
+
+   [RFC6136]   Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual
+               Private Network (L2VPN) Operations, Administration, and
+               Maintenance (OAM) Requirements and Framework", RFC 6136,
+               March 2011.
+
+   [802.1D]    IEEE 802.1D-2004, "IEEE Standard for Local and
+               Metropolitan Area Networks - Media access control (MAC)
+               Bridges (Incorporates IEEE 802.1t-2001 and IEEE 802.1w)".
+
+   [802.1Q]    IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area
+               Networks".
+
+   [p802.1Qbe] IEEE Draft Standard P802.1Qbe, "IEEE Draft Standard for
+               Local and Metropolitan Area Networks -- Virtual Bridged
+               Local Area Networks Amendment: Multiple I-SID
+               Registration Protocol".
+
+
+
+
+
+
+
+
+
+Sajassi, et al.               Informational                    [Page 19]
+
+RFC 6246              VPLS Interop with CE Bridges             June 2011
+
+
+Authors' Addresses
+
+   Ali Sajassi (editor)
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134
+   EMail: sajassi@cisco.com
+
+   Frank Brockners
+   Cisco Systems, Inc.
+   Hansaallee 249
+   40549 Duesseldorf
+   Germany
+   EMail: fbrockne@cisco.com
+
+   Dinesh Mohan (editor)
+   Nortel
+   Ottawa, ON K2K3E5
+   EMail: dinmohan@hotmail.com
+
+   Yetik Serbest
+   AT&T Labs
+   9505 Arboretum Blvd.
+   Austin, TX 78759
+   EMail: yetik_serbest@labs.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sajassi, et al.               Informational                    [Page 20]
+