RFC 7361
LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)
RFC 7361: LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) 🎀
- Authors: P. Dutta (Alcatel-Lucent), F. Balus (Alcatel-Lucent), O. Stokes (Extreme Networks), G. Calvignac (Orange), D. Fedyk (Hewlett-Packard)
- Category: Standards Track ✨
- ISSN: 2070-1721
- Date: September 2014 📅
- Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🌸
Abstract 💜
Okay, so [RFC4762] (written as "RFC 4762" here, just like the original) describes how to remove or unlearn MAC addresses that were dynamically learned in a Virtual Private LAN Service (VPLS) instance. The whole point is faster convergence when the topology changes 🦋. The catch is that the old procedure also wipes MAC addresses that didn't need relearning at all, which is a bit much, ngl 💀.
This document adds an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762). With it, a Provider Edge (PE) device can remove only the MAC addresses that need relearning. Main character energy 👑. On top of that, there are extra extensions to the RFC 4762 MAC withdraw procedures for optimized MAC flushing in the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041 🧚.
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, and it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🌈.
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7361 🫶.
Copyright Notice 🔥
Copyright (c) 2014 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) as they're in effect on the date of publication. Please actually read these, bestie, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🍓.
Table of Contents 🦋
1. Introduction ....................................................4
2. Terminology .....................................................6
2.1. Requirements Language ......................................6
3. Overview ........................................................6
3.1. MAC Flushing on Activation of Backup Spoke PW ..............8
3.1.1. MAC Flushing Initiated by PE-rs .....................8
3.1.2. MAC Flushing Initiated by MTU-s .....................8
3.2. MAC Flushing on Failure ....................................9
3.3. MAC Flushing in PBB-VPLS ..................................10
4. Problem Description ............................................10
4.1. MAC Flushing Optimization in VPLS Resiliency ..............10
4.1.1. MAC Flushing Optimization for Regular H-VPLS .......11
4.1.2. MAC Flushing Optimization for Native Ethernet
Access .............................................13
4.2. Black-Holing Issue in PBB-VPLS ............................13
5. Solution Description ...........................................14
5.1. MAC Flushing Optimization for VPLS Resiliency .............14
5.1.1. MAC Flush Parameters TLV ...........................15
5.1.2. Application of the MAC Flush TLV in
Optimized MAC Flushing .............................16
5.1.3. MAC Flush TLV Processing Rules for Regular VPLS ....17
5.1.4. Optimized MAC Flush Procedures .....................18
5.2. LDP MAC Flush Extensions for PBB-VPLS .....................19
5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS ........20
5.2.2. Applicability of the MAC Flush Parameters TLV ......22
6. Operational Considerations .....................................23
7. IANA Considerations ............................................24
7.1. New LDP TLV ...............................................24
7.2. New Registry for MAC Flush Flags ..........................24
8. Security Considerations ........................................24
9. Contributing Author ............................................25
10. Acknowledgements ..............................................25
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................251. Introduction ✨
Virtual Private LAN Service (VPLS), also called Transparent LAN Services (TLS), is described in [RFC4762] 🌸. A VPLS is built from a bunch of point-to-point pseudowires (PWs) [RFC4664] arranged in a flat, full-mesh topology. That mesh gives you a LAN segment, or broadcast domain, that can fully learn and forward on Ethernet Media Access Control (MAC) addresses at the Provider Edge (PE) devices. It's giving LAN party energy 🎉.
You can bolt extra non-meshed spoke nodes onto that full-mesh core to get a Hierarchical VPLS (H-VPLS) service [RFC4762]. In this document, that setup is called "regular" H-VPLS 💖.
[RFC7041] explains how Provider Backbone Bridging (PBB) can be integrated with VPLS. You get useful PBB features while still avoiding the Multiple Spanning Tree Protocol (MSTP) in the backbone 🦋. The combined solution is called "PBB-VPLS". Depending on where the I-component sits in the PBB-VPLS topology, it scales better in terms of the number of service instances, PWs, and C-MAC (Customer MAC) addresses the VPLS PEs have to handle 🍓.
RFC 4762 also describes a MAC address withdrawal mechanism for VPLS, used to remove or unlearn MAC addresses so things converge faster when the topology changes in resilient H-VPLS setups 🧚. Heads up: the H-VPLS topology in [RFC4762] treats the two-tier hierarchy as the basic building block of H-VPLS, but an H-VPLS can also have a multi-tier hierarchy 👑.
Figure 1 is copied from [RFC4762] and shows dual-homing in H-VPLS 🌈.
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | Primary PW | -- |---/ |
| / \ |- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ \ |
/ \ +--------+
/ \ | |
CE-2 \ | -- |
\ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / |
| -- |
+--------+
PE3-rs
Figure 1: An Example of a Dual-Homed MTU-sThe MAC flushing mechanism shows up in dual-homed H-VPLS, where an edge device called the Multi-Tenant Unit switch (MTU-s) [RFC4762] connects to two PE devices, one through a primary spoke PW and one through a backup spoke PW 🫶. That redundancy protects against failure of the primary spoke PW or the primary PE device. There can be more ways to dual-home in H-VPLS than the ones described in [RFC4762]. For example, check out this bit from Section 10.2.1 of [RFC4762] 👀:
How a spoke is designated primary or secondary is outside the
scope of this document. For example, a spanning tree instance
running between only the MTU-s and the two PE-rs nodes is one
possible method. Another method could be configuration.This document is here to clarify several H-VPLS dual-homing models that are used in practice, plus the different ways LDP-based MAC flushing gets used in those models 💅.
2. Terminology 📚
This document uses the terminology defined in [RFC7041], [RFC5036], [RFC4447], and [RFC4762] 🌸.
Throughout this document, "Virtual Private LAN Service" (VPLS) refers to the emulated bridged LAN service offered to a customer. "H-VPLS" refers to the hierarchical connectivity or layout of the MTU-s and the Provider Edge routing- and switching-capable (PE-rs) devices that offer the VPLS [RFC4762] 💖.
"spoke node" and "MTU-s" in H-VPLS are used interchangeably. Same vibe, different name 🦋.
"Spoke PW" refers to the Pseudowire (PW) that provides connectivity between MTU-s and PE-rs nodes 🍓.
"Mesh PW" refers to the PW that provides connectivity between PE-rs nodes in a VPLS full-mesh core 🧚.
"MAC flush message" refers to a Label Distribution Protocol (LDP) address withdraw message without a MAC List TLV 🔥.
A MAC flush message "in the context of a PW" refers to the message that was received over the LDP session used to set up the PW that provides connectivity in VPLS. The MAC flush message carries the context of the PW through the Forwarding Equivalence Class (FEC) TLV associated with the PW [RFC4762] [RFC4447] 👑.
In general, "MAC flushing" refers to the method of initiating and processing MAC flush messages across a VPLS instance 🌈.
2.1. Requirements Language 🎀
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] ✨.
3. Overview ✨
Okay so when the MTU-s switches over to the backup PW, the big requirement is to flush the MAC addresses learned in the matching Virtual Switch Instance (VSI) on the peer PE devices in the full mesh 💅. If nobody flushes them, frames headed to those addresses get black-holed, and that is a total mess 😭. The fix is an LDP address withdraw message (a brand-new message defined in this document 🎀) sent from the PE that's no longer connected to the MTU-s with the primary PW. The new message carries a list of MAC addresses to remove and goes out to all the other PEs over the corresponding LDP sessions.
Lots of implementations want to keep LDP convergence time and scalability in check when a MAC List TLV has a ton of MAC addresses in it, so they send an LDP address withdraw message with an empty MAC list instead 🧚. The catch is that when a PE-rs switch in the full mesh of H-VPLS gets this message, it also flushes MAC addresses the topology change didn't touch, which causes unnecessary flooding and relearning 🙈. Throughout this document, "MAC flush message" means an LDP address withdraw message with an empty MAC list, as described in [RFC4762]. The solutions in this document only apply to LDP address withdraw messages with empty MAC lists.
In a VPLS topology, the core PWs stay active and learning happens on the PE-rs nodes. But when the VPLS topology changes, the PE-rs has to relearn using MAC address withdrawal or flushing 🔄. Under the MAC address withdrawal processing rules in [RFC4762], a PE device that gets a MAC flush message removes all MAC addresses tied to the specified VPLS instance (as indicated in the FEC TLV) except the ones learned over the PW linked to the signaling session the message arrived on 👑. We call this "positive" MAC flushing, or "flush-all-but-mine" ✨.
This document introduces an optimized "negative" MAC flush message, described in Section 3.2, that can be configured to improve how topology changes are handled in a bunch of Ethernet topologies where the Service Level Agreement (SLA) depends on minimal disruption and fast restoration of affected traffic 🦋. This new message is used in Provider Backbone Bridging (PBB) topologies to limit the flushing to a set of service instances (I-SIDs). Also super important: the MAC flush message from [RFC4762] (which this document calls "a positive MAC flush message") MUST always be handled for Backbone MACs (B-MACs) when the core nodes change or fail 🚨. In dual-homed or multi-homed edge topologies, the procedures here augment [RFC4762] messages and cause less disruption in those cases 💖.
3.1. MAC Flushing on Activation of Backup Spoke PW
Okay, this section is all about the situations where MAC flush withdrawal kicks off when a backup PW in H-VPLS gets activated 🌸.
3.1.1. MAC Flushing Initiated by PE-rs
[RFC4762] says that when the primary PW fails, it's PE3-rs (Figure 1) that starts MAC flushing towards the core. Ngl, though, PE3-rs can only start MAC flushing if it's dual-homing "aware", meaning some redundancy management protocol is running between the MTU-s and its host PE-rs devices 🧠. The scope of this document applies to several dual-homing or multi-homing protocols. It also shows that multi-homing gets better with negative MAC flushing. One example is BGP-based multi-homing in LDP-based VPLS, which uses the procedures defined in [VPLS-MH]. In this method of dual-homing, PE3-rs would neither forward any traffic to the MTU-s nor receive any traffic from the MTU-s while PE1-rs is acting as a primary (or designated forwarder) 🫶.
3.1.2. MAC Flushing Initiated by MTU-s
When dual-homing is set up by manual configuration in the MTU-s, the hosting PE-rs devices are dual-homing "agnostic", so PE3-rs can't start MAC flush messages 🙅♀️. PE3-rs can still send or receive traffic over the backup PW, since the dual-homing control lives only in the MTU-s. When the MTU-s makes the backup PW active, the MTU-s triggers a MAC flush message 🔥. That message goes out over the LDP session tied to the newly activated PW. When PE3-rs (the PE-rs device with a now-active PW) gets the MAC flush message from the MTU-s, it flushes all the MAC addresses it has learned, except the ones learned over the newly activated spoke PW. PE3-rs then starts a MAC flush message to all the other PE devices in the core. Also, a forced switchover to the backup PW can be triggered by the MTU-s because of maintenance or administrative activities on the former primary spoke PW 🛠️.
This MTU-s-initiated MAC flushing is modeled after the Topology Change Notification (TCN) in the Rapid Spanning Tree Protocol (RSTP) [IEEE.802.1Q-2011] 🌳. When a bridge switches from a failed link to the backup link, it sends a TCN message over the newly activated link. When the upstream bridge gets that message, it flushes its entire list of MAC addresses, except the ones received over this link. Then the upstream bridge sends the TCN message out of its other ports in that spanning tree instance. The other bridges keep relaying the message along the spanning tree 🔁.
The MAC flushing info gets propagated in the control plane 🎛️. The control-plane message propagation is tied to the data path, so it follows propagation rules similar to the ones used for forwarding in the LDP data plane. For example, PE-rs nodes follow the data-plane "split-horizon" forwarding rules in H-VPLS (refer to Section 4.4 of [RFC4762]) 🪞. So a MAC flush message gets propagated in the context of mesh PW(s) when it was received in the context of a spoke PW. When a PE-rs node receives a MAC flush message in the context of a mesh PW, it does not get propagated to other mesh PWs 🚫.
3.2. MAC Flushing on Failure
MAC flushing on failure, also known as "negative" MAC flushing, is introduced in this document 🎉. Negative MAC flushing is an upgrade on the current practice of sending a MAC flush message with an empty MAC list, as described in Section 3.1.1. We call this "negative" MAC flushing or "flush-all-from-me" 🙋♀️, as opposed to the "positive" MAC flush action in [RFC4762]. With negative MAC flushing, PE1-rs (Figure 1) starts the flushing when it detects a failure of the primary spoke PW. The MAC flush message goes to all participating PE-rs devices in the VPLS full mesh. PE1-rs should initiate MAC flushing only if PE1-rs is dual-homing aware. (If PE1-rs is dual-homing agnostic, the policy is to not initiate MAC flushing on failure, since that could cause unnecessary flushing in the case of a single-homed MTU-s.) The specific dual-homing protocols for this scenario are outside the scope of this document, but the operator can choose to use the optimized MAC flushing described in this document or the [RFC4762] procedures 🎛️.
The negative MAC flushing procedure is beneficial and causes less disruption than the [RFC4762] procedures, including when the MTU-s is dual-homed with a variety of Ethernet technologies, not just LDP 💅. The negative MAC flush message is a more targeted MAC flush, so the other PE-rs nodes only flush the specified MACs 🎯. That targeted flush can't be achieved with the MAC address withdraw message defined in [RFC4762]. Negative MAC flushing typically results in a smaller set of MACs to be flushed, so these topologies get less disruption overall 🌈.
Note that in the case of negative MAC flushing, the list SHOULD be only the MACs for the affected MTU-s. If the list is empty, then the negative MAC flush procedures will flush and relearn all attached MTU-s devices for the originating PE-rs 😬.
3.3. MAC Flushing in PBB-VPLS
[RFC7041] explains how PBB can be integrated with VPLS to get useful PBB capabilities while still avoiding MSTP in the backbone 🦋. The combined solution, called "PBB-VPLS", scales better in terms of the number of service instances, PWs, and C-MACs that the VPLS PE-rs devices have to handle 📈. This document describes extensions to the LDP MAC flushing procedures described in [RFC4762] that are required to build the desirable capabilities for the PBB-VPLS solution 🧩.
The solution proposed in this document is generic and applies when Multi-Segment Pseudowires (MS-PWs) [RFC6073] are used to interconnect PE devices in H-VPLS 🔗. Other H-VPLS models not defined in this document might also be a fit for the solution.
4. Problem Description 🔍
This section breaks down the problems in detail with respect to the various MAC flushing actions described in Section 3 🕵️♀️.
4.1. MAC Flushing Optimization in VPLS Resiliency
This section describes the optimizations required in MAC flushing procedures when H-VPLS resiliency is provided by primary and backup spoke PWs 💜.
4.1.1. MAC Flushing Optimization for Regular H-VPLS
okay bestie, Figure 2 is a dual-homed H-VPLS setup for one VPLS instance, and it's the perfect example of the MAC flushing problem from Section 3 🦋
PE1-rs PE3-rs
+--------+ +--------+
| | | |
| -- | | -- |
Customer Site 1 | / \ |------------------| / \ |->Z
X->CE-1 /-----| \s / | | \s / |
\ primary spoke PW | -- | /------| -- |
\ / +--------+ / +--------+
\ (MTU-s)/ | \ / |
+--------+/ | \ / |
| | | \ / |
| -- | | \ / |
| / \ | | H-VPLS Full-Mesh Core|
| \s / | | / \ |
| -- | | / \ |
/+--------+\ | / \ |
/ backup spoke PW | / \ |
/ \ +--------+ \--------+--------+
Y->CE-2 \ | | | |
Customer Site 2 \------| -- | | -- |
| / \ |------------------| / \ |->
| \s / | | \s / |
| -- | | -- |
+--------+ +--------+
PE2-rs PE4-rs
Figure 2: Dual-Homed MTU-s in Two-Tier Hierarchy H-VPLSSo in Figure 2, the MTU-s is dual-homed to PE1-rs and PE2-rs 💅 Only the primary spoke PW is active at the MTU-s, which means PE1-rs is the active device (designated forwarder) to reach the full mesh in the VPLS instance. The MAC addresses of nodes at access sites (behind CE-1 and CE-2) are learned at PE1-rs over the primary spoke PW. Let's say X is a set of those MAC addresses behind CE-1, and MAC Z is one of a possible set of other destination MACs. As packets flow from X to other MACs in the VPLS network, PE2-rs, PE3-rs, and PE4-rs learn about X on their respective mesh PWs terminating at PE1-rs.
Now the plot twist 😭 When the MTU-s switches to the backup spoke PW and activates it, PE2-rs becomes the active device (designated forwarder) to reach the full-mesh core for the MTU-s. Traffic entering the H-VPLS from CE-1 and CE-2 gets diverted by the MTU-s to the spoke PW to PE2-rs. Meanwhile, traffic going from PE2-rs, PE3-rs, and PE4-rs to X gets black-holed until the MAC address aging timer expires (the default is 5 minutes) or a packet flows from X to other addresses through PE2-rs. Rude 💀
For example, if a packet flows from MAC Z to MAC X after the backup spoke PW is active, packets from MAC Z travel from PE3-rs to PE1-rs and get dropped. However, if a packet with MAC X as source and MAC Z as destination arrives at PE2-rs, PE2-rs will now learn that MAC X is on the backup spoke PW and will forward to MAC Z. At this point, traffic from PE3-rs to MAC X goes to PE2-rs, since PE3-rs has also learned about MAC X. Therefore, a mechanism is required to make this learning more timely in cases where traffic is not bidirectional. We need it, bestie 🙈
To avoid traffic black-holing, the MAC addresses that were learned in the upstream VPLS full mesh through PE1-rs must be relearned or removed from the MAC Forwarding Information Bases (FIBs) in the VSIs at PE2-rs, PE3-rs, and PE4-rs. If PE1-rs and PE2-rs are dual-homing agnostic, then on activation of the standby PW from the MTU-s, a MAC flush message will be sent by the MTU-s to PE2-rs. That message flushes all the MAC addresses learned in the VPLS instance at PE2-rs from all other PWs except the PW connected to the MTU-s.
PE2-rs then relays the MAC flush messages to all other PE-rs devices in the full mesh. The same processing rule applies to each of those PE-rs devices: all the MAC addresses are flushed except the ones learned on the PW connected to PE2-rs. For example, at PE3-rs, all of the MAC addresses learned from the PWs connected to PE1-rs and PE4-rs are flushed and then relearned. Before the relearning happens, unknown destination MAC addresses get flooded throughout the network. As the number of PE-rs devices in the full mesh grows, the number of unaffected MAC addresses flushed in a VPLS instance also grows, which leads to unnecessary flooding and relearning. With a large number of VPLS instances provisioned in the H-VPLS network topology, the amount of unnecessary flooding and relearning increases even more 😩 So an optimization is required that flushes only the MAC addresses learned from the respective PWs between PE1-rs and other PE devices in the full mesh, to minimize the relearning and flooding in the network. In the example above, only the MAC addresses in sets X and Y (shown in Figure 2) need to be flushed across the core. ✨
The same case applies when PE1-rs and PE2-rs are dual-homing aware and take part in a designated forwarder election. When PE2-rs becomes the active device for the MTU-s, PE2-rs MAY initiate MAC flushing towards the core. The receiving action of the MAC flush message in other PE-rs devices is the same as in MAC flushing initiated by the MTU-s. This is the behavior specified in [RFC4762].
4.1.2. MAC Flushing Optimization for Native Ethernet Access
The analysis in Section 4.1.1 also applies to native Ethernet access into a VPLS. In this scenario, one active endpoint and one or more standby endpoints terminate into two or more VPLS or H-VPLS PE-rs devices. Examples of this dual-homed access are ITU-T [ITU.G8032] access rings or any proprietary multi-chassis Link Aggregation Group (LAG) emulations. When the active native Ethernet endpoint on PE1-rs fails, an optimized MAC flush message is required to be initiated by PE1-rs. That way, on PE2-rs, PE3-rs, and PE4-rs, only the MAC addresses learned from the respective PWs connected to PE1-rs get flushed. Clean and precise 🎀
4.2. Black-Holing Issue in PBB-VPLS
In a PBB-VPLS deployment, a B-component VPLS (B-VPLS) may be used as infrastructure to support one or more I-component instances. The B-VPLS control plane (LDP Signaling) and the learning of Backbone MACs (B-MACs) replace the I-component control plane and the learning of Customer MACs (C-MACs) throughout the MPLS core. This raises an extra challenge related to black-hole avoidance in the I-component domain, which we'll get into in this section 🧚 Figure 3 shows the case of a Customer Edge (CE) device (node A) dual-homed to two I-component instances located on two PBB-VPLS PEs (PE1-rs and PE2-rs).
IP/MPLS Core
+--------------+
|PE2-rs |
+----+ |
|PBB | |
|VPLS| +-+ |
|(B2)|---|P| |
Stby/+----+ /+-+\ |PE3-rs
/ +----+ / \+----+
+---+/ |PBB |/ +-+ |PBB | +---+
C-MAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--C-MAC Y
| |Act|(B1)| +-+ | | | |
+---+ +----+ +----+ +---+
A |PE1-rs | B
| |
+--------------+
Figure 3: PBB Black-Holing Issue - CE Dual-Homing Use CaseThe link between PE1-rs and CE-A is active (marked with A), while the link between CE-A and PE2-rs is in standby/blocked status. In the network diagram, C-MAC X is one of the MAC addresses located behind CE-A in the customer domain, C-MAC Y is behind CE-B, and the B-VPLS instances on PE1-rs are associated with B-MAC B1, while PE2-rs is associated with B-MAC B2.
Here's how it goes wrong 😬 As packets flow from C-MAC X to C-MAC Y through PE1-rs with B-MAC B1, the remote PE-rs devices participating in the B-VPLS with the same I-SID (for example, PE3-rs) learn the C-MAC X associated with B-MAC B1 on PE1-rs. Under a failure condition of the link between CE-A and PE1-rs, and on activation of the link to PE2-rs, the remote PE-rs devices (for example, PE3-rs) forward the traffic destined for C-MAC X to B-MAC B1. PE1-rs then black-holes that traffic until the aging timer expires or a packet flows from X to Y through PE2-rs (B-MAC B2). This may take a long time (the default aging timer is 5 minutes) and may affect a large number of flows across multiple I-components.
A possible solution is to use the existing LDP MAC flushing method specified in [RFC4762] to flush the B-MAC associated with the PE-rs in the B-VPLS domain where the failure occurred. That automatically flushes the C-MAC-to-B-MAC association in the remote PE-rs devices. The catch is that this solution produces a lot of unnecessary MAC flushing in the B-VPLS domain, since there was no failure or topology change affecting the Backbone domain. Ugh, overkill 🙄
A better solution would propagate the I-component events through the backbone infrastructure (B-VPLS). It is required in order to flush only the C-MAC-to-B-MAC associations in the remote PBB-VPLS-capable PE-rs devices. Since there are no I-component control-plane exchanges across the PBB backbone, extensions to the B-VPLS control plane are required to propagate the I-component MAC flushing events across the B-VPLS. Main character energy for the B-VPLS control plane, honestly 👑
5. Solution Description
This section describes the solution for the problem space described in Section 4. ✨
5.1. MAC Flushing Optimization for VPLS Resiliency
The basic principle of the optimized MAC flush mechanism is explained with reference to Figure 2. The optimization is achieved by initiating MAC flushing on failure, as described in Section 3.2.
PE1-rs would initiate MAC flushing towards the core on detection of failure of the primary spoke PW between the MTU-s and PE1-rs (or a status change from active to standby [RFC6718]). This method is referred to as "MAC flushing on failure" throughout this document. 🌸
The MAC flush message tells receiving PE-rs devices to flush all MACs learned over the PW in the context of the VPLS for which the MAC flush message is received. Each PE-rs device in the full mesh that receives the message identifies the VPLS instance and its respective PW that terminates in PE1-rs from the FEC TLV received in the message and/or the LDP session. So the PE-rs device flushes only the MAC addresses learned from that PW connected to PE1-rs, which minimizes the required relearning and the flooding throughout the VPLS domain. Efficient and iconic 💖
This section defines a generic MAC Flush Parameters TLV for LDP [RFC5036]. Throughout this document, the MAC Flush Parameters TLV is also referred to as the "MAC Flush TLV". A MAC Flush TLV carries information on the desired action at the PE-rs device receiving the message, and it's used for optimized MAC flushing in VPLS. The MAC Flush TLV can also be used for the [RFC4762] style of MAC flushing, as explained in Section 3. 🦋
5.1.1. MAC Flush Parameters TLV ✨
okay so the MAC Flush Parameters TLV is giving structure 💅 here's the layout bestie:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| MAC Flush TLV (0x0406) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Variable-Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the U-bit and F-bit [RFC5036] are set to forward if unknown, so potential intermediate VPLS PE-rs devices that have no clue about this new TLV can just pass it along transparently 🦋 and in a B-VPLS network with PBB-VPLS in the core and no I-components attached, this message can still be useful to edge B-VPLS devices that do have the I-components with the I-SIDs and actually understand it 🫶 the MAC Flush Parameters TLV type is 0x0406, as assigned by IANA. the encoding follows the standard LDP TLV encoding described in [RFC5036] 🌸
the TLV value field has a 1-byte Flag field (more on that in a sec). the TLV value MAY carry one or more sub-TLVs. and any sub-TLV definition for the above TLV MUST address the actions in combination with other existing sub-TLVs, so nobody gets left out 👑
the detailed format for the Flags bit vector looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|N| MBZ | (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+the 1-byte Flag field is mandatory. these flags are defined:
- C-flag: used to indicate the context of the PBB-VPLS component where MAC flushing is needed 💜 for PBB-VPLS there are two contexts, the Backbone VPLS (B-component VPLS) and the Customer VPLS (I-component VPLS). the C-flag MUST be ZERO (C = 0) when a MAC flush action for the B-VPLS is required, and MUST be set (C = 1) when the MAC flush action for the I-component is required. in the regular H-VPLS case, the C-flag MUST be ZERO (C = 0) to show that the flush applies to the current VPLS context 🎀
- N-flag: used to indicate whether a positive (N = 0, flush-all-but-mine) or negative (N = 1, flush-all-from-me) MAC flush action is needed 🔥 the source (mine/me) is defined as the PW associated with either the LDP session where the LDP MAC withdraw was received, or the B-MAC(s) listed in the B-MAC Sub-TLV. for the optimized MAC flush procedure in this section, the flag MUST be set (N = 1) 💖
detailed usage in the PBB-VPLS context is explained in Section 5.2 ✨
MBZ flags: the rest of the flags SHOULD be set to zero on transmission and ignored on reception 🧚
the MAC Flush TLV SHOULD be placed after the existing TLVs in the [RFC4762] MAC flush message 🍓
5.1.2. Application of the MAC Flush TLV in Optimized MAC Flushing
okay so when optimized MAC flushing is supported, the MAC Flush TLV MUST be sent in an existing LDP address withdraw message with an empty MAC list 🌈 it comes from the core PE-rs when it detects failure of its local/primary spoke PW. the N-bit in the TLV MUST be set to 1 to show flush-all-from-me 💅 if the optimized MAC flush procedure is used in a Backbone VPLS or regular VPLS/H-VPLS context, the C-bit MUST be ZERO (C = 0). if it's used in an I-component context, the C-bit MUST be set (C = 1). see Section 5.2 for the full details on how this works in PBB-VPLS 🦋
note that the assumption is the MAC Flush TLV is understood by all devices before it gets turned on in any network. see Section 6 ("Operational Considerations") 🙈
when optimized MAC flushing is NOT supported, the MAC withdraw procedures defined in [RFC4762] SHOULD be used, where either the MTU-s or PE2-rs sends the MAC withdraw message. this includes the case where the network is being changed to support optimized MAC flushing but not all devices can understand the optimized MAC flush messages yet 🫶
and for B-VPLS devices, the optimized MAC flush message SHOULD be supported 👑
5.1.3. MAC Flush TLV Processing Rules for Regular VPLS
this section is the processing rulebook for the MAC Flush TLV, and it MUST be followed in the context of optimized MAC flush procedures in VPLS 📖✨
when optimized MAC flushing is supported, a multi-homing PE-rs starts a MAC flush message toward the other related VPLS PE-rs devices when it detects a transition (failure or a change to standby) in its active spoke PW 🔥 in that case the MAC Flush TLV MUST be sent with N = 1. a PE-rs device that receives the MAC Flush TLV SHOULD follow the same processing rules as the ones described in this section 💖
note that if a Multi-Segment Pseudowire (MS-PW) is used in VPLS, a MAC flush message only gets processed at the PW Terminating Provider Edge (T-PE) nodes, because PW Switching Provider Edge S-PE(s) traversed by the MS-PW just propagate the MAC flush messages without doing anything 🧚 in this section, a PE-rs device means only a T-PE in the MS-PW case.
when a PE-rs device receives a MAC Flush TLV with N = 1, it SHOULD flush all the MAC addresses learned from the PW in the VPLS, in the context where the MAC flush message was received 🌸 it's assumed that when these procedures are used, all nodes support the MAC flush message. see Section 6 ("Operational Considerations") for details.
when optimized MAC flushing is NOT supported, a MAC Flush TLV is received with N = 0 in the MAC flush message. in that case, the receiving PE-rs SHOULD flush the MAC addresses learned from all PWs in the VPLS instance, except the ones learned over the PW where the message was received 🎀
regardless of whether optimized MAC flushing is supported, if a PE-rs device receives a MAC flush message with a MAC Flush TLV option (N = 0 or N = 1) and a valid MAC address list, it SHOULD ignore the option and deal with the MAC addresses explicitly as per [RFC4762] 💅
5.1.4. Optimized MAC Flush Procedures
this section expands on the optimized MAC flush procedure in the scenario shown in Figure 2 🦋
when optimized MAC flushing is being used, a PE-rs that is dual-homing aware SHOULD send MAC address messages with a MAC Flush TLV and N = 1, as long as the other PEs understand the new messages 🫶 when PE2-rs gets the MAC flush message, it figures out which VPLS instance needs MAC flushing from the FEC element in the FEC TLV ✨ on receiving N = 1, PE2-rs removes all MAC addresses learned from that PW over which the message was received. PE3-rs and PE4-rs do the same action 👑
Figure 4 shows another redundant H-VPLS topology, this time to protect against failure of the MTU-s device 💜 since there is more than a single MTU-S, a protocol such as provider RSTP [IEEE.802.1Q-2011] may be used as the selection algorithm for active and backup PWs, so connectivity between MTU-s devices and PE-rs devices at the edge is maintained 🌈 it's assumed that PE-rs devices can detect failure on PWs in either direction through OAM mechanisms (for instance, Virtual Circuit Connectivity Verification (VCCV) procedures) 🧚
MTU-1================PE1-rs==============PE3-rs
|| || \ /||
|| Redundancy || \ / ||
|| Provider RSTP || Full Mesh . ||
|| || / \ ||
|| || / \||
MTU-2----------------PE2-rs==============PE4-rs
Backup PW
Figure 4: Redundancy with Provider RSTPMTU-1, MTU-2, PE1-rs, and PE2-rs take part in provider RSTP 🍓 configuration using RSTP makes sure the PW between MTU-1 and PE1-rs is active, and the PW between MTU-2 and PE2-rs is blocked (made backup) at the MTU-2 end. when RSTP detects the active PW failure, it activates the PW between MTU-2 and PE2-rs. when PE1-rs detects the failing PW to MTU-1, it MAY trigger MAC flushing into the full mesh with a MAC Flush TLV that carries N = 1. other PE-rs devices in the full mesh that receive the MAC flush message find their respective PWs terminating on PE1-rs and flush all the MAC addresses learned from it 🔥
[RFC4762] describes a multi-domain VPLS service, where fully meshed VPLS networks (domains) are connected together by a single spoke PW per VPLS service between the VPLS "border" PE-rs devices 💖 to protect against failure of the inter-domain spoke, a full mesh of inter-domain spokes can be set up between border PE-rs devices, and provider RSTP may be used to pick the active inter-domain spoke. if an inter-domain spoke PW fails, MAC withdrawal initiated by PE-rs MAY be used for optimized MAC flush procedures within individual domains 🎀
and these procedures also apply to any native Ethernet access topologies multi-homed to two or more VPLS PE-rs devices 🌸 the text in this section applies to the native Ethernet case, where active/standby PWs are replaced with active/standby Ethernet endpoints. an optimized MAC flush message can be generated by the VPLS PE-rs that detects the failure in the primary Ethernet access 🦋
5.2. LDP MAC Flush Extensions for PBB-VPLS 💖
okay bestie, so [RFC4762] already came up with the idea of sending an address withdraw message with a MAC List TLV to speed up removing MAC addresses when the topology changes 🦋. Think of when the primary link on a VPLS PE-rs device dies and the alternate link takes over (dual-homing, iykyk). Those existing steps apply to the B-VPLS and I-component domains separately.
When a topology change needs to show up in the access networks hanging off the I-components across the B-VPLS domain, there are some extras worth knowing about, and they're all below 🌸
MAC switching in PBB is basically mapping Customer MACs (C-MACs) onto one or more Backbone MACs (B-MACs) 🧚. A change in the access (the I-component domain) should just kick off flushing the C-MAC entries in the PBB PEs' FIB(s) tied to the I-component(s) hit by the failure. We also need a way to say which PBB PE (the B-MAC source) sent the MAC flush message, so only the MACs that are actually affected get flushed 💅.
Here's how we get there: you put the MAC Flush Parameters TLV inside the LDP address withdraw message to say which domain(s) need MAC flushing 🎀. On the receiving end, the PEs SHOULD use the info from that new TLV to flush only the related FIB entry/entries in the I-component instance(s) ✨.
Also, if the C-flag is set to 1, at least one of the following sub-TLVs MUST be included in the MAC Flush Parameters TLV 👑
- PBB B-MAC List Sub-TLV:
- Type:
0x0407 - Length: Value length in octets. At least one B-MAC address MUST be present in the list.
- Value: One or a list of 48-bit B-MAC addresses. These are the source B-MAC addresses associated with the B-VPLS instance that originated the MAC withdraw message. They get used to identify the C-MAC(s) mapped to the B-MAC(s) listed in the sub-TLV.
- Type:
- PBB I-SID List Sub-TLV:
- Type:
0x0408 - Length: Value length in octets. Zero indicates an empty I-SID list. An empty I-SID list means that the flushing applies to all the I-SIDs mapped to the B-VPLS indicated by the FEC TLV.
- Value: One or a list of 24-bit I-SIDs that represent the I-component FIB(s) where the MAC flushing needs to take place.
- Type:
5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS
these steps spell out how the MAC Flush TLV gets processed in PBB-VPLS 🍓. It's mostly the same vibe as regular VPLS, just tailored to PBB, which can have a lot of MAC addresses. In PBB you've got two sets of MACs: Backbone (outer) MACs (B-MACs) and Customer (inner) MACs (C-MACs). C-MACs get tied to remote B-MACs by learning. There are also I-SIDs, which are kind of like VLANs for what we're talking about here. To act similar to the Regular VPLS case, the optimized MAC flush message gets interpreted a little differently ✨
- Positive flush of C-MACs. This is equivalent to [RFC4762] MAC flushing in a PBB context. Here the N-bit is set to 0, the C-bit is set to 1, and C-MACs are to be flushed. But since C-MACs are related to B-MACs in an I-SID context, the flushing scope can get refined further.
- If an I-SID needs to be flushed (all C-MACs within that I-SID), then the I-SIDs get listed in the appropriate TLV. If all I-SIDs are supposed to have their C-MACs flushed, the I-SID TLV can be empty. It's typical to flush a single I-SID only, since each I-SID is associated with one or more interfaces (typically one, in the dual-homing case). In the PBB case, flushing the I-SID is equivalent to the empty MAC list discussed in [RFC4762].
- If only a set of B-MAC-to-C-MAC associations needs to be flushed, a B-MAC list can be included to narrow things down. This can happen if an I-SID component has more than one interface and a B-MAC is used to refine the granularity. Since this is a positive MAC flush message, the intended behavior is to flush all C-MACs except those associated with B-MACs in the list.
- Positive flush of B-MACs is also useful for propagating flush from other protocols, such as RSTP 🌈
- Negative flush of C-MACs. This is equivalent to optimized MAC flushing. Here the N-bit is set to 1, the C-bit is set to 1, and a list of B-MACs is provided so the respective C-MACs can be flushed.
- The I-SID list SHOULD be specified. If it's absent, then all I-SIDs require that the C-MACs be flushed.
- A set of B-MACs SHOULD be listed, since B-MAC-to-C-MAC associations need to be flushed, and listing B-MACs scopes the flush to just those B-MACs. This is the typical usage, because a PBB VPLS I-component interface will have one associated I-SID and typically one (but possibly more than one) B-MAC, each with multiple remotely learned C-MACs. The B-MAC list is included to further refine the list for the remote receiver. Since this is a negative MAC flush message, the intended behavior is to flush all remote C-MACs that are associated with any B-MACs in the list (in other words, from the affected interface) 💜
The processing rules on reception of the MAC flush message are:
- On Backbone Core Bridges (BCBs), if the C-bit is set to 1, then the PBB-VPLS SHOULD NOT flush their B-MAC FIBs. The B-VPLS control plane SHOULD propagate the MAC flush message following the data-plane split-horizon rules to the established B-VPLS topology.
- On Backbone Edge Bridges (BEBs), the following actions apply:
- The PBB I-SID list is used to determine the particular I-SID FIBs (I-component) that need to be considered for flushing action. If the PBB I-SID List Sub-TLV is not included in a received message, then all the I-SID FIBs associated with the receiving B-VPLS SHOULD be considered for flushing action.
- The PBB B-MAC list is used to pick out, from the I-SID FIBs in the previous step, the B-MAC-to-C-MAC associations to selectively flush, depending on the N-flag specified below. If the PBB B-MAC List Sub-TLV is not included in a received message, then all B-MAC-to-C-MAC associations in all I-SID FIBs (I-component) as specified by the I-SID List are considered for required flushing action, again depending on the N-flag specified below.
- Next, depending on the N-flag value, the following actions apply:
- N = 0: all the C-MACs in the selected I-SID FIBs SHOULD be flushed, with the exception of the resultant C-MAC list from the B-MAC list mentioned in the message ("flush all but the C-MACs associated with the B-MAC(s) in the B-MAC List Sub-TLV from the FIBs associated with the I-SID list").
- N = 1: all the resultant C-MACs SHOULD be flushed ("flush all the C-MACs associated with the B-MAC(s) in the B-MAC List Sub-TLV from the FIBs associated with the I-SID list").
5.2.2. Applicability of the MAC Flush Parameters TLV
heads up 🚨 if a Backbone Edge Bridge (BEB) in a PBB-VPLS gets the MAC Flush Parameters TLV and doesn't understand it, an undesirable MAC flushing action may result. It is RECOMMENDED that all PE-rs devices participating in PBB-VPLS support the MAC Flush Parameters TLV. If that's not possible, the MAC Flush Parameters TLV SHOULD be disabled, as mentioned in Section 6 ("Operational Considerations") 🙈
"Mac Flush TLV" and its formal name, "MAC Flush Parameters TLV", are the same thing 🫶 The MAC Flush TLV also applies to the regular VPLS context, as explained in Section 3.1.1. To get negative MAC flushing (flush-all-from-me) in a regular VPLS context, the MAC Flush Parameters TLV SHOULD be encoded with C = 0 and N = 1, without including any Sub-TLVs. A negative MAC flush message is highly desirable in scenarios where VPLS access redundancy is provided by Ethernet ring protection, as specified in the ITU-T G.8032 [ITU.G8032] specification 🔥
6. Operational Considerations
as mentioned earlier, if a receiver doesn't understand the MAC Flush Parameters TLV, an undesirable MAC flushing action would result 😭 One possible fix is to develop an LDP-based capability negotiation mechanism, so PE-rs devices in a VPLS instance can negotiate support for the various MAC flushing capabilities. A negotiation mechanism was discussed previously, but it was considered outside the scope of this document. Negotiation is not required to deploy this optimized MAC flushing as described in this document 💅
VPLS can be used with or without the optimization. If an operator wants the optimization for VPLS, it's the operator's job to make sure the VPLS devices that can support it are properly configured 🧚 From an operational standpoint, it is RECOMMENDED that implementations of the solution give administrators control over which MAC flushing action to use towards a PE-rs device in the VPLS. So, in the topology described in Figure 2, an implementation could support PE1-rs, sending optimized MAC flush messages towards the PE-rs devices that support the solution, while the PE2-rs device sends the [RFC4762] style of MAC flush messages towards the PE-rs devices that don't support the optimized solution during upgrades. The PE-rs that supports the MAC Flush Parameters TLV MUST support the RFC 4762 MAC flushing procedures, since this document only augments them 👑
In the case of PBB-VPLS, this operation is the only method supported for specifying I-SIDs. The optimization is assumed to be supported, or should be turned off, reverting to flushing using [RFC4762] at the Backbone MAC level 🌸
7. IANA Considerations
7.1. New LDP TLV
IANA maintains a registry called "Label Distribution Protocol (LDP) Parameters" with a sub-registry called "TLV Type Name Space" 📋
IANA has allocated three new code points, like this 🍓
Value | Description | Reference | Notes
-------+---------------------------+------------+-----------
0x0406 | MAC Flush Parameters TLV | [RFC7361] |
0x0407 | PBB B-MAC List Sub-TLV | [RFC7361] |
0x0408 | PBB I-SID List Sub-TLV | [RFC7361] |7.2. New Registry for MAC Flush Flags
IANA has created a new sub-registry under "Label Distribution Protocol (LDP) Parameters" called "MAC Flush Flags" 🦋
IANA has populated the registry as follows 💖
Bit Number | Hex | Abbreviation | Description | Reference
-----------+------+--------------+-----------------------+-----------
0 | 0x80 | C | Context | [RFC7361]
1 | 0x40 | N | Negative MAC flushing | [RFC7361]
2-7 | | | Unassigned |Other new bits are to be assigned by Standards Action [RFC5226] ✨
8. Security Considerations 🔒✨
Okay bestie, security is serious, so listen up 👀 There are two sides to this: the control plane and the data plane.
Control-plane aspects:
LDP security (authentication) methods from [RFC5036] apply here too 🔐 On top of that, this document follows the security considerations from [RFC4447] and [RFC4762]. The extensions in this document optimize MAC flushing, so the risk of security attacks goes down 📉 BUT, and this is a big but 🚨, if somebody spoofs the configuration for support of the new TLV, you'll get sub-optimal behavior. Not a disaster, just not the glow-up you wanted 💀
Data-plane aspects:
This specification has zero impact on the VPLS forwarding plane 🙌 What it can do is improve MAC flushing behavior, which is iconic ✨
9. Contributing Author 💜
Huge shoutout to Marc Lasserre, who made a major contribution to developing this document. Literally MVP energy 👑
Marc Lasserre
Alcatel-Lucent
EMail: marc.lasserre@alcatel-lucent.com10. Acknowledgements 🫶
The authors want to thank the following people, who gave valuable comments, feedback, and review on the topics in this document. You all ate 🍓💅: Dimitri Papadimitriou, Jorge Rabadan, Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Henderickx, Paul Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar, Giles Heron, Adrian Farrel, Ben Niven-Jenkins, Robert Sparks, Susan Hares, and Stephen Farrell 🌸
11. References 📚
11.1. Normative References
These are the must-read ones 🤓
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, April 2006.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol
(LDP) Signaling", RFC 4762, January 2007.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.11.2. Informative References
These are the background reads, still very worth it 💖
[IEEE.802.1Q-2011]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
2011.
[ITU.G8032] International Telecommunication Union, "Ethernet ring
protection switching", ITU-T Recommendation G.8032,
February 2012.
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for
Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", RFC 6718, August 2012.
[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, November 2013.
[VPLS-MH] Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
Uttaro, J., Palislamovic, S., and W. Lin, "BGP based
Multi-homing in Virtual Private LAN Service", Work in
Progress, July 2014.Authors' Addresses 🦋
Meet the squad who wrote this 💕
Pranjal Kumar Dutta
Alcatel-Lucent
701 E Middlefield Road
Mountain View, CA 94043
USA
EMail: pranjal.dutta@alcatel-lucent.com
Florin Balus
Alcatel-Lucent
701 E Middlefield Road
Mountain View, CA 94043
USA
EMail: florin.balus@alcatel-lucent.com
Olen Stokes
Extreme Networks
2121 RDU Center Drive
Suite 300
Morrisville, NC 27650
USA
EMail: ostokes@extremenetworks.com
Geraldine Calvignac
Orange
2, avenue Pierre-Marzin
Lannion Cedex, 22307
France
EMail: geraldine.calvignac@orange.com
Don Fedyk
Hewlett-Packard Company
USA
EMail: don.fedyk@hp.com📦 where this page comes from
- ietf: rfc7361 2014-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms