RFC 4761
Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
RFC 4761 ✨ Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
(Part 1 of 6 💖)
- RFC number: 4761
- Stream: Network Working Group
- Authors: K. Kompella, Ed. 🎀 and Y. Rekhter, Ed. 🎀, both at Juniper Networks
- Category: Standards Track 👑
- Date: January 2007 🌸
- Obsoletes / Updates: nothing is listed in the header 🙈
Status of This Memo 📜
okay so this section is the official "what kind of doc is this" part 🤓. It says this is an Internet standards track protocol spec for the Internet community, and it's basically asking everyone for discussion and suggestions for improvements 💬. If you want the current standardization state of the protocol, you go check the "Internet Official Protocol Standards" (STD 1) doc 📚. And the distribution of this memo is unlimited, so share it with everyone 🦋.
Copyright Notice ©️
Copyright (C) The IETF Trust (2007). That's the legal bit, bestie, don't @ me 💅.
IESG Note 🚨
⚠️ Heads up, this one's a plot twist: the L2VPN Working Group made two separate docs, RFC 4762 and this one, and they both kinda do similar stuff but in different ways 🙃. Each method gets called "VPLS" in everyday talk, even though they're distinct and incompatible with each other 💀. So if someone says "VPLS" in a meeting, always ask which VPLS they mean 🫶.
Abstract 🌈
Okay, so Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a super useful thing a Service Provider can offer 💖. It's a Layer 2 Virtual Private Network (VPN), but here's the twist: the customers in a VPLS are hooked up with a multipoint Ethernet LAN 🔥. Regular Layer 2 VPNs are point-to-point, so VPLS is giving main character energy 👑.
This doc covers three things: the functions you need to offer VPLS ✅, a mechanism for signaling a VPLS 📡, and the rules for forwarding VPLS frames across a packet switched network 🦋.
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 .....................................261. Introduction 🎀
Okay so VPLS (Virtual Private LAN Service, aka Transparent LAN Service or Virtual Private Switched Network service) is a really useful service 🌸. A Virtual Private LAN looks and acts like an Ethernet LAN to a Service Provider's customers, pretty much in every way 🫶. The catch is that the customers aren't all plugged into one LAN. They can be spread across a metro area or a wide area 🗺️. Basically a VPLS glues several separate LANs together over a packet switched network so they act like one single LAN [9] ✨. It works by using MAC address learning, flooding, and forwarding, but all of that happens in the context of pseudowires that connect those individual LANs over the packet switched network 🔥.
This doc lays out the functions you need to offer VPLS 📋. Then it describes a mechanism for auto-discovering the endpoints of a VPLS and for signaling a VPLS 📡. It also explains how VPLS frames get transported over tunnels across a packet switched network 🚇. The auto-discovery and signaling part uses BGP as the control plane protocol 💜. There's also a quick look at deployment options, especially the idea of splitting functions across devices 🧩.
Other approaches exist too. [14] lets you build a Layer 2 VPN with Ethernet as the interconnect, and [13] lets you set up an Ethernet connection across a packet switched network 🌈. But both of those are point-to-point Ethernet services 🙈. What makes VPLS different from those two is that it's a multipoint service 💅. Setting up pseudowires for VPLS with the Label Distribution Protocol (LDP) is covered in [10] ⭐.
1.1. Scope of This Document 🗺️
This doc has four big parts 🧁: a VPLS functional model, a control plane for setting up VPLS, a data plane (encapsulation and forwarding of data), and various deployment options 🎀.
The functional model is in Section 2 🔍. It describes the service being offered, the network pieces that work together to provide it, and how they interact at a high level 🧠.
The control plane uses Multiprotocol BGP [4] to set up VPLS service 🦋. That means auto-discovering VPLS members and setting up and tearing down the pseudowires that make up a given VPLS instance 🔧. Section 3 is all about that. It also covers how a VPLS spanning Autonomous System boundaries gets set up, and how multi-homing is handled 🌐. Using BGP as the control plane for VPNs isn't new, honestly (see [14], [6], and [11]) 🙃. What's described here is based on the mechanisms proposed in [6] 💖.
The forwarding plane, and what a participating Provider Edge (PE) router offering the VPLS service has to do, is in Section 4 📦.
Section 5 defines the idea of 'decoupled' operation and explains how decoupled and non-decoupled PEs interact 🧩. Decoupling makes VPLS way more flexible to deploy 🚀.
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 VPLS2.1. Terminology 🏷️
Okay, so this doc uses terminology similar to [6] 💅. You've got a Service Provider (SP) network with P (Provider-only) and PE (Provider Edge) routers, and customers with CE (Customer Edge) devices 🏢. There's one extra concept though: the "u-PE", which is a Layer 2 PE device used for Layer 2 aggregation 🪄. The u-PE gets more detail in Section 5 🔜. PE and u-PE devices are "VPLS-aware", which just means they know 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 💖.
The CE device is different 💁. It could be owned and run by the SP or by the customer, and it's VPLS-unaware 🙈. As far as the CE is concerned, it's connected to the other CEs in the VPLS through a Layer 2 switched network 🔗. So there should be no changes to a CE device, either to the hardware or the software, in order to offer VPLS ✨.
A CE can be connected to a PE or a u-PE through VPLS-unaware Layer 2 switches 🔌. From a VPLS point of view those switches are invisible, so we won't talk about them more 👻. Also, a u-PE might connect to a PE through a mix of Layer 2 and Layer 3 devices, and that gets covered later on 🔮.
The term "demultiplexor" means an identifier in a data packet that tells you which VPLS the packet belongs to, plus the ingress PE 🔑. In this doc, the demultiplexor is an MPLS label 🏷️.
The term "VPLS" can mean the service itself or one specific instance of the service (aka an emulated LAN) 🌈. You can usually tell from context which one is meant, bestie 🫶.
2.2. Assumptions 🫶
okay so first, the Service Provider Network is a packet switched network 📦. The PEs are assumed to be (logically) fully meshed with tunnels, and packets that belong to a service (like VPLS) get encapsulated and forwarded over those tunnels 🚇. The tunnels can be IP tunnels, like Generic Routing Encapsulation (GRE), or MPLS tunnels set up by Resource Reservation Protocol - Traffic Engineering (RSVP-TE) or LDP. The tunnels are established independently of the services running over them, and this document doesn't talk about how the tunnels get signaled and set up 🤷♀️
"Flooding" and MAC address "learning" (see Section 4) are an integral part of VPLS 💅 But these activities are private to an SP device. In the VPLS described below, no SP device asks another SP device to flood packets or learn MAC addresses on its behalf. Main character energy, no outsourcing 😤
All the PEs in a VPLS are assumed to be fully meshed in the data plane 🕸️ That means there's a bidirectional pseudowire between every pair of PEs in that VPLS, so every (ingress) PE can send a VPLS packet straight to the egress PE(s) without needing an intermediate PE (see Section 4.2.5.) ✨ This needs the VPLS PEs to be logically fully meshed in the control plane too, so a PE can message another PE to set up those 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" 🖥️ CE devices that belong to a given VPLS instance V can interact through the SP network as if they were connected by a LAN, which is so iconic. VPLS is "private" too, because CE devices in different VPLSs cannot interact at all 🙅♀️ And it's "virtual" because multiple VPLSs can be offered over one common packet switched network 🦋
PE devices interact to "discover" all the other PEs in the same VPLS, and to exchange demultiplexors 🔍 These interactions are control-driven, not data-driven 🎀
u-PEs interact with PEs to set up connections with remote PEs or u-PEs in the same VPLS. This interaction is also control-driven 🌸
PE devices can participate in both VPLS and IP VPNs at the same time [6] 👯♀️ These are independent services, so the information exchanged for each one is kept separate. The reason is that the Network Layer Reachability Information (NLRI) used for the exchange has different Address Family Identifiers (AFIs) and Subsequent Address Family Identifiers (SAFIs) 🗂️ Which means an implementation MUST maintain a separate routing storage for each service. This is a must, bestie 🚨 Still, multiple services can share the same underlying tunnels, and the VPLS or VPN label is what demultiplexes the packets belonging to the 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 make up the VPLS (often called signaling) 💖 Section 3.1 and Section 3.2 describe these. Both of them get done with a single BGP Update advertisement, and Section 3.3 explains how that works by going through the BGP protocol operation for VPLS 🤓 Section 3.4 covers setting up pseudowires that span Autonomous Systems 🌐 and Section 3.5 explains how multi-homing is handled 🏠
3.1. Auto-Discovery 🔎
Discovery is the process of finding all the PEs that participate in a given VPLS instance ✨ A PE can either be configured with the identities of all the other PEs in a given VPLS, or it can use some protocol to discover them. The second option is called auto-discovery.
The configure-it-yourself approach is pretty configuration-intensive, especially since the PEs in a given VPLS are required to be fully meshed (so every PE in that VPLS has to establish pseudowires to every other PE in it) 😩 And when the topology of a VPLS changes (a PE gets added to or removed from the VPLS), the VPLS configuration on every PE in that VPLS has to be changed too. Too much work, periodt 🙄
In the auto-discovery approach, each PE "discovers" which other PEs are part of a given VPLS using some protocol, which in this case is BGP 🪄 This means each PE's configuration only has to contain the identity of the VPLS instance on that PE, not the identity of every other PE in that instance, because that part gets auto-discovered 🥰 And when the topology of a VPLS changes, only the affected PE's configuration changes. The 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 the other PEs in VPLS V that it's also a member of V 📣 A PE also needs a way to declare that it no longer participates in a VPLS. To do both of these, the PE has to have a means of identifying a VPLS, plus a means of communicating with all the other PEs 💌
U-PE devices also need to know what makes up a given VPLS, but they don't need the same level of detail. The PE (or PEs) that a u-PE is connected to gives the u-PE an abstraction of the VPLS, which is described in Section 5 🎀
3.1.2. Protocol Specification 📜
The specific auto-discovery mechanism described here is based on [14] and [6]. It uses BGP extended communities [5] to identify members of a VPLS, specifically the Route Target community, whose format is described in [5] 💜 The semantics of Route Targets are described in [6], and their use in VPLS is identical 🫶
Since VPLSs are assumed to be fully meshed, a single Route Target RT is enough for a given VPLS V. 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. It then acts on that by accepting NLRIs from other PEs that carry Route Target RT 📬 And a PE announces that it no longer participates in V by withdrawing all the NLRIs it had advertised with Route Target RT. Bye bye, V 👋
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. In other words, they 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.
Quick recap: a demultiplexor tells apart several different streams of traffic carried over a tunnel, and each stream might represent a different service 🧩 For VPLS, the demultiplexor doesn't just say which specific VPLS a packet belongs to, it also identifies the ingress PE 👀 The first bit is used for forwarding the packet, and the second bit is used for learning MAC addresses. The demultiplexor described here is an MPLS label. But the PE-to-PE tunnels don't have to be MPLS tunnels, so no stress 💁♀️
Now, if you used a distinct BGP Update message to send a demultiplexor to each remote PE, the originating PE would have to send N such messages for N remote PEs. That's a lot of messages 😵 The solution in this document lets a PE send a single (common) Update message that contains demultiplexors for all the remote PEs, instead of N individual messages. This cuts down the control plane load on the originating PE, and also on the BGP Route Reflectors that might be involved in distributing that Update to other PEs 🙌
3.2.1. Label Blocks 🧱
So to pull this off, we introduce the notion of "label blocks" 🎉 A label block is defined by a label base LB and a VE block size VBS. It's a contiguous set of labels {LB, LB+1, ..., LB+VBS-1}. Here's how it works: all PEs in a given VPLS get assigned unique VE IDs as part of their configuration 🪪 A PE X that wants to send a VPLS update sends the same label block information to all the other PEs. Then each receiving PE figures out the label meant for PE X by adding its own (unique) VE ID to the label base 🧮 That's how each receiving PE ends up with a unique demultiplexor for PE X for that VPLS. Genius, honestly 🧠✨
This simple idea gets an upgrade 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}. So instead of one giant label block to cover all VE IDs in a VPLS, you can have several label blocks, each with a different label base 🍓 That makes label block management easier, and it also lets PE X handle a PE joining a VPLS with a VE ID that isn't covered by the set of label blocks PE X has already advertised, which is so graceful 🦢
When a PE starts up, or gets configured with a new VPLS instance, the BGP process may want to wait to receive several advertisements for that VPLS instance from other PEs. That way label block allocation is more efficient ⏳
3.2.2. VPLS BGP NLRI 🗒️
The VPLS BGP NLRI described below, which has a new AFI and SAFI (see [4]), is used to exchange VPLS membership and demultiplexors 🤩
A VPLS BGP NLRI has these information elements: a VE ID, a VE Block Offset, a VE Block Size, and a label base. The format of the VPLS NLRI is shown 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 InformationA 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 also have a VE ID for itself, if it acts as a VE for that VPLS 💁 From here on, we'll call the PE announcing the VPLS NLRI PE-a, and we'll assume that PE-a owns VE ID V (either belonging to PE-a itself or to a u-PE connected to PE-a) 🫡
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 tells 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's 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 ✨
okay so picture this, bestie 💖 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 in VPLS foo and has VE ID W, PE-b does the following 🦋
- checks if
Wis part of PE-a's 'remote VE set': ifVBO <= W < VBO + VBS, thenWis part of PE-a's remote VE set. If not, PE-b ignores this message and skips the rest of this procedure. 🙈 - 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). 🌸 - checks if
Vis part of any 'remote VE set' that PE-b announced. In other words, PE-b checks ifVbelongs to some remote VE set that PE-b announced, say with VE Block OffsetVBO', VE Block SizeVBS', and label baseLB'. If not, PE-b MUST make a new announcement as described in Section 3.3. 📣 - 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'). 🧚
And the teardown part is serious, so listen up ⚠️ 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. No ghost PWs allowed, periodt 💅
3.2.4. Signaling PE Capabilities ✨
So this one is the "Layer2 Info Extended Community" 🎀 It's an extended attribute used to signal control information about the pseudowires that get set up for a given VPLS. The extended community value is to be allocated by IANA (the value currently in use is 0x800A). The info includes the Encaps Type (what kind of encapsulation the pseudowires use), the Control Flags (control info about those pseudowires), and the Maximum Transmission Unit (MTU) to be used on them. 💜
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
Now look at Figure 4 with me 👀 The bits defined in the Control Flags are the ones below. The remaining bits, the MBZ ones, MUST be set to zero when sending and MUST be ignored when receiving this community. Rude to ignore them if you're receiving, but also don't mess with them when you send 🙃
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- C: a Control word [7] MUST or MUST NOT be present when sending VPLS packets to this PE. It depends 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. It depends on whether S is 1 or 0, respectively. 🌈
3.3. BGP VPLS Operation 💅
okay this is where the magic happens ✨ To create a new VPLS, say VPLS foo, a network administrator must pick an RT for VPLS foo, say RT-foo. Every PE that serves VPLS foo uses it. To configure a PE, say PE-a, to be part of VPLS foo, the admin only has to choose a VE ID V for 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. Multi-tasking queen 👑)
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. 🦋
Next, PE-a 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. That's 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 are also achieved with the same Update message. Efficiency, bestie 💜
If W is not in any remote VE set that PE-a announced for VE ID V in VPLS foo, PE-b won't be able to set up its part of the pseudowire to PE-a. 😭 To fix 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 in VPLS foo. Heads up though, this 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. Non-negotiable 🙅♀️ 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 the other PEs in VPLS foo know in some way that PE-a is no longer connected to its CEs. Be a good neighbor 🫶
3.4. Multi-AS VPLS 🌍
So 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 connect to PEs in a single Autonomous System (AS). Simple, right? 🌸
BUT sites in a VPLS may connect to PEs in different ASes, and that leads to two issues 😬 1) there wouldn't 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. Plot twist, bestie 🎭
A similar problem is solved in [6], Section 10. Three methods are suggested to address issue (1), and all of these methods have analogs in multi-AS VPLS. ✨
Here's 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. They're 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, plus 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. Ooh, that last one is giving clean boundaries 🧚
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 it's connected to, 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. Mirror mirror 🪞
This method does not require MPLS on the ASBR1-ASBR2 link. It 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. That's a LOT of work for one router, and it limits the number of multi-AS VPLSs. 😩
Note that in general there will be multiple connections between a pair of ASes, for redundancy. In that 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 adds even more work for the ASBRs and PEs in those VPLSs, since 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
okay so this method needs 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 example from before, 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. Then ASBR2 sends the NLRI to PE2 with new labels and itself as the nexthop 🎀.
That means there are three tunnels: T1 from PE1 to ASBR1, T2 from ASBR1 to ASBR2, and T3 from ASBR2 to PE2. Inside each tunnel, the VPLS label is picked by the receiving device. For example, the VPLS label inside T1 is a label from the label block that ASBR1 sent to PE1. The ASBRs are the ones receiving VPLS packets inside a tunnel and doing the label swap operations (we'll get to those next) so the next receiving device can identify and forward the packet correctly 🫶✨.
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, but the Label Base may be different. Furthermore, ASBR1 must also update its forwarding path. So 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:
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 it uses a tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the label from ASBR1. Then ASBR1 swaps the VPLS label with the label from PE1, and pushes a tunnel label to reach PE1 💖.
In this method, you need MPLS on the ASBR1-ASBR2 interface, but there is no requirement that the link layer be Ethernet 🌈. The ASBRs also take part in distributing VPLS information. However, their data plane requirements are much simpler than in method (a), since they're limited to label operations. Finally, loop-free VPLS topologies are built 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 goes via route reflectors, the BGP nexthop is not changed. This requires that there be a tunnel LSP from PE1 to PE2. The tunnel LSP can be created exactly as in [6], Section 10 (c), for example by 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. Then it 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, just like method (b), loop-free VPLS topologies are built by routing decisions, i.e., BGP 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
to make VE ID allocation easier for a VPLS that spans multiple ASes, you can allocate ranges for each AS 🎀. For example, AS1 uses VE IDs in the range 1 to 100, AS2 uses 101 to 200, and so on. 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 get exchanged while still making sure VE IDs stay unique ✨.
In the above example, if AS1 ever needed more than 100 sites, another range could be allocated to AS1. The only caveat is that there must 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's 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 gets accomplished is outside the scope of this document. The rest of this section, though, will describe the former case in some detail 🧚. Note that multi-homing by the SP and STP on the CEs can co-exist, so 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 one. 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 🦋.
3.6. Hierarchical BGP VPLS
this section is about how you scale the VPLS control plane when using BGP 🌸. There are at least three aspects of scaling the control plane:
- alleviating the full mesh connectivity requirement among VPLS BGP speakers;
- limiting BGP VPLS message passing to just the interested speakers rather than all BGP speakers; and
- simplifying the addition and deletion of BGP speakers, whether for VPLS or other applications.
Fortunately, BGP for Internet routing and for IP VPNs has already produced 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. This way, there is no need for direct full mesh connectivity among all the BGP speakers. If a provider's scaling needs call for a large number of RRs, 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 it 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 handles all messages from a given PE. You can define several sets of RRs, for example, one 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 (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 it works well in conjunction with RRs. RTF is also very effective in inter-AS VPLS, and more details on how RTF works and its benefits are provided in [12] 💅.
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:
- a PE joins or leaves a VPLS; or
- 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. Combined 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 its 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
okay so the key thing that makes VPLS VPLS is that it's a multipoint service 🦋 The whole Service Provider network should look like ONE logical learning bridge for each VPLS the SP supports. Its logical ports are the customer ports plus the pseudowires on a VE. Just like a learning bridge learns MAC addresses on its ports, the SP bridge must learn MAC addresses at its VEs 🧚
learning is basically linking source MAC addresses to the (logical) ports they showed up on, and that link is the Forwarding Information Base (FIB) 💜 the FIB is what gets used to forward packets. example: the bridge gets a packet with source MAC S on (logical) port P. later, a packet comes in with destination MAC S, and boom, it knows to send it out port P ✨
if a VE learns source MAC S on logical port P, then later sees S on a different port P', it MUST update its FIB to reflect the new port P' 🔥 and a VE MAY implement a mechanism to damp flapping of source ports for a given MAC address. (lowkey a good idea to keep the chaos down 🙈)
4.2.2. Aging
VPLS PEs SHOULD have an aging mechanism to remove a MAC address associated with a logical port, pretty much like learning bridges do 🌸 this is needed so a MAC address can get relearned if it "moves" from one logical port to another. that could happen because the station really did move, or because of a topology change in the LAN that makes the MAC show up on a new port 🦋 aging also shrinks a VPLS MAC table down to just the active MAC addresses, instead of every MAC address in that VPLS. so efficient, periodt 💅
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 goes over the aging time T, S MUST be flushed from the FIB 😭 and every time S shows up as a source MAC on port P, its age resets. obviously.
an implementation SHOULD provide a configurable knob to set the aging time T on a per-VPLS basis ⭐ and an implementation MAY speed up aging of all MAC addresses in a VPLS if it detects certain situations, like a Spanning Tree topology change in that VPLS 🌈
4.2.3. Flooding
when a bridge gets a packet for a destination that isn't in its FIB, it floods the packet out all the other ports 🍓 a VE does the same thing: it floods packets to an unknown destination to all other VEs in the VPLS. it's giving unknown = send to everyone, no cap 🫶
so using Figure 1 above as the vibe check: if CE2 sent an Ethernet frame to PE2, and the destination MAC wasn't in PE2's FIB (for that VPLS), then PE2 would be responsible for flooding that frame to every other PE in the same VPLS. when PE1 gets that frame, PE1 would be responsible for flooding it further to CE1 and CE5 (unless PE1 already knew which CE "owned" that MAC address) 💖
now the other side of the story 👑 if PE3 received the frame, it could hand off the further flooding to its u-PE. if PE3 was connected to two u-PEs, it would announce that it has two u-PEs. PE3 could announce that it is incapable of flooding, in which case it would get two frames, one for each u-PE. OR it could announce that it is capable of flooding, in which case it gets ONE copy of the frame and sends that copy to both u-PEs. both are valid, bestie, it's just a vibe choice 🎀
4.2.4. Broadcast and Multicast
there's a well-known broadcast MAC address 📣 an Ethernet frame whose destination MAC is the broadcast MAC address must be sent to all stations in that VPLS. this can be done with the same method used for flooding ✨
there's 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, the ones who have indicated interest in the corresponding multicast group 🦋 the discussion of how that works is outside the scope of this document, so we're leaving that one for another day 🙈
4.2.5. "Split Horizon" Forwarding
when a PE that's capable of flooding (let's call it PEx) gets a broadcast Ethernet frame, or one with an unknown destination MAC address, it must flood the frame 🔥 if the frame came from an attached CE, PEx must send a copy of the frame to every other attached CE, AND to all other PEs participating in the VPLS 💅 but if the frame came from another PE (say PEy), PEx must send a copy of the packet only to its attached CEs. PEx MUST NOT send the frame to other PEs, because PEy already did that 😭 this is called "split horizon" forwarding, and it's a consequence of the PEs being logically fully meshed for VPLS. the logic is so clean it's iconic 👑
split horizon forwarding rules apply to broadcast and multicast packets, as well as packets to an unknown MAC address ✨
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" 🌸 but the key for learning can also include the VLAN tag when one is present, and that's called "qualified learning" 💜
in VPLS, learning happens in the context of a VPLS instance, which usually maps to a customer 🧚 if the customer uses VLAN tags, you can make the same qualified vs. unqualified distinction. if the key within a VPLS is just the MAC address, the VPLS is operating under unqualified learning. if the key is (customer VLAN tag + MAC address), the VPLS is operating under qualified learning 🍓
picking between the two comes down to a few factors, and the big one is whether you want a single global broadcast domain (unqualified) or a broadcast domain per VLAN (qualified) 🎀 qualified makes flooding and broadcasting more efficient, but it needs bigger MAC tables. and these considerations apply equally to normal Ethernet forwarding AND to VPLS, so it's not a VPLS-only drama 💅
4.2.7. Class of Service
if you want different Classes of Service within a VPLS, an implementation MAY choose to map the 802.1p bits in a customer Ethernet frame that has a VLAN tag to an appropriate setting of EXP bits in the pseudowire and/or tunnel label 🌈 that lets VPLS frames get differential treatment in the packet switched network. main character energy ⭐
to be useful, an implementation SHOULD allow this mapping function to be different for each VPLS 🫶 each VPLS customer may have its own view of what the required behavior should be for a given setting of 802.1p bits, so one size definitely does not fit all 💖
5. Deployment Options ✨
in deploying a network that supports VPLS, the SP has to decide which functions the VPLS-aware device closest to the customer (the VE) supports 🎀 the default case in this document is that the VE is a PE. but there are a bunch of reasons the VE might be a device that does all the Layer 2 functions (like MAC address learning and flooding) plus a limited set of Layer 3 functions (like communicating with its PE), but, for example, doesn't do full-fledged discovery and PE-to-PE signaling. a device like that is called a "u-PE" 🦋
both of these cases have benefits, so you'd really like to be able to "mix and match" the scenarios 🌸 the signaling mechanism presented here allows exactly that. for example, in a given provider network, one PE might connect directly to CE devices, another might connect to u-PEs that are connected to CEs, and a third might connect directly to a customer over some interfaces and to u-PEs over others 👑 all these PEs do discovery and signaling in the same manner. how they do learning and forwarding depends on whether or not there is a u-PE, but that's a local matter and it's not signaled 🧚 the details of how a u-PE operates and how it interacts with PEs and other u-PEs are beyond the scope of this document, so that's a story for later 💅
6. Security Considerations ✨
okay bestie, this is the part where we talk about keeping everyone's data private 🔒💖 The whole point of Virtual Private LAN Service is privacy: data in a VPLS only goes to the other nodes in that VPLS. It should never leak to some outside agent or to a different VPLS 🙈
Real talk though, VPLS does not give you confidentiality, integrity, or authentication 💀 VPLS packets travel in the clear across the packet switched network, so a man-in-the-middle can eavesdrop and might even be able to inject packets into the data stream. Yikes! 😭 If you want security, the PE-to-PE tunnels can be IPsec tunnels 🛡️ For extra protection, the end systems at the VPLS sites can encrypt their data before it even enters the Service Provider network. Main character encryption energy 💅
There are two parts to getting data privacy in a VPLS: securing the control plane and protecting the forwarding path 🧚 If the control plane gets compromised, a PE could send data from one VPLS into another VPLS, blackhole VPLS data, or even send it to an eavesdropper. None of that is acceptable from a privacy point of view 😤 All control plane exchanges happen over BGP, so techniques such as the one in [2] can help authenticate BGP messages. That makes it harder to spoof updates (which could divert VPLS traffic to the wrong VPLS) or withdraws (denial-of-service attacks). In the multi-AS methods (b) and (c) from Section 3, this also means protecting the inter-AS BGP sessions, whether they run between the ASBRs, the PEs, or the Route Reflectors 🌸 You can also use the techniques in Section 10 (b) and (c) of [6], for both the control plane and the data plane. Also, [2] won't help keep VPLS labels private. If someone knows the labels, they can eavesdrop on VPLS traffic. Still, that requires access to the data path inside a Service Provider network 👀
Misconfiguration is another risk. It can accidentally connect CEs in different VPLSs, for example by attaching the wrong Route Target to a VPLS instance. This problem is shared by [6], and it's still marked for further study 📚
Protecting the data plane means making sure the PE-to-PE tunnels are well-behaved (that's outside the scope of this document), and that VPLS labels are only accepted from valid interfaces 🎀 For a PE, valid interfaces are links from P routers. For an ASBR, a valid interface is a link from an ASBR in an AS that's part of a given VPLS. It's especially important in multi-AS VPLSs that you only accept VPLS packets from valid interfaces. No exceptions, bestie 🫶
MPLS-in-IP and MPLS-in-GRE tunneling are specified in [3] 🦋 If you want to use those tunnels to carry VPLS packets, you have to fully understand the security considerations in Section 8 of that document. Any VPLS implementation that lets VPLS packets be tunneled as described there MUST include an implementation of IPsec that can be used as described there ✨ If the tunnel isn't secured by IPsec, then IP address filtering at the border routers (described in Section 8.2 of that document) is the only way to make sure a packet that exits the tunnel at a particular egress PE was actually put in the tunnel by the proper tunnel head node. In other words, it checks that the packet doesn't have a spoofed source address. Border routers often filter only source addresses, so packet filtering may not work unless the egress PE can check the IP source address of every tunneled packet it receives, and compare it against a list of valid tunnel head addresses 🕵️♀️ Any implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling without IPsec MUST let the egress PE validate the IP source address of every tunneled packet it receives in this way 💅🔥
7. IANA Considerations 🌈
IANA allocated value (25) for AFI for L2VPN information 🍓 This should be the same as the AFI requested by [11].
IANA also allocated an extended community value (0x800a) for the Layer2 Info Extended Community 💜
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.
- [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.
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 TelAppendix 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 💖
Editors' Addresses 💌
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: kireeti@juniper.netYakov Rekhter
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: yakov@juniper.netFull 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.
📦 where this page comes from
- ietf: rfc4761 2007-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms