doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc6624.txt b/doc/rfc/rfc6624.txt
new file mode 100644
index 0000000..f0b3fdb
--- /dev/null
+++ b/doc/rfc/rfc6624.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       K. Kompella
+Request for Comments: 6624                              Juniper Networks
+Category: Informational                                       B. Kothari
+ISSN: 2070-1721                                            Cisco Systems
+                                                            R. Cherukuri
+                                                        Juniper Networks
+                                                                May 2012
+
+
+             Layer 2 Virtual Private Networks Using BGP for
+                      Auto-Discovery and Signaling
+
+Abstract
+
+   Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM
+   circuits have been around a long time; more recently, Ethernet VPNs,
+   including Virtual Private LAN Service, have become popular.
+   Traditional L2VPNs often required a separate Service Provider
+   infrastructure for each type and yet another for the Internet and IP
+   VPNs.  In addition, L2VPN provisioning was cumbersome.  This document
+   presents a new approach to the problem of offering L2VPN services
+   where the L2VPN customer's experience is virtually identical to that
+   offered by traditional L2VPNs, but such that a Service Provider can
+   maintain a single network for L2VPNs, IP VPNs, and the Internet, as
+   well as a common provisioning methodology for all services.
+
+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/rfc6624.
+
+
+
+
+
+
+
+
+
+
+Kompella, et al.              Informational                     [Page 1]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al.              Informational                     [Page 2]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................6
+           1.1.1. Conventions Used in This Document ...................6
+      1.2. Advantages of Layer 2 VPNs .................................6
+           1.2.1. Separation of Administrative Responsibilities .......7
+           1.2.2. Migrating from Traditional Layer 2 VPNs .............7
+           1.2.3. Privacy of Routing ..................................7
+           1.2.4. Layer 3 Independence ................................7
+           1.2.5. PE Scaling ..........................................8
+           1.2.6. Ease of Configuration ...............................8
+      1.3. Advantages of Layer 3 VPNs .................................9
+           1.3.1. Layer 2 Independence ................................9
+           1.3.2. SP Routing as Added Value ..........................10
+           1.3.3. Class of Service ...................................10
+      1.4. Multicast Routing .........................................10
+   2. Operation of a Layer 2 VPN .....................................11
+      2.1. Network Topology ..........................................11
+      2.2. Configuration .............................................13
+           2.2.1. CE Configuration ...................................14
+           2.2.2. PE Configuration ...................................15
+           2.2.3. Adding a New Site ..................................15
+           2.2.4. Deleting a Site ....................................16
+           2.2.5. Managing CE ID Mappings ............................16
+           2.2.6. Managing Label Blocks ..............................16
+      2.3. Operations, Administration, and Maintenance (OAM) .........17
+   3. PE Information Exchange ........................................17
+      3.1. Circuit Status Vector .....................................19
+      3.2. Generalizing the VPN Topology .............................20
+   4. Layer 2 Interworking ...........................................21
+   5. Packet Transport ...............................................22
+      5.1. Layer 2 MTU ...............................................22
+      5.2. Layer 2 Frame Format ......................................22
+      5.3. IP-Only Layer 2 Interworking ..............................23
+   6. Security Considerations ........................................23
+   7. IANA Considerations ............................................23
+   8. Acknowledgments ................................................24
+   9. Contributors ...................................................24
+   10. References ....................................................24
+      10.1. Normative References .....................................24
+      10.2. Informative References ...................................25
+
+
+
+
+
+
+
+
+
+Kompella, et al.              Informational                     [Page 3]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+1.  Introduction
+
+   The earliest Virtual Private Networks (VPNs) were based on Layer 2
+   circuits: X.25, Frame Relay, and ATM (see [Kosiur]).  More recently,
+   multipoint VPNs based on Ethernet Virtual Local Area Networks (VLANs)
+   and Virtual Private LAN Service (VPLS) [RFC4761][RFC4762] have become
+   quite popular.  In contrast, the VPNs described in this document are
+   point-to-point, and usually called Virtual Private Wire Service
+   (VPWS).  All of these come under the classification of Layer 2 VPNs
+   (L2VPNs), as the customer-to-Service-Provider hand-off is at Layer 2.
+
+   There are at least two factors that adversely affected the cost of
+   offering L2VPNs.  The first is that the easiest way to offer an L2VPN
+   of a given type of Layer 2 was over an infrastructure of the same
+   type.  This approach required that the Service Provider build a
+   separate infrastructure for each Layer 2 encapsulation, e.g., an ATM
+   infrastructure for ATM VPNs, an Ethernet infrastructure for Ethernet
+   VPNs, etc.  In addition, a separate infrastructure was needed for the
+   Internet and IP VPNs [RFC4364], and possibly yet another for voice
+   services.  Going down this path meant a proliferation of networks.
+
+   The other is that each of these networks had different provisioning
+   methodologies.  Furthermore, the provisioning of an L2VPN was fairly
+   complex.  It is important to distinguish between a single Layer 2
+   circuit, which connects two customer sites, and a Layer 2 VPN, which
+   is a set of circuits that connect sites belonging to the same
+   customer.  The fact that two different circuits belonged to the same
+   VPN was typically known only to the provisioning system, not to the
+   switches offering the service; this complicated the setting up, and
+   subsequently, the troubleshooting, of an L2VPN.  Also, each switch
+   offering the service had to be provisioned with the address of every
+   other switch in the same VPN, requiring, in the case of full-mesh VPN
+   connectivity, provisioning proportional to the square of the number
+   of sites.  This made full-mesh L2VPN connectivity prohibitively
+   expensive for the Service Provider (SP) and thus also for customers.
+   Finally, even setting up an individual circuit often required the
+   provisioning of every switch along the path.
+
+   Of late, there has been much progress in network "convergence",
+   whereby Layer 2 traffic, Internet traffic, and IP VPN traffic can be
+   carried over a single, consolidated network infrastructure based on
+   IP/MPLS tunnels; this is made possible by techniques such as those
+   described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717] for Layer
+   2 traffic and in [RFC4364] for IP VPN traffic.  This development goes
+   a long way toward addressing the problem of network proliferation.
+   This document goes one step further and shows how a Service Provider
+   can offer Layer 2 VPNs using protocol and provisioning methodologies
+   similar to that used for VPLS [RFC4761] and IP VPNs [RFC4364],
+
+
+
+Kompella, et al.              Informational                     [Page 4]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   thereby achieving a significant degree of operational convergence as
+   well.  In particular, all of these methodologies include the notion
+   of a VPN identifier that serves to unify components of a given VPN
+   and the concept of auto-discovery, which simplifies the provisioning
+   of dense VPN topologies (for example, a full mesh).  In addition,
+   similar techniques are used in all of the above-mentioned VPN
+   technologies to offer inter-AS and inter-provider VPNs (i.e., VPNs
+   whose sites are connected to multiple Autonomous Systems (ASes) or
+   Service Providers).
+
+   Technically, the approach proposed here uses the concepts and
+   solution described in [RFC4761], which describes a method for VPLS, a
+   particular form of a Layer 2 VPN.  That document, in turn, borrowed
+   much from [RFC4364], including the use of BGP for auto-discovery and
+   "demultiplexor" (see below) exchange and the concepts of Route
+   Distinguishers to make VPN advertisements unique and Route Targets to
+   control VPN topology.  In addition, all three documents share the
+   idea that routers not directly connected to VPN customers should
+   carry no VPN state, restricting the provisioning of individual
+   connections to just the edge devices.  This is achieved using tunnels
+   to carry the data, with a demultiplexor that identifies individual
+   VPN circuits.  These tunnels could be based on MPLS, GRE, or any
+   other tunnel technology that offers a demultiplexing field; the
+   signaling of these tunnels is outside the scope of this document.
+   The specific approach taken here is to use an MPLS label as the
+   demultiplexor.
+
+   Layer 2 VPNs typically require that all sites in the VPN connect to
+   the SP with the same Layer 2 encapsulation.  To ease this
+   restriction, this document proposes a limited form of Layer 2
+   interworking, by restricting the Layer 3 protocol to IP only (see
+   Section 4).
+
+   It may be instructive to compare the approach described in [RFC4447]
+   and [RFC6074] (these are the IETF-approved technologies for the
+   functions described in this document, albeit using two separate
+   protocols) with the one described here.  To comply with IETF
+   standards, it is recommended that devices implementing the solution
+   described in this document also implement the approach in [RFC4447]
+   and [RFC6074].
+
+   The rest of this section discusses the relative merits of Layer 2 and
+   Layer 3 VPNs.  Section 2 describes the operation of a Layer 2 VPN.
+   Section 3 describes PE information exchange.  Section 4 describes IP-
+   only Layer 2 interworking.  Section 5 describes how the L2 packets
+   are transported across the SP network.
+
+
+
+
+
+Kompella, et al.              Informational                     [Page 5]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+1.1.  Terminology
+
+   The terminology used is from [RFC4761] and [RFC4364]; it is briefly
+   repeated here.  A "customer" is a customer of a Service Provider
+   seeking to interconnect their various "sites" (each an independent
+   network) at Layer 2 through the Service Provider's network, while
+   maintaining privacy of communication and address space.  The device
+   in a customer site that connects to a Service Provider router is
+   termed the CE (customer edge) device; this device may be a router or
+   a switch.  The Service Provider router to which a CE connects is
+   termed a PE (provider edge).  A router in the Service Provider's
+   network that doesn't connect directly to any CE is termed P
+   ("provider" device).  Every pair of PEs is connected by a "tunnel";
+   within a tunnel, VPN data is distinguished by a "demultiplexor",
+   which in this document is an MPLS label.
+
+   Each CE within a VPN is assigned a CE ID, a number that uniquely
+   identifies a CE within an L2VPN.  More accurately, the CE ID
+   identifies a physical connection from the CE device to the PE, since
+   a CE may be connected to multiple PEs (or multiply connected to a
+   PE); in such a case, the CE would have a CE ID for each connection.
+   A CE may also be part of many L2VPNs; it would need one (or more) CE
+   ID(s) for each L2VPN of which it is a member.  The number space for
+   CE IDs is scoped to a given VPN.
+
+   In the case of inter-provider L2VPNs, there needs to be some
+   coordination of allocation of CE IDs.  One solution is to allocate
+   ranges for each SP.  Other solutions may be forthcoming.
+
+   Within each physical connection from a CE to a PE, there may be
+   multiple virtual circuits.  These will be referred to as Attachment
+   Circuits (ACs), following [RFC3985].  Similarly, the entity that
+   connects two attachment circuits across the Service Provider network
+   is called a pseudowire (PW).
+
+1.1.1.  Conventions Used in This Document
+
+   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].
+
+1.2.  Advantages of Layer 2 VPNs
+
+   A Layer 2 VPN is one where a Service Provider provides Layer 2
+   connectivity to the customer.  The Service Provider does not
+   participate in the customer's Layer 3 network, especially in the
+   routing, resulting in several advantages to the SP as a whole and to
+   PE routers in particular.
+
+
+
+Kompella, et al.              Informational                     [Page 6]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+1.2.1.  Separation of Administrative Responsibilities
+
+   In a Layer 2 VPN, the Service Provider is responsible for Layer 2
+   connectivity; the customer is responsible for Layer 3 connectivity,
+   which includes routing.  If the customer says that host x in site A
+   cannot reach host y in site B, the Service Provider need only
+   demonstrate that site A is connected to site B.  The details of how
+   routes for host y reach host x are the customer's responsibility.
+
+   Another important factor is that once a PE provides Layer 2
+   connectivity to its connected CE, its job is done.  A misbehaving CE
+   can at worst flap its interface, but route flaps in the customer
+   network have little effect on the SP network.  On the other hand, a
+   misbehaving CE in a Layer 3 VPN can flap its routes, leading to
+   instability of the PE router or even the entire SP network.  Thus,
+   when offering a Layer 3 VPN, an SP should proactively protect itself
+   from Layer 3 instability in the CE network.
+
+1.2.2.  Migrating from Traditional Layer 2 VPNs
+
+   Since "traditional" Layer 2 VPNs (i.e., real Frame Relay circuits
+   connecting sites) are indistinguishable from tunnel-based VPNs from
+   the customer's point of view, migrating from one to the other raises
+   few issues.  Layer 3 VPNs, on the other hand, require a considerable
+   redesign of the customer's Layer 3 routing architecture.
+   Furthermore, with Layer 3 VPNs, special care has to be taken that
+   routes within the traditional VPN are not preferred over the Layer 3
+   VPN routes (the so-called "backdoor routing" problem, whose solution
+   requires protocol changes that are somewhat ad hoc).
+
+1.2.3.  Privacy of Routing
+
+   In an L2VPN, the privacy of customer routing is a natural fallout of
+   the fact that the Service Provider does not participate in routing.
+   The SP routers need not do anything special to keep customer routes
+   separate from other customers or from the Internet; there is no need
+   for per-VPN routing tables and the additional complexity this imposes
+   on PE routers.
+
+1.2.4.  Layer 3 Independence
+
+   Since the Service Provider simply provides Layer 2 connectivity, the
+   customer can run any Layer 3 protocols they choose.  If the SP were
+   participating in customer routing, it would be vital that the
+   customer and SP both use the same Layer 3 protocol(s) and routing
+   protocols.
+
+
+
+
+
+Kompella, et al.              Informational                     [Page 7]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   Note that IP-only Layer 2 interworking doesn't have this benefit as
+   it restricts the Layer 3 to IP only.
+
+1.2.5.  PE Scaling
+
+   In the Layer 2 VPN scheme described below, each PE transmits a single
+   small chunk of information about every CE that the PE is connected to
+   every other PE.  That means that each PE need only maintain a single
+   chunk of information from each CE in each VPN and keep a single
+   "route" to every site in every VPN.  This means that both the
+   Forwarding Information Base and the Routing Information Base scale
+   well with the number of sites and number of VPNs.  Furthermore, the
+   scaling properties are independent of the customer: the only germane
+   quantity is the total number of VPN sites.
+
+   This is to be contrasted with Layer 3 VPNs, where each CE in a VPN
+   may have an arbitrary number of routes that need to be carried by the
+   SP.  This leads to two issues.  First, both the information stored at
+   each PE and the number of routes installed by the PE for a CE in a
+   VPN can be (in principle) unbounded, which means in practice that a
+   PE must restrict itself to installing routes associated with the VPNs
+   of which it is currently a member.  Second, a CE can send a large
+   number of routes to its PE, which means that the PE must protect
+   itself against such a condition.  Thus, the SP must enforce limits on
+   the number of routes accepted from a CE; this, in turn, requires the
+   PE router to offer such control.
+
+   The scaling issues of Layer 3 VPNs come into sharp focus at a BGP
+   route reflector (RR).  An RR cannot keep all the advertised routes in
+   every VPN since the number of routes will be too large.  The
+   following solutions/extensions are needed to address this issue:
+
+   1.  RRs could be partitioned so that each RR services a subset of
+       VPNs so that no single RR has to carry all the routes.
+
+   2.  An RR could use a preconfigured list of Route Targets for its
+       inbound route filtering.  The RR may choose to perform Route
+       Target Filtering, described in [RFC4684].
+
+1.2.6.  Ease of Configuration
+
+   Configuring traditional Layer 2 VPNs with dense topologies was a
+   burden primarily because of the O(n*n) nature of the task.  If there
+   are n CEs in a Frame Relay VPN, say full-mesh connected, n*(n-1)/2
+   DLCI (Data Link Connection Identifier) Permanent Virtual Circuits
+   (PVCs) must be provisioned across the SP network.  At each CE, (n-1)
+   DLCIs must be configured to reach each of the other CEs.
+   Furthermore, when a new CE is added, n new DLCI PVCs must be
+
+
+
+Kompella, et al.              Informational                     [Page 8]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   provisioned; also, each existing CE must be updated with a new DLCI
+   to reach the new CE.  Finally, each PVC requires state in every
+   transit switch.
+
+   In our proposal, PVCs are tunneled across the SP network.  The
+   tunnels used are provisioned independently of the L2VPNs, using
+   signaling protocols (in the case of MPLS, LDP or RSVP - Traffic
+   Engineering (RSVP-TE) can be used), or set up by configuration; the
+   number of tunnels is independent of the number of L2VPNs.  This
+   reduces a large part of the provisioning burden.
+
+   Furthermore, we assume that DLCIs at the CE edge are relatively cheap
+   and that VPN labels in the SP network are cheap.  This allows the SP
+   to "overprovision" VPNs, for example, allocate 50 CEs to a VPN when
+   only 20 are needed.  With this overprovisioning, adding a new CE to a
+   VPN requires configuring just the new CE and its associated PE;
+   existing CEs and their PEs need not be reconfigured.  Note that if
+   DLCIs at the CE edge are expensive, e.g., if these DLCIs are
+   provisioned across a switched network, one could provision them as
+   and when needed, at the expense of extra configuration.  This need
+   not still result in extra state in the SP network, i.e., an
+   intelligent implementation can allow overprovisioning of the pool of
+   VPN labels.
+
+1.3.  Advantages of Layer 3 VPNs
+
+   Layer 3 VPNs ([RFC4364] in particular) offer a good solution when the
+   customer traffic is wholly IP, customer routing is reasonably simple,
+   and the customer sites connect to the SP with a variety of Layer 2
+   technologies.
+
+1.3.1.  Layer 2 Independence
+
+   One major restriction in a Layer 2 VPN is that the Layer 2 media with
+   which the various sites of a single VPN connect to the SP must be
+   uniform.  On the other hand, the various sites of a Layer 3 VPN can
+   connect to the SP with any supported media; for example, some sites
+   may connect with Frame Relay circuits and others with Ethernet.
+
+   This restriction of Layer 2 VPN is alleviated by the IP-only Layer 2
+   interworking proposed in this document.  This comes at the cost of
+   losing the Layer 3 independence.
+
+   A corollary to this is that the number of sites that can be in a
+   Layer 2 VPN is determined by the number of Layer 2 circuits that the
+   Layer 2 technology provides.  For example, if the Layer 2 technology
+   is Frame Relay with 2-octet DLCIs, a CE can at most connect to about
+   a thousand other CEs in a VPN.
+
+
+
+Kompella, et al.              Informational                     [Page 9]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+1.3.2.  SP Routing as Added Value
+
+   Another problem with Layer 2 VPNs is that the CE router in a VPN must
+   be able to deal with having N routing peers, where N is the number of
+   sites in the VPN.  This can be alleviated by manipulating the
+   topology of the VPN.  For example, a hub-and-spoke VPN architecture
+   means that only one CE router (the hub) need deal with N neighbors.
+   However, in a Layer 3 VPN, a CE router need only deal with one
+   neighbor, the PE router.  Thus, the SP can offer Layer 3 VPNs as a
+   value-added service to its customers.
+
+   Moreover, with Layer 2 VPNs, it is up to a customer to build and
+   operate the whole network.  With Layer 3 VPNs, a customer is just
+   responsible for building and operating routing within each site,
+   which is likely to be much simpler than building and operating
+   routing for the whole VPN.  That, in turn, makes Layer 3 VPNs more
+   suitable for customers who don't have sufficient routing expertise,
+   again allowing the SP to provide added value.
+
+   As mentioned later, multicast routing and forwarding is another
+   value-added service that an SP can offer.
+
+1.3.3.  Class of Service
+
+   Class-of-Service (CoS) issues have been addressed for Layer 3 VPNs.
+   Since the PE router has visibility into the network Layer (IP), the
+   PE router can take on the tasks of CoS classification and routing.
+   This restriction on Layer 2 VPNs is again eased in the case of IP-
+   only Layer 2 interworking, as the PE router has visibility into the
+   network Layer (IP).
+
+1.4.  Multicast Routing
+
+   There are two aspects to multicast routing that we will consider.  On
+   the protocol front, supporting IP multicast in a Layer 3 VPN requires
+   PE routers to participate in the multicast routing instance of the
+   customer and thus keep some related state information.
+
+   In the Layer 2 VPN case, the CE routers run native multicast routing
+   directly.  The SP network just provides pipes to connect the CE
+   routers; PEs are unaware whether the CEs run multicast or not and
+   thus do not have to participate in multicast protocols or keep
+   multicast state information.
+
+   On the forwarding front, in a Layer 3 VPN, CE routers do not
+   replicate multicast packets; thus, the CE-PE link carries only one
+   copy of a multicast packet.  Whether replication occurs at the
+   ingress PE or somewhere within the SP network depends on the
+
+
+
+Kompella, et al.              Informational                    [Page 10]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   sophistication of the Layer 3 VPN multicast solution.  The simple
+   solution where a PE replicates packets for each of its CEs may place
+   considerable burden on the PE.  More complex solutions may require
+   VPN multicast state in the SP network but may significantly reduce
+   the traffic in the SP network by delaying packet replication until
+   needed.
+
+   In a Layer 2 VPN, packet replication occurs at the CE.  This has the
+   advantage of distributing the burden of replication among the CEs
+   rather than focusing it on the PE to which they are attached and thus
+   will scale better.  However, the CE-PE link will need to carry
+   multiple copies of multicast packets.  However, in the case of
+   Virtual Private LAN Service (a specific type of L2VPN; see
+   [RFC4761]), the CE-PE link need transport only one copy of a
+   multicast packet.
+
+   Thus, just as in the case of unicast routing, the SP has the choice
+   to offer a value-added service (multicast routing and forwarding) at
+   some cost (multicast state and packet replication) using a Layer 3
+   VPN or to keep it simple and use a Layer 2 VPN.
+
+2.  Operation of a Layer 2 VPN
+
+   The following simple example of a customer with four sites connected
+   to three PE routers in a Service Provider network will hopefully
+   illustrate the various aspects of the operation of a Layer 2 VPN.
+   For simplicity, we assume that a full-mesh topology is desired.
+
+   In what follows, Frame Relay serves as the Layer 2 media, and each CE
+   has multiple DLCIs to its PE, each connecting to another CE in the
+   VPN.  If the Layer 2 media were ATM, then each CE would have multiple
+   VPIs/VCIs (Virtual Path Identifiers/Virtual Channel Identifiers) to
+   connect to other CEs.  For Point-to-Point Protocol (PPP) and Cisco
+   High-Level Data Link Control (HDLC), each CE would have multiple
+   physical interfaces to connect to other CEs.  In the case of IP-only
+   Layer 2 interworking, each CE could have a mix of one or more of the
+   above Layer 2 media to connect to other CEs.
+
+2.1.  Network Topology
+
+   Consider a Service Provider network with edge routers PE0, PE1, and
+   PE2.  Assume that PE0 and PE1 are IGP neighbors, and PE2 is more than
+   one hop away from PE0.
+
+   Suppose that a customer C has four sites S0, S1, S2, and S3, that C
+   wants to connect via the Service Provider's network using Frame
+   Relay.  Site S0 has CE0 and CE1 both connected to PE0.  Site S1 has
+   CE2 connected to PE0.  Site S2 has CE3 connected to PE1 and CE4
+
+
+
+Kompella, et al.              Informational                    [Page 11]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   connected to PE2.  Site S3 has CE5 connected to PE2.  (See Figure 1
+   below.)  Suppose further that C wants to "overprovision" each current
+   site, in expectation that the number of sites will grow to at least
+   10 in the near future.  However, CE4 is only provisioned with nine
+   DLCIs.  (Note that the signaling mechanism discussed in Section 3.2
+   of [RFC4761] will allow a site to grow in terms of connectivity to
+   other sites at a later point of time at the cost of additional
+   signaling, i.e., overprovisioning is not a must but a
+   recommendation).
+
+   Finally, suppose that the CEs have been provisioned with DLCIs as per
+   the following:
+
+      CE#  |  Provisioned DLCIs
+     --------------------------------------------------------
+        0  |  100 through 109
+        1  |  200 through 209
+        2  |  100 through 109
+        3  |  200 through 209
+        4  |  107, 209, 265, 301, 414, 555, 654, 777, and 888
+        5  |  417 through 426
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 12]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+           S0                                                   S3
+     ..............                                       ..............
+     .            .                                       .            .
+     .    +-----+ .                                       .            .
+     .    | CE0 |-----------+                             .   +-----+  .
+     .    +-----+ .         |                             .   | CE5 |  .
+     .            .         |                             .   +--+--+  .
+     .    +-----+ .         |                             .      |     .
+     .    | CE1 |-------+   |                             .......|......
+     .    +-----+ .     |   |                                   /
+     .            .     |   |                                  /
+     ..............     |   |                                 /
+                        |   |         SP Network             /
+                   .....|...|.............................../.....
+                   .    |   |                              /     .
+                   .  +-+---+-+       +-------+           /      .
+                   .  |  PE0  |-------|   P   |--        |       .
+                   .  +-+---+-+       +-------+  \       |       .
+                   .   /    \                     \  +---+---+   .
+                   .  |      -----+                --|  PE2  |   .
+                   .  |           |                  +---+---+   .
+                   .  |       +---+---+                 /        .
+                   .  |       |  PE1  |                /         .
+                   .  |       +---+---+               /          .
+                   .  |            \                 /           .
+                   ...|.............|.............../.............
+                      |             |              /
+                      |             |             /
+                      |             |            /
+          S1          |             |    S2     /
+     ..............   |     ........|........../......
+     .            .   |     .       |         |      .
+     .    +-----+ .   |     .    +--+--+   +--+--+   .
+     .    | CE2 |-----+     .    | CE3 |   | CE4 |   .
+     .    +-----+ .         .    +-----+   +-----+   .
+     .            .         .                        .
+     ..............         ..........................
+
+                    Figure 1: Example Network Topology
+
+2.2.  Configuration
+
+   The following sub-sections detail the configuration that is needed to
+   provision the above VPN.  For the purpose of exposition, we assume
+   that the customer will connect to the SP with Frame Relay circuits.
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 13]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   While we focus primarily on the configuration that an SP has to do,
+   we touch upon the configuration requirements of CEs as well.  The
+   main point of contact in CE-PE configuration is that both must agree
+   on the DLCIs that will be used on the interface connecting them.
+
+   If the PE-CE connection is Frame Relay, it is recommended to run Link
+   Management Interface (LMI) between the PE and CE.  For the case of
+   ATM VCs, Operations, Administration, and Maintenance (OAM) cells may
+   be used.  For PPP and Cisco HDLC, keepalives may be used directly
+   between CEs; however, in this case, PEs would not have visibility as
+   to the liveness of customers circuits.
+
+   In the case of IP-only Layer 2 interworking, if CE1, attached to PE0,
+   connects to CE3, attached to PE1, via an L2VPN circuit, the Layer 2
+   media between CE1 and PE0 is independent of the Layer 2 media between
+   CE3 and PE1.  Each side will run its own Layer-2-specific link
+   management protocol, e.g., LMI, Link Control Protocol (LCP), etc.
+   PE0 will inform PE1 about the status of its local circuit to CE1 via
+   the circuit status vector TLV defined in Section 3.1.  Similarly, PE1
+   will inform PE0 about the status of its local circuit to CE3.
+
+2.2.1.  CE Configuration
+
+   Each CE that belongs to a VPN is given a "CE ID".  CE IDs must be
+   unique in the context of a VPN.  For the example, we assume that the
+   CE ID for CE-k is k.
+
+   Each CE is configured to communicate with its corresponding PE with
+   the set of DLCIs given above, for example, CE0 is configured with
+   DLCIs 100 through 109.  In general, a CE is configured with a list of
+   circuits, all with the same Layer 2 encapsulation type, e.g., DLCIs,
+   VCIs, physical PPP interface, etc.  (IP-only Layer 2 interworking
+   allows a mix of Layer 2 encapsulation types.)  The size of this list/
+   set determines the number of remote CEs with which a given CE can
+   communicate.  Denote the size of this list/set as the CE's range.  A
+   CE's range must be at least the number of remote CEs that the CE will
+   connect to in a given VPN; if the range exceeds this, then the CE is
+   overprovisioned, in anticipation of growth of the VPN.
+
+   Each CE also "knows" which DLCI connects it to every other CE.  The
+   methodology followed in this example is to use the CE ID of the other
+   CE as an index into the DLCI list this CE has (with zero-based
+   indexing, i.e., 0 is the first index).  For example, CE0 is connected
+   to CE3 through its fourth DLCI, 103; CE4 is connected to CE2 by the
+   third DLCI in its list, namely 265.  This is just the methodology
+   used in the description here; the actual methodology used to pick the
+   DLCI to be used is a local matter.  The key factor is that CE-k may
+   communicate with CE-m using a different DLCI from the DLCI that CE-m
+
+
+
+Kompella, et al.              Informational                    [Page 14]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   uses to communicate to CE-k, i.e., the SP network effectively acts as
+   a giant Frame Relay switch.  This is very important, as it decouples
+   the DLCIs used at each CE site, making for much simpler provisioning.
+
+2.2.2.  PE Configuration
+
+   Each PE is configured with the VPNs in which it participates.  Each
+   VPN is associated with one or more Route Target communities [RFC4360]
+   that serve to define the topology of the VPN.  For each VPN, the PE
+   must determine a Route Distinguisher (RD) to use; this may either be
+   configured or chosen by the PE.  RDs do not have to be unique across
+   the VPN.  For each CE attached to the PE in a given VPN, the PE must
+   know the set of virtual circuits (DLCI, VCI/VPI, or VLAN) connecting
+   it to the CE and a CE ID identifying the CE within the VPN.  CE IDs
+   must be unique in the context of a given VPN.
+
+2.2.3.  Adding a New Site
+
+   The first step in adding a new site to a VPN is to pick a new CE ID.
+   If all current members of the VPN are overprovisioned, i.e., their
+   range includes the new CE ID, adding the new site is a purely local
+   task.  Otherwise, the sites whose range doesn't include the new CE ID
+   and that wish to communicate directly with the new CE must have their
+   ranges increased by allocating additional local circuits to
+   incorporate the new CE ID.
+
+   The next step is ensuring that the new site has the required
+   connectivity.  This usually requires adding a new virtual circuit
+   between the PE and CE; in most cases, this configuration is limited
+   to the PE in question.
+
+   The rest of the configuration is a local matter between the new CE
+   and the PE to which it is attached.  At this point, the PE can signal
+   to other PEs that it has a new site in the VPN by advertising a BGP
+   Layer 2 route, and traffic connectivity will be set up.
+
+   It bears repeating that the key to making additions easy is
+   overprovisioning and the algorithm for mapping a CE ID to a DLCI that
+   is used for connecting to the corresponding CE.  However, what is
+   being overprovisioned is the number of DLCIs/VCIs that connect the CE
+   to the PE.  This is a local matter between the PE and CE; it does not
+   affect other PEs or CEs.
+
+
+
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 15]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+2.2.4.  Deleting a Site
+
+   Deleting a site consists first of removing the CE ID of the site from
+   the configuration of the PE to which the site is attached.  The PE
+   will then signal to other PEs that it no longer has access to that
+   site by withdrawing its previously advertised BGP Layer 2 route.
+   Connectivity to the deleted site will cease.
+
+   The next steps are bookkeeping: decommissioning the attachment
+   circuit from the PE to the CE that corresponds to the site being
+   removed and noting that the CE ID is now free for future allocation.
+   Note that each PE is now (further) overprovisioned; one may choose to
+   actively "reap" CE IDs if desired.
+
+2.2.5.  Managing CE ID Mappings
+
+   In the data plane, an attachment circuit, identified say by a DLCI,
+   is mapped to a label via the control plane abstraction of a CE ID.
+   At the egress PE, the label is mapped back to an attachment circuit
+   via the same CE ID.  It is up to the VPN administrator
+
+   o  to provision attachment circuits (e.g., DLCIs);
+
+   o  to allocate CE IDs; and
+
+   o  to keep a clear mapping of CE IDs to attachment circuits (and
+      reflect this in PE configurations).
+
+   The PEs manage the mappings between attachment circuits and labels,
+   i.e., the data plane mappings.
+
+   Note that in the N-to-one modes listed in Table 1, a single
+   attachment circuit may correspond to several Layer 2 virtual
+   circuits.  Nevertheless, there is a one-to-one mapping between an
+   attachment circuit and a CE ID (and thus a label).
+
+2.2.6.  Managing Label Blocks
+
+   Label blocks and label values are managed by the PEs.  As sites get
+   added and removed, labels are allocated and released.  The easiest
+   way to manage these is to use fixed-size label blocks rather than
+   variable-size blocks, although the signaling described here supports
+   either.  If an implementation uses fixed-size blocks, then allocating
+   a label for a new site may requiring allocating a new block;
+   similarly, freeing a label may require freeing a block.
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 16]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   If the implementation requires fixed-size blocks, there is probably a
+   default block size, but the implementation SHOULD allow the
+   administrator to choose a size.  Larger label block sizes mean more
+   potential "wasted" labels but less signaling overhead, a trade-off
+   that the administrator might want to control.
+
+   Also, as sites get added and deleted, a PE may receive packets with a
+   label that reflects a site that has been deleted locally but not yet
+   processed by remote PEs or that reflects a new site added remotely
+   but not processed locally.  In either of these cases, the PE SHOULD
+   silently discard the packet; it may choose to log the event once for
+   each such label, but not for every such packet.
+
+2.3.  Operations, Administration, and Maintenance (OAM)
+
+   Many Layer 2 mediums have OAM mechanisms.  For example, the PPP has
+   Echo Request and Echo Reply messages; Frame Relay has the Local
+   Management Interface.  Among other things, OAM is used for
+   troubleshooting and as keepalives.
+
+   There are two ways to carry OAM information across Layer 2 VPNs.  The
+   first is to convey OAM packets as any other Layer 2 packets across
+   the VPN.  This is the most general method; it maintains full Layer 2
+   transparency and preserves all OAM information.  The other method
+   applies only to the link liveness aspect of OAM; it consists of
+   transmitting the status of each attachment circuit across the control
+   plane using the circuit status vector (Section 3.1).  This method is
+   the only one applicable to Layer 2 Interworking VPNs (Section 4),
+   since OAM packets are not IP frames and thus cannot be transmitted
+   across such Layer 2 VPNs.
+
+3.  PE Information Exchange
+
+   When a PE is configured with all the required information for a CE,
+   it advertises to other PEs the fact that it is participating in a VPN
+   via BGP messages, as per [RFC4761], Section 3.  BGP was chosen as the
+   means for exchanging L2VPN information for two reasons: it offers
+   mechanisms for both auto-discovery and signaling, and it allows for
+   operational convergence, as explained in Section 1.  A bonus for
+   using BGP is a robust inter-AS solution for L2VPNs.
+
+   There are two modifications to the formatting of messages.  The first
+   is that the set of Encaps Types carried in the L2-info extended
+   community has been expanded to include those from Table 1.  The value
+   of the Encaps Type field identifies the Layer 2 encapsulation, e.g.,
+   ATM, Frame Relay, etc.
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 17]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   +-----------+-------------------------------------------+-----------+
+   | Encaps    | Description                               | Reference |
+   | Type      |                                           |           |
+   +-----------+-------------------------------------------+-----------+
+   | 0         | Reserved                                  | -         |
+   |           |                                           |           |
+   | 1         | Frame Relay                               | RFC 4446  |
+   |           |                                           |           |
+   | 2         | ATM AAL5 SDU VCC transport                | RFC 4446  |
+   |           |                                           |           |
+   | 3         | ATM transparent cell transport            | RFC 4816  |
+   |           |                                           |           |
+   | 4         | Ethernet (VLAN) Tagged Mode               | RFC 4448  |
+   |           |                                           |           |
+   | 5         | Ethernet Raw Mode                         | RFC 4448  |
+   |           |                                           |           |
+   | 6         | Cisco HDLC                                | RFC 4618  |
+   |           |                                           |           |
+   | 7         | PPP                                       | RFC 4618  |
+   |           |                                           |           |
+   | 8         | SONET/SDH Circuit Emulation Service       | RFC 4842  |
+   |           |                                           |           |
+   | 9         | ATM n-to-one VCC cell transport           | RFC 4717  |
+   |           |                                           |           |
+   | 10        | ATM n-to-one VPC cell transport           | RFC 4717  |
+   |           |                                           |           |
+   | 11        | IP Layer 2 Transport                      | RFC 3032  |
+   |           |                                           |           |
+   | 15        | Frame Relay Port mode                     | RFC 4619  |
+   |           |                                           |           |
+   | 17        | Structure-agnostic E1 over packet         | RFC 4553  |
+   |           |                                           |           |
+   | 18        | Structure-agnostic T1 (DS1) over packet   | RFC 4553  |
+   |           |                                           |           |
+   | 19        | VPLS                                      | RFC 4761  |
+   |           |                                           |           |
+   | 20        | Structure-agnostic T3 (DS3) over packet   | RFC 4553  |
+   |           |                                           |           |
+   | 21        | Nx64kbit/s Basic Service using            | RFC 5086  |
+   |           | Structure-aware                           |           |
+   |           |                                           |           |
+   | 25        | Frame Relay DLCI                          | RFC 4619  |
+   |           |                                           |           |
+   | 40        | Structure-agnostic E3 over packet         | RFC 4553  |
+   |           |                                           |           |
+   | 41 (1)    | Octet-aligned payload for                 | RFC 4553  |
+   |           | Structure-agnostic DS1 circuits           |           |
+   |           |                                           |           |
+
+
+
+Kompella, et al.              Informational                    [Page 18]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   | 42 (2)    | E1 Nx64kbit/s with CAS using              | RFC 5086  |
+   |           | Structure-aware                           |           |
+   |           |                                           |           |
+   | 43        | DS1 (ESF) Nx64kbit/s with CAS using       | RFC 5086  |
+   |           | Structure-aware                           |           |
+   |           |                                           |           |
+   | 44        | DS1 (SF) Nx64kbit/s with CAS using        | RFC 5086  |
+   |           | Structure-aware                           |           |
+   +-----------+-------------------------------------------+-----------+
+
+                           Table 1: Encaps Types
+
+   Note (1): Allocation of a separate code point for Encaps Type
+   eliminates the need for Time Division Multiplexer (TDM) payload size.
+
+   Note (2): Having separate code points for Encaps Types 42-44 allows
+   specifying the trunk framing (i.e., E1, T1 ESF, or T1 SF) with
+   Channel Associated Signaling (CAS).
+
+   The second is the introduction of TLVs (Type-Length-Value triplets)
+   in the VPLS NLRI (Network Layer Reachability Information).  L2VPN
+   TLVs can be added to extend the information carried in the NLRI,
+   using the format shown in Figure 2.  In L2VPN TLVs, Type is 1 octet,
+   and Length is 2 octets and represents the size of the Value field in
+   bits.  L2VPN TLVs, if present, occur as the last element of a VPLS
+   NLRI.  The length of the NLRI includes the total length of the TLVs,
+   including their headers.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |            Length             |     Value     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Value (continued, if needed) ...                              |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                         Figure 2: Format of TLVs
+
+3.1.  Circuit Status Vector
+
+   This sub-TLV carries the status of an L2VPN PVC between a pair of
+   PEs.  Note that an L2VPN PVC is bidirectional, composed of two
+   simplex connections going in opposite directions.  A simplex
+   connection consists of three segments: 1) the local access circuit
+   between the source CE and the ingress PE, 2) the tunnel Label
+   Switched Path (LSP) between the ingress and egress PEs, and 3) the
+   access circuit between the egress PE and the destination CE.
+
+
+
+
+Kompella, et al.              Informational                    [Page 19]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   To monitor the status of a PVC, a PE needs to monitor the status of
+   both simplex connections.  Since it knows the status of its access
+   circuit and the status of the tunnel towards the remote PE, it can
+   inform the remote PE of these two.  Similarly, the remote PE can
+   inform the status of its access circuit to its local CE and the
+   status of the tunnel to the first PE.  Combining the local and the
+   remote information, a PE can determine the status of a PVC.
+
+   The basic unit of advertisement in L2VPN for a given CE is a label
+   block.  Each label within a label block corresponds to a PVC on the
+   CE.  The local status information for all PVCs corresponding to a
+   label block is advertised along with the NLRI for the label block
+   using the status vector TLV.  The Type field of this TLV is 1.  The
+   Length field of the TLV specifies the length of the value field in
+   bits.  The Value field of this TLV is a bit-vector, each bit of which
+   indicates the status of the PVC associated with the corresponding
+   label in the label block.  Bit value 0 corresponds to the PVC
+   associated with the first label in the label block and indicates that
+   the local circuit and the tunnel LSP to the remote PE is up, while a
+   value of 1 indicates that either or both of them are down.  The Value
+   field is padded to the nearest octet boundary.
+
+   A PE can determine the status of a PVC from one of its CEs to a
+   remote CE as follows.  Say PE A has CE n in VPN X, and PE A gets an
+   advertisement from PE B for remote CE m also in VPN X; this
+   advertisement includes a label block and a circuit status vector.  To
+   determine which label to use for CE m, PE A must determine the index
+   corresponding to CE m in the label block that PE B advertised.  The
+   status of the PVC between CE n and CE m can be obtained by looking at
+   the bit in the circuit status vector corresponding to this index.
+
+                   +----------+-----------------------+
+                   | TLV Type |      Description      |
+                   +----------+-----------------------+
+                   |     1    | Circuit Status Vector |
+                   +----------+-----------------------+
+
+                            Table 2: TLV Types
+
+3.2.  Generalizing the VPN Topology
+
+   In the above, we assumed for simplicity that the VPN was a full mesh.
+   To allow for more general VPN topologies, a mechanism based on
+   filtering of BGP extended communities can be used.
+
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 20]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+4.  Layer 2 Interworking
+
+   As defined so far in this document, all CE-PE connections for a given
+   Layer 2 VPN must use the same Layer 2 encapsulation, e.g., they must
+   all be Frame Relay.  This is often a burdensome restriction.  One
+   answer is to use an existing Layer 2 interworking mechanism, for
+   example, Frame Relay-ATM interworking.
+
+   In this document, we take a different approach: we postulate that the
+   network Layer is IP and base Layer 2 interworking on that.  Thus, one
+   can choose between pure Layer 2 VPNs, with a stringent Layer 2
+   restriction but with Layer 3 independence, or Layer 2 interworking
+   VPNs, where there is no restriction on Layer 2, but Layer 3 must be
+   IP.  Of course, a PE may choose to implement Frame Relay-ATM
+   interworking.  For example, an ATM Layer 2 VPN could have some CEs
+   connect via Frame Relay links, if their PE could translate Frame
+   Relay to ATM transparently to the rest of the VPN.  This would be
+   private to the CE-PE connection, and such a course is outside the
+   scope of this document.
+
+   For Layer 2 interworking as defined here, when an IP packet arrives
+   at a PE, its Layer 2 address is noted, then all Layer 2 overhead is
+   stripped, leaving just the IP packet.  Next, a VPN label is added,
+   and the packet is encapsulated in the PE-PE tunnel (as required by
+   the tunnel technology).  Finally, the packet is forwarded.  Note that
+   the forwarding decision is made on the basis of the Layer 2
+   information, not the IP header.  At the egress, the VPN label
+   determines to which CE the packet must be sent and over which virtual
+   circuit; from this, the egress PE can also determine the Layer 2
+   encapsulation to place on the packet once the VPN label is stripped.
+
+   An added benefit of restricting interworking to IP only as the Layer
+   3 technology is that the provider's network can provide IP Diffserv
+   or any other IP-based QoS mechanism to the L2VPN customer.  The
+   ingress PE can set up IP/TCP/UDP-based classifiers to do Diffserv
+   marking and other functions like policing and shaping on the L2
+   circuits of the VPN customer.  Note the division of labor: the CE
+   determines the destination CE and encodes that in the Layer 2
+   address.  The ingress PE thus determines the egress PE and VPN label
+   based on the Layer 2 address supplied by the CE, but the ingress PE
+   can choose the tunnel to reach the egress PE (in the case that there
+   are different tunnels for each CoS/Diffserv code point) or the CoS
+   bits to place in the tunnel (in the case where a single tunnel
+   carries multiple CoS/Diffserv code points) based on its own
+   classification of the packet.
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 21]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+5.  Packet Transport
+
+   When a packet arrives at a PE from a CE in a Layer 2 VPN, the Layer 2
+   address of the packet identifies to which remote attachment circuit
+   (and thus remote CE) the packet is destined.  The procedure outlined
+   above installs a route that maps the Layer 2 address to a tunnel
+   (which identifies the PE to which the destination CE is attached) and
+   a VPN label (which identifies the destination AC).  If the egress PE
+   is the same as the ingress PE, no tunnel or VPN label is needed.
+
+   The packet may then be modified (depending on the Layer 2
+   encapsulation).  In case of IP-only Layer 2 interworking, the Layer 2
+   header is completely stripped off up to the IP header.  Then, a VPN
+   label and tunnel encapsulation are added as specified by the route
+   described above, and the packet is sent to the egress PE.
+
+   If the egress PE is the same as the ingress, the packet "arrives"
+   with no labels.  Otherwise, the packet arrives with the VPN label,
+   which is used to determine which CE is the destination CE.  The
+   packet is restored to a fully formed Layer 2 packet and then sent to
+   the CE.
+
+5.1.  Layer 2 MTU
+
+   This document requires that the Layer 2 MTU configured on all the
+   access circuits connecting CEs to PEs in an L2VPN be the same.  This
+   can be ensured by passing the configured Layer 2 MTU in the Layer2-
+   info extended community when advertising L2VPN label blocks.  On
+   receiving an L2VPN label block from remote PEs in a VPN, the MTU
+   value carried in the Layer2-info extended community should be
+   compared against the configured value for the VPN.  If they don't
+   match, then the label block should be ignored.
+
+   The MTU on the Layer 2 access links MUST be chosen such that the size
+   of the L2 frames plus the L2VPN header does not exceed the MTU of the
+   SP network.  Layer 2 frames that exceed the MTU after encapsulation
+   MUST be dropped.  For the case of IP-only Layer 2 interworking, the
+   IP MTU on the Layer 2 access link must be chosen such that the size
+   of the IP packet and the L2VPN header does not exceed the MTU of the
+   SP network.
+
+5.2.  Layer 2 Frame Format
+
+   The modification to the Layer 2 frame depends on the Layer 2 type.
+   This document requires that the encapsulation methods used in
+   transporting Layer 2 frames over tunnels be the same as described in
+   [RFC4448], [RFC4618], [RFC4619], and [RFC4717], except in the case of
+   IP-only Layer 2 Interworking, which is described next.
+
+
+
+Kompella, et al.              Informational                    [Page 22]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+5.3.  IP-Only Layer 2 Interworking
+
+         +-----------------------------------+
+         | PSN Transport |  VPN  |    IP     |     VPN label is the
+         |     Header    | Label |  Packet   |     demultiplexing field
+         +-----------------------------------+
+
+          Figure 3: Format of IP-Only Layer 2 Interworking Packet
+
+   At the ingress PE, an L2 frame's L2 header is completely stripped off
+   and is carried over as an IP packet within the SP network (Figure 3).
+   The forwarding decision is still based on the L2 address of the
+   incoming L2 frame.  At the egress PE, the IP packet is encapsulated
+   back in an L2 frame and transported over to the destination CE.  The
+   forwarding decision at the egress PE is based on the VPN label as
+   before.  The L2 technology between egress PE and CE is independent of
+   the L2 technology between ingress PE and CE.
+
+6.  Security Considerations
+
+   RFC 4761 [RFC4761], on which this document is based, has a detailed
+   discussion of security considerations.  As in RFC 4761, the focus
+   here is the privacy of customer VPN data (as opposed to
+   confidentiality, integrity, or authentication of said data); to
+   achieve the latter, one can use the methods suggested in RFC 4761.
+   The techniques described in RFC 4761 for securing the control plane
+   and protecting the forwarding path apply equally to L2VPNs, as do the
+   remarks regarding multi-AS operation.  The mitigation strategies and
+   the analogies with RFC 4364 [RFC4364] also apply here.
+
+   RFC 4761 perhaps should have discussed Denial-of-Service attacks
+   based on the fact that VPLS PEs have to learn Media Access Control
+   (MAC) addresses and replicate packets (for flooding and multicast).
+   However, those considerations don't apply here, as neither of those
+   actions are required of PEs implementing the procedures in this
+   document.
+
+7.  IANA Considerations
+
+   IANA has created two new registries: the first is for the one-octet
+   Encaps Type field of the L2-info extended community.  The name of the
+   registry is "BGP Layer 2 Encapsulation Types"; the values already
+   allocated are in Table 1 of Section 3.  The allocation policy for new
+   entries up to and including value 127 is "Expert Review" [RFC5226].
+   The allocation policy for values 128 through 251 is "First Come First
+   Served".  The values from 252 through 255 are for "Experimental Use".
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 23]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   The second registry is for the one-octet Type field of the TLVs of
+   the VPLS NLRI.  The name of the registry is "BGP L2 TLV Types"; the
+   sole allocated value is in Table 2 of Section 3.  The allocation
+   policy for new entries up to and including value 127 is "Expert
+   Review".  The allocation policy for values 128 through 251 is "First
+   Come First Served".  The values from 252 through 255 are for
+   "Experimental Use".
+
+8.  Acknowledgments
+
+   The authors would like to thank Chaitanya Kodeboyina, Dennis
+   Ferguson, Der-Hwa Gan, Dave Katz, Nischal Sheth, John Stewart, and
+   Paul Traina for the enlightening discussions that helped shape the
+   ideas presented here.  The authors also thank Ross Callon for his
+   valuable comments.
+
+   The idea of using extended communities for more general connectivity
+   of a Layer 2 VPN was a contribution by Yakov Rekhter, who also gave
+   many useful comments on the text.  Many thanks to him.
+
+9.  Contributors
+
+   The following individuals contributed to this document.
+
+   Manoj Leelanivas, Juniper Networks
+   Quaizar Vohra, Juniper Networks
+   Javier Achirica, Consultant
+   Ronald Bonica, Juniper Networks
+   Dave Cooper, Global Crossing
+   Chris Liljenstolpe, Telstra
+   Eduard Metz, KPN Dutch Telecom
+   Hamid Ould-Brahim, Nortel
+   Chandramouli Sargor
+   Himanshu Shah, Ciena
+   Vijay Srinivasan
+   Zhaohui Zhang, Juniper Networks
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
+              Communities Attribute", RFC 4360, February 2006.
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 24]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, February 2006.
+
+   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+              Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+   [RFC4448]  Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
+              "Encapsulation Methods for Transport of Ethernet over MPLS
+              Networks", RFC 4448, April 2006.
+
+   [RFC4618]  Martini, L., Rosen, E., Heron, G., and A. Malis,
+              "Encapsulation Methods for Transport of PPP/High-Level
+              Data Link Control (HDLC) over MPLS Networks", RFC 4618,
+              September 2006.
+
+   [RFC4619]  Martini, L., Kawa, C., and A. Malis, "Encapsulation
+              Methods for Transport of Frame Relay over Multiprotocol
+              Label Switching (MPLS) Networks", RFC 4619,
+              September 2006.
+
+   [RFC4717]  Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N.,
+              Brayley, J., and G. Koleyni, "Encapsulation Methods for
+              Transport of Asynchronous Transfer Mode (ATM) over MPLS
+              Networks", RFC 4717, December 2006.
+
+   [RFC4761]  Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
+              (VPLS) Using BGP for Auto-Discovery and Signaling",
+              RFC 4761, January 2007.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+10.2.  Informative References
+
+   [Kosiur]   Kosiur, D., "Building and Managing Virtual Private
+              Networks", Wiley Computer Publishing, 1998.
+
+   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
+              Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
+              Heron, "Pseudowire Setup and Maintenance Using the Label
+              Distribution Protocol (LDP)", RFC 4447, April 2006.
+
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 25]
+
+RFC 6624       BGP Auto-Discovery and Signaling for L2VPN       May 2012
+
+
+   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
+              R., Patel, K., and J. Guichard, "Constrained Route
+              Distribution for Border Gateway Protocol/MultiProtocol
+              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
+              Private Networks (VPNs)", RFC 4684, November 2006.
+
+   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
+              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
+              RFC 4762, January 2007.
+
+   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
+              "Provisioning, Auto-Discovery, and Signaling in Layer 2
+              Virtual Private Networks (L2VPNs)", RFC 6074,
+              January 2011.
+
+Authors' Addresses
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA  94089
+   USA
+
+   EMail: kireeti@juniper.net
+
+
+   Bhupesh Kothari
+   Cisco Systems
+   3750 Cisco Way
+   San Jose, CA  95134
+   USA
+
+   EMail: bhupesh@cisco.com
+
+
+   Rao Cherukuri
+   Juniper Networks
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA  94089
+   USA
+
+   EMail: cherukuri@juniper.net
+
+
+
+
+
+
+
+
+
+Kompella, et al.              Informational                    [Page 26]
+