RFC 4762
Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
RFC 4762 🎀 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
okay bestie, this is RFC 4762 and it's giving Standards Track 💅 It was published in January 2007 by M. Lasserre, Ed. and V. Kompella, Ed., both from Alcatel-Lucent. The header doesn't say it obsoletes or updates anything, so there's nothing to report there ✨
Status of This Memo 🌸
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🫶
Copyright Notice 🌈
Copyright (C) The IETF Trust (2007).
IESG Note ⚠️
okay this one is important. The L2VPN Working Group made two separate documents, RFC 4761 and this one, that do similar jobs but use different signaling protocols. Each method gets called "VPLS" even though they're distinct and incompatible with each other 😭 so be careful which one you're talking about 💀
Abstract 🦋
okay so this document describes a Virtual Private LAN Service (VPLS) solution that uses pseudowires 🧚 It's a service that used to run on other tunneling technologies and was known as Transparent LAN Services (TLS). A VPLS builds an emulated LAN segment for a group of users. In other words, it makes a Layer 2 broadcast domain that can fully learn and forward on Ethernet MAC addresses, and it's closed off to just that group of users 🔥 One Provider Edge (PE) node can support several VPLS services at once, which is so efficient ngl 💖
This document covers the control plane side, which is signaling pseudowire labels with Label Distribution Protocol (LDP), as an extension to RFC 4447. It doesn't care which discovery protocols you use 🤷♀️ It also covers the data plane side, which is forwarding, and it focuses especially on learning MAC addresses 👑 How VPLS packets get encapsulated is handled in RFC 4448.
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Conventions ................................................4
3. Acronyms ........................................................4
4. Topological Model for VPLS ......................................5
4.1. Flooding and Forwarding ....................................6
4.2. Address Learning ...........................................6
4.3. Tunnel Topology ............................................7
4.4. Loop free VPLS .............................................7
5. Discovery .......................................................7
6. Control Plane ...................................................7
6.1. LDP-Based Signaling of Demultiplexers ......................8
6.1.1. Using the Generalized PWid FEC Element ..............8
6.2. MAC Address Withdrawal .....................................9
6.2.1. MAC List TLV ........................................9
6.2.2. Address Withdraw Message Containing MAC List TLV ...11
7. Data Forwarding on an Ethernet PW ..............................11
7.1. VPLS Encapsulation Actions ................................11
7.2. VPLS Learning Actions .....................................12
8. Data Forwarding on an Ethernet VLAN PW .........................13
8.1. VPLS Encapsulation Actions ................................13
9. Operation of a VPLS ............................................14
9.1. MAC Address Aging .........................................15
10. A Hierarchical VPLS Model .....................................16
10.1. Hierarchical Connectivity ................................16
10.1.1. Spoke Connectivity for Bridging-Capable Devices ...17
10.1.2. Advantages of Spoke Connectivity ..................18
10.1.3. Spoke Connectivity for Non-Bridging Devices .......19
10.2. Redundant Spoke Connections ..............................21
10.2.1. Dual-Homed MTU-s ..................................21
10.2.2. Failure Detection and Recovery ....................22
10.3. Multi-domain VPLS Service ................................23
11. Hierarchical VPLS Model Using Ethernet Access Network .........23
11.1. Scalability ..............................................24
11.2. Dual Homing and Failure Recovery .........................24
12. Contributors ..................................................25
13. Acknowledgements ..............................................25
14. Security Considerations .......................................26
15. IANA Considerations ...........................................26
16. References ....................................................27
16.1. Normative References .....................................27
16.2. Informative References ...................................27
Appendix A. VPLS Signaling using the PWid FEC Element .............291. Introduction ✨
Ethernet is now the main technology for Local Area Network (LAN) connectivity, and it's getting popular as an access technology too, especially in Metropolitan and Wide Area Networks (MAN and WAN, respectively) 🌸 The big reason VPLS exists is to connect customer sites that are spread out across MANs and WANs, so they act like they're plugged into one LAN 🦋 End users can use it in two main ways:
- Connectivity between customer routers: LAN routing application
- Connectivity between customer Ethernet switches: LAN switching application
Broadcast and multicast are things you get on regular LANs 📡 Sites in the same broadcast domain that are linked through an MPLS network expect broadcast, multicast, and unicast traffic to reach the right place(s). That means you need MAC address learning and aging on a per-pseudowire basis, plus packet replication across pseudowires for multicast and broadcast traffic, and for flooding unknown unicast destination traffic 💅
[RFC4448] explains how to carry Layer 2 (L2) frames over point-to-point pseudowires (PW). This document extends [RFC4447] so Ethernet/802.3 and VLAN [802.1Q] traffic can cross multiple sites that belong to the same L2 broadcast domain, or VPLS 🫶 The same model can work with other 802.1 technologies too. It's a simple, scalable way to offer Virtual LAN services. It floods broadcast, multicast, and unknown unicast destination traffic over MPLS, with no address resolution servers or other external servers needed, as [L2VPN-REQ] discusses 🧚
The stuff below applies to devices that are VPLS capable and can tunnel labeled packets between each other. Put them together and you get a private MPLS VPN 👑
2. Terminology 🌈
Q-in-Q 802.1ad Provider Bridge extensions also known
as stackable VLANs or Q-in-Q.
Qualified learning Learning mode in which each customer VLAN is
mapped to its own VPLS instance.
Service delimiter Information used to identify a specific customer
service instance. This is typically encoded in
the encapsulation header of customer frames
(e.g., VLAN Id).
Tagged frame Frame with an 802.1Q VLAN identifier.
Unqualified learning Learning mode where all the VLANs of a single
customer are mapped to a single VPLS.
Untagged frame Frame without an 802.1Q VLAN identifier.2.1. Conventions 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🤓
3. Acronyms 💜
AC Attachment Circuit
BPDU Bridge Protocol Data Unit
CE Customer Edge device
FEC Forwarding Equivalence Class
FIB Forwarding Information Base
GRE Generic Routing Encapsulation
IPsec IP security
L2TP Layer Two Tunneling Protocol
LAN Local Area Network
LDP Label Distribution Protocol
MTU-s Multi-Tenant Unit switch
PE Provider Edge device
PW Pseudowire
STP Spanning Tree Protocol
VLAN Virtual LAN
VLAN tag VLAN Identifier4. Topological Model for VPLS 🧚
okay this section is the big picture 🖼️ An interface that takes part in a VPLS must be able to flood, forward, and filter Ethernet frames. Figure 1 shows the topological model. The PE devices linked by PWs look like one single emulated LAN to customer X 🎀 Every PE builds remote MAC address to PW associations, and it links directly attached MAC addresses to local customer-facing ports. It copies standard IEEE 802.1 MAC address learning, so nothing too wild 😌
+-----+ +-----+
| CE1 +---+ ........................... +---| CE2 |
+-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2
+---| PE | Cloud | PE |---+
+----+ +----+
. .
. +----+ .
..........| PE |...........
+----+ ^
| |
| +-- Emulated LAN
+-----+
| CE3 |
+-----+
Site 3
Figure 1: Topological Model of a VPLS for
Customer X with three sitesWe're going to say this again: this document uses MPLS transport tunnels in its examples, but other tunnels that PWs can use (as [RFC4447] mentions), like GRE, L2TP, or IPsec, work too 🦋 The only catch is that the originating PE has to be identifiable, since MAC learning depends on it 🔍
The VPLS only lives inside the PEs in the service provider network 💅 Apart from customer service delineation, how a customer site connects to the network doesn't matter to the VPLS [L2VPN-REQ]. So the attachment circuit (AC) connected to the customer could be a physical Ethernet port, a logical (tagged) Ethernet port, an ATM PVC carrying Ethernet frames, and so on, or even an Ethernet PW 🌈
The PE is usually an edge router that can run the LDP signaling protocol, routing protocols, or both, to set up PWs 🧠 On top of that, it can set up transport tunnels to other PEs and deliver traffic over the PWs. Iconic behavior honestly 👑
4.1. Flooding and Forwarding ✨
Okay bestie, so one of the defining vibes of Ethernet service is that frames sent to broadcast addresses and to unknown destination MAC addresses get flooded to all ports 🌊. To make that happen inside the provider network, all unknown unicast, broadcast and multicast frames get flooded over the matching PWs to every PE in the VPLS, plus all the ACs. 💖
Multicast frames are a special case, ngl. They don't have to go to every VPN member, but for simplicity the default move is to broadcast multicast frames too. 🦋
To forward a frame, a PE MUST be able to link a destination MAC address with a PW. 💅 Asking PEs to statically configure a mapping for every possible destination MAC is unreasonable and maybe even impossible, so VPLS-capable PEs SHOULD be able to dynamically learn MAC addresses on both ACs and PWs, and forward and replicate packets across both. It's giving flexibility 🎀
4.2. Address Learning 🌸
Unlike BGP VPNs [RFC4364], reachability info isn't advertised or distributed through a control plane. Instead, reachability comes from standard learning bridge functions in the data plane. Main character energy, no extra signaling needed 👑
When a packet arrives on a PW and the source MAC address is unknown, that MAC needs to get associated with the PW, so outbound packets to it can be delivered over that PW. Same deal for ACs: an unknown source MAC arriving on an AC gets associated with that AC, so outbound packets can head back out over it. 🫶
Standard learning, filtering, and forwarding actions, as defined in [802.1D-ORIG], [802.1D-REV], and [802.1Q], are required when a PW or AC state changes. 🔥
4.3. Tunnel Topology 🧚
PE routers are assumed to be able to set up transport tunnels. Tunnels get built between PEs to aggregate traffic, and PWs are signaled to demultiplex the encapsulated Ethernet frames from multiple VPLS instances that travel through those transport tunnels. 🌈
In an Ethernet L2VPN, creating the loop-free topology is the service provider's job 💁♀️ For simplicity, we define the topology of a VPLS as a full mesh of PWs ✨
4.4. Loop free VPLS 💜
If the topology isn't restricted to a full mesh, then two PEs that aren't directly connected via PWs might have to use an intermediary PE to relay packets. That setup would need some loop-breaking protocol, like a spanning tree protocol. 😵💫
So instead, we establish a full mesh of PWs between PEs! 🎉 Since every PE is directly connected to every other PE in the VPLS via a PW, there's no need to relay packets anymore, and we can use a much simpler loop-breaking rule: the "split horizon" rule. That means a PE MUST NOT forward traffic from one PW to another in the same VPLS mesh. 🙅♀️
Note that customers are allowed to run a Spanning Tree Protocol (STP) (e.g., as defined in [802.1D-REV]), like when a customer has "back door" links for redundancy in case something fails within the VPLS. In that case, STP Bridge PDUs (BPDUs) are simply tunneled through the provider cloud. 🍓
5. Discovery 🔍
Manually configuring the addresses of the remote PEs is REQUIRED, bestie 😤 Manual configuration isn't necessary if an auto-discovery procedure is used, though. A bunch of auto-discovery procedures are compatible with this document ([RADIUS-DISC], [BGP-DISC]) ✨
6. Control Plane 🎀
This document covers the control plane functions for signaling PW labels. It also lays some foundational groundwork for multi-homing support. The extensions that provide multi-homing support should work independently of the basic VPLS operation, and they aren't described here. 🫶
6.1. LDP-Based Signaling of Demultiplexers 🌷
A full mesh of LDP sessions is used to establish the mesh of PWs. Honestly the full mesh requirement can mean a huge number of targeted LDP sessions 😭 Section 10 talks about setting up hierarchical topologies to minimize the size of the VPLS full mesh.
Once an LDP session has been formed between two PEs, all PWs between those two PEs get signaled over that one session. Efficient queen behavior 👑
In [RFC4447], two types of FECs are described: the PWid FEC Element (FEC type 128) and the Generalized PWid FEC Element (FEC type 129). The original FEC element used for VPLS was compatible with the PWid FEC Element. The text for signaling with the PWid FEC Element has been moved to Appendix A. What we describe below replaces that with a more generalized L2VPN descriptor, the Generalized PWid FEC Element. 🦋
6.1.1. Using the Generalized PWid FEC Element 💅
[RFC4447] describes a generalized FEC structure for VPLS signaling, and here's how it gets used. We break down the assignment of the Generalized PWid FEC Element fields in the context of VPLS signaling. Let's go! 🚀
- Control bit (C): This bit signals the use of the control word as specified in [RFC4447].
- PW type: The allowed PW types are Ethernet (
0x0005) and Ethernet tagged mode (0x004), as specified in [RFC4446]. - PW info length: As specified in [RFC4447].
- Attachment Group Identifier (AGI), Length, Value: This is the unique name of the VPLS. The AGI identifies a type of name, Length tells you how long the Value is, and Value is the name of the VPLS. We use the term AGI interchangeably with VPLS identifier. 🏷️
- Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null, because the mesh of PWs in a VPLS terminates on MAC learning tables, not on individual attachment circuits. Using non-null TAII and SAII is reserved for future enhancements. 🔮
- Interface Parameters: The relevant interface parameters are:
- MTU: The MTU (Maximum Transmission Unit) of the VPLS MUST be the same across all the PWs in the mesh. 📏
- Optional Description String: Same as [RFC4447]. 📝
- Requested VLAN ID: If the PW type is Ethernet tagged mode, this parameter may be used to signal the insertion of the appropriate VLAN ID, as defined in [RFC4448]. 🏷️
6.2. MAC Address Withdrawal 🧹
It MAY be desirable to remove or unlearn MAC addresses that were dynamically learned, so convergence is faster. To do that, you send an LDP Address Withdraw Message with the list of MAC addresses to be removed to all other PEs over the corresponding LDP sessions. Clean slate, bestie ✨
We introduce an optional MAC List TLV in LDP. It specifies a list of MAC addresses that can be removed or unlearned using the LDP Address Withdraw Message. 🫧
The Address Withdraw message with MAC List TLVs MAY be supported to speed up removal of MAC addresses after a topology change (e.g., failure of the primary link for a dual-homed VPLS-capable switch). That's a whole glow-up for failover 💥
To keep the LDP convergence time from getting hit, when the MAC List TLV has a huge number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list instead. 🌙
6.2.1. MAC List TLV 🧾
MAC addresses to be unlearned can be signaled using an LDP Address Withdraw Message that contains a new TLV, the MAC List TLV. Here's its format. Each encoded MAC List TLV address is the 6-octet MAC address specified by IEEE 802 documents [802.1D-ORIG] [802.1D-REV]. 🧠
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | MAC Address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U bit: Unknown bit. This bit MUST be set to 1. If the MAC address format isn't understood, then the TLV isn't understood either, and it MUST be ignored. 🤷♀️
- F bit: Forward bit. This bit MUST be set to 0. Since the LDP mechanism used here is targeted, the TLV MUST NOT be forwarded. 🛑
- Type: Type field. This field MUST be set to
0x0404. It identifies the TLV type as MAC List TLV. 🏷️ - Length: Length field. This field specifies the total length in octets of the MAC addresses in the TLV. The length MUST be a multiple of 6. 🔢
- MAC Address: The MAC address(es) being removed. 👋
The MAC Address Withdraw Message contains a FEC TLV (to identify the VPLS affected), a MAC Address TLV, and optional parameters. No optional parameters have been defined for the MAC Address Withdraw signaling. 📦 Note that if a PE receives a MAC Address Withdraw Message and doesn't understand it, it MUST ignore the message. In that case, instead of flushing its MAC address table, the PE keeps using stale info, unless:
- it receives a packet with a known MAC address association, but from a different PW, in which case it replaces the old association; or
- it ages out the old association.
⚠️ Heads up: a PE that ignores the withdraw message is still running on stale MAC info until one of those two things happens. Not ideal, but it's still allowed!
The MAC Address Withdraw message only helps speed up convergence, so PEs that don't understand the message can keep participating in the VPLS just fine 🥰
6.2.2. Address Withdraw Message Containing MAC List TLV 🌟
Here's how a MAC List TLV received in an Address Withdraw Message gets processed. 🔄
For each MAC address in the TLV:
- Remove the association between the MAC address and the AC or PW over which this message is received.
For a MAC Address Withdraw message with an empty list:
- Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received. 🧹✨
The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be figured out from the length field in the TLV. 🔢💜
7. Data Forwarding on an Ethernet PW 💌
This section describes the data plane behavior on an Ethernet PW used in a VPLS. The encapsulation is similar to what's described in [RFC4448], but this part covers the functions of stripping the service-delimiting tag and using a "normalized" Ethernet frame. Stay tuned, we're just getting to the good part! 🦋🌸
7.1. VPLS Encapsulation Actions ✨
okay so in a VPLS, a customer Ethernet frame (no preamble!) gets wrapped up with a header defined in [RFC4448] 🎀. Here's how the customer frame works:
- If the frame shows up at the PE with an encapsulation the local PE uses as a service delimiter (aka the thing that identifies the customer and/or their particular service) 💅, that encapsulation may be stripped before the frame goes into the VPLS. When the frame exits the VPLS, it may get a service-delimiting encapsulation inserted again.
- If the frame shows up at the PE with an encapsulation that is NOT service delimiting, then it's a customer frame whose encapsulation should not be touched by the VPLS. For example, a frame carrying customer-specific VLAN tags that the service provider doesn't know about and doesn't want to change 🙈.
Applying those rules: a customer frame might arrive at a customer-facing port with a VLAN tag that identifies the customer's VPLS instance. That tag gets stripped before it's encapsulated in the VPLS. On the way out, the frame may get tagged again (if a service-delimiting tag is used) or left untagged (if none is used) 🦋.
Same deal if a customer frame arrives at a customer-facing port over an ATM or Frame Relay VC that identifies the customer's VPLS instance: the ATM or FR encapsulation is removed before the frame is passed into the VPLS 💖.
Now the opposite case: if a customer frame arrives at a customer-facing port with a VLAN tag that identifies a VLAN domain in the customer L2 network, the tag is NOT modified or stripped, because it belongs with the rest of the customer frame 🫶.
So by following these rules, the Ethernet frame that travels across a VPLS is always a customer Ethernet frame ✨. The ingress and egress actions for service delimiters are local actions, and neither PE has to signal them to the other. That's what makes it possible to mix and match VLAN tagged and untagged services at either end 🌈. It also means a VLAN tag with only local significance does NOT get carried across a VPLS 💀. The service delimiter can also be an MPLS label, so an Ethernet PW given by [RFC4448] can serve as the access side connection into a PE 🧚. An RFC1483 Bridged PVC encapsulation could also be a service delimiter. And by keeping locally significant encapsulations at the edge, hierarchical VPLS models can be built to network-engineer scalable VPLS deployments, as described below 👑.
7.2. VPLS Learning Actions
Learning is based on the customer Ethernet frame as defined above 🍓. The Forwarding Information Base (FIB) keeps track of which customer Ethernet frame addressing maps to which PW to use. There are two modes of learning: qualified and unqualified. Qualified learning is the default mode and it MUST be supported. Support for unqualified learning is OPTIONAL 🌸.
In unqualified learning, all the VLANs of a single customer are handled by a single VPLS, so they all share one broadcast domain and one MAC address space. That means MAC addresses need to be unique and non-overlapping among customer VLANs, or else they can't be told apart within the VPLS instance, and customer frames can get lost 😭. An example is port-based VPLS service for a given customer (for instance, a customer with a non-multiplexed AC, where all the traffic on a physical port, which may include multiple customer VLANs, is mapped to a single VPLS instance).
In qualified learning, each customer VLAN gets its own VPLS instance, so each customer VLAN has its own broadcast domain and MAC address space 💜. That means MAC addresses can overlap between customer VLANs and still be handled correctly, because each customer VLAN has its own FIB, meaning its own MAC address space. Since VPLS broadcasts multicast frames by default, qualified learning has the perk of limiting the broadcast scope to a given customer VLAN 📣. The tradeoff is that FIB tables can get big, because the logical MAC address is now a VLAN tag + MAC address 🫠.
For STP to work in qualified learning mode, a VPLS PE must be able to forward STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case (see details in Section 10), service delimiting tags (Q-in-Q or [RFC4448]) can be added so PEs can unambiguously identify all customer traffic, including STP BPDUs 🎀. In a basic VPLS case, upstream switches must insert those service delimiting tags. When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP traffic. The STP frames get encapsulated with a unique provider tag per customer (just like regular customer traffic), and a PE looks up the provider tag to send those frames across the proper VPLS instance 🦋.
8. Data Forwarding on an Ethernet VLAN PW 🌈
This section covers the data plane behavior on an Ethernet VLAN PW in a VPLS. The encapsulation is similar to what's described in [RFC4448], but this section explains how tags get imposed and how a "normalized" Ethernet frame is used. The learning behavior is the same as for Ethernet PWs 💖.
8.1. VPLS Encapsulation Actions
Once again, a customer Ethernet frame (no preamble) gets encapsulated with a header defined in [RFC4448]. Here's how it's defined:
- If the frame shows up at the PE with an encapsulation that is part of the customer frame AND is also used by the local PE as a service delimiter (so it identifies the customer and/or their particular service), then that encapsulation is preserved as the frame goes into the VPLS. The exception is when the Requested VLAN ID optional parameter was signaled. In that case, the VLAN tag gets overwritten before the frame is sent out on the PW 🔥.
- If the frame shows up at the PE with an encapsulation that doesn't have the required VLAN tag, a null tag is imposed when the Requested VLAN ID optional parameter was NOT signaled 🙈.
Applying these rules: a customer frame might arrive at a customer-facing port with a VLAN tag that identifies the customer's VPLS instance AND identifies a customer VLAN. That tag gets preserved as it's encapsulated in the VPLS 🫶.
The Ethernet VLAN PW gives you a simple way to preserve customer 802.1p bits ✨.
A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a PE can't support both PWs at the same time, it SHOULD send a Label Release on the PW messages it can't support, with a status code "Unknown FEC" as given in [RFC3036] 😭.
9. Operation of a VPLS 👑
Okay, time for an example! Figure 2 below shows how a VPLS works. The discussion that follows uses this figure, where a VPLS has been set up between PE1, PE2, and PE3. The VPLS connects a customer with 4 sites, labeled A1, A2, A3, and A4, through CE1, CE2, CE3, and CE4 respectively 🌸.
-----
/ A1 \
---- ----CE1 |
/ \ -------- ------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \---/ \ -----
---- ---PE2 |
| Service Provider Network |
\ / \ /
----- PE3 / \ /
|Agg|_/ -------- -------
-| |
---- / ----- ----
/ \/ \ / \ CE = Customer Edge Router
| A3 CE3 -CE4 A4 | PE = Provider Edge Router
\ / \ / Agg = Layer 2 Aggregation
---- ----Figure 2: Example of a VPLS
Initially, the VPLS is set up so that PE1, PE2, and PE3 have a full mesh of Ethernet PWs 🕸️. The VPLS instance gets an identifier (AGI). In this example, say PE1 signals PW label 102 to PE2 and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3 💜.
Let's say a packet from A1 is bound for A2 🧚. When it leaves CE1, say it has a source MAC address of M1 and a destination MAC of M2. If PE1 doesn't know where M2 is, it will flood the packet, meaning it sends it to PE2 and PE3 📣. When PE2 receives the packet, it will have a PW label of 201. PE2 can conclude that source MAC address M1 is behind PE1, since it distributed label 201 to PE1. So it can associate MAC address M1 with PW label 102 🎀.
9.1. MAC Address Aging
PEs that learn remote MAC addresses SHOULD have an aging mechanism to remove unused entries associated with a PW label. This matters for both memory conservation and administrative purposes 🧹. For example, if customer site A is shut down, eventually the other PEs should unlearn A's MAC address 🥲.
The aging timer for MAC address M SHOULD be reset when a packet with source MAC address M is received 🌈.
10. A Hierarchical VPLS Model 🏗️
The solution described above needs a full mesh of tunnel LSPs between all the PE routers that participate in the VPLS service. For each VPLS service, n*(n-1)/2 PWs must be set up between the PE routers. Signaling overhead is one problem, but the real dealbreaker for large-scale deployment is the packet replication requirement for each provisioned PW on a PE router 😩. Hierarchical connectivity, described in this document, reduces signaling and replication overhead so large-scale deployment becomes doable 💅.
In many cases, service providers put smaller edge devices in multi-tenant buildings and aggregate them into a PE in a large Central Office (CO) facility 🏢. In some cases, standard IEEE 802.1q (Dot 1Q) tagging techniques can be used to make it easier to map CE interfaces to VPLS access circuits at a PE 🏷️.
It's often beneficial to extend VPLS service tunneling techniques into the access switch domain 🦋. You can do this by treating the access device as a PE and provisioning PWs between it and every other edge, just like a basic VPLS. Another option is to use [RFC4448] PWs or Q-in-Q logical interfaces between the access device and selected VPLS-enabled PE routers 🫶. Q-in-Q encapsulation is another form of L2 tunneling, and it can be used together with MPLS signaling, as described later. The next two sections focus on this alternative approach. The VPLS core PWs (hub) get augmented with access PWs (spoke) to form a two-tier hierarchical VPLS (H-VPLS) ✨.
Spoke PWs can be implemented using any L2 tunneling mechanism, and the first tier's scope expands to include non-bridging VPLS PE routers 🌸. The non-bridging PE router extends a spoke PW from a Layer-2 switch that connects to it, through the service core network, to a bridging VPLS PE router that supports hub PWs. We also describe how VPLS-challenged nodes and low-end CEs without MPLS capabilities can take part in a hierarchical VPLS 🧚.
For the rest of this discussion, we refer to a bridging-capable access device as MTU-s and a non-bridging PE as PE-r. A routing and bridging capable device is called PE-rs 💜.
10.1. Hierarchical Connectivity ✨
okay so this section is all about the hub and spoke connectivity model 🧚 It also spells out what the bridging capable and non-bridging MTU-s devices need to do so they can support the spoke connections 💅
10.1.1. Spoke Connectivity for Bridging-Capable Devices 🎀
okay, picture Figure 3 🦋 Three customer sites hook up to an MTU-s through CE-1, CE-2, and CE-3. The MTU-s has one single connection (PW-1) to PE1-rs. The PE-rs devices are linked together in a basic VPLS full mesh 🕸️ For each VPLS service, one spoke PW gets set up between the MTU-s and the PE-rs, based on [RFC4447]. Here's the twist: normal PWs end on a physical port (or a VLAN-tagged logical port), but a spoke PW ends on a virtual switch instance (VSI; see [L2FRAME]) on both the MTU-s and the PE-rs. Iconic 👑
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | PW-1 | -- |---/ |
| / \--|- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ |
---- +--------+
|Agg | | |
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \S / |
| -- |
+--------+
PE3-rs
Agg = Layer-2 Aggregation
--
/ \
\S / = Virtual Switch Instance
--
Figure 3: An example of a hierarchical VPLS modelso the MTU-s and the PE-rs both treat each spoke connection like an AC (attachment circuit) of the VPLS service 💖 The PW label is what ties the traffic coming from the spoke to a specific VPLS instance 🏷️
10.1.1.1. MTU-s Operation 🌸
an MTU-s is a device that does layer-2 switching and handles all the normal bridging jobs: learning and replication on all of its ports 🫶 The spoke counts as one of those ports too, just a virtual one. Packets headed to unknown destinations get replicated to every port in the service, spoke included.
once the MAC address is learned, traffic between CE1 and CE2 gets switched locally by the MTU-s, which saves spoke capacity to the PE-rs 🙌 Traffic between CE1 or CE2 and any remote destination goes straight onto the spoke and gets sent to the PE-rs over the point-to-point PW. ngl that's so efficient 😭
since the MTU-s is bridging capable, you only need a single PW per VPLS instance, no matter how many access connections are in the same VPLS service ✨ That cuts down even more on signaling overhead between the MTU-s and the PE-rs.
if the MTU-s is directly connected to the PE-rs, other encapsulation techniques, such as Q-in-Q, can be used for the spoke 🧁
10.1.1.2. PE-rs Operation 💜
a PE-rs is a device that supports all the bridging functions for VPLS service, plus routing and MPLS encapsulation. so basically it supports everything described for a basic VPLS above 💅
the PE-rs works the same no matter what kind of device is on the other end of the spoke 🤷♀️ So the spoke from the MTU-s is treated as a virtual port, and the PE-rs switches traffic between the spoke PW, hub PWs, and ACs once it has learned the MAC addresses. it's giving efficiency 🦋
10.1.2. Advantages of Spoke Connectivity 🌈
spoke connectivity has a bunch of scaling and operational perks for building big VPLS setups, and it still keeps all the functionality of the VPLS service 🙌
- It gets rid of the need for a full mesh of tunnels and a full mesh of PWs per service between all devices in the VPLS service. 😭
- It minimizes signaling overhead, since fewer PWs are needed for the VPLS service. 💖
- It segments VPLS nodal discovery 🧚 The MTU-s only needs to know about the PE-rs node, even though it's taking part in a VPLS service that spans multiple devices. Meanwhile, every VPLS PE-rs has to know about every other VPLS PE-rs and all of its locally connected MTU-s and PE-r devices.
- Adding another site means configuring the new MTU-s, but it does not require any provisioning of the existing MTU-s devices on that service. 🎀
- Hierarchical connections can be used to build a VPLS service that spans multiple service provider domains. We'll get into that in a later section 👑
note that as more devices join the VPLS, more devices need the capability for learning and replication 👀
10.1.3. Spoke Connectivity for Non-Bridging Devices 🍓
sometimes a bridging PE-rs isn't deployed, or a PE-r is already out there in the wild 🌸 This section explains how a PE-r that doesn't support any VPLS bridging functionality can still join the VPLS service.
in Figure 4, three customer sites connect through CE-1, CE-2, and CE-3 to the VPLS through a PE-r. For every attachment circuit that takes part in the VPLS service, the PE-r creates a point-to-point PW that ends on the VSI of PE1-rs 🦋
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ PE-r PE1-rs / |
+--------+ +--------+ / |
|\ | | | / |
| \ | PW-1 | -- |---/ |
| ------|- - - - - - - - - - - | / \ | |
| -----|- - - - - - - - - - - | \S / | |
| / | | -- |---\ |
+--------+ +--------+ \ |
/ \ |
---- +--------+
| Agg| | |
---- | -- |
/ \ | / \ |
CE-2 CE-3 | \S / |
| -- |
+--------+
PE3-rs
Figure 4: An example of a hierarchical VPLS
with non-bridging spokesthe PE-r is a device that supports routing but doesn't support any bridging functions 🧁 It can still set up PWs between itself and the PE-rs though. For every port supported in the VPLS service, a PW gets set up from the PE-r to the PE-rs. Once the PWs are up, the PE-r doesn't need any learning or replication function at all 🙈 All traffic received on any of the ACs gets transmitted on the PW. And all traffic received on a PW gets transmitted to the AC where that PW terminates. So traffic from CE1 going to CE2 gets switched at PE1-rs, not at PE-r ✨
💌 Heads up: when PE-r devices use Provider VLANs (P-VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as such and map these "circuits" into a VPLS domain to provide bridging support between them.
this approach adds more overhead than the bridging-capable (MTU-s) spoke approach 😤 That's because a PW is needed for every AC that takes part in the service, versus a single PW per service (regardless of ACs) when an MTU-s is used. the upside is that this approach lets you offer a VPLS service alongside a routed internet service, without adding any new MTU-s 🌈
10.2. Redundant Spoke Connections 💅
okay so the big weakness of the hub and spoke approach we've covered is that the MTU-s has a single connection to the PE-rs 🥺 If that connection fails, or the PE-rs does, the MTU-s loses all connectivity. yikes 💀
this section describes how redundant connections can be provided so the MTU-s doesn't end up with total loss of connectivity 🫶 The mechanism is identical for both MTU-s and PE-r devices, periodt 👑
10.2.1. Dual-Homed MTU-s 🎀
okay so bestie, to protect against the PW dying or the PE-rs dying, the MTU-s (or the PE-r) gets dual-homed into two PE-rs devices 💅. The PE-rs devices must be part of the same VPLS service instance, no exceptions 🙈
In Figure 5, two customer sites connect through CE-1 and CE-2 to one MTU-s. The MTU-s sets up two PWs for each VPLS instance, one to PE1-rs and one to PE3-rs. One PW is the primary, which is the one that's actively used under normal conditions. The other is the secondary, which just sits in a standby state 🦋 The MTU-s negotiates the PW labels for both the primary and secondary PWs, but it doesn't use the secondary PW unless the primary PW fails. How a spoke gets labeled primary or secondary is outside the scope of this document. A spanning tree instance running between only the MTU-s and the two PE-rs nodes is one possible method, and configuration is another ✨
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | Primary PW | -- |---/ |
| / \ |- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ \ |
/ \ +--------+
/ \ | |
CE-2 \ | -- |
\ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / |
| -- |
+--------+
PE3-rs
Figure 5: An example of a dual-homed MTU-s10.2.2. Failure Detection and Recovery 🔥
so the MTU-s should control how the spokes to the PE-rs devices get used 💖 If the spokes are PWs, LDP signaling negotiates the PW labels, and the hello messages used for the LDP session could be used to detect a failure of the primary PW. Other mechanisms that could detect failures faster are outside the scope of this document 🧚
When the primary PW fails, the MTU-s immediately switches over to the secondary PW 🦋 Right then, the PE3-rs that terminates the secondary PW starts learning MAC addresses on the spoke PW. But here's the drama: all the other PE-rs nodes still think CE-1 and CE-2 are behind PE1-rs, so they may keep sending traffic to PE1-rs until they figure out the devices are now behind PE3-rs. That unlearning process can take a long time, and it may mess with the connectivity of higher-level protocols from CE1 and CE2 😭 To speed things up, the PE3-rs where the secondary PW got activated may send out a flush message (as explained in Section 6.2). It uses the MAC List TLV, as defined in Section 6, and goes to all PE-rs nodes. When they get the message, the PE-rs nodes flush the MAC addresses associated with that VPLS instance. Main character energy for sure 👑
10.3. Multi-domain VPLS Service 🌈
Hierarchy can also be used to build a large-scale VPLS service within a single domain, or a service that spans multiple domains, without needing full mesh connectivity between every VPLS-capable device 🍓 Two fully meshed VPLS networks get connected together using a single LSP tunnel between the VPLS "border" devices. A single spoke PW per VPLS service is set up to connect the two domains together 💜
When more than two domains need to be connected, a full mesh of inter-domain spokes gets created between the border PEs. The forwarding rules over this mesh are identical to the rules defined in Section 4 ✨
Put it all together and you get a three-tier hierarchical model 🫶 It has a hub-and-spoke topology between MTU-s and PE-rs devices, a full-mesh topology between PE-rs devices, and a full mesh of inter-domain spokes between border PE-rs devices. Iconic architecture, no notes.
This document does not specify how redundant border PEs per domain per VPLS instance can be supported 🙈
11. Hierarchical VPLS Model Using Ethernet Access Network 🦋
In this section, the hierarchical model gets expanded to include an Ethernet access network 💅 It keeps the hierarchical architecture we just talked about, since it still leans on the full-mesh topology among PE-rs devices. But no restriction is placed on the topology of the Ethernet access network. For example, the topology between MTU-s and PE-rs devices isn't limited to hub and spoke, so it's giving flexibility 🌸
The reason this matters is that some service providers already deploy Ethernet-based networks to offer VPLS services to their customers. So it's important to have a mechanism that lets those networks plug into an IP or MPLS core and give you scalable VPLS services ✨
One way to tunnel a customer's Ethernet traffic through an Ethernet access network is to add an extra VLAN tag to the customer's data, which may be tagged or untagged. That extra tag is called the Provider's VLAN (P-VLAN) 🎀 Inside the provider's network, each P-VLAN stands for a customer, or more specifically, a VPLS instance for that customer. So there's a one-to-one correspondence between a P-VLAN and a VPLS instance. In this model, the MTU-s needs to be able to add the extra P-VLAN tag to non-multiplexed ACs, where customer VLANs aren't used as service delimiters. This functionality is described in [802.1ad].
If customer VLANs need to be treated as service delimiters (for example, when the AC is a multiplexed port), then the MTU-s needs the extra capability of translating a customer VLAN (C-VLAN) to a P-VLAN, or of pushing an additional P-VLAN tag. That's how overlapping VLAN tags used by different customers get resolved 🧚 So the MTU-s in this model can be considered a typical bridge with this additional capability. This functionality is also described in [802.1ad] 💜
The PE-rs needs to be able to do bridging over the standard Ethernet ports toward the access network, as well as over the PWs toward the network core 🌈 In this model, the PE-rs may need to run STP toward the access network, in addition to split-horizon over the MPLS core. The PE-rs also needs to map a P-VLAN to a VPLS-instance and its associated PWs, and vice versa 🍓
The details of bridge operation for MTU-s and PE-rs (for example, the encapsulation format for Q-in-Q messages, and how the customer's Ethernet control protocols get handled) are outside the scope of this document and are covered in [802.1ad]. The relevant part for us is how the bridge module interacts with the MPLS/IP PWs in the PE-rs, which behaves just like a regular VPLS 🫶
11.1. Scalability 📈
Since each P-VLAN corresponds to a VPLS instance, the total number of VPLS instances supported is limited to 4K 💀 The P-VLAN acts as a local service delimiter inside the provider's network, and it gets stripped as it's mapped to a PW in a VPLS instance. So the 4K limit only applies within an Ethernet access network (an Ethernet island), not to the entire network 🌸 The SP network is a core MPLS/IP network that connects many Ethernet islands. That means the number of VPLS instances can scale along with the number of Ethernet islands (a metro region can be represented by one or more islands) ✨
11.2. Dual Homing and Failure Recovery 🔥
In this model, an MTU-s can be dual homed to different devices, which can be aggregators and/or PE-rs devices 💅 Failure protection for access network nodes and links can be provided by running STP in each island. The STP of each island is independent of the others and does not interact with them 🦋 If an island has more than one PE-rs, then a dedicated full-mesh of PWs gets used among those PE-rs devices to carry the SP BPDU packets for that island. On a per-P-VLAN basis, STP designates a single PE-rs to carry the traffic across the core. Loop-free protection through the core is done using split-horizon, and failure protection in the core is done through standard IP/MPLS re-routing 👑
12. Contributors 🌷
- Loa Andersson, TLA
- Ron Haberman, Alcatel-Lucent
- Juha Heinanen, Independent
- Giles Heron, Tellabs
- Sunil Khandekar, Alcatel-Lucent
- Luca Martini, Cisco
- Pascal Menezes, Independent
- Rob Nath, Alcatel-Lucent
- Eric Puetz, AT&T
- Vasile Radoaca, Independent
- Ali Sajassi, Cisco
- Yetik Serbest, AT&T
- Nick Slabakov, Juniper
- Andrew Smith, Consultant
- Tom Soon, AT&T
- Nick Tingle, Alcatel-Lucent
13. Acknowledgments 🫶
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable feedback 💖
We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu (Ixia), and Charlie Hundall for identifying issues with the draft during the interoperability tests 🧚
We would also like to thank Ina Minei, Bob Thomas, Eric Gray, and Dimitri Papadimitriou for their thorough technical review of the document 🌈
14. Security Considerations 🚨
A more comprehensive description of the security issues involved in L2VPNs is covered in [RFC4111]. An unguarded VPLS service is vulnerable to some security issues that pose risks to both the customer and provider networks. Most of these issues can be avoided by implementing appropriate guards. A couple of them can be prevented through existing protocols. This part is serious, bestie, so pay attention 😭
- Data plane aspects 💀
- Traffic isolation between VPLS domains is guaranteed by the use of a per-VPLS L2 FIB table and the use of per-VPLS PWs.
- The customer traffic, which consists of Ethernet frames, is carried unchanged over VPLS. If security is required, the customer traffic SHOULD be encrypted and/or authenticated before it enters the service provider network.
- Preventing broadcast storms can be achieved by using routers as CPE devices or by rate policing the amount of broadcast traffic that customers can send.
- Control plane aspects 🔐
- LDP security (authentication) methods as described in [RFC3036] SHOULD be applied. This would prevent unauthenticated messages from disrupting a PE in a VPLS.
- Denial of service attacks 🚫
- Some means to limit the number of MAC addresses (per site per VPLS) that a PE can learn SHOULD be implemented.
15. IANA Considerations 📋
The type field in the MAC List TLV is defined as 0x404 in Section 6.2.1 ✨
16. References 📚
16.1. Normative References 📚
okay so these are the docs you literally cannot skip if you want the spec to make sense 🫶
- [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
- [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
- [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges".
- [802.1D-REV] 802.1D - "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.
- [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", July 1998.
- [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
- [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
16.2. Informative References 🦋
these ones are more like bonus reading. super useful for context, but not strictly required to get the core vibe ✨
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
- [RADIUS-DISC] Heinanen, J., Weber, G., Ed., Townsley, W., Booth, S., and W. Luo, "Using Radius for PE-Based VPN Discovery", Work in Progress, October 2005.
- [BGP-DISC] Ould-Brahim, H., Ed., Rosen, E., Ed., and Y. Rekhter, Ed., "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", Work in Progress, September 2006.
- [L2FRAME] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
- [L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
- [RFC4111] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
- [802.1ad] "IEEE standard for Provider Bridges", Work in Progress, December 2002.
Appendix A. VPLS Signaling using the PWid FEC Element 🎀
okay this part is giving legacy realness 🕰️ it's being kept around because live deployments are still using this version of the signaling for VPLS. so it's not going anywhere 💅
the VPLS signaling info rides inside a Label Mapping message that's sent in downstream unsolicited mode 📨. the message carries the PWid FEC TLV shown below ✨
PW, C, PW Info Length, Group ID, and Interface parameters all mean exactly what they mean in [RFC4447] 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW TLV |C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Ethernet PW type is how we spot the PWs that carry Ethernet traffic for multipoint connectivity 🌈
now, the tea ☕: in a VPLS, we use a VCID to identify an emulated LAN segment 🫧. when you're using the PWid FEC, the VCID has been swapped out for a more general identifier (AGI), which is what lets the scope of a VPLS get extended 🌸. but here's the twist 👀: the VCID in [RFC4447] is a service identifier for a service that emulates a point-to-point virtual circuit. inside a VPLS, the VCID is one single service identifier, so it has global significance across all PEs involved in the VPLS instance 💜. every PE in that instance is on the same page, no cap 🙌
Authors' Addresses 🖊️
Marc Lasserre Alcatel-Lucent EMail: mlasserre@alcatel-lucent.com
Vach Kompella Alcatel-Lucent EMail: vach.kompella@alcatel-lucent.com
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. 💖
📦 where this page comes from
- ietf: rfc4762 2007-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms