RFC 7796
Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)
Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) 🦋
okay so this is RFC 7796 🎀 It's a Standards Track document from March 2016, written by Y. Jiang (Ed.), L. Yong, and M. Paul. Jiang and Yong are at Huawei, and Paul is at Deutsche Telekom. It's ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a fresh one 💅
Abstract 💖
this doc specifies a generic Virtual Private LAN Service (VPLS) solution that uses VLANs to tell root traffic apart from leaf traffic, so it can support Ethernet-Tree (E-Tree) services 🌸 A VPLS Provider Edge (PE) model is shown as an example. In the solution, E-Tree VPLS PEs are linked together by Pseudowires (PWs), and those PWs carry the VLAN that marks the E-Tree attribute. The MAC address-based Ethernet forwarding engine works the same way it does in RFC 4762, and the PW works the same way it does in RFC 4448. There's also a signaling mechanism for E-Tree capability and VLAN mapping negotiation 🧚
Status of This Memo 📜
this is an Internet Standards Track document ✨
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7796.
Copyright Notice 🌈
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. PE Model with E-Tree Support . . . . . . . . . . . . . . . . 5
4.1. Existing PE Models . . . . . . . . . . . . . . . . . . . 5
4.2. A New PE Model with E-Tree Support . . . . . . . . . . . 8
5. PW for E-Tree Support . . . . . . . . . . . . . . . . . . . . 9
5.1. PW Encapsulation . . . . . . . . . . . . . . . . . . . . 9
5.2. VLAN Mapping . . . . . . . . . . . . . . . . . . . . . . 10
5.3. PW Processing . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. PW Processing in the VLAN Mapping Mode . . . . . . . 11
5.3.2. PW Processing in the Compatible Mode . . . . . . . . 12
5.3.3. PW Processing in the Optimized Mode . . . . . . . . . 13
6. Signaling for E-Tree Support . . . . . . . . . . . . . . . . 14
6.1. LDP Extensions for E-Tree Support . . . . . . . . . . . . 14
6.2. BGP Extensions for E-Tree Support . . . . . . . . . . . . 17
7. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Other PE Models for E-Tree . . . . . . . . . . . . . 23
A.1. A PE Model with a VSI and No Bridge . . . . . . . . . . . 23
A.2. A PE Model with External E-Tree Interface . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 261. Introduction ✨
okay so the Ethernet-Tree (E-Tree) service is defined in the Metro Ethernet Forum (MEF) Technical Specification MEF 6.2 [MEF6.2] as a Rooted-Multipoint Ethernet Virtual Connection (EVC) service 💜 An MEF 6.2 E-Tree solution has to meet these design requirements: the Ethernet frames from a root may be received by any other root or leaf, and the frames from a leaf may be received by any root, but must not be received by a leaf. An E-Tree service can also include multiple roots and multiple leaves. Virtual Private Multicast Service (VPMS) [VPMS] and Point-to-Multipoint (P2MP) multicast are kinda simplified versions of this service. But honestly they're both multicast services, so they're different from an E-Tree service, which can include both unicast and multicast traffic 🙈
[RFC7152] gives the requirements for E-Tree solutions in VPLS and the need to filter leaf-to-leaf traffic. [RFC7387] goes further and describes a Multiprotocol Label Switching (MPLS) framework for providing E-Tree. There were proposals for using the Pseudowire (PW) control word, or PWs, to indicate the root/leaf attribute of an E-Tree frame. The catch is that both methods only work for "VPLS only" networks, so they're limited 😭
A VPLS PE usually contains a bridge module itself (see [RFC4664] and [RFC6246]). Plus, E-Tree services may cross both Ethernet and VPLS domains. So we need an E-Tree solution for both "VPLS only" scenarios and for interworking between Ethernet and VPLS 🌸
IEEE 802.1 has built the generic E-Tree solution into 802.1Q [IEEE-802.1Q-2014], and it's an upgrade on the old asymmetric VLAN mechanism. In the asymmetric VLAN mechanism, described in Section B.1.3 of IEEE 802.1Q [IEEE-802.1Q-2003], one VLAN ID marks the traffic from a server, and multiple VLAN IDs mark the traffic from the clients (one VLAN ID per client). In the new IEEE 802.1Q solution, only two VLANs are used to show the root/leaf attributes of a frame. One VLAN ID marks frames that originate from roots, and another VLAN ID marks frames that originate from leaves. At a leaf port, the bridge can then filter out all the frames from other leaf ports based on the VLAN ID. It's better to reuse this same mechanism in VPLS than to invent a new one, because a new mechanism would add more complexity when interworking with the new IEEE 802.1Q solution 🧠
This document specifies how the Ethernet VLAN solution can be used to support generic E-Tree services in VPLS. The solution here is fully compatible with the IEEE bridge architecture and with IETF Pseudowire Emulation Edge-to-Edge (PWE3) technology. That means it won't change the FIB (such as installing E-Tree attributes in the FIB) or need any specially tailored implementation. VPLS scalability and simplicity are also kept intact. With this mechanism, it's also convenient to deploy a converged E-Tree service across both Ethernet and MPLS networks 🦋
A typical VPLS PE model is introduced as an example. The model is then extended so that a Tree VSI connects to a VLAN bridge with a dual-VLAN interface.
This document then covers the PW encapsulation and PW processing, including the VLAN mapping options for transporting E-Tree services in VPLS.
Finally, this document describes the signaling extensions and processing procedures for E-Tree support in VPLS 🎀
2. Conventions Used in This Document 📝
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official requirement words, so read them carefully 🫶
3. Terminology 🧚
- AC: Attachment Circuit
- B-VLAN: Backbone VLAN
- C-VLAN: Customer VLAN
- E-Tree: Ethernet Tree, a Rooted-Multipoint EVC service as defined in [MEF6.2]
- EVC: Ethernet Virtual Connection, as defined in [MEF4]
- FIB: Forwarding Information Base, also known as "forwarding table"
- I-SID: Backbone Service Instance Identifier, as defined in IEEE 802.1ah [IEEE-802.1Q-2014]
- Leaf AC: An AC attached with a leaf
- Leaf VLAN: A VLAN Identifier (ID) used to indicate all the frames that are originated at a leaf AC. It may be a C-VLAN, an S-VLAN, or a B-VLAN
- OAM: Operations, Administration, and Maintenance
- PBB: Provider Backbone Bridge
- PE: Provider Edge
- PW: Pseudowire
- Root AC: An AC attached with a root
- Root VLAN: A VLAN ID used to indicate all the frames that are originated at a root AC. It may be a C-VLAN, an S-VLAN, or a B-VLAN
- S-VLAN: Service VLAN
- T-VSI: Tree VSI, a VSI with E-Tree support
- VLAN: Virtual Local Area Network
- VPLS: Virtual Private LAN Service
- VSI: Virtual Switching Instance as defined in [RFC4664], also known as "VPLS Forwarder" in [RFC7041]
4. PE Model with E-Tree Support 🌈
the problem scenario of E-Tree, shown in Figure 1 of [RFC7152], is a simplification of the L2VPN architecture. Several common VPLS PE architectures are discussed in more detail in [RFC4664] and [RFC6246].
Below, an E-Tree solution in VPLS is demonstrated with the help of a typical VPLS PE model. Its use in other PE models is discussed in Appendix A.
more parts are coming, bestie, so stay tuned 🎀💖
4.1. Existing PE Models 💅
Okay so, according to [RFC4664], there are at least three models possible for a VPLS PE, including:
- A single bridge module, a single VSI;
- A single bridge module, multiple VSIs;
- Multiple bridge modules, each attaches to a VSI.
The second PE model is commonly used. 🌸 A typical example is shown in Figure 1 and Figure 2 (both figures are extracted from [RFC6246]), where an S-VLAN bridge module is connected to multiple VSIs, each with a single VLAN virtual interface.
+-------------------------------+
| 802.1ad Bridge Module Model |
| |
+---+ AC | +------+ +-----------+ |
|CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | |
| +------+ | | |
| o | S-VLAN | |
| o | | | ---> to VSI
| o | Bridge | |
+---+ AC | +------+ | | |
|CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | |
| +------+ +-----------+ |
+-------------------------------+Figure 1: A Model of 802.1ad Bridge Module
+----------------------------------------+
| VPLS-Capable PE Model |
| +---------------+ +------+ |
| | | |VSI-1 |------------
| | |==========| |------------ PWs
| | Bridge ------------ |------------
| | | S-VLAN-1 +------+ |
| | Module | o |
| | | o |
| | (802.1ad | o |
| | bridge) | o |
| | | o |
| | | S-VLAN-n +------+ |
| | ------------VSI-n |-------------
| | |==========| |------------- PWs
| | | ^ | |-------------
| +---------------+ | +------+ |
| | |
+-------------------------|--------------+
LAN Emulation InterfaceFigure 2: A VPLS-Capable PE Model
In this PE model, Ethernet frames from Customer Edges (CEs) cross multiple stages of bridge modules (that is, the C-VLAN and S-VLAN bridges), and a VSI in a PE, before they're sent on the PW to a remote PE. ✨ That's why the association between an AC port and a PW on a VSI is difficult. 🙈
This model could be further enhanced. When Ethernet frames arrive at an ingress PE, a root VLAN or a leaf VLAN tag is added. At an egress PE, the frames with the root VLAN tag are transmitted both to the roots and the leaves, while the frames with the leaf VLAN tag are transmitted to the roots but dropped for the leaves. (These VLAN tags are removed before the frames are transmitted over the ACs.) It was demonstrated in [IEEE-802.1Q-2014] that the E-Tree service in Ethernet networks can be well supported with this mechanism. 🦋
Assuming this mechanism is implemented in the bridge module, it's quite straightforward to infer a VPLS PE model with two VSIs to support the E-Tree (as shown in Figure 3). But this model would require two VSIs per PE and two sets of PWs per E-Tree service, which is poorly scalable in a large MPLS/VPLS network. On top of that, both of these VSIs have to share their learned MAC addresses. 😭
+----------------------------------------+
| VPLS-Capable PE Model |
| +---------------+ +------+ |
| | | |VSI-1 |------------
| | |==========| |------------ PWs
| | Bridge ------------ |------------
| | | Root +------+ |
| | Module | S-VLAN |
| | | |
| | (802.1ad | |
| | bridge) | |
| | | Leaf |
| | | S-VLAN +------+ |
| | ------------VSI-2 |-------------
| | |==========| |------------- PWs
| | | ^ | |-------------
| +---------------+ | +------+ |
| | |
+-------------------------|--------------+
LAN Emulation InterfaceFigure 3: A VPLS PE Model for E-Tree with 2VSIs
4.2. A New PE Model with E-Tree Support 🎀
In order to support the E-Tree in a more scalable way, a new VPLS PE model with a single Tree VSI (T-VSI, a VSI with E-Tree support) is specified. As shown in Figure 4, the bridge module is connected to the T-VSI with a dual-VLAN virtual interface. In other words, both the root VLAN and the leaf VLAN are connected to the same T-VSI, and they share the same FIB and work in shared VLAN learning. 👑 This way, only one VPLS instance and one set of PWs is needed per E-Tree service, and the scalability of VPLS is improved.
+----------------------------------------+
| VPLS-Capable PE Model |
| +---------------+ +------+ |
| | |==========|TVSI-1|------------
+---+ AC | | ------------ |------------ PWs
|CE |--------| Bridge ------------ |------------
+---+ | | | Root & +------+ |
| | Module | Leaf VLAN o |
| | | o |
| | | o |
| | | o |
| | | o |
+---+ AC | | | VLAN-n +------+ |
|CE |--------| ------------VSI-n |-------------
+---+ | | |==========| |------------- PWs
| | | ^ | |-------------
| +---------------+ | +------+ |
| | |
+-------------------------|--------------+
LAN Emulation InterfaceFigure 4: A VPLS PE Model for E-Tree with a Single T-VSI
For an untagged AC port (frames over this port are untagged) or a VLAN unaware port (VLAN tags in the frames are ignored), where the bridge module is a C-VLAN bridge, the Ethernet frames received from the root ACs MUST be tagged with a root C-VLAN. When the bridge module is an 802.1ad bridge [IEEE-802.1Q-2014], the Ethernet frames received from the root ACs MUST be tagged with a root S-VLAN. Note, this can be done by adding a root C-VLAN first in a C-VLAN bridge, but this is out of the scope of this document. 💖
For a C-VLAN tagged port, the Ethernet frames received from the root ACs MUST be tagged with a root S-VLAN. 🍓
For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs SHOULD be translated to the root S-VLAN in the VPLS network domain. 🌈
Alternatively, for an S-VLAN tagged port, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE), as described in [RFC7041], MAY be used. A root B-VLAN or a leaf B-VLAN MAY be added. The E-Tree attribute may also be indicated with two I-SID tags in the bridge module, and the frames are then encapsulated and transported transparently over a single B-VLAN. So the PBB VPLS works in the same way as described in [RFC7041] and won't be discussed further in this document. When many S-VLANs are multiplexed in a single AC, PBB VPLS has the advantages of both VLAN scalability and MAC address scalability. 🧚
In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN, or B-VLAN. 💜
In all cases, the outermost VLAN in the resulting Ethernet header is used to indicate the E-Tree attribute of an Ethernet frame. This document uses "VLAN" to refer to this outermost VLAN for simplicity in the latter sections. ⭐
5. PW for E-Tree Support ✨
5.1. PW Encapsulation 🦋
To support an E-Tree service, T-VSIs in a VPLS MUST be interconnected with a bidirectional Ethernet PW. The Ethernet PW SHOULD work in the tagged mode (PW type 0x0004), as described in [RFC4448], in which case a VLAN tag MUST be carried in each frame in the PW to indicate whether the frame originated from a root or a leaf. (The VLAN tag indicating whether the frame originated from a root or a leaf can be translated by a bridge module in the PE, or added by an outside Ethernet edge device, even by a customer device.) In the tagged PW mode, two service-delimiting VLANs MUST be allocated in the VPLS domain for an E-Tree. PW processing for the tagged PW will be described in Section 5.3 of this document. 🔥
A raw mode PW (PW type 0x0005 in [RFC4448]) MAY also be used to carry an E-Tree service for a PW in Compatible mode, as shown in Section 5.3.2. As defined in [RFC4448], for a raw mode PW, an Ethernet frame's 802.1Q VLAN tag is not meaningful to the PEs, and it passes transparently through them. 🫶
5.2. VLAN Mapping 🌸
There are two ways of manipulating VLANs for an E-Tree in VPLS:
- Global VLAN based, that is, provisioning two global VLANs (Root VLAN and Leaf VLAN) across the VPLS network, so no VLAN mapping is needed at all, or the VLAN mapping is done completely in the Ethernet domains.
- Local VLAN based, that is, provisioning two local VLANs for each PE (that participates in the E-Tree) in the VPLS network independently.
The first method requires no VLAN mapping in the PW, but two unique service-delimiting VLANs must be allocated across the VPLS domain.
The second method is more scalable in the use of VLANs, but it needs a VLAN mapping mechanism in the PW, similar to what is already described in Section 4.3 of [RFC4448]. 🧁
Global or local VLANs can be manually configured or provisioned by an Operational Support System. Alternatively, some automatic VLAN allocation algorithm may be provided in the management plane, but that's out of scope of this document. 🙌
For both methods, VLAN mapping parameters from a remote PE can be provisioned or determined by a signaling protocol, as described in Section 6, when a PW is being established. 💅
5.3. PW Processing 🎀
5.3.1. PW Processing in the VLAN Mapping Mode 🦋
okay so VLAN mapping mode is where two VPLS PEs with E-Tree capability get interconnected with a PW. Figure 5 is the scenario where each PE has both root and leaf nodes hanging off it 💅
+----------------------------+
| VPLS PE with T-VSI |
| |
+----+ | +------+ Root VLAN +-----+ | PW
|Root|------| VLAN |-----------|T-VSI|----------
+----+ | | BRG | Leaf VLAN | |----------
+----+ | | |-----------| |----------
|Leaf|------| | | |-----+
+----+ | +------+ +-----+ | |
| | |
+----------------------------+ |
|
+----------------------------+ |
| VPLS PE with T-VSI | |
| | |
+----+ | +------+ Root VLAN +-----+ | | PW
|Root|------| VLAN |-----------|T-VSI|-----+
+----+ | | BRG | Leaf VLAN | |----------
+----+ | | |-----------| |----------
|Leaf|------| | | |----------
+----+ | +------+ +-----+ |
| | BRG: Bridge Module
+----------------------------+Figure 5: T-VSI Interconnected in the Normal Mode
If a PE is in the VLAN mapping mode for a PW, then in the data plane, the PE MUST map the VLAN in each frame like this:
- Sending on the PW: the PE maps from the local VLAN to the remote VLAN. So a local leaf VLAN gets translated to the remote leaf VLAN, and a local root VLAN gets translated to the remote root VLAN. 🌈
- Receiving on the PW: the PE maps from the remote VLAN back to the local VLAN. Then the frames are further forwarded or dropped in the egress bridge module using the filtering mechanism as described in [IEEE-802.1Q-2014]. ✨
The signaling for VLANs used by E-Tree is specified in Section 6. 🎀
5.3.2. PW Processing in the Compatible Mode 🌸
the new VPLS PE model can totally work in a traditional VPLS network in compatibility mode, no drama 🫶 As shown in Figure 6, the VPLS PE with T-VSI can be attached with root and/or leaf nodes, while the VPLS PE with a traditional VSI can only be attached with root nodes. A raw PW SHOULD be used to connect them.
+------------------------+
| VPLS PE with T-VSI |
| |
+----+ | +------+ +-----+ | PW
|Root|------| VLAN |-------|T-VSI|----------
+----+ | | BRG | | |----------
+----+ | | |-------| |----------
|Leaf|------| | | |---------+
+----+ | +------+ +-----+ | |
| | |
+------------------------+ |
|
+------------------------+ |
| VPLS PE with VSI | |
| | |
+----+ | +------+ +-----+ | PW |
|Root|------| VLAN |-------|VSI |---------+
+----+ | | BRG | | |----------
+----+ | | | | |----------
|Root|------| | | |----------
+----+ | +------+ +-----+ |
| |
+------------------------+Figure 6: T-VSI Interconnected with Traditional VSI
If a PE is in the Compatible mode for a PW, then in the data plane, the PE MUST process the frame like so:
- Sending on the PW: remove the root or leaf VLAN in the frames. 💖
- Receiving on the PW: add a VLAN tag with a value of the local root VLAN to the frames. 🦋
5.3.3. PW Processing in the Optimized Mode ✨
okay the vibe here is bandwidth efficiency 🍓 When two PEs (both with E-Tree capability) are inter-connected with a PW and one of them (e.g., PE2) is attached with only leaf nodes, as shown in the scenario of Figure 7, its peer PE (e.g., PE1) should then work in the Optimized mode for this PW. In this case, PE1 should not send the frames originated from the local leaf VLAN to PE2, i.e., these frames are dropped rather than transported over the PW. The bandwidth efficiency of the VPLS can thus be improved. The signaling for the PE attached with only leaf nodes is specified in Section 6. 💅
+------------------------+
|VPLS PE with T-VSI (PE1)|
| |
+----+ | +------+ +-----+ | PW
|Root|------| VLAN |-------|T-VSI|----------
+----+ | | BRG | | |----------
+----+ | | |-------| |----------
|Leaf|------| | | |---------+
+----+ | +------+ +-----+ | |
| | |
+------------------------+ |
|
+------------------------+ |
|VPLS PE with T-VSI (PE2)| |
| | |
+----+ | +------+ +-----+ | PW |
|Leaf|------| VLAN |-------|T-VSI|---------+
+----+ | | BRG | | |----------
+----+ | | |-------| |----------
|Leaf|------| | | |----------
+----+ | +------+ +-----+ |
| |
+------------------------+Figure 7: T-VSI Interconnected with PE Attached with Only Leaf Nodes
If a PE is in the Optimized Mode for a PW, upon transmit, the PE SHOULD drop a frame if its VLAN ID matches the local leaf VLAN ID. 🙈
6. Signaling for E-Tree Support 🧚
6.1. LDP Extensions for E-Tree Support 💜
okay so, in addition to the signaling procedures as specified in Section 5.3.3 of [RFC4447], this document specifies a new interface parameter sub-TLV to provision an E-Tree service and negotiate the VLAN mapping function. Here's the layout 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-Tree(0x1A) | Length=8 | Reserved |P|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | Root VLAN ID | MBZ | Leaf VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: E-Tree Sub-TLV
Where:
E-Treeis the sub-TLV identifier (0x1A) as assigned by IANA.Lengthis the length of the sub-TLV in octets.Reserved: bits MUST be set to zero on transmit and be ignored on receive.Pis a leaf-only bit. It is set to 1 to indicate that the PE is attached with only leaf nodes, and set to 0 otherwise. 🌸Vis a bit indicating the sender's VLAN mapping capability. A PE capable of VLAN mapping MUST set this bit, and clear it otherwise. 🍓MBZ(Must Be Zero): 4 bits MUST be set to zero on transmit and be ignored on receive.Root VLAN IDis the value of the local root VLAN.Leaf VLAN IDis the value of the local leaf VLAN.
When setting up a PW for the E-Tree based VPLS, two peer PEs negotiate the E-Tree support using the above E-Tree sub-TLV. Note that the PW type of 0x0004 SHOULD be used during the PW negotiation. 🦋
A PE that wishes to support an E-Tree service MUST include an E-Tree sub-TLV in its PW Label Mapping message, and include its local root VLAN ID and leaf VLAN ID in the TLV. A PE that has the VLAN mapping capability MUST set the V bit to 1, and a PE attached with only leaf nodes SHOULD set the P bit to 1. ✨
A PE that receives a PW Label Mapping message with an E-Tree sub-TLV from its peer PE, after saving the VLAN information for the PW, MUST process it as follows:
1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and
Optimized-Mode to FALSE.
2) If either the root VLAN ID in the message is not equal to the
local root VLAN ID, or the leaf VLAN ID in the message is not
equal to the local leaf VLAN ID {
If the bit V is cleared {
If the PE is capable of VLAN mapping, it MUST set
VLAN-Mapping-Mode to TRUE;
Else {
A Label Release message with the error code "E-
Tree VLAN mapping not supported" is sent to the
peer PE and exit the process;
}
}
If the bit V is set, and the PE is capable of VLAN mapping,
the PE with the minimum IP address MUST set
VLAN-Mapping-Mode to TRUE;
}
3) If the P bit is set
{
If the PE is a leaf-only node itself, a Label Release
message with a status code "Leaf-to-Leaf PW released" is
sent to the peer PE and exits the process;
Else the PE SHOULD set the Optimized-Mode to TRUE.
}A PE SHOULD send a Label Mapping message with an E-Tree sub-TLV as per Section 5.3.3 of [RFC4447]. A PE MUST send a Label Mapping message with an updated E-Tree sub-TLV to all other PEs over corresponding LDP sessions when its role changes from leaf-only to not leaf-only (i.e., when a root node is added to a PE attached with only leaf nodes). 🌈
If a PE has sent a Label Mapping message with an E-Tree sub-TLV but does not receive any E-Tree sub-TLV in its peer's PW Label Mapping message, the PE SHOULD then establish a raw PW with this peer as in traditional VPLS, and set Compatible-Mode to TRUE for this PW. 💅
Data plane processing for this PW is as follows:
- If
Optimized-ModeisTRUE, then data plane processing as described in Section 5.3.3 applies. - If
VLAN-Mapping-ModeisTRUE, then data plane processing as described in Section 5.3.1 applies. - If
Compatible-ModeisTRUE, then data plane processing as described in Section 5.3.2 applies. - PW processing as described in [RFC4448] proceeds as usual for all cases. 🫶
When VPLS is set up using the Pseudowire ID (PWid) Forwarding Equivalence Class (FEC) Element (see Appendix A of [RFC4762]), its E-Tree signaling is similar to the above process. Dynamic re-configuration of E-Tree should be avoided for this case. However, when re-configuration of E-Tree is forced on a PE for some reason (e.g., a configuration error), the PE may close the LDP sessions with its peer PEs for this VPLS instance and re-install its PW labels, so that its peer PEs can send out the LDP Label Mapping messages again. 😭
6.2. BGP Extensions for E-Tree Support ✨
Okay bestie, BGP gets its own E-Tree extended community 🎀, and IANA allocated 0x800b for E-Tree signaling in BGP VPLS. Here's the layout:
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| MBZ | Root VLAN (12 bits) |
+------------------------------------+
| MBZ | Leaf VLAN (12 bits) |
+------------------------------------+
| Reserved |P|V|
+------------------------------------+
Figure 9: E-Tree Extended CommunityHere's what each piece means 💅:
- Must Be Zero (MBZ), 4 bits MUST be set to zero on transmit and be ignored on receive.
- Root VLAN ID is the value of the local root VLAN.
- Leaf VLAN ID is the value of the local leaf VLAN.
- Reserved, 14 bits MUST be set to zero on transmit and be ignored on receive.
- P is a leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaf nodes, and set to 0 otherwise.
- V is a bit indicating the sender's VLAN mapping capability. A PE capable of VLAN mapping MUST set this bit, and clear it otherwise.
Now the vibes 🫶. PEs with both leaf and root nodes MUST support BGP E-Tree signaling as described in this document, and SHOULD support VLAN mapping in their data planes. A traditional PE with only root nodes may also participate in an E-Tree service. If some PEs don't support VLAN mapping, global VLANs as per Section 5.2 MUST be provisioned for an E-Tree service, no exceptions 😭.
In BGP VPLS signaling, you attach a Layer2 Info Extended Community as detailed in [RFC4761], and an E-Tree Extended Community MUST be further attached if a PE wants in on an E-Tree service 🦋. The PE MUST include its local root VLAN ID and leaf VLAN ID in the E-Tree Extended Community. A PE attached with only leaf nodes of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to 1.
A PE that receives a BGP UPDATE message with an E-Tree Extended Community from its peer PE, after saving the VLAN information for the PW, MUST process it as follows (after processing procedures as specified in Section 3.2 of [RFC4761]):
1) For this PW, set VLAN-Mapping-Mode, Compatible-Mode, and
Optimized-Mode to FALSE.
2) If either the root VLAN ID in the E-Tree Extended Community is
not equal to the local root VLAN ID, or the leaf VLAN ID in the
E-Tree Extended Community is not equal to the local leaf VLAN ID {
If the bit V is cleared {
If the PE is capable of VLAN mapping, it MUST set VLAN-
Mapping-Mode to TRUE;
Else {
Log with a message "E-Tree VLAN mapping not
supported" and exit the process;
}
}
If the bit V is set, and the PE is capable of VLAN mapping,
the PE with the minimum IP address MUST set VLAN-Mapping-Mode
to TRUE;
}
3) If the P bit is set {
If the PE is a leaf-only PE itself, forbids any traffic on the
PW;
Else the PE SHOULD set the Optimized-Mode to TRUE.
}A PE that doesn't recognize this attribute SHALL ignore it silently 🙈. If a PE has sent an E-Tree Extended Community but doesn't get any E-Tree Extended Community back from its peer, it SHOULD then establish a raw PW with this peer as in traditional VPLS and set Compatible-Mode to TRUE for this PW.
The data plane in the VPLS is the same as described in Section 4.2 of [RFC4761], and data plane processing for a PW is the same as described at the end of Section 6.1 in this document. Easy 🌸.
7. OAM Considerations ✨
The VPLS OAM requirements and framework as specified in [RFC6136] are applicable to E-Tree, because Ethernet OAM frames and data traffic both travel over the same PW 🧚.
Ethernet OAM for E-Tree, including both service OAM and segment OAM frames, SHALL undergo the same VLAN mapping as the data traffic. Also, root VLAN SHOULD be applied to segment OAM frames so they don't get filtered 💜.
8. Applicability ✨
The solution in this document applies to both LDP VPLS [RFC4762] and BGP VPLS [RFC4761] 🍓.
It works for both "VPLS Only" networks and VPLS with Ethernet aggregation networks.
It also applies to PBB VPLS networks.
9. IANA Considerations ✨
IANA allocated the following value for E-Tree in the "Pseudowire Interface Parameters Sub-TLV type Registry":
Parameter ID Length Description
=======================================
0x1A 8 E-TreeIANA also allocated the two following new LDP status codes in the "Status Code Name Space" registry:
Range/Value E Description
------------- ----- ----------------------
0x20000003 1 E-Tree VLAN mapping not supported
0x20000004 0 Leaf-to-Leaf PW releasedLast one 🌈. IANA allocated the following value for E-tree in the "Generic Transitive Experimental Use Extended Community Sub-Types" registry within the BGP Extended Community registry:
Type Value Sub-Type Value Name
========== ============== ============
0x80 0x0b E-Tree Info10. Security Considerations ✨
⚠️ Big security moment, bestie. This solution requires implementations to prevent leaf-to-leaf communication in the data plane of VPLS when its PEs are interconnected with PWs. If all PEs enforce that, then network attacks from one leaf to another leaf are avoided, and security can be enhanced for customers with this solution.
However, if a PE is compromised or inappropriately configured, a leaf node may be taken as a root node and may receive traffic from other leaf nodes inappropriately 💀. Authenticity and integrity measures for LDP need to be considered as in RFC 5036 [RFC5036]. Security considerations as described in [RFC4448], [RFC4761], and [RFC4762] also apply.
11. References ✨
11.1. Normative References
[IEEE-802.1Q-2014]
IEEE, "Bridges and Bridged Networks", IEEE 802.1Q,
DOI 10.1109/ieeestd.2014.6991462, November 2014.
[MEF6.2] Metro Ethernet Forum 6.2, "EVC Ethernet Services
Definitions Phase 3", August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<http://www.rfc-editor.org/info/rfc4448>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.11.2. Informative References
[IEEE-802.1Q-2003]
IEEE, "Virtual Bridged Local Area Networks", IEEE 802.1,
DOI 10.1109/IEEESTD.2003.94280, May 2003.
[MEF4] Metro Ethernet Forum 4, "Metro Ethernet Network
Architecture Framework - Part 1: Generic Framework", May
2004.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006,
<http://www.rfc-editor.org/info/rfc4664>.
[RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual
Private Network (L2VPN) Operations, Administration, and
Maintenance (OAM) Requirements and Framework", RFC 6136,
DOI 10.17487/RFC6136, March 2011,
<http://www.rfc-editor.org/info/rfc6136>.
[RFC6246] Sajassi, A., Ed., Brockners, F., Mohan, D., Ed., and Y.
Serbest, "Virtual Private LAN Service (VPLS)
Interoperability with Customer Edge (CE) Bridges",
RFC 6246, DOI 10.17487/RFC6246, June 2011,
<http://www.rfc-editor.org/info/rfc6246>.
[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
"Extensions to the Virtual Private LAN Service (VPLS)
Provider Edge (PE) Model for Provider Backbone Bridging",
RFC 7041, DOI 10.17487/RFC7041, November 2013,
<http://www.rfc-editor.org/info/rfc7041>.
[RFC7152] Key, R., Ed., DeLord, S., Jounay, F., Huang, L., Liu, Z.,
and M. Paul, "Requirements for Metro Ethernet Forum (MEF)
Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private
Network (L2VPN)", RFC 7152, DOI 10.17487/RFC7152, March
2014, <http://www.rfc-editor.org/info/rfc7152>.
[RFC7387] Key, R., Ed., Yong, L., Ed., Delord, S., Jounay, F., and
L. Jin, "A Framework for Ethernet Tree (E-Tree) Service
over a Multiprotocol Label Switching (MPLS) Network",
RFC 7387, DOI 10.17487/RFC7387, October 2014,
<http://www.rfc-editor.org/info/rfc7387>.
[VPMS] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", Work in Progress,
draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012.Appendix A. Other PE Models for E-Tree ✨
A.1. A PE Model with a VSI and No Bridge 🌸
okay bestie, so if a PE doesn't have a bridge module, it can be built out of Native Service Processors (NSPs) instead, like in Figure 10 (adapted from Figure 5 of [RFC3985]). The NSPs can do any VLAN transformation (think VLAN insertion/removal or VLAN mapping) 💅. That means an NSP can add a root VLAN or a leaf VLAN depending on whether the UNI (root or leaf) on the AC the packet came in on is root or leaf ✨
also, when a packet with a leaf VLAN leaves a forwarder and shows up at the NSP, the NSP must drop it if the egress AC is tied to a leaf UNI 🙅♀️ no exceptions, periodt 💀
tagged PW and VLAN mapping work the exact same way they do in the typical PE model 🦋
+----------------------------------------+
| PE Device |
Multiple+----------------------------------------+
AC | | | Single | PW Instance
<------>o NSP # + PW Instance X<---------->
| | | |
|------| VSI |----------------------|
| | | Single | PW Instance
<------>o NSP #Forwarder + PW Instance X<---------->
| | | |
|------| |----------------------|
| | | Single | PW Instance
<------>o NSP # + PW Instance X<---------->
| | | |
+----------------------------------------+
Figure 10: A PE Model with a VSI and No Bridge Modulethis PE model is giving "keep it simple" 🧚 it can be used by a Multi-Tenant Unit switch (MTU-s) in a Hierarchical VPLS (H-VPLS) network, or by a Network-facing PE (N-PE) in an H-VPLS network with non-bridging edge devices. in that setup, a spoke PW can be treated as an AC 🌈
A.2. A PE Model with External E-Tree Interface 🫶
+----------------------------------------+
| PE Device |
Root +----------------------------------------+
VLAN | | Single | PW Instance
<------>o + PW Instance X<---------->
| | |
| VSI |----------------------|
| | Single | PW Instance
| Forwarder + PW Instance X<---------->
| | |
Leaf | |----------------------|
VLAN | | Single | PW Instance
<------>o + PW Instance X<---------->
| | |
+----------------------------------------+
Figure 11: A PE Model with External E-Tree Interfaceok so this one is the simplified version, and it's lowkey so cute ✨ A.2 shows Root/Leaf VLANs getting connected, directly or indirectly, over a single PW to the same VSI forwarder in a PE. any transformation of E-Tree VLANs (like VLAN insertion/removal or VLAN mapping) can be done by some outer equipment, and then the PE can translate those VLANs into its own local VLANs 🎀
this model may be used by an N-PE in an H-VPLS network with bridging-capable devices, or in situations like providing E-Tree Network-to-Network interfaces 👑
Acknowledgements 💖
the authors wanna give a huge shoutout to Stewart Bryant, Lizhong Jin, Deborah Brungard, Russ Housley, Stephen Farrell, Sheng Jiang, Alvaro Retana, and Ben Campbell for their detailed reviews and suggestions 🙌 and to Adrian Farrel, Susan Hares, Shane Amante, and Andrew Malis for their valuable advice 🌷 also, big thanks to Ben Mack-crane, Edwin Mallette, Donald Fedyk, Dave Allan, Giles Heron, Raymond Key, Josh Rogers, Sam Cao, and Daniel Cohn for their valuable comments and discussions 🫶😭
Contributors 🧚
these people made significant contributions to this document, and they're all absolute legends 👑
Frederic Jounay
Salt Mobile SA
Rue du Caudray 4
1020 Renens
Switzerland
Email: frederic.jounay@salt.chFlorin Balus
Alcatel-Lucent
701 East Middlefield Road
Mountain View, CA 94043
United States
Email: florin.balus@alcatel-lucent.comWim Henderickx
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp
Belgium
Email: wim.henderickx@alcatel-lucent.comAli Sajassi
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
Email: sajassi@cisco.comAuthors' Addresses 🎀
Yuanlong Jiang (editor)
Huawei
Bantian, Longgang district
Shenzhen 518129
China
Email: jiangyuanlong@huawei.comLucy Yong
Huawei
207 Estrella Xing
Georgetown, TX 78628
United States
Email: lucyyong@huawei.comManuel Paul
Deutsche Telekom
Winterfeldtstrasse 21
Berlin 10781
Germany
Email: manuel.paul@telekom.de📦 where this page comes from
- ietf: rfc7796 2016-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms