doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc4761.txt b/doc/rfc/rfc4761.txt
new file mode 100644
index 0000000..14a835a
--- /dev/null
+++ b/doc/rfc/rfc4761.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                   K. Kompella, Ed.
+Request for Comments: 4761                               Y. Rekhter, Ed.
+Category: Standards Track                               Juniper Networks
+                                                            January 2007
+
+
+                  Virtual Private LAN Service (VPLS)
+               Using BGP for Auto-Discovery and Signaling
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+IESG Note
+
+   The L2VPN Working Group produced two separate documents, RFC 4762 and
+   this document, that ultimately perform similar functions in different
+   manners.  Be aware that each method is commonly referred to as "VPLS"
+   even though they are distinct and incompatible with one another.
+
+Abstract
+
+   Virtual Private LAN Service (VPLS), also known as Transparent LAN
+   Service and Virtual Private Switched Network service, is a useful
+   Service Provider offering.  The service offers a Layer 2 Virtual
+   Private Network (VPN); however, in the case of VPLS, the customers in
+   the VPN are connected by a multipoint Ethernet LAN, in contrast to
+   the usual Layer 2 VPNs, which are point-to-point in nature.
+
+   This document describes the functions required to offer VPLS, a
+   mechanism for signaling a VPLS, and rules for forwarding VPLS frames
+   across a packet switched network.
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 1]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Scope of This Document .....................................3
+      1.2. Conventions Used in This Document ..........................4
+   2. Functional Model ................................................4
+      2.1. Terminology ................................................5
+      2.2. Assumptions ................................................5
+      2.3. Interactions ...............................................6
+   3. Control Plane ...................................................6
+      3.1. Auto-Discovery .............................................7
+           3.1.1. Functions ...........................................7
+           3.1.2. Protocol Specification ..............................7
+      3.2. Signaling ..................................................8
+           3.2.1. Label Blocks ........................................8
+           3.2.2. VPLS BGP NLRI .......................................9
+           3.2.3. PW Setup and Teardown ..............................10
+           3.2.4. Signaling PE Capabilities ..........................10
+      3.3. BGP VPLS Operation ........................................11
+      3.4. Multi-AS VPLS .............................................13
+           3.4.1. Method (a): VPLS-to-VPLS Connections at the ASBRs ..13
+           3.4.2. Method (b): EBGP Redistribution of VPLS
+                  Information between ASBRs ..........................14
+           3.4.3. Method (c): Multi-Hop EBGP Redistribution
+                  of VPLS Information ................................15
+           3.4.4. Allocation of VE IDs across Multiple ASes ..........16
+      3.5. Multi-homing and Path Selection ...........................16
+      3.6. Hierarchical BGP VPLS .....................................17
+   4. Data Plane .....................................................18
+      4.1. Encapsulation .............................................18
+      4.2. Forwarding ................................................18
+           4.2.1. MAC Address Learning ...............................18
+           4.2.2. Aging ..............................................19
+           4.2.3. Flooding ...........................................19
+           4.2.4. Broadcast and Multicast ............................20
+           4.2.5. "Split Horizon" Forwarding .........................20
+           4.2.6. Qualified and Unqualified Learning .................21
+           4.2.7. Class of Service ...................................21
+   5. Deployment Options .............................................21
+   6. Security Considerations ........................................22
+   7. IANA Considerations ............................................23
+   8. References .....................................................24
+      8.1. Normative References ......................................24
+      8.2. Informative References ....................................24
+   Appendix A.  Contributors .........................................26
+   Appendix B.  Acknowledgements .....................................26
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 2]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+1.  Introduction
+
+   Virtual Private LAN Service (VPLS), also known as Transparent LAN
+   Service and Virtual Private Switched Network service, is a useful
+   service offering.  A Virtual Private LAN appears in (almost) all
+   respects as an Ethernet LAN to customers of a Service Provider.
+   However, in a VPLS, the customers are not all connected to a single
+   LAN; the customers may be spread across a metro or wide area.  In
+   essence, a VPLS glues together several individual LANs across a
+   packet switched network to appear and function as a single LAN [9].
+   This is accomplished by incorporating MAC address learning, flooding,
+   and forwarding functions in the context of pseudowires that connect
+   these individual LANs across the packet switched network.
+
+   This document details the functions needed to offer VPLS, and then
+   goes on to describe a mechanism for the auto-discovery of the
+   endpoints of a VPLS as well as for signaling a VPLS.  It also
+   describes how VPLS frames are transported over tunnels across a
+   packet switched network.  The auto-discovery and signaling mechanism
+   uses BGP as the control plane protocol.  This document also briefly
+   discusses deployment options, in particular, the notion of decoupling
+   functions across devices.
+
+   Alternative approaches include: [14], which allows one to build a
+   Layer 2 VPN with Ethernet as the interconnect; and [13], which allows
+   one to set up an Ethernet connection across a packet switched
+   network.  Both of these, however, offer point-to-point Ethernet
+   services.  What distinguishes VPLS from the above two is that a VPLS
+   offers a multipoint service.  A mechanism for setting up pseudowires
+   for VPLS using the Label Distribution Protocol (LDP) is defined in
+   [10].
+
+1.1.  Scope of This Document
+
+   This document has four major parts: defining a VPLS functional model;
+   defining a control plane for setting up VPLS; defining the data plane
+   for VPLS (encapsulation and forwarding of data); and defining various
+   deployment options.
+
+   The functional model underlying VPLS is laid out in Section 2.  This
+   describes the service being offered, the network components that
+   interact to provide the service, and at a high level their
+   interactions.
+
+   The control plane described in this document uses Multiprotocol BGP
+   [4] to establish VPLS service, i.e., for the auto-discovery of VPLS
+   members and for the setup and teardown of the pseudowires that
+   constitute a given VPLS instance.  Section 3 focuses on this, and
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 3]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   also describes how a VPLS that spans Autonomous System boundaries is
+   set up, as well as how multi-homing is handled.  Using BGP as the
+   control plane for VPNs is not new (see [14], [6], and [11]): what is
+   described here is based on the mechanisms proposed in [6].
+
+   The forwarding plane and the actions that a participating Provider
+   Edge (PE) router offering the VPLS service must take is described in
+   Section 4.
+
+   In Section 5, the notion of 'decoupled' operation is defined, and the
+   interaction of decoupled and non-decoupled PEs is described.
+   Decoupling allows for more flexible deployment of VPLS.
+
+1.2.  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 RFC 2119 [1].
+
+2.  Functional Model
+
+   This will be described with reference to the following figure.
+
+                                                       -----
+                                                      /  A1 \
+        ----                                     ____CE1     |
+       /    \          --------       --------  /    |       |
+      |  A2 CE2-      /        \     /        PE1     \     /
+       \    /   \    /          \___/          | \     -----
+        ----     ---PE2                        |  \
+                    |                          |   \   -----
+                    | Service Provider Network |    \ /     \
+                    |                          |     CE5  A5 |
+                    |            ___           |   /  \     /
+             |----|  \          /   \         PE4_/    -----
+             |u-PE|--PE3       /     \       /
+             |----|    --------       -------
+      ----  /   |    ----
+     /    \/    \   /    \               CE = Customer Edge Device
+    |  A3 CE3    --CE4 A4 |              PE = Provider Edge Router
+     \    /         \    /               u-PE = Layer 2 Aggregation
+      ----           ----                A<n> = Customer site n
+
+                        Figure 1: Example of a VPLS
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 4]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+2.1.  Terminology
+
+   Terminology similar to that in [6] is used: a Service Provider (SP)
+   network with P (Provider-only) and PE (Provider Edge) routers, and
+   customers with CE (Customer Edge) devices.  Here, however, there is
+   an additional concept, that of a "u-PE", a Layer 2 PE device used for
+   Layer 2 aggregation.  The notion of u-PE is described further in
+   Section 5.  PE and u-PE devices are "VPLS-aware", which means that
+   they know that a VPLS service is being offered.  The term "VE" refers
+   to a VPLS edge device, which could be either a PE or a u-PE.
+
+   In contrast, the CE device (which may be owned and operated by either
+   the SP or the customer) is VPLS-unaware; as far as the CE is
+   concerned, it is connected to the other CEs in the VPLS via a Layer 2
+   switched network.  This means that there should be no changes to a CE
+   device, either to the hardware or the software, in order to offer
+   VPLS.
+
+   A CE device may be connected to a PE or a u-PE via Layer 2 switches
+   that are VPLS-unaware.  From a VPLS point of view, such Layer 2
+   switches are invisible, and hence will not be discussed further.
+   Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3
+   devices; this will be discussed further in a later section.
+
+   The term "demultiplexor" refers to an identifier in a data packet
+   that identifies the VPLS to which the packet belongs as well as the
+   ingress PE.  In this document, the demultiplexor is an MPLS label.
+
+   The term "VPLS" will refer to the service as well as a particular
+   instantiation of the service (i.e., an emulated LAN); it should be
+   clear from the context which usage is intended.
+
+2.2.  Assumptions
+
+   The Service Provider Network is a packet switched network.  The PEs
+   are assumed to be (logically) fully meshed with tunnels over which
+   packets that belong to a service (such as VPLS) are encapsulated and
+   forwarded.  These tunnels can be IP tunnels, such as Generic Routing
+   Encapsulation (GRE), or MPLS tunnels, established by Resource
+   Reservation Protocol - Traffic Engineering (RSVP-TE) or LDP.  These
+   tunnels are established independently of the services offered over
+   them; the signaling and establishment of these tunnels are not
+   discussed in this document.
+
+   "Flooding" and MAC address "learning" (see Section 4) are an integral
+   part of VPLS.  However, these activities are private to an SP device,
+   i.e., in the VPLS described below, no SP device requests another SP
+   device to flood packets or learn MAC addresses on its behalf.
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 5]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   All the PEs participating in a VPLS are assumed to be fully meshed in
+   the data plane, i.e., there is a bidirectional pseudowire between
+   every pair of PEs participating in that VPLS, and thus every
+   (ingress) PE can send a VPLS packet to the egress PE(s) directly,
+   without the need for an intermediate PE (see Section 4.2.5.)  This
+   requires that VPLS PEs are logically fully meshed in the control
+   plane so that a PE can send a message to another PE to set up the
+   necessary pseudowires.  See Section 3.6 for a discussion on
+   alternatives to achieve a logical full mesh in the control plane.
+
+2.3.  Interactions
+
+   VPLS is a "LAN Service" in that CE devices that belong to a given
+   VPLS instance V can interact through the SP network as if they were
+   connected by a LAN.  VPLS is "private" in that CE devices that belong
+   to different VPLSs cannot interact.  VPLS is "virtual" in that
+   multiple VPLSs can be offered over a common packet switched network.
+
+   PE devices interact to "discover" all the other PEs participating in
+   the same VPLS, and to exchange demultiplexors.  These interactions
+   are control-driven, not data-driven.
+
+   u-PEs interact with PEs to establish connections with remote PEs or
+   u-PEs in the same VPLS.  This interaction is control-driven.
+
+   PE devices can participate simultaneously in both VPLS and IP VPNs
+   [6].  These are independent services, and the information exchanged
+   for each type of service is kept separate as the Network Layer
+   Reachability Information (NLRI) used for this exchange has different
+   Address Family Identifiers (AFIs) and Subsequent Address Family
+   Identifiers (SAFIs).  Consequently, an implementation MUST maintain a
+   separate routing storage for each service.  However, multiple
+   services can use the same underlying tunnels; the VPLS or VPN label
+   is used to demultiplex the packets belonging to different services.
+
+3.  Control Plane
+
+   There are two primary functions of the VPLS control plane: auto-
+   discovery, and setup and teardown of the pseudowires that constitute
+   the VPLS, often called signaling.  Section 3.1 and Section 3.2
+   describe these functions.  Both of these functions are accomplished
+   with a single BGP Update advertisement; Section 3.3 describes how
+   this is done by detailing BGP protocol operation for VPLS.
+   Section 3.4 describes the setting up of pseudowires that span
+   Autonomous Systems.  Section 3.5 describes how multi-homing is
+   handled.
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 6]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+3.1.  Auto-Discovery
+
+   Discovery refers to the process of finding all the PEs that
+   participate in a given VPLS instance.  A PE either can be configured
+   with the identities of all the other PEs in a given VPLS or can use
+   some protocol to discover the other PEs.  The latter is called auto-
+   discovery.
+
+   The former approach is fairly configuration-intensive, especially
+   since it is required that the PEs participating in a given VPLS are
+   fully meshed (i.e., that every PE in a given VPLS establish
+   pseudowires to every other PE in that VPLS).  Furthermore, when the
+   topology of a VPLS changes (i.e., a PE is added to, or removed from,
+   the VPLS), the VPLS configuration on all PEs in that VPLS must be
+   changed.
+
+   In the auto-discovery approach, each PE "discovers" which other PEs
+   are part of a given VPLS by means of some protocol, in this case BGP.
+   This allows each PE's configuration to consist only of the identity
+   of the VPLS instance established on this PE, not the identity of
+   every other PE in that VPLS instance -- that is auto-discovered.
+   Moreover, when the topology of a VPLS changes, only the affected PE's
+   configuration changes; other PEs automatically find out about the
+   change and adapt.
+
+3.1.1.  Functions
+
+   A PE that participates in a given VPLS instance V must be able to
+   tell all other PEs in VPLS V that it is also a member of V.  A PE
+   must also have a means of declaring that it no longer participates in
+   a VPLS.  To do both of these, the PE must have a means of identifying
+   a VPLS and a means by which to communicate to all other PEs.
+
+   U-PE devices also need to know what constitutes a given VPLS;
+   however, they don't need the same level of detail.  The PE (or PEs)
+   to which a u-PE is connected gives the u-PE an abstraction of the
+   VPLS; this is described in Section 5.
+
+3.1.2.  Protocol Specification
+
+   The specific mechanism for auto-discovery described here is based on
+   [14] and [6]; it uses BGP extended communities [5] to identify
+   members of a VPLS, in particular, the Route Target community, whose
+   format is described in [5].  The semantics of the use of Route
+   Targets is described in [6]; their use in VPLS is identical.
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 7]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   As it has been assumed that VPLSs are fully meshed, a single Route
+   Target RT suffices for a given VPLS V, and in effect that RT is the
+   identifier for VPLS V.
+
+   A PE announces (typically via I-BGP) that it belongs to VPLS V by
+   annotating its NLRIs for V (see next subsection) with Route Target
+   RT, and acts on this by accepting NLRIs from other PEs that have
+   Route Target RT.  A PE announces that it no longer participates in V
+   by withdrawing all NLRIs that it had advertised with Route Target RT.
+
+3.2.  Signaling
+
+   Once discovery is done, each pair of PEs in a VPLS must be able to
+   establish (and tear down) pseudowires to each other, i.e., exchange
+   (and withdraw) demultiplexors.  This process is known as signaling.
+   Signaling is also used to transmit certain characteristics of the
+   pseudowires that a PE sets up for a given VPLS.
+
+   Recall that a demultiplexor is used to distinguish among several
+   different streams of traffic carried over a tunnel, each stream
+   possibly representing a different service.  In the case of VPLS, the
+   demultiplexor not only says to which specific VPLS a packet belongs,
+   but also identifies the ingress PE.  The former information is used
+   for forwarding the packet; the latter information is used for
+   learning MAC addresses.  The demultiplexor described here is an MPLS
+   label.  However, note that the PE-to-PE tunnels need not be MPLS
+   tunnels.
+
+   Using a distinct BGP Update message to send a demultiplexor to each
+   remote PE would require the originating PE to send N such messages
+   for N remote PEs.  The solution described in this document allows a
+   PE to send a single (common) Update message that contains
+   demultiplexors for all the remote PEs, instead of N individual
+   messages.  Doing this reduces the control plane load both on the
+   originating PE as well as on the BGP Route Reflectors that may be
+   involved in distributing this Update to other PEs.
+
+3.2.1.  Label Blocks
+
+   To accomplish this, we introduce the notion of "label blocks".  A
+   label block, defined by a label base LB and a VE block size VBS, is a
+   contiguous set of labels {LB, LB+1, ..., LB+VBS-1}.  Here's how label
+   blocks work.  All PEs within a given VPLS are assigned unique VE IDs
+   as part of their configuration.  A PE X wishing to send a VPLS update
+   sends the same label block information to all other PEs.  Each
+   receiving PE infers the label intended for PE X by adding its
+   (unique) VE ID to the label base.  In this manner, each receiving PE
+   gets a unique demultiplexor for PE X for that VPLS.
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 8]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   This simple notion is enhanced with the concept of a VE block offset
+   VBO.  A label block defined by <LB, VBO, VBS> is the set {LB+VBO,
+   LB+VBO+1, ..., LB+VBO+VBS-1}.  Thus, instead of a single large label
+   block to cover all VE IDs in a VPLS, one can have several label
+   blocks, each with a different label base.  This makes label block
+   management easier, and also allows PE X to cater gracefully to a PE
+   joining a VPLS with a VE ID that is not covered by the set of label
+   blocks that PE X has already advertised.
+
+   When a PE starts up, or is configured with a new VPLS instance, the
+   BGP process may wish to wait to receive several advertisements for
+   that VPLS instance from other PEs to improve the efficiency of label
+   block allocation.
+
+3.2.2.  VPLS BGP NLRI
+
+   The VPLS BGP NLRI described below, with a new AFI and SAFI (see [4])
+   is used to exchange VPLS membership and demultiplexors.
+
+   A VPLS BGP NLRI has the following information elements: a VE ID, a VE
+   Block Offset, a VE Block Size, and a label base.  The format of the
+   VPLS NLRI is given below.  The AFI is the L2VPN AFI (25), and the
+   SAFI is the VPLS SAFI (65).  The Length field is in octets.
+
+      +------------------------------------+
+      |  Length (2 octets)                 |
+      +------------------------------------+
+      |  Route Distinguisher  (8 octets)   |
+      +------------------------------------+
+      |  VE ID (2 octets)                  |
+      +------------------------------------+
+      |  VE Block Offset (2 octets)        |
+      +------------------------------------+
+      |  VE Block Size (2 octets)          |
+      +------------------------------------+
+      |  Label Base (3 octets)             |
+      +------------------------------------+
+
+                  Figure 2: BGP NLRI for VPLS Information
+
+   A PE participating in a VPLS must have at least one VE ID.  If the PE
+   is the VE, it typically has one VE ID.  If the PE is connected to
+   several u-PEs, it has a distinct VE ID for each u-PE.  It may
+   additionally have a VE ID for itself, if it itself acts as a VE for
+   that VPLS.  In what follows, we will call the PE announcing the VPLS
+   NLRI PE-a, and we will assume that PE-a owns VE ID V (either
+   belonging to PE-a itself or to a u-PE connected to PE-a).
+
+
+
+
+Kompella & Rekhter          Standards Track                     [Page 9]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   VE IDs are typically assigned by the network administrator.  Their
+   scope is local to a VPLS.  A given VE ID should belong to only one
+   PE, unless a CE is multi-homed (see Section 3.5).
+
+   A label block is a set of demultiplexor labels used to reach a given
+   VE ID.  A VPLS BGP NLRI with VE ID V, VE Block Offset VBO, VE Block
+   Size VBS, and label base LB communicates to its peers the following:
+
+       label block for V:  labels from LB to (LB + VBS - 1), and
+
+       remote VE set for V:  from VBO to (VBO + VBS - 1).
+
+   There is a one-to-one correspondence between the remote VE set and
+   the label block: VE ID (VBO + n) corresponds to label (LB + n).
+
+3.2.3.  PW Setup and Teardown
+
+   Suppose PE-a is part of VPLS foo and makes an announcement with VE ID
+   V, VE Block Offset VBO, VE Block Size VBS, and label base LB.  If
+   PE-b is also part of VPLS foo and has VE ID W, PE-b does the
+   following:
+
+   1.  checks if W is part of PE-a's 'remote VE set': if VBO <= W < VBO
+       + VBS, then W is part of PE-a's remote VE set.  If not, PE-b
+       ignores this message, and skips the rest of this procedure.
+
+   2.  sets up a PW to PE-a: the demultiplexor label to send traffic
+       from PE-b to PE-a is computed as (LB + W - VBO).
+
+   3.  checks if V is part of any 'remote VE set' that PE-b announced,
+       i.e., PE-b checks if V belongs to some remote VE set that PE-b
+       announced, say with VE Block Offset VBO', VE Block Size VBS', and
+       label base LB'.  If not, PE-b MUST make a new announcement as
+       described in Section 3.3.
+
+   4.  sets up a PW from PE-a: the demultiplexor label over which PE-b
+       should expect traffic from PE-a is computed as: (LB' + V - VBO').
+
+   If Y withdraws an NLRI for V that X was using, then X MUST tear down
+   its ends of the pseudowire between X and Y.
+
+3.2.4.  Signaling PE Capabilities
+
+   The following extended attribute, the "Layer2 Info Extended
+   Community", is used to signal control information about the
+   pseudowires to be setup for a given VPLS.  The extended community
+   value is to be allocated by IANA (currently used value is 0x800A).
+   This information includes the Encaps Type (type of encapsulation on
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 10]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   the pseudowires), Control Flags (control information regarding the
+   pseudowires), and the Maximum Transmission Unit (MTU) to be used on
+   the pseudowires.
+
+   The Encaps Type for VPLS is 19.
+
+      +------------------------------------+
+      | Extended community type (2 octets) |
+      +------------------------------------+
+      |  Encaps Type (1 octet)             |
+      +------------------------------------+
+      |  Control Flags (1 octet)           |
+      +------------------------------------+
+      |  Layer-2 MTU (2 octet)             |
+      +------------------------------------+
+      |  Reserved (2 octets)               |
+      +------------------------------------+
+
+                 Figure 3: Layer2 Info Extended Community
+
+
+       0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+
+      |   MBZ     |C|S|      (MBZ = MUST Be Zero)
+      +-+-+-+-+-+-+-+-+
+
+                    Figure 4: Control Flags Bit Vector
+
+   With reference to Figure 4, the following bits in the Control Flags
+   are defined; the remaining bits, designated MBZ, MUST be set to zero
+   when sending and MUST be ignored when receiving this community.
+
+        Name   Meaning
+
+           C   A Control word [7] MUST or MUST NOT be present when
+               sending VPLS packets to this PE, depending on whether C
+               is 1 or 0, respectively
+
+           S   Sequenced delivery of frames MUST or MUST NOT be used
+               when sending VPLS packets to this PE, depending on
+               whether S is 1 or 0, respectively
+
+3.3.  BGP VPLS Operation
+
+   To create a new VPLS, say VPLS foo, a network administrator must pick
+   an RT for VPLS foo, say RT-foo.  This will be used by all PEs that
+   serve VPLS foo.  To configure a given PE, say PE-a, to be part of
+   VPLS foo, the network administrator only has to choose a VE ID V for
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 11]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   PE-a.  (If PE-a is connected to u-PEs, PE-a may be configured with
+   more than one VE ID; in that case, the following is done for each VE
+   ID).  The PE may also be configured with a Route Distinguisher (RD);
+   if not, it generates a unique RD for VPLS foo.  Say the RD is
+   RD-foo-a.  PE-a then generates an initial label block and a remote VE
+   set for V, defined by VE Block Offset VBO, VE Block Size VBS, and
+   label base LB.  These may be empty.
+
+   PE-a then creates a VPLS BGP NLRI with RD RD-foo-a, VE ID V, VE Block
+   Offset VBO, VE Block Size VBS and label base LB.  To this, it
+   attaches a Layer2 Info Extended Community and an RT, RT-foo.  It sets
+   the BGP Next Hop for this NLRI as itself, and announces this NLRI to
+   its peers.  The Network Layer protocol associated with the Network
+   Address of the Next Hop for the combination <AFI=L2VPN AFI, SAFI=VPLS
+   SAFI> is IP; this association is required by [4], Section 5.  If the
+   value of the Length of the Next Hop field is 4, then the Next Hop
+   contains an IPv4 address.  If this value is 16, then the Next Hop
+   contains an IPv6 address.
+
+   If PE-a hears from another PE, say PE-b, a VPLS BGP announcement with
+   RT-foo and VE ID W, then PE-a knows that PE-b is a member of the same
+   VPLS (auto-discovery).  PE-a then has to set up its part of a VPLS
+   pseudowire between PE-a and PE-b, using the mechanisms in
+   Section 3.2.  Similarly, PE-b will have discovered that PE-a is in
+   the same VPLS, and PE-b must set up its part of the VPLS pseudowire.
+   Thus, signaling and pseudowire setup is also achieved with the same
+   Update message.
+
+   If W is not in any remote VE set that PE-a announced for VE ID V in
+   VPLS foo, PE-b will not be able to set up its part of the pseudowire
+   to PE-a.  To address this, PE-a can choose to withdraw the old
+   announcement(s) it made for VPLS foo, and announce a new Update with
+   a larger remote VE set and corresponding label block that covers all
+   VE IDs that are in VPLS foo.  This, however, may cause some service
+   disruption.  An alternative for PE-a is to create a new remote VE set
+   and corresponding label block, and announce them in a new Update,
+   without withdrawing previous announcements.
+
+   If PE-a's configuration is changed to remove VE ID V from VPLS foo,
+   then PE-a MUST withdraw all its announcements for VPLS foo that
+   contain VE ID V.  If all of PE-a's links to its CEs in VPLS foo go
+   down, then PE-a SHOULD either withdraw all its NLRIs for VPLS foo or
+   let other PEs in the VPLS foo know in some way that PE-a is no longer
+   connected to its CEs.
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 12]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+3.4.  Multi-AS VPLS
+
+   As in [14] and [6], the above auto-discovery and signaling functions
+   are typically announced via I-BGP.  This assumes that all the sites
+   in a VPLS are connected to PEs in a single Autonomous System (AS).
+
+   However, sites in a VPLS may connect to PEs in different ASes.  This
+   leads to two issues: 1) there would not be an I-BGP connection
+   between those PEs, so some means of signaling across ASes is needed;
+   and 2) there may not be PE-to-PE tunnels between the ASes.
+
+   A similar problem is solved in [6], Section 10.  Three methods are
+   suggested to address issue (1); all these methods have analogs in
+   multi-AS VPLS.
+
+   Here is a diagram for reference:
+
+     __________       ____________       ____________       __________
+    /          \     /            \     /            \     /          \
+                \___/        AS 1  \   /  AS 2        \___/
+                                    \ /
+      +-----+           +-------+    |    +-------+           +-----+
+      | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+      +-----+           +-------+    |    +-------+           +-----+
+                 ___                / \                ___
+                /   \              /   \              /   \
+    \__________/     \____________/     \____________/     \__________/
+
+                          Figure 5: Inter-AS VPLS
+
+   As in the above reference, three methods for signaling inter-provider
+   VPLS are given; these are presented in order of increasing
+   scalability.  Method (a) is the easiest to understand conceptually,
+   and the easiest to deploy; however, it requires an Ethernet
+   interconnect between the ASes, and both VPLS control and data plane
+   state on the AS border routers (ASBRs).  Method (b) requires VPLS
+   control plane state on the ASBRs and MPLS on the AS-AS interconnect
+   (which need not be Ethernet).  Method (c) requires MPLS on the AS-AS
+   interconnect, but no VPLS state of any kind on the ASBRs.
+
+3.4.1.  Method (a): VPLS-to-VPLS Connections at the ASBRs
+
+   In this method, an AS Border Router (ASBR1) acts as a PE for all
+   VPLSs that span AS1 and an AS to which ASBR1 is connected, such as
+   AS2 here.  The ASBR on the neighboring AS (ASBR2) is viewed by ASBR1
+   as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as
+   a PE for this VPLS from AS2's point of view, and views ASBR1 as a CE.
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 13]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   This method does not require MPLS on the ASBR1-ASBR2 link, but does
+   require that this link carry Ethernet traffic and that there be a
+   separate VLAN sub-interface for each VPLS traversing this link.  It
+   further requires that ASBR1 does the PE operations (discovery,
+   signaling, MAC address learning, flooding, encapsulation, etc.) for
+   all VPLSs that traverse ASBR1.  This imposes a significant burden on
+   ASBR1, both on the control plane and the data plane, which limits the
+   number of multi-AS VPLSs.
+
+   Note that in general, there will be multiple connections between a
+   pair of ASes, for redundancy.  In this case, the Spanning Tree
+   Protocol (STP) [15], or some other means of loop detection and
+   prevention, must be run on each VPLS that spans these ASes, so that a
+   loop-free topology can be constructed in each VPLS.  This imposes a
+   further burden on the ASBRs and PEs participating in those VPLSs, as
+   these devices would need to run a loop detection algorithm for each
+   such VPLS.  How this may be achieved is outside the scope of this
+   document.
+
+3.4.2.  Method (b): EBGP Redistribution of VPLS Information between
+        ASBRs
+
+   This method requires I-BGP peerings between the PEs in AS1 and ASBR1
+   in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1
+   and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in
+   AS2.  In the above example, PE1 sends a VPLS NLRI to ASBR1 with a
+   label block and itself as the BGP nexthop; ASBR1 sends the NLRI to
+   ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends
+   the NLRI to PE2 with new labels and itself as the nexthop.
+   Correspondingly, there are three tunnels: T1 from PE1 to ASBR1, T2
+   from ASBR1 to ASBR2, and T3 from ASBR2 to PE2.  Within each tunnel,
+   the VPLS label to be used is determined by the receiving device;
+   e.g., the VPLS label within T1 is a label from the label block that
+   ASBR1 sent to PE1.  The ASBRs are responsible for receiving VPLS
+   packets encapsulated in a tunnel and performing the appropriate label
+   swap operations described next so that the next receiving device can
+   correctly identify and forward the packet.
+
+   The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2
+   sends to PE2) is identical to the VPLS NLRI that PE1 sends to ASBR1,
+   except for the label block.  To be precise, the Length, the Route
+   Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size
+   MUST be the same; the Label Base may be different.  Furthermore,
+   ASBR1 must also update its forwarding path as follows: if the Label
+   Base sent by PE1 is L1, the Label-block Size is N, the Label Base
+   sent by ASBR1 is L2, and the tunnel label from ASBR1 to PE1 is T,
+   then ASBR1 must install the following in the forwarding path:
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 14]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+      swap L2 with L1 and push T,
+
+      swap L2+1 with L1+1 and push T, ...
+
+      swap L2+N-1 with L1+N-1 and push T.
+
+   ASBR2 must act similarly, except that it may not need a tunnel label
+   if it is directly connected with ASBR1.
+
+   When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to
+   get the right VPLS label from ASBR2's label block for PE1, and uses a
+   tunnel label to reach ASBR2.  ASBR2 swaps the VPLS label with the
+   label from ASBR1; ASBR1 then swaps the VPLS label with the label from
+   PE1, and pushes a tunnel label to reach PE1.
+
+   In this method, one needs MPLS on the ASBR1-ASBR2 interface, but
+   there is no requirement that the link layer be Ethernet.
+   Furthermore, the ASBRs take part in distributing VPLS information.
+   However, the data plane requirements of the ASBRs are much simpler
+   than in method (a), being limited to label operations.  Finally, the
+   construction of loop-free VPLS topologies is done by routing
+   decisions, viz. BGP path and nexthop selection, so there is no need
+   to run the Spanning Tree Protocol on a per-VPLS basis.  Thus, this
+   method is considerably more scalable than method (a).
+
+3.4.3.  Method (c): Multi-Hop EBGP Redistribution of VPLS Information
+        between ASes
+
+   In this method, there is a multi-hop E-BGP peering between the PEs
+   (or preferably, a Route Reflector) in AS1 and the PEs (or Route
+   Reflector) in AS2.  PE1 sends a VPLS NLRI with labels and nexthop
+   self to PE2; if this is via route reflectors, the BGP nexthop is not
+   changed.  This requires that there be a tunnel LSP from PE1 to PE2.
+   This tunnel LSP can be created exactly as in [6], Section 10 (c), for
+   example using E-BGP to exchange labeled IPv4 routes for the PE
+   loopbacks.
+
+   When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label
+   corresponding to its own VE ID onto the packet.  It then pushes the
+   tunnel label(s) to reach PE2.
+
+   This method requires no VPLS information (in either the control or
+   the data plane) on the ASBRs.  The ASBRs only need to set up PE-to-PE
+   tunnel LSPs in the control plane, and do label operations in the data
+   plane.  Again, as in the case of method (b), the construction of
+   loop-free VPLS topologies is done by routing decisions, i.e., BGP
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 15]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   path and nexthop selection, so there is no need to run the Spanning
+   Tree Protocol on a per-VPLS basis.  This option is likely to be the
+   most scalable of the three methods presented here.
+
+3.4.4.  Allocation of VE IDs across Multiple ASes
+
+   In order to ease the allocation of VE IDs for a VPLS that spans
+   multiple ASes, one can allocate ranges for each AS.  For example, AS1
+   uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc.  If
+   there are 10 sites attached to AS1 and 20 to AS2, the allocated VE
+   IDs could be 1-10 and 101 to 120.  This minimizes the number of VPLS
+   NLRIs that are exchanged while ensuring that VE IDs are kept unique.
+
+   In the above example, if AS1 needed more than 100 sites, then another
+   range can be allocated to AS1.  The only caveat is that there be no
+   overlap between VE ID ranges among ASes.  The exception to this rule
+   is multi-homing, which is dealt with below.
+
+3.5.  Multi-homing and Path Selection
+
+   It is often desired to multi-home a VPLS site, i.e., to connect it to
+   multiple PEs, perhaps even in different ASes.  In such a case, the
+   PEs connected to the same site can be configured either with the same
+   VE ID or with different VE IDs.  In the latter case, it is mandatory
+   to run STP on the CE device, and possibly on the PEs, to construct a
+   loop-free VPLS topology.  How this can be accomplished is outside the
+   scope of this document; however, the rest of this section will
+   describe in some detail the former case.  Note that multi-homing by
+   the SP and STP on the CEs can co-exist; thus, it is recommended that
+   the VPLS customer run STP if the CEs are able to.
+
+   In the case where the PEs connected to the same site are assigned the
+   same VE ID, a loop-free topology is constructed by routing
+   mechanisms, in particular, by BGP path selection.  When a BGP speaker
+   receives two equivalent NLRIs (see below for the definition), it
+   applies standard path selection criteria such as Local Preference and
+   AS Path Length to determine which NLRI to choose; it MUST pick only
+   one.  If the chosen NLRI is subsequently withdrawn, the BGP speaker
+   applies path selection to the remaining equivalent VPLS NLRIs to pick
+   another; if none remain, the forwarding information associated with
+   that NLRI is removed.
+
+   Two VPLS NLRIs are considered equivalent from a path selection point
+   of view if the Route Distinguisher, the VE ID, and the VE Block
+   Offset are the same.  If two PEs are assigned the same VE ID in a
+   given VPLS, they MUST use the same Route Distinguisher, and they
+   SHOULD announce the same VE Block Size for a given VE Offset.
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 16]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+3.6.  Hierarchical BGP VPLS
+
+   This section discusses how one can scale the VPLS control plane when
+   using BGP.  There are at least three aspects of scaling the control
+   plane:
+
+   1.  alleviating the full mesh connectivity requirement among VPLS BGP
+       speakers;
+
+   2.  limiting BGP VPLS message passing to just the interested speakers
+       rather than all BGP speakers; and
+
+   3.  simplifying the addition and deletion of BGP speakers, whether
+       for VPLS or other applications.
+
+   Fortunately, the use of BGP for Internet routing as well as for IP
+   VPNs has yielded several good solutions for all these problems.  The
+   basic technique is hierarchy, using BGP Route Reflectors (RRs) [8].
+   The idea is to designate a small set of Route Reflectors that are
+   themselves fully meshed, and then establish a BGP session between
+   each BGP speaker and one or more RRs.  In this way, there is no need
+   for direct full mesh connectivity among all the BGP speakers.  If the
+   particular scaling needs of a provider require a large number of RRs,
+   then this technique can be applied recursively: the full mesh
+   connectivity among the RRs can be brokered by yet another level of
+   RRs.  The use of RRs solves problems 1 and 3 above.
+
+   It is important to note that RRs, as used for VPLS and VPNs, are
+   purely a control plane technique.  The use of RRs introduces no data
+   plane state and no data plane forwarding requirements on the RRs, and
+   does not in any way change the forwarding path of VPLS traffic.  This
+   is in contrast to the technique of Hierarchical VPLS defined in [10].
+
+   Another consequence of this approach is that it is not required that
+   one set of RRs handles all BGP messages, or that a particular RR
+   handle all messages from a given PE.  One can define several sets of
+   RRs, for example, a set to handle VPLS, another to handle IP VPNs,
+   and another for Internet routing.  Another partitioning could be to
+   have some subset of VPLSs and IP VPNs handled by one set of RRs, and
+   another subset of VPLSs and IP VPNs handled by another set of RRs;
+   the use of Route Target Filtering (RTF), described in [12], can make
+   this simpler and more effective.
+
+   Finally, problem 2 (that of limiting BGP VPLS message passing to just
+   the interested BGP speakers) is addressed by the use of RTF.  This
+   technique is orthogonal to the use of RRs, but works well in
+   conjunction with RRs.  RTF is also very effective in inter-AS VPLS;
+   more details on how RTF works and its benefits are provided in [12].
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 17]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   It is worth mentioning an aspect of the control plane that is often a
+   source of confusion.  No MAC addresses are exchanged via BGP.  All
+   MAC address learning and aging is done in the data plane individually
+   by each PE.  The only task of BGP VPLS message exchange is auto-
+   discovery and label exchange.
+
+   Thus, BGP processing for VPLS occurs when
+
+   1.  a PE joins or leaves a VPLS; or
+
+   2.  a failure occurs in the network, bringing down a PE-PE tunnel or
+       a PE-CE link.
+
+   These events are relatively rare, and typically, each such event
+   causes one BGP update to be generated.  Coupled with BGP's messaging
+   efficiency when used for signaling VPLS, these observations lead to
+   the conclusion that BGP as a control plane for VPLS will scale quite
+   well in terms of both processing and memory requirements.
+
+4.  Data Plane
+
+   This section discusses two aspects of the data plane for PEs and
+   u-PEs implementing VPLS: encapsulation and forwarding.
+
+4.1.  Encapsulation
+
+   Ethernet frames received from CE devices are encapsulated for
+   transmission over the packet switched network connecting the PEs.
+   The encapsulation is as in [7].
+
+4.2.  Forwarding
+
+   VPLS packets are classified as belonging to a given service instance
+   and associated forwarding table based on the interface over which the
+   packet is received.  Packets are forwarded in the context of the
+   service instance based on the destination MAC address.  The former
+   mapping is determined by configuration.  The latter is the focus of
+   this section.
+
+4.2.1.  MAC Address Learning
+
+   As was mentioned earlier, the key distinguishing feature of VPLS is
+   that it is a multipoint service.  This means that the entire Service
+   Provider network should appear as a single logical learning bridge
+   for each VPLS that the SP network supports.  The logical ports for
+   the SP "bridge" are the customer ports as well as the pseudowires on
+   a VE.  Just as a learning bridge learns MAC addresses on its ports,
+   the SP bridge must learn MAC addresses at its VEs.
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 18]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   Learning consists of associating source MAC addresses of packets with
+   the (logical) ports on which they arrive; this association is the
+   Forwarding Information Base (FIB).  The FIB is used for forwarding
+   packets.  For example, suppose the bridge receives a packet with
+   source MAC address S on (logical) port P.  If subsequently, the
+   bridge receives a packet with destination MAC address S, it knows
+   that it should send the packet out on port P.
+
+   If a VE learns a source MAC address S on logical port P, then later
+   sees S on a different port P', then the VE MUST update its FIB to
+   reflect the new port P'.  A VE MAY implement a mechanism to damp
+   flapping of source ports for a given MAC address.
+
+4.2.2.  Aging
+
+   VPLS PEs SHOULD have an aging mechanism to remove a MAC address
+   associated with a logical port, much the same as learning bridges do.
+   This is required so that a MAC address can be relearned if it "moves"
+   from a logical port to another logical port, either because the
+   station to which that MAC address belongs really has moved or because
+   of a topology change in the LAN that causes this MAC address to
+   arrive on a new port.  In addition, aging reduces the size of a VPLS
+   MAC table to just the active MAC addresses, rather than all MAC
+   addresses in that VPLS.
+
+   The "age" of a source MAC address S on a logical port P is the time
+   since it was last seen as a source MAC on port P.  If the age exceeds
+   the aging time T, S MUST be flushed from the FIB.  This of course
+   means that every time S is seen as a source MAC address on port P,
+   S's age is reset.
+
+   An implementation SHOULD provide a configurable knob to set the aging
+   time T on a per-VPLS basis.  In addition, an implementation MAY
+   accelerate aging of all MAC addresses in a VPLS if it detects certain
+   situations, such as a Spanning Tree topology change in that VPLS.
+
+4.2.3.  Flooding
+
+   When a bridge receives a packet to a destination that is not in its
+   FIB, it floods the packet on all the other ports.  Similarly, a VE
+   will flood packets to an unknown destination to all other VEs in the
+   VPLS.
+
+   In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the
+   destination MAC address on the frame was not in PE2's FIB (for that
+   VPLS), then PE2 would be responsible for flooding that frame to every
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 19]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   other PE in the same VPLS.  On receiving that frame, PE1 would be
+   responsible for further flooding the frame to CE1 and CE5 (unless PE1
+   knew which CE "owned" that MAC address).
+
+   On the other hand, if PE3 received the frame, it could delegate
+   further flooding of the frame to its u-PE.  If PE3 was connected to
+   two u-PEs, it would announce that it has two u-PEs.  PE3 could either
+   announce that it is incapable of flooding, in which case it would
+   receive two frames, one for each u-PE, or it could announce that it
+   is capable of flooding, in which case it would receive one copy of
+   the frame, which it would then send to both u-PEs.
+
+4.2.4.  Broadcast and Multicast
+
+   There is a well-known broadcast MAC address.  An Ethernet frame whose
+   destination MAC address is the broadcast MAC address must be sent to
+   all stations in that VPLS.  This can be accomplished by the same
+   means that is used for flooding.
+
+   There is also an easily recognized set of "multicast" MAC addresses.
+   Ethernet frames with a destination multicast MAC address MAY be
+   broadcast to all stations; a VE MAY also use certain techniques to
+   restrict transmission of multicast frames to a smaller set of
+   receivers, those that have indicated interest in the corresponding
+   multicast group.  Discussion of this is outside the scope of this
+   document.
+
+4.2.5.  "Split Horizon" Forwarding
+
+   When a PE capable of flooding (say PEx) receives a broadcast Ethernet
+   frame, or one with an unknown destination MAC address, it must flood
+   the frame.  If the frame arrived from an attached CE, PEx must send a
+   copy of the frame to every other attached CE, as well as to all other
+   PEs participating in the VPLS.  If, on the other hand, the frame
+   arrived from another PE (say PEy), PEx must send a copy of the packet
+   only to attached CEs.  PEx MUST NOT send the frame to other PEs,
+   since PEy would have already done so.  This notion has been termed
+   "split horizon" forwarding and is a consequence of the PEs being
+   logically fully meshed for VPLS.
+
+   Split horizon forwarding rules apply to broadcast and multicast
+   packets, as well as packets to an unknown MAC address.
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 20]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+4.2.6.  Qualified and Unqualified Learning
+
+   The key for normal Ethernet MAC learning is usually just the
+   (6-octet) MAC address.  This is called "unqualified learning".
+   However, it is also possible that the key for learning includes the
+   VLAN tag when present; this is called "qualified learning".
+
+   In the case of VPLS, learning is done in the context of a VPLS
+   instance, which typically corresponds to a customer.  If the customer
+   uses VLAN tags, one can make the same distinctions of qualified and
+   unqualified learning.  If the key for learning within a VPLS is just
+   the MAC address, then this VPLS is operating under unqualified
+   learning.  If the key for learning is (customer VLAN tag + MAC
+   address), then this VPLS is operating under qualified learning.
+
+   Choosing between qualified and unqualified learning involves several
+   factors, the most important of which is whether one wants a single
+   global broadcast domain (unqualified) or a broadcast domain per VLAN
+   (qualified).  The latter makes flooding and broadcasting more
+   efficient, but requires larger MAC tables.  These considerations
+   apply equally to normal Ethernet forwarding and to VPLS.
+
+4.2.7.  Class of Service
+
+   In order to offer different Classes of Service within a VPLS, an
+   implementation MAY choose to map 802.1p bits in a customer Ethernet
+   frame with a VLAN tag to an appropriate setting of EXP bits in the
+   pseudowire and/or tunnel label, allowing for differential treatment
+   of VPLS frames in the packet switched network.
+
+   To be useful, an implementation SHOULD allow this mapping function to
+   be different for each VPLS, as each VPLS customer may have its own
+   view of the required behavior for a given setting of 802.1p bits.
+
+5.  Deployment Options
+
+   In deploying a network that supports VPLS, the SP must decide what
+   functions the VPLS-aware device closest to the customer (the VE)
+   supports.  The default case described in this document is that the VE
+   is a PE.  However, there are a number of reasons that the VE might be
+   a device that does all the Layer 2 functions (such as MAC address
+   learning and flooding), and a limited set of Layer 3 functions (such
+   as communicating to its PE), but, for example, doesn't do full-
+   fledged discovery and PE-to-PE signaling.  Such a device is called a
+   "u-PE".
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 21]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   As both of these cases have benefits, one would like to be able to
+   "mix and match" these scenarios.  The signaling mechanism presented
+   here allows this.  For example, in a given provider network, one PE
+   may be directly connected to CE devices, another may be connected to
+   u-PEs that are connected to CEs, and a third may be connected
+   directly to a customer over some interfaces and to u-PEs over others.
+   All these PEs perform discovery and signaling in the same manner.
+   How they do learning and forwarding depends on whether or not there
+   is a u-PE; however, this is a local matter, and is not signaled.
+   However, the details of the operation of a u-PE and its interactions
+   with PEs and other u-PEs are beyond the scope of this document.
+
+6.  Security Considerations
+
+   The focus in Virtual Private LAN Service is the privacy of data,
+   i.e., that data in a VPLS is only distributed to other nodes in that
+   VPLS and not to any external agent or other VPLS.  Note that VPLS
+   does not offer confidentiality, integrity, or authentication: VPLS
+   packets are sent in the clear in the packet switched network, and a
+   man-in-the-middle can eavesdrop, and may be able to inject packets
+   into the data stream.  If security is desired, the PE-to-PE tunnels
+   can be IPsec tunnels.  For more security, the end systems in the VPLS
+   sites can use appropriate means of encryption to secure their data
+   even before it enters the Service Provider network.
+
+   There are two aspects to achieving data privacy in a VPLS: securing
+   the control plane and protecting the forwarding path.  Compromise of
+   the control plane could result in a PE sending data belonging to some
+   VPLS to another VPLS, or blackholing VPLS data, or even sending it to
+   an eavesdropper; none of which are acceptable from a data privacy
+   point of view.  Since all control plane exchanges are via BGP,
+   techniques such as in [2] help authenticate BGP messages, making it
+   harder to spoof updates (which can be used to divert VPLS traffic to
+   the wrong VPLS) or withdraws (denial-of-service attacks).  In the
+   multi-AS methods (b) and (c) described in Section 3, this also means
+   protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or
+   the Route Reflectors.  One can also use the techniques described in
+   Section 10 (b) and (c) of [6], both for the control plane and the
+   data plane.  Note that [2] will not help in keeping VPLS labels
+   private -- knowing the labels, one can eavesdrop on VPLS traffic.
+   However, this requires access to the data path within a Service
+   Provider network.
+
+   There can also be misconfiguration leading to unintentional
+   connection of CEs in different VPLSs.  This can be caused, for
+   example, by associating the wrong Route Target with a VPLS instance.
+   This problem, shared by [6], is for further study.
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 22]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   Protecting the data plane requires ensuring that PE-to-PE tunnels are
+   well-behaved (this is outside the scope of this document), and that
+   VPLS labels are accepted only from valid interfaces.  For a PE, valid
+   interfaces comprise links from P routers.  For an ASBR, a valid
+   interface is a link from an ASBR in an AS that is part of a given
+   VPLS.  It is especially important in the case of multi-AS VPLSs that
+   one accept VPLS packets only from valid interfaces.
+
+   MPLS-in-IP and MPLS-in-GRE tunneling are specified in [3].  If it is
+   desired to use such tunnels to carry VPLS packets, then the security
+   considerations described in Section 8 of that document must be fully
+   understood.  Any implementation of VPLS that allows VPLS packets to
+   be tunneled as described in that document MUST contain an
+   implementation of IPsec that can be used as therein described.  If
+   the tunnel is not secured by IPsec, then the technique of IP address
+   filtering at the border routers, described in Section 8.2 of that
+   document, is the only means of ensuring that a packet that exits the
+   tunnel at a particular egress PE was actually placed in the tunnel by
+   the proper tunnel head node (i.e., that the packet does not have a
+   spoofed source address).  Since border routers frequently filter only
+   source addresses, packet filtering may not be effective unless the
+   egress PE can check the IP source address of any tunneled packet it
+   receives, and compare it to a list of IP addresses that are valid
+   tunnel head addresses.  Any implementation that allows MPLS-in-IP
+   and/or MPLS-in-GRE tunneling to be used without IPsec MUST allow the
+   egress PE to validate in this manner the IP source address of any
+   tunneled packet that it receives.
+
+7.  IANA Considerations
+
+   IANA allocated value (25) for AFI for L2VPN information.  This should
+   be the same as the AFI requested by [11].
+
+   IANA allocated an extended community value (0x800a) for the Layer2
+   Info Extended Community.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 23]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
+        Signature Option", RFC 2385, August 1998.
+
+   [3]  Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in
+        IP or Generic Routing Encapsulation (GRE)", RFC 4023,
+        March 2005.
+
+   [4]  Bates, T., Katz, D., and Y. Rekhter, "Multiprotocol Extensions
+        for BGP-4", RFC 4760, January 2007.
+
+   [5]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
+        Communities Attribute", RFC 4360, February 2006.
+
+   [6]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
+        (VPNs)", RFC 4364, February 2006.
+
+   [7]  Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
+        "Encapsulation Methods for Transport of Ethernet over MPLS
+        Networks", RFC 4448, April 2006.
+
+8.2.  Informative References
+
+   [8]   Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An
+         Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456,
+         April 2006.
+
+   [9]   Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
+         Private Networks (L2VPNs)", RFC 4664, September 2006.
+
+   [10]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN
+         Service (VPLS) Using Label Distribution Protocol (LDP)
+         Signaling", RFC 4762, January 2007.
+
+   [11]  Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism for
+         VR-based Layer-3 VPNs", Work in Progress, April 2006.
+
+   [12]  Marques, P., "Constrained VPN Route Distribution", Work in
+         Progress, June 2005.
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 24]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+   [13]  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.
+
+   [14]  Kompella, K., "Layer 2 VPNs Over Tunnels", Work in Progress,
+         January 2006.
+
+   [15]  Institute of Electrical and Electronics Engineers, "Information
+         technology - Telecommunications and information exchange
+         between systems - Local and metropolitan area networks - Common
+         specifications - Part 3: Media Access Control (MAC) Bridges:
+         Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-
+         1992 and 802.6k-1992.  It incorporates P802.11c, P802.1p and
+         P802.12e.  ISO/IEC 15802-3: 1998.", IEEE Standard 802.1D,
+         July 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 25]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+Appendix A.  Contributors
+
+   The following contributed to this document:
+
+           Javier Achirica, Telefonica
+           Loa Andersson, Acreo
+           Giles Heron, Tellabs
+           Sunil Khandekar, Alcatel-Lucent
+           Chaitanya Kodeboyina, Nuova Systems
+           Vach Kompella, Alcatel-Lucent
+           Marc Lasserre, Alcatel-Lucent
+           Pierre Lin
+           Pascal Menezes
+           Ashwin Moranganti, Appian
+           Hamid Ould-Brahim, Nortel
+           Seo Yeong-il, Korea Tel
+
+Appendix B.  Acknowledgements
+
+   Thanks to Joe Regan and Alfred Nothaft for their contributions.  Many
+   thanks too to Eric Ji, Chaitanya Kodeboyina, Mike Loomis, and Elwyn
+   Davies for their detailed reviews.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 26]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+Editors' Addresses
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA  94089
+   US
+
+   EMail: kireeti@juniper.net
+
+
+   Yakov Rekhter
+   Juniper Networks
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA  94089
+   US
+
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 27]
+
+RFC 4761       BGP Auto-Discovery and Signaling for VPLS    January 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Kompella & Rekhter          Standards Track                    [Page 28]
+