RFC 6246
Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges
Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges 🎀
- RFC number: 6246, from the Internet Engineering Task Force (IETF) 🦋
- Authors: A. Sajassi (Ed.) and F. Brockners from Cisco Systems, D. Mohan (Ed.) from Nortel, and Y. Serbest from AT&T 💜
- Category: Informational, so it's published for info and isn't a Standards Track spec 📚
- ISSN: 2070-1721
- Date: June 2011 📅
- Obsoletes/Updates: The header doesn't list anything this RFC obsoletes or updates. 🌸
Abstract
okay so the big reason VPLS is so iconic is that it doesn't just connect customer routers and servers/hosts, it connects customer IEEE bridges too 🫶 The goal is that it gives you the same level of service that enterprise users already get from their own bridged networks or from their Ethernet Service Providers. main character energy, fr 💅
when the customer edge (CE) devices are IEEE bridges, there are some issues and challenges you have to handle in a VPLS network 😭 Most of them were already sorted out in the IEEE 802.1ad standard for provider bridges, so VPLS can borrow those fixes. This document extends the provider edge (PE) model from RFC 4664, built on the IEEE 802.1ad bridge module, and draws a clean line between the IEEE bridge module and the IETF LAN emulation module ✨ The result is that most of the interoperability issues with CE bridges can be handed off to the 802.1ad bridge module, so the IETF LAN emulation module inside a VPLS PE doesn't have to carry all that weight 🙌
Status of This Memo
ngl this part is the official paperwork, but here's the tea 🍓 This document is not an Internet Standards Track specification. It's published for informational purposes only.
It's a product of the IETF, so it reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧐
Info about this document's current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6246 🔗
Copyright Notice
Copyright (c) 2011 IETF Trust and the people listed as the document's authors. All rights reserved 💖
This document falls under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read those carefully, because they spell out your rights and restrictions. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 🎀
This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright on some of that material may not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside that process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Table of Contents
1. Introduction ....................................................3
1.1. Conventions ................................................4
2. Ethernet Service Instance .......................................4
3. VPLS-Capable PE Model with Bridge Module ........................5
4. Mandatory Issues ................................................8
4.1. Service Mapping ............................................8
4.2. CE Bridge Protocol Handling ...............................10
4.3. Partial Mesh of Pseudowires ...............................11
4.4. Multicast Traffic .........................................12
5. Optional Issues ................................................13
5.1. Customer Network Topology Changes .........................13
5.2. Redundancy ................................................15
5.3. MAC Address Learning ......................................16
6. Interoperability with 802.1ad Networks .........................17
7. Acknowledgments ................................................17
8. Security Considerations ........................................17
9. Normative References ...........................................18
10. Informative References ........................................191. Introduction 💜
okay so VPLS is a LAN emulation service that's built to connect customer sites that are spread out across MANs/WANs (running over MPLS/IP), as if they were all plugged into one LAN 🦋 One of its biggest selling points is that it can connect not only customer routers and servers/hosts but also IEEE customer bridges. If you only need the customer's IP routers and hosts to talk to each other, an IP-only LAN Service [IPLS] solution could work instead. But the strength of VPLS is that it handles both bridge and non-bridge types of CE devices 🫶 It's supposed to give the same level of service that enterprise users already get from their own bridged networks [802.1D] [802.1Q] today, or the same level they get from Ethernet Service Providers running IEEE 802.1ad-based networks [802.1ad] (or the older QinQ-based networks that came before) ✨
When CE devices are IEEE bridges, there are some issues and challenges you have to account for in a VPLS network 😭 Most of these were already dealt with in the IEEE 802.1ad standard for provider bridges, so VPLS can borrow those solutions. This document builds on the PE model from [RFC4664] using the IEEE 802.1ad bridge module, and it draws a clear line between the IEEE bridge module and the IETF LAN emulation module. Because of that, it explains that most interoperability issues with CE bridges can be passed to the 802.1ad bridge module, which takes the load off the IETF LAN emulation module inside a VPLS PE 🙌 The document talks through these issues and, wherever it can, suggests areas to explore for fixing them. The detailed solution specs for these issues are out of scope for this doc 🌸
This document also covers interoperability issues between VPLS and IEEE 802.1ad networks, for when an end-to-end service crosses both kinds of networks, as outlined in [RFC4762] 🎀
This document sorts the CE-bridge issues into two groups: 1) mandatory and 2) optional. The issues in group (1) need to be addressed to make sure CE bridges work properly. The issues in group (2) add extra operational improvement and efficiency, but they may not be required for interoperability with CE bridges 🍓 Sections 5 and 6 discuss these mandatory and optional issues, respectively.
1.1. Conventions 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🧚
2. Ethernet Service Instance 🌈
Before we get into the bridging issues, we have to be clear about what "Ethernet Service" means, because VPLS means different things in different contexts 💅 In general, VPLS gets used in these contexts [RFC6136]: a) as an end-to-end bridged LAN service across one or more networks (one of which is an MPLS/IP network), b) as an MPLS/IP network that supports those bridged LAN services, and c) as (V)LAN emulation. To keep things clear, this document uses the terms VPLS network and VPLS instance to tell apart the network view and the service view. We also limit VPLS (both network and service) to just the part of the end-to-end network that crosses an MPLS/IP network. For an end-to-end service among different sites of a given customer, we use the term "Ethernet Service Instance" or ESI 💖
We define the Ethernet Service Instance (ESI) as an association of two or more Attachment Circuits (ACs) over which an Ethernet service is offered to a given customer. An AC can be a User-Network Interface (UNI) or a Network-Network Interface (NNI). It can also be an Ethernet interface or a VLAN, an ATM or Frame Relay Virtual Circuit, or a PPP/HDLC (PPP/High-Level Data Link Control) interface 🦋 If an ESI is associated with more than two ACs, then it's a multipoint ESI. In this document, wherever the keyword ESI shows up, it means a multipoint ESI unless it's stated otherwise ✨
An ESI can correspond to a VPLS instance if its associated ACs are only connected to a VPLS network. An ESI can also correspond to a Service VLAN if its associated ACs are only connected to a Provider-Bridged network [802.1ad]. And an ESI can be tied to both a VPLS instance and a Service VLAN when you're looking at an end-to-end service that spans both VPLS and Provider-Bridged networks 🫶 An ESI can even span different networks (like IEEE 802.1ad and VPLS) that belong to the same or to different administrative domains 🌸
An ESI most often represents a customer or a specific service that a customer asked for. Since keeping traffic isolated between different customers (or their services) is super important in service provider networks, the design shall provide a separate Media Access Control (MAC) address domain and broadcast domain per ESI 😭 A separate MAC address domain comes from using a separate MAC forwarding table per ESI, like a Forwarding Information Base (FIB), which is also known as a filtering database [802.1D], and this applies to both VPLS and IEEE 802.1ad networks 🙈 A separate broadcast domain comes from using a full mesh of pseudowires per ESI over the IP/MPLS core in a VPLS network, and/or from a dedicated Service VLAN per ESI in an IEEE 802.1ad network 👑
3. VPLS-Capable PE Model with Bridge Module 🎀
okay so [RFC4664] gives us three models for a VPLS-capable PE (VPLS-PE), and they're all about what bridging functionality the PE needs to support 💅 If the CE devices are routers/hosts or IEEE bridges, the second model from [RFC4664] is the most suitable one, bestie. It's adequate to provide the VPLS level of service AND it's consistent with the IEEE standards for Provider Bridges [802.1ad]. We'll quickly recap the second model, then level it up by breaking it into sub-components based on the [802.1ad] Provider Bridge model 🦋
As described in [RFC4664], the second model for VPLS-PE has a single bridge module that supports all the VPLS instances on that PE 🌸 Each VPLS instance is represented by a unique VLAN inside that bridge module (also known as a Service VLAN or S-VLAN). The bridge module has one "Emulated LAN" interface that it uses to talk to all the VPLS forwarders, and each VPLS instance is represented by a unique S-VLAN tag. Each VPLS instance can consist of a set of pseudowires, and its forwarder can correspond to a single VLAN, as shown in Figure 1 below. That's why it's sometimes called VLAN emulation ✨
+----------------------------------------+
| VPLS-Capable PE Model |
| +---------------+ +------+ |
| | | |VPLS-1|------------
| | |=======+ |Fwdr |------------ PWs
| | Bridge --------|--- |------------
| | | SVID-1| +------+ |
| | Module | | o |
| | | | o |
| | (802.1ad | | o |
| | bridge) | | o |
| | | | o |
| | | SVID-n| +------+ |
| | --------|---VPLS-n|-------------
| | |=======+ | Fwdr |------------- PWs
| | | ^ | |-------------
| +---------------+ | +------+ |
| | |
+-----------------------|----------------+
|
LAN emulation (multi-access) interface
Figure 1. VPLS-Capable PE ModelCustomer frames associated with a given ESI carry the S-VLAN ID for that ESI over the LAN emulation interface 💖 The S-VLAN ID gets stripped before the frames are sent over the set of pseudowires (PWs) associated with that VPLS instance (assuming raw mode PWs are used, as specified in [RFC4448]).
The bridge module can itself consist of one or two sub-components, depending on what functionality it needs to perform 🧚 Figure 2 shows the model for the bridge module based on [802.1ad].
+-------------------------------+
| 802.1ad Bridge Module Model |
| |
+---+ AC | +------+ +-----------+ |
|CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | |
| +------+ | | |
| o | S-VLAN | |
| o | | |
| o | Bridge | |
+---+ AC | +------+ | | |
|CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | |
| +------+ | | |
+---+ AC | | | |
|CE |-----------------------| | |
+---+ | +-----------+ |
+-------------------------------+
Figure 2. Model of the 802.1ad Bridge ModuleThe S-VLAN bridge component is always required, and it's responsible for tagging customer frames with S-VLAN tags in the ingress direction (from customer UNIs) and removing S-VLAN tags in the egress direction (toward customer UNIs) 💅 It also runs the provider's bridge protocol -- such as Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), Generic VLAN Registration Protocol (GVRP), GARP Multicast Registration Protocol (GMRP), etc. -- among provider bridges within a single administrative domain 👑
The customer VLAN (C-VLAN) bridge component is required when the customer Attachment Circuits are VLANs (aka C-VLANs) 🌈 In that case, the VPLS-capable PE needs to take part in some of the customer's bridging protocols, such as RSTP and MSTP. That participation is required because a C-VLAN at one site can be mapped into a different C-VLAN at a different site or, in the case of asymmetric mapping, a customer Ethernet port at one site can be mapped into a C-VLAN (or group of C-VLANs) at a different site 🫶
The C-VLAN bridge component does service selection and identification based on C-VLAN tags. Each frame from the customer device gets assigned to a C-VLAN and presented at one or more internal port-based interfaces, each supporting a single service instance that the customer wants to carry that C-VLAN on. Similarly, frames from the provider network get assigned to an internal interface or 'LAN' (e.g, between C-VLAN and S-VLAN components) based on the S-VLAN tag. Since each internal interface supports a single service instance, the S-VLAN tag can be, and is, removed at this interface by the S-VLAN bridge component. If multiple C-VLANs are supported by this service instance (e.g., via VLAN bundling or port-based service), then the frames will have already been tagged with C-VLAN tags. If a single C-VLAN is supported by this service instance (e.g., VLAN-based), then the frames will not have been tagged with a C-VLAN tag, since the C-VLAN can be derived from the S-VLAN (e.g., one-to-one mapping). The C-VLAN-aware bridge component applies a port VLAN ID (PVID) to untagged frames received on each internal 'LAN', which gives full control over the delivery of frames for each C-VLAN through the Customer UNI Port 🍓
4. Mandatory Issues ✨
4.1. Service Mapping ✨
okay so bestie, different Ethernet AC types can all be attached to a single Ethernet Service Instance (ESI) 💖. An ESI can be tied to only physical Ethernet ports, only VLANs, or a mix of both 🎀. Like, one end of the service could be physical ports while the other end is VLANs, and that's totally a thing 🦋. In [RFC4762], unqualified and qualified learning are the terms for port-based and VLAN-based operation, respectively 🌸. [RFC4762] doesn't really cover the possible mappings between different kinds of Ethernet ACs (like 802.1D, 802.1Q, or 802.1ad frames) 🤔.
Generally, mapping a customer port or VLAN to a given service instance is a local function done by the local PE, and the service provisioning shall accommodate it. In other words, there's no reason to limit an ESI to only port-based ACs or only VLAN-based ACs 🙅♀️. [802.1ad] lets each customer AC (a physical port, a VLAN, or a group of VLANs) get mapped independently to an ESI, which gives enterprise customers better service offerings 💅. For better, more flexible service offerings, and for interoperability between VPLS and 802.1ad networks, it is imperative that both networks offer the same capabilities when it comes to customer ACs mapping to the customer service instance 👑.
The table below lists the possible mappings between customer ACs and their associated ESIs. As you can see, there are several ways to do this 😭. In the first scenario, an Ethernet physical port only carries untagged traffic, and all of that traffic is mapped to the corresponding service instance or ESI. This is called "port-based with untagged traffic" 🍓. In the second scenario, an Ethernet physical port carries both tagged and untagged traffic, and all of it is mapped to the corresponding service instance or ESI. This is called "port-based with tagged and untagged traffic" 🌈. In the third scenario, only a single VLAN is mapped to the corresponding service instance or ESI. This is called "VLAN-based" ✨. Finally, in the fourth scenario, a group of VLANs from the Ethernet physical interface is mapped to the corresponding service instance or ESI. This is called "VLAN bundling" 🧚.
===================================================================
Ethernet I/F & Associated Service Instance(s)
-------------------------------------------------------------------
Port-based Port-based VLAN-based VLAN
untagged tagged & bundling
untagged
-------------------------------------------------------------------
Port-based Y N Y(Note-1) N
untagged
Port-based N Y Y(Note-2) Y
tagged &
untagged
VLAN-based Y(Note-1) Y(Note-2) Y Y(Note-3)
VLAN N Y Y(Note-3) Y
Bundling
===================================================================Note-1: In this asymmetric mapping scenario, the CE device with a "VLAN-based" AC is assumed to be capable of supporting the [802.1Q] frame format 🎀.
Note-2: In this asymmetric mapping scenario, the CE device with a "VLAN-based" AC is assumed to be able to support the [802.1ad] frame format 🫶. That's because it receives Ethernet frames with two tags: the outer tag is an S-VLAN and the inner tag is a C-VLAN received from the "port-based" AC. One example of such a CE device is a Broadband Remote Access Server (BRAS) used for DSL aggregation over a Metro Ethernet network 🌐.
Note-3: In this asymmetric mapping scenario, the CE device with a "VLAN-based" AC is assumed to be able to support the [802.1ad] frame format 💜. That's because it receives Ethernet frames with two tags: the outer tag is an S-VLAN and the inner tag is a C-VLAN received from the "VLAN bundling" AC.
If a PE uses an S-VLAN tag for a given ESI (either by adding an S-VLAN tag to customer traffic or by replacing a C-VLAN tag with an S-VLAN tag), then the frame format and EtherType for S-VLAN SHALL adhere to [802.1ad] 📦. No wiggle room there, bestie 🔥.
As mentioned before, the mapping function between the customer AC and its associated ESI is a local function. So when the AC is a single customer VLAN, it's possible to map different customer VLANs at different sites to a single ESI without coordinating among those sites 🦋.
When a port-based mapping or a VLAN-bundling mapping is used, the PE may use an additional S-VLAN tag to mark the customer traffic received over that AC as belonging to a given ESI 🏷️. If the PE uses that additional S-VLAN tag, then in the opposite direction the PE SHALL strip the S-VLAN tag before sending the customer frames over the same AC 🧹. However, when VLAN-mapping mode is used at an AC and the PE uses the S-VLAN tag locally, then if the Ethernet interface is a UNI, the tagged frames over this interface SHALL have a frame format based on [802.1Q] 🎀. In that case, the PE SHALL translate the customer tag (C-VLAN) into the provider tag (S-VLAN) when it receives a frame from the customer. In the opposite direction, the PE SHALL translate from the provider frame format (802.1ad) back to the customer frame format (802.1Q) 🔁.
All of the above asymmetric services can be supported via the PE model with the bridge module depicted in Figure 2 (based on [802.1ad]) 👑.
4.2. CE Bridge Protocol Handling 💅
When a VPLS-capable PE is connected to a CE bridge, then, depending on the type of Attachment Circuit, the bridge module of the PE may need different protocol handling 🧠. [802.1ad] says that when a PE is connected to a CE bridge, the service offered by the PE may appear to specific customer protocols running on the CE in one of four ways 🌸:
- a) Transparent to the operation of the protocol among CEs of different sites using the service provided, appearing as an individual LAN without bridges 🫧;
- b) Discarding frames, acting as a non-participating barrier to the operation of the protocol 🚧;
- c) Peering, with a local protocol entity at the point of provider ingress and egress, participating in and terminating the operation of the protocol; or 🤝
- d) Participation in individual instances of customer protocols 🧩.
All of the above CE bridge protocol handling can be supported via the PE model with the bridge module depicted in Figure 2 (based on [802.1ad]) ✨. For example, when an Attachment Circuit is port-based, the bridge module of the PE can operate transparently with respect to the CE's RSTPs or MSTPs (so no C-VLAN component is required for that customer UNI) 🦋. However, when an Attachment Circuit is VLAN-based (either VLAN-based or VLAN bundling), the bridge module of the PE needs to peer with the RSTPs or MSTPs running on the CE (so the C-VLAN bridge component is required) 🫶. In other words, when the AC is VLAN-based, protocol peering between CE and PE devices may be needed 🤝. There are also protocols that require peering but don't depend on the type of Attachment Circuit. One example is the link aggregation protocol [802.1AX]. However, as its name implies, this is a media-dependent protocol 🔗.
[802.1ad] reserves a block of 16 MAC addresses for the operation of C-VLAN and S-VLAN bridge components 🔐. It also shows which of these reserved MAC addresses are only for C-VLAN bridge components, which are only for S-VLAN bridge components, and which apply to both C-VLAN and S-VLAN components 🗺️.
4.3. Partial Mesh of Pseudowires 💀
A VPLS service depends on a full mesh of pseudowires, so a pseudowire failure reduces the underlying connectivity to a partial mesh, which can have adverse effects on the VPLS service 😱. If the CE devices belonging to an ESI are routers running link state routing protocols that use LAN procedures over that ESI, then a partial mesh of PWs can result in "black holing" traffic among the selected set of routers 🕳️. And if the CE devices belonging to an ESI are IEEE bridges, then a partial mesh of PWs can cause broadcast storms in the customer and provider networks 🌪️. It can also cause multiple copies of a single frame to be received by the CE and/or PE devices 👯. So it is of paramount importance to be able to detect PW failure and to take corrective action to prevent the creation of a partial mesh of PWs 🚨.
When the PE model depicted in Figure 2 is used, [802.1ag] procedures could be used to detect a partial mesh of PWs 🔍. [802.1ag] defines a set of procedures for fault detection, verification, isolation, and notification per ESI 🧭.
The fault detection mechanism of [802.1ag] can be used to perform connectivity checks among PEs belonging to a given VPLS instance 🛰️. It checks the integrity of a service instance end-to-end within an administrative domain, e.g., from one AC at one end of the network to another AC at the other end of the network 💫. So its path coverage includes the bridge module within a PE, and it isn't limited to just PWs 🙌. Furthermore, [802.1ag] operates transparently over the full mesh of PWs for a given service instance, since it operates at the Ethernet level (and not at the PW level) 🍰. It should be noted that since a PW consists of two unidirectional Label Switched Paths (LSPs), one direction can fail independently of the other 🙈. Even in this case, the procedures of [802.1ag] can provide a consistent view of the full mesh to the participating PEs by relying on remote defect indication (RDI) 🥹.
Another, less preferred, option is to define a procedure for detecting a partial mesh 🫤. In this procedure, each PE keeps track of the status of its PW Endpoint Entities (EEs, e.g., VPLS forwarders) as well as the EEs reported by other PEs 📋. So upon a PW failure, the PE that detects the failure not only takes notice locally, but also notifies the other PEs belonging to that service instance, so that all the participant PEs have a consistent view of the PW mesh 📣. This procedure detects a partial mesh per service instance, and in turn it relies on an additional procedure for PW failure detection, such as Bidirectional Forward Detection (BFD) or Virtual Circuit Connectivity Verification (VCCV) 🔧. Given that there can be tens (or even hundreds) of thousands of PWs in a PE, there can be scalability issues with these fault detection and notification procedures 📈💦.
4.4. Multicast Traffic 🦋
okay so VPLS does multicast with a centralized model inside an ESI 💅 It relies on ingress replication, which means the ingress PE makes a copy of the multicast packet for every egress PE and sends each copy over a point-to-point PW riding a unicast tunnel. VPLS runs on an overlay built from a full mesh of pseudo-wires, so depending on the underlying topology, the same datagram can go down the same physical link more than once 😭 VPLS also has no mechanism to limit where multicast or broadcast traffic of an ESI goes across the network. That's extra work for the ingress PE, extra load on the MPLS core, and extra processing at the receiving PE, which then has to throw away the extraneous multicast packets 💀
One possible fix is IGMP snooping, so the packet only goes to the PEs that actually have receivers for that traffic instead of every PE in the VPLS instance ✨ If the customer bridge or its network is dual-homed, then (for IGMP snooping to work properly) the PE must generate a "General Query" over that customer's UNIs when it gets a customer topology change notification, as described in [RFC4541]. That General Query is what gets the customer multicast MAC address(es) properly registered at the PE when the customer topology changes 🎀 Just know that IGMP snooping only solves the IP multicast case and doesn't apply to general multicast data 🙈
With IGMP snooping, the ingress PE can pick a subset of PWs for replication, so it stops sending multicast to egress PEs that don't need it. The replication still happens at the ingress PE though 😤 To get rid of ingress replication, you might want to use multicast distribution trees (MDTs) in the provider core, but that comes with some potential pitfalls 🫠 If one MDT carries all multicast traffic for a given customer, then customer multicast and unicast traffic end up on different PWs, and even on a different physical topology inside the provider network. That's a serious issue for customer bridges, because customer Bridge Protocol Data Units (BPDUs) are multicast data, so they can take a different path than the unicast data. You could end up in a situation where either unicast OR multicast connectivity is lost. If unicast dies but multicast keeps working, the customer spanning tree won't notice and its unicast traffic gets lost. If multicast dies but unicast is fine, the customer spanning tree will activate the blocked port, and that can make a loop in the customer network 😱 So the MDT cannot be used for both customer multicast control and data traffic. If it is used, it should only be limited to customer data traffic. Even then there's a potential issue, because the MDT doesn't fit the PE model in Figure 1 (it runs independently from the full mesh of PWs that correspond to an S-VLAN). It's also unclear how connectivity fault management (CFM) procedures (802.1ag), which are used for the ESI integrity check (e.g., per service instance), could check the integrity of customer multicast traffic over the provider MDT 🤔 Because of all these potential issues, the specific applications of the provider MDT to customer multicast traffic shall be documented, and its limitations be clearly specified 📝
5. Optional Issues 🌸
5.1. Customer Network Topology Changes 🧚
okay so a single CE or a customer network can connect to a provider network through more than one User-Network Interface (UNI). It can also connect to more than one provider network 🫶 [RFC4665] has some examples of this kind of customer connectivity, and they're shown in Figure 3 below. These topologies are built to protect against failure or removal of components in the customer network, and it's assumed that the customer uses the spanning tree protocol to protect against those cases. So in these scenarios, it's important to flush customer MAC addresses in the provider network whenever the customer topology changes, so that customer frames don't get black-holed 🕳️💅
+----------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+
| \ | | \ |
|Back \ | |Back \ +---------------
|door \ | SP network |door \ +---------------
|link \ | |link \ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+------------ +---------------
(a) (b)
Figure 3. Combination of Dual-Homing and Backdoor Links for
CE DevicesThe customer networks run their own spanning tree instances to configure and partition their active topology, so the provider connectivity doesn't create a data loop 🔁 But when a customer reconfigures its active topology, the customer end stations can seem to move from the PEs' point of view 👀 The provider bridge model in Figure 1 gives two ways to deal with this. In the first method, the Topology Change Notification (TCN) message from the CE device gets translated into one or more out-of-band "MAC Address Withdrawal" messages, as specified in [RFC4762]. In the second method, the TCN message from the CE device gets translated into one or more in-band "Flush" messages per [p802.1Qbe]. The second method is recommended, because it makes it easier for the bridge and LAN emulation modules of the PE to interoperate 🎀
5.2. Redundancy 👑
[RFC4762] talks about dual-homing a Multi-Tenant Unit switch (MTU-s) to two PEs over a provider MPLS access network, which protects against link and node failures 🛡️ For example, if the primary PE fails or its connection goes down, the MTU-s uses the backup PWs to reroute traffic to the backup PE. It also covers redundancy when a provider Ethernet access network is used, and how any arbitrary access network topology (not just hub-and-spoke) can be supported using the provider's MSTP protocol. It additionally explains how the provider MSTP for a given access network can be confined to that access network and run independently from the MSTP protocols in other access networks 🧠
In both kinds of redundancy mechanism (Ethernet and MPLS access networks), only one PE is active for a given VPLS instance at any time 🙌 With an Ethernet access network, the core-facing PWs (for a VPLS instance) at the PE get blocked by MSTP. With an MPLS access network, the access-facing PW gets blocked at the MTU-s for a given VPLS instance 🔒
------------------------+ Provider +-----------------------
. Core .
+------+ . . +------+
| PE |======================| PE |
Provider | (P) |---------\ /-------| (P) | Provider
Access +------+ . \ / . +------+ Access
Network . \/ . Network
(1) +------+ . /\ . +------+ (2)
| PE |----------/ \--------| PE |
| (B) |----------------------| (B) |
+------+ . . +------+
. .
------------------------+ +-----------------------
Figure 4. Bridge Module ModelFigure 4 shows two provider access networks, each with two PEs connected by a full mesh of PWs for a given VPLS instance. As the figure shows, only one PE in each access network acts as the Primary PE (P) for that VPLS instance, and the other PE is the backup PE (B). In this figure, each primary PE has two active PWs coming out of it. So when a multicast, broadcast, or unknown unicast frame arrives at the primary PE from the access network side, the PE replicates the frame over both PWs in the core, even though it only needs to send it over a single PW (shown with "==" in Figure 4) to the primary PE on the other side 😩 That's unnecessary replication of customer frames, and it eats core-network bandwidth (half of the frames get discarded at the receiving PE). It gets worse with more than two PEs per provider access network. With three PEs or four PEs per access network, 67% or 75% respectively of core-network bandwidth for multicast, broadcast, and unknown unicast gets wasted 💸
So it's recommended to have a protocol among PEs that can share the status of PWs (active or blocked) between them. It's also recommended to tie that protocol to the redundancy mechanism, so that (per VPLS instance) the active/backup status of a PE gets reflected on the corresponding PWs coming out of that PE 💖
Everything above was about the inefficiency of packet replication over MPLS core networks in the current VPLS redundancy mechanism. Another important thing to think about is how customer redundancy mechanisms interact with service provider redundancy mechanisms, especially when the customer devices are IEEE bridges 🍓 If CEs are IEEE bridges, they can run RSTPs or MSTPs. RSTP convergence and detection time is way faster than its predecessor (IEEE 802.1D STP, which is obsolete). So if the provider network offers a VPLS redundancy mechanism, it should be transparent to the customer's network during a failure inside the provider network. For example, the failure detection and recovery time within the service provider network should be less than the one in the customer network. If that's not the case, then a failure within the provider network can cause unnecessary switch-over and temporary flooding/loops inside the dual-homed customer network 🌈
5.3. MAC Address Learning 🧠
Okay so, when the customer devices are routers, servers, or hosts, each customer site only has a few MAC addresses, usually just one per CE. 🙈 But when the CEs are bridges, it gets wild, because there can be hundreds of customer MAC addresses behind each CE. 😭
[802.1ad] already came up with a trick to ease MAC address learning inside provider Ethernet networks, and it works just as well for VPLS networks. ✨ The trick says you turn off MAC address learning for an S-VLAN (or a service instance) inside a provider bridge (or PE) when only one ingress port and one egress port are associated with that service instance on that PE. 💅 Why? Because the path through that PE is already fixed, so there's no reason to learn customer MAC addresses there. For example, if a service instance is hooked up to four CEs at four different sites, then only three provider bridges (or PEs) ever need to take part in learning customer MAC addresses, no matter how many PEs are on that service instance's path. 🦋 This trick can cut down the number of MAC addresses learned in a hierarchical VPLS (H-VPLS) with QinQ access configuration. 🌸
If the provider access network is Ethernet (like an IEEE 802.1ad-based network), then MSTP can split the access network into several loop-free spanning tree topologies, and the Ethernet service instances (S-VLANs) get spread across those trees. 🧚 GVRP can then limit the scope of each service instance to a subset of its tree, which limits customer MAC address learning to that sub-tree. 💜 And then the MAC address disabling trick from above can be applied to that sub-tree too, so even fewer nodes (PEs) on it need to learn customer MAC addresses for that service instance. It's giving layers 🎀
Also, [802.1ah] lets you encapsulate customers' MAC addresses inside the provider MAC header. ✨ An MTU-s that can do this can seriously reduce the number of MAC addresses learned in the provider network, for both H-VPLS with QinQ access and H-VPLS with MPLS access. 👑
6. Interoperability with 802.1ad Networks 🌈
[RFC4762] talks about H-VPLS provider-network topologies that use both Ethernet [802.1ad] and MPLS access networks. 🫶 So it's really important that these two kinds of networks work together seamlessly. 💖
Provider bridges specified in [802.1ad] are meant to work seamlessly with customer bridges and to provide the required services. 🍓 So if a PE is modeled on Figures 1 and 2, which include an [802.1ad] bridge module, then it should work seamlessly with Provider Bridges, as long as the issues discussed in this document have been taken into account. ✨
7. Acknowledgments 🫶
The authors want to thank Norm Finn and Samer Salam for their comments and valuable feedback. 💜
8. Security Considerations 💀🔐
Okay, bestie, this section is serious. 😭 On top of the security issues described in [RFC4762], the following considerations apply:
- When a CE that is a customer bridge is connected to the VPLS network, it may be desirable to secure the end-to-end communication between the customer bridge nodes across the VPLS network. This can be accomplished by running [802.1AE] MAC security between the C-VLAN components of the customer bridges. In this case, the VPLS PEs must ensure transparent delivery of the encryption/security protocol datagrams using the Bridge Group Address [802.1ad].
- When a CE that is a customer bridge is connected to the VPLS network, it may be desirable to secure the communication between the customer bridge and its directly connected PE. If the PE is modeled to include an [802.1ad] bridge module, then this can be achieved by running MAC security between the customer bridge and the S-VLAN component of the VPLS PE, as described in Section 7.7.2 of [802.1AX].
- When an 802.1ad network is connected to a VPLS network, it is possible to secure the NNI between the two networks using the procedures of [802.1AE] and [802.1AX] between the S-VLAN components of the Provider Edge Bridge and the attached VPLS PE, as long as the PE is modeled to include an [802.1ad] bridge module. 🔥
9. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol
(LDP) Signaling", RFC 4762, January 2007.
[802.1ad] IEEE 802.1ad-2005, "Amendment to IEEE 802.1Q-2005. IEEE
Standard for Local and Metropolitan Area Networks -
Virtual Bridged Local Area Networks Revision-Amendment 4:
Provider Bridges".
[802.1AE] IEEE 802.1AE-2006, "IEEE Standard for Local and
Metropolitan Area Networks - Media Access Control (MAC)
Security".
[802.1ag] IEEE 802.1ag-2007, "IEEE Standard for Local and
Metropolitan Area Networks - Virtual Bridged Local Area
Networks Amendment 5: Connectivity Fault Management".
[802.1ah] IEEE 802.1ah-2008, "IEEE Standard for Local and
Metropolitan Area Networks - Virtual Bridged Local Area
Networks Amendment 7: Provider Backbone Bridges".
[802.1AX] IEEE 802.1AX-2008 "IEEE Standard for Local and
Metropolitan Area Networks - Link Aggregation".10. Informative References 🦋
[IPLS] Shah, H., Rosen, E., Le Faucheur, F., and G. Heron, "IP-
Only LAN Service (IPLS)", Work in Progress, February
2010.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over
MPLS Networks", RFC 4448, April 2006.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for
Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[RFC4665] Augustyn, W., Ed., and Y. Serbest, Ed., "Service
Requirements for Layer 2 Provider-Provisioned Virtual
Private Networks", RFC 4665, September 2006.
[RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual
Private Network (L2VPN) Operations, Administration, and
Maintenance (OAM) Requirements and Framework", RFC 6136,
March 2011.
[802.1D] IEEE 802.1D-2004, "IEEE Standard for Local and
Metropolitan Area Networks - Media access control (MAC)
Bridges (Incorporates IEEE 802.1t-2001 and IEEE 802.1w)".
[802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area
Networks".
[p802.1Qbe] IEEE Draft Standard P802.1Qbe, "IEEE Draft Standard for
Local and Metropolitan Area Networks -- Virtual Bridged
Local Area Networks Amendment: Multiple I-SID
Registration Protocol".Authors' Addresses 🎀
Ali Sajassi (editor)
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
EMail: sajassi@cisco.com
Frank Brockners
Cisco Systems, Inc.
Hansaallee 249
40549 Duesseldorf
Germany
EMail: fbrockne@cisco.com
Dinesh Mohan (editor)
Nortel
Ottawa, ON K2K3E5
EMail: dinmohan@hotmail.com
Yetik Serbest
AT&T Labs
9505 Arboretum Blvd.
Austin, TX 78759
EMail: yetik_serbest@labs.att.com📦 where this page comes from
- ietf: rfc6246 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms