RFC 8104
Pseudowire (PW) Endpoint Fast Failure Protection
RFC 8104: Pseudowire (PW) Endpoint Fast Failure Protection ✨
Quick facts, bestie 🎀
- Publisher: Internet Engineering Task Force (IETF) 🌸
- Number: RFC 8104
- Category: Standards Track
- Status: ISSN 2070-1721
- Date: March 2017
- Authors: Y. Shen (Juniper Networks), R. Aggarwal (Arktan, Inc.), W. Henderickx (Nokia), and Y. Jiang (Huawei Technologies Co., Ltd.) 👑
- Obsoletes/Updates: The header doesn't list anything this one obsoletes or updates. 🦋
Abstract
okay so this doc is all about a fast way to protect pseudowires (PWs) that ride over IP/MPLS tunnels 💖 when the failure happens at the egress endpoint. The failures it covers are: egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. 😭
The mechanism runs on a few ingredients: a multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching. With those, the router right upstream of a failure can do the local repair itself 🫶 It can restore a PW in the order of tens of milliseconds by sending traffic around the failure to a protector through a pre-established bypass tunnel. Literally so fast 🔥
So this mechanism can cut down on traffic loss before global repair kicks in and the network converges on the topology changes caused by the failure. ✨
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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841. 💅
For info on the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc8104. 🧚
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is covered by 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 these carefully, because they spell out your rights and restrictions for this document. 🙈 Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License. ⭐
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of Requirements . . . . . . . . . . . . . . . . 5
3. Reference Models for Egress Endpoint Failures . . . . . . . . 5
3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 6
3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . 9
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 10
4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Local Repair . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Context Identifier . . . . . . . . . . . . . . . . . . . 14
4.3.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. FEC . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.3. IGP Advertisement and Path Computation . . . . . . . 16
4.4. Protection Models . . . . . . . . . . . . . . . . . . . . 17
4.4.1. Co-located Protector . . . . . . . . . . . . . . . . 17
4.4.2. Centralized Protector . . . . . . . . . . . . . . . . 19
4.5. Transport Tunnel . . . . . . . . . . . . . . . . . . . . 20
4.6. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 21
4.7. Examples of Forwarding State . . . . . . . . . . . . . . 22
4.7.1. Co-located Protector Model . . . . . . . . . . . . . 22
4.7.2. Centralized Protector Model . . . . . . . . . . . . . 26
5. Restorative and Revertive Behaviors . . . . . . . . . . . . . 29
6. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Egress Protection Capability TLV . . . . . . . . . . . . 31
6.2. PW Label Distribution from Primary PE to Protector . . . 32
6.3. PW Label Distribution from Backup PE to Protector . . . . 33
6.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 34
6.4.1. Encoding Format for PWid with IPv4 PE Addresses . . . 35
6.4.2. Encoding Format for Generalized PWid with IPv4 PE
Addresses . . . . . . . . . . . . . . . . . . . . . . 36
6.4.3. Encoding Format for PWid with IPv6 PE Addresses . . . 37
6.4.4. Encoding Format for Generalized PWid with IPv6 PE
Addresses . . . . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 431. Introduction
okay so, per [RFC3985], [RFC8077], and [RFC5659], a pseudowire (PW) or PW segment is basically a connection between a pair of forwarders hosted by two PEs. It carries an emulated Layer 2 service across a packet switched network (PSN) 🦋 In the single-segment PW (SS-PW) case, a forwarder binds a PW to an attachment circuit (AC). In the multi-segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds a PW segment to an AC, while a forwarder on a switching PE (S-PE) binds one PW segment to another PW segment. Between the PEs, in each direction, PW packets ride a PSN tunnel, which is also called a transport tunnel. 🌸
Now, to protect the PW service against network failures, you have to protect every link and node along the entire data path 🥹 For traffic going in a given direction, that covers the ingress AC, the ingress (T-)PE, the intermediate routers of the transport tunnel, the S-PEs, the egress (T-)PE, and the egress AC. To keep service disruption tiny when something breaks, it's also really nice if each of these parts is covered by a fast protection mechanism built on local repair. 💅
These mechanisms usually work like this: a bypass path gets pre-computed and pre-installed in the data plane on the router directly upstream of an expected failure. That router is called a "point of local repair" (PLR). ✨ The bypass path can steer traffic around the failure, and it stays unaffected by the topology changes that the failure causes. When the failure hits, the PLR can use the bypass path to restore the service really fast. 🔥
Today, fast protection against an ingress AC failure or an ingress (T-)PE failure can be done with a multihomed CE and redundant ACs, like a multi-chassis link aggregation group (MC-LAG). 🎀 Fast protection against an intermediate router of the transport tunnel failing can be done with RSVP fast reroute [RFC4090] or IP/LDP fast reroute [RFC5286] [RFC5714]. 🌈 But here's the tea: there's no equivalent mechanism for an egress AC failure, an egress (T-)PE failure, or an S-PE failure 😭 For those, service restoration has to lean on global repair or control-plane convergence. Global repair usually means the ingress CE or ingress (T-)PE switches traffic onto an alternative path, based on remote failure detection via PW status notification, end-to-end Operations, Administration, and Maintenance (OAM), and others. Control-plane convergence means control protocols react to the topology changes caused by the failure. Compared to local repair, both of these are relatively slow at reacting to a failure and getting traffic back. 🐢
So this document fills that gap 💖 It specifies a fast protection mechanism based on local repair to protect PWs against these endpoint failures:
- a. Egress AC failure.
- b. Egress PE failure: a link or node failure of an egress PE of an SS-PW, or of a T-PE of an MS-PW.
- c. Switching PE failure: a link or node failure of an S-PE of an MS-PW.
This mechanism works for LDP-signaled PWs. It's relevant to networks that have redundant PWs and multihomed CEs. It's designed on top of MPLS upstream label assignment and context-specific label switching [RFC5331]. "Fast protection" here refers to its ability to restore traffic in the order of tens of milliseconds ⭐ Compared with global repair and control-plane convergence, this mechanism can restore service faster. But it's meant to complement those mechanisms, not replace them, because networks still rely on them to eventually move traffic onto fully functional alternative paths. 🫶
2. Specification of Requirements
Here's the official key word list, bestie: 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. Reference Models for Egress Endpoint Failures
Next up, this document looks at the following topologies to describe egress endpoint failures and the protection procedures. 🍓
3.1. Single-Segment PW ✨
Okay bestie, let's look at the single-segment PW setup 🦋. Figure 1 shows an IP/MPLS network full of PE and P routers, and it gives a PW service between CE1 and CE2. Each CE is multihomed through two ACs to two PEs, which creates two divergent paths between the CEs. Path one uses PW1 between PE1 and PE2, and path two uses PW2 between PE3 and PE4. The transport tunnels and the other links between routers are left out so the picture stays clean 🌸
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ---------------- PE2 -
/ \
/ \
CE1 CE2
\ /
\ /
- PE3 -------------- P2 ---------------- PE4 -
|<-------------- PW2 --------------->|
Figure 1So a CE can run its ACs in two modes when it sends traffic to the remote CE: active-standby mode and active-active mode 💅
- In the active-standby mode, the CE picks one AC as the active AC and its path as the active path. The other AC becomes the standby AC, with its path as the standby path. The CE only sends traffic on the active AC as long as the active path is working. It only starts sending on the standby AC after it notices the active path has failed. Here's the plot twist 🙈: the CE may receive traffic on either AC, depending on whether the remote CE picked the same active path for the reverse direction. In this document, even when both CEs pick the same active path, each CE should still anticipate receiving traffic on a standby AC, because the fast protection mechanism may redirect the traffic to the standby path.
- In the active-active mode, the CE treats both ACs and their paths as active. It sends traffic on both ACs in a load-balancing fashion. In the reverse direction, the CE may receive traffic on both ACs. Main character energy 👑
These modes assume the traffic is data traffic, which isn't tied to one specific AC. Control-protocol traffic between the CEs is not included here, at least when the CE-CE control-protocol sessions or adjacencies on the two ACs are treated as distinct rather than as having a primary and backup relationship. Generally speaking, a dual-homed CE should not make any explicit or implicit assumptions about which AC it gets packets from the remote CE on 🫶
Now, for either mode, when we look at traffic flowing in a given direction over an active path, this document sees the ACs, PEs, and PWs as playing either primary or backup roles. The ACs, PEs, and PWs along the active path have primary roles, and the ones along the other path have backup roles. In active-active mode, each AC, PE, and PW on an active path has a primary role and also a backup role protecting the other path, which is also active. It's giving double duty 💖
For Figure 1, these are the roles for traffic going from CE1 to CE2 via PW1:
- Primary ingress AC:
CE1-PE1 - Primary ingress PE:
PE1 - Primary PW:
PW1 - Primary egress PE:
PE2 - Primary egress AC:
PE2-CE2 - Backup ingress AC:
CE1-PE3 - Backup ingress PE:
PE3 - Backup PW:
PW2 - Backup egress PE:
PE4 - Backup egress AC:
PE4-CE2
Based on this schema, the document covers egress endpoint failures and the fast protection mechanism on a per-active-path and per-direction basis 🎀 In this case, an egress AC failure means the AC PE2-CE2 has failed, and an egress node failure means PE2 has failed. The big goal is that when something fails, the traffic should be repaired locally, so it can eventually reach CE2 through the backup egress PE (PE4) and the backup egress AC (PE4-CE2). Iconic 🌈
After that local repair, one of two things happens. Either the current active path heals once the control plane converges on the new topology, or the ingress CE switches traffic from the primary path to the backup path, depending on the failure. In the second case, the ingress CE may do the path switchover based on end-to-end OAM (in-band or out-band), PW status notification, CE-PE control protocols (for example, the Link Aggregation Control Protocol (LACP)), and other things. In active-standby mode, this promotes the standby path to be the new active path. In active-active mode, the other active path carries all the traffic between the two CEs. Either way, this restoration phase falls under control-plane convergence and global repair, so it's out of scope for this document. The point of the fast protection mechanism here is to cut down on traffic loss before that restoration happens ⭐
Quick heads up 🚨: in Figure 1, if reverse traffic (from CE2 to CE1) goes through the AC CE2-PE2 and PE2 as its active path, then a failure of PE2 or of the AC PE2-CE2 counts as an ingress failure for that traffic. If CE2 can detect those failures, it may protect the traffic by switching to the backup path through the AC CE2-PE4 and PE4. But that's categorized as ingress endpoint failure protection, so this document's mechanism doesn't handle it 💀
Figure 2 shows another possible setup, where CE1 is single-homed to PE1 and CE2 stays multihomed to PE2 and PE4. From the point of view of egress endpoint protection for traffic going from CE1 to CE2 over PW1, this is the same as the scenario in Figure 1 🍓
|<-------------- PW1 --------------->|
------------- P1 ---------------- PE2 -
/ \
/ \
CE1 -- PE1 CE2
\ /
\ /
------------- P2 ---------------- PE4 -
|<-------------- PW2 --------------->|
Figure 2Just so we're clear 🧚: when we're talking about egress endpoints, primary egress AC, primary egress PE, backup egress AC, and backup egress PE may simply be called primary AC, primary PE, backup AC, and backup PE.
3.2. Multi-Segment PW 💜
Figure 3 is basically Figure 1 but in an MS-PW environment 🌸 PW1 and PW2 are both MS-PWs. PW1 is set up between TPE1 and TPE2, and it switches between SEG1 and SEG2 at SPE1. PW2 is set up between TPE3 and TPE4, and it switches between SEG3 and SEG4 at SPE2. CE1 is multihomed to TPE1 and TPE3, and CE2 is multihomed to TPE2 and TPE4. The transport tunnels for the PW segments are hidden so the diagram stays readable 🦋
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 -------------- SPE1 --------------- TPE2 -
/ \
/ \
CE1 CE2
\ /
\ /
- TPE3 -------------- SPE2 --------------- TPE4 -
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 3In this document, traffic going from CE1 to CE2 gets these primary and backup roles:
- Primary ingress AC:
CE1-TPE1 - Primary ingress T-PE:
TPE1 - Primary PW:
PW1 - Primary S-PE:
SPE1 - Primary egress T-PE:
TPE2 - Primary egress AC:
TPE2-CE2 - Backup ingress AC:
CE1-TPE3 - Backup ingress T-PE:
TPE3 - Backup PW:
PW2 - Backup S-PE:
SPE2 - Backup egress T-PE:
TPE4 - Backup egress AC:
TPE4-CE2
In this case, an egress AC failure is the failure of the AC TPE2-CE2. An egress node failure is the failure of TPE2. An S-PE failure is the failure of SPE1 ✨
To stay consistent with the SS-PW scenario, primary T-PEs and primary S-PEs may simply be called primary PEs in this document, wherever the specifics don't matter. Similarly, backup T-PEs and backup S-PEs may be called backup PEs 🫶
4. Theory of Operation 🔥
The fast protection mechanism in this document offers three types of protection for PWs. Each one matches one of the three types of failures from Section 1 💅
- a. Egress AC protection
- b. Egress (T-)PE node protection
- c. S-PE node protection
4.1. Applicability 🌈
This mechanism works with LDP-signaled PWs, in an environment where an egress CE is multihomed to a primary PE and a backup PE, and there's a backup PW like the one described in Section 3. The procedure for S-PE node protection applies when there's a backup S-PE on the backup PW 🧚
The mechanism assumes IP/MPLS transport tunnels, and it works with tunnels that have a single path or equal-cost multipaths (ECMPs). Picture a tunnel carrying one or more PWs that goes through a router with ECMPs to a primary PE. The ECMPs include at least one direct link to the PE and some multi-hop paths to the PE. Because of that direct link, the router counts as a penultimate hop of the tunnel and can do local detection and repair for an egress node failure 👑 The router normally uses a hashing algorithm to spread PW packets across the ECMPs, either per PW or per flow. If the direct link fails (a transit link failure), the router pulls that link out of the hashing algorithm. That automatically spreads the link's traffic across the other ECMP paths, which is local repair. That scenario isn't the focus of this document. If the PE fails (an egress node failure), the router SHOULD perform local repair by rerouting all of the ECMP traffic, since the failure affects every path. If the router doesn't have a fast or reliable way to detect an egress node failure, it is RECOMMENDED that the router SHOULD treat a failure of the direct link as an egress node failure 🙈
The mechanism applies to both best-effort and traffic engineering (TE) transport tunnels. For TE transport tunnels that need bandwidth protection, TE bypass tunnels with reserved bandwidth MAY be used to avoid congestion for rerouted traffic 💖
It is also RECOMMENDED that the mechanism SHOULD be used together with global repair and control-plane convergence. The mechanism temporarily repairs a failed path by using a bypass tunnel, and then global repair and control-plane convergence eventually move the traffic to a fully working alternative path. Teamwork makes the dream work 🫶
4.2. Local Repair 🔧
okay so the fast protection part of this whole mechanism comes from local repair 💖 It's done by routers sitting upstream and right next to a failure, and each one of those is called a PLR. A PLR MUST be able to detect a failure with a rapid mechanism, like physical-layer failure detection, Bidirectional Forwarding Detection (BFD) [RFC5880], Seamless BFD (S-BFD) [RFC7880], and others 🚨 Before anything breaks, the PLR MUST also pre-establish a bypass tunnel to a "protector" and pre-install a bypass route for that tunnel in the data plane ✨ The protector is either a backup PE or a router that forwards traffic to a backup PE. The bypass tunnel MUST have the property that it won't be affected by the topology changes caused by the failure. Specifically, it MUST NOT traverse the primary PE or the penultimate link of the protected transport tunnel, and it can't share any shared risk link groups (SRLGs) with the penultimate link 🙅♀️ When the failure is detected, the PLR invokes the bypass route in the data plane and reroutes PW traffic to the protector through the bypass tunnel. The protector then sends the traffic on to the target CE. That whole procedure is called local repair 🦋
Different routers can be the PLR and the protector depending on the scenario 🌈
- In egress AC protection, the PLR is the primary PE, and the protector is the backup PE (Figure 4).
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ---------------- PE2 -
/ PLR \
/ | \
CE1 bypass| CE2
\ | /
\ | /
- PE3 -------------- P2 ---------------- PE4 -
protector
|<-------------- PW2 --------------->|
Figure 4- In egress PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW, and the protector is the backup PE (Figure 5).
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ------- P3 ----- PE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- PE3 -------------- P2 ---------------- PE4 -
protector
|<-------------- PW2 --------------->|
Figure 5- In S-PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW segment, and the protector is the backup S-PE (Figure 6).
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 -------------- TPE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- TPE3 --------------- SPE2 -------------- TPE4 -
protector
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 6In egress AC protection, the PLR knows its job from a "context identifier" that's configured on it. This is introduced in this document (Section 4.3) 🎀 The PLR sets up its bypass tunnel to the protector in the same way it would set up a normal PSN tunnel.
In egress PE and S-PE node protection, the PLR is just a transit router on the transport tunnel, and it normally doesn't know about the PW(s) riding on that tunnel 🤷♀️ In this document, the PLR simply computes and sets up a node-protection bypass tunnel the same way it does for normal IP/MPLS node protection. The only twist is the context identifier, so the bypass tunnel gets established from the PLR to the protector (Section 4.6) 💅 And the flip side: if the router stops being a PLR for egress PE or S-PE node protection, because the network topology or the transport tunnel's path changed, the router should go back to being a regular transit router. That includes being a PLR for transit link and node protection too 🔄
In local repair, the PLR just switches all the traffic it gets on the transport tunnel over to the bypass tunnel 🏃♀️ That only works if the protector behind the bypass tunnel MUST be meant for all the PWs carried by the transport tunnel. Here's how that gets achieved: the ingress PE uses a context identifier to tie a PW to one specific pair of {primary PE, protector}, then maps that PW onto a transport tunnel headed to that exact same {primary PE, protector}. The ingress PE MAY map multiple PWs onto the transport tunnel, as long as they all share the same {primary PE, protector} 🫶
In local repair, the PLR keeps the PW label intact in packets. That's a big deal because the PLR doesn't need bypass routes for each PW, so bypass tunnels can be shared between PWs ✨ The catch is that it puts a requirement on the protector. It MUST be able to forward packets based on a PW label that was assigned by the primary PE, and it has to make sure the traffic MUST reach the target CE over a backup path 😬 From the protector's point of view, that PW label is an upstream assigned label [RFC5331]. So to make this work, the protector MUST learn the PW label from the primary PE before the failure, then install the right forwarding state for that label in a dedicated label space tied to the primary PE. During local repair, the protector MUST perform the PW label lookup in that label space 🔍
The examples so far showed protectors that are backup (T-/S-)PEs. But a protector can also be a dedicated router that does this job, separate from the backup (T-/S-)PE 🧚 During local repair, the PLR still reroutes traffic to the protector through a bypass tunnel. The protector then forwards the traffic to the backup (T-/S-)PE, which forwards it on to the target CE over a backup AC or a backup PW segment. There's more detail on this in Section 4.4 🌸
4.3. Context Identifier 🆔
okay so a protector can protect multiple primary PEs, and it MUST keep a separate label space for each one 💜 And the PWs ending on one primary PE can be protected by several protectors, each covering a subset of those PWs. Either way, a given PW MUST be associated with one and only one {primary PE, protector} pair 🙌
This document brings in the idea of a context identifier to make protection setup easier ✨ A context identifier is an IPv4/v6 address given to each ordered {primary PE, protector} pair. The address MUST be globally unique, or at least unique in the address space of the network where the primary PE and the protector live 🌍
4.3.1. Semantics 💭
The semantics of a context identifier are twofold, bestie 👑
- A context identifier identifies a primary PE and its associated protector. It stands in for the primary PE as the PW destination on a per-protector basis. One primary PE can be protected by multiple protectors, each covering a subset of the PWs that terminate on that primary PE. A distinct context identifier MUST be assigned to each
{primary PE, protector}pair.
The ingress PE of a PW learns the context identifier of the PW's {primary PE, protector} from the primary PE, through the Interface_ID TLV [RFC3471] [RFC3472] in the LDP Label Mapping message for the PW. Then the ingress PE sets up or resolves a transport tunnel using the context identifier as the destination, instead of a private IP address of the primary PE 🎯 That destination does two jobs at once: it gets the transport tunnel to the primary PE, and it tells the PLR who the protector is. The PLR MUST use the context identifier as the destination for the bypass tunnel to the protector. And the ingress PE MUST map only the PWs that terminate on the exact primary PE and are protected by the exact protector onto that transport tunnel 🔒
- A context identifier indicates the primary PE's label space on the protector. The protector may protect PWs for multiple primary PEs, and for each primary PE it MUST maintain a separate label space that stores the PW labels assigned by that primary PE. It ties a PW label to a label space through the context identifier of the
{primary PE, protector}, like this 🧩
In addition to the normal LDP PW signaling, the primary PE MUST have a targeted LDP session with the protector, and it advertises PW labels to the protector in LDP Label Mapping messages (Section 6) 📨 The primary PE MUST attach the context identifier to each message. When the protector receives the message, it MUST install the advertised PW label in the label space identified by that context identifier.
When a PLR sets up or resolves a bypass tunnel to the protector, it MUST use the context identifier, not a private IP address of the protector, as the destination. The protector MUST use the bypass tunnel (either the MPLS tunnel label or the IP tunnel destination address) as the pointer to the matching label space. And the protector MUST forward PW packets that arrive on the bypass tunnel based on a label lookup in that label space 🎀
4.3.2. FEC 🧾
In an MPLS network, a context identifier represents a Forwarding Equivalence Class (FEC) for the transport tunnels and bypass tunnels headed to it 🦋 For example, it may be encoded in an LDP Prefix FEC Element, or in the "tunnel endpoint address" of an RSVP Session object. The FEC is tied to a unique forwarding state on the PLRs and the protector, and that state can't be shared with other FECs 🚫 Some MPLS protocols (e.g., LDP) support FEC aggregation [RFC3031]. But when it comes to a context identifier's FEC, FEC aggregation MUST NOT be applied, and every router MUST assign a unique label to that FEC 💖
4.3.3. IGP Advertisement and Path Computation ✨
Okay bestie, this part is about how the routers actually find out about the context identifier, because both the transport tunnel and the bypass tunnel point at it 🎀. The primary PE and the protector have to coordinate how they advertise it across the routing domain and the TE domain. The context identifier should be advertised so that all the routers on the tunnels MUST be able to independently reach this shared view of paths 🗺️:
- The transport tunnel MUST have the primary PE as its path endpoint 💖.
- The bypass tunnel MUST have the protector as its path endpoint. In egress PE and S-PE node protection, the path MUST avoid the primary PE 🙅♀️.
There are generally two categories of approaches to get there, and they're both giving main character energy 👑:
- Category one doesn't need the ingress PE or the PLR to know about the PW egress endpoint protection schema 🧠. It also doesn't need any IGP extension for context identifier advertisement 🙌. The primary PE and the protector both advertise the context identifier as an address that's reachable via both routers. The ingress PE and the PLR can then compute paths the normal way, using things like Dijkstra, constrained shortest path first (CSPF), Loop-Free Alternate (LFA) [RFC5286], and Maximally Redundant Tree (MRT) [RFC7812]. One example is to advertise the context identifier as a virtual proxy node that connects to the primary PE and the protector. The link between the proxy node and the primary PE gets a more preferable IGP and TE metric than the link between the proxy node and the protector 🪄. The transport tunnel then follows the shortest path or a TE path to the primary PE and gets terminated there. The PLR won't see itself as the penultimate hop of the transport tunnel anymore. It'll see itself as two hops away from the proxy node, via the primary PE 🦋. So a node-protection bypass tunnel is available via the protector to the proxy node, but it actually gets terminated by the protector 🫶.
- Category two does require the PLR to know about the PW egress endpoint protection schema 🔍. The primary PE advertises the context identifier as a regular IP address. The protector advertises it using an explicit "context identifier object," which MUST be understood by the PLR 📦. That object needs an IGP extension 🛠️. In both the routing domain and the TE domain, the context identifier is only reachable via the primary PE, and that's what makes sure the transport tunnel is terminated by the primary PE 💅. The PLR sees itself as the penultimate hop of the transport tunnel. Then, based on the IGP context identifier object, it sets up or resolves a bypass tunnel to the advertiser (that's the protector), and it avoids the primary PE while doing it 🌸.
This mechanism is meant to be flexible about which approach a network uses, as long as it meets the requirements above for the transport tunnel path and the bypass tunnel path 💜. In theory, a network can use one approach for context ID X and a different approach for context ID Y 🌈. For any given context ID, though, all the relevant routers (the primary PE, the protector, and the PLR) must support and agree on the approach that was chosen 🤝. The routers can get that coordination done through configuration ⚙️.
4.4. Protection Models 🛡️
There are two protection models, and they're based on where the protector lives: the co-located protector model and the centralized protector model 🏠🌍. A network MAY use either model or both 💖.
4.4.1. Co-located Protector 🏡
In this model, the protector is a backup PE that's directly connected to the target CE through a backup AC. Or it's a backup S-PE on a backup PW. Either way, the protector is co-located with the backup (S-)PE 📍. You can see examples of this model in Figures 4, 5, and 6 in Section 4.2 👀.
In egress AC protection and egress PE node protection, when a protector gets traffic from the PLR, it forwards that traffic to the CE through the backup AC 🚀. Figure 7 shows this, where PE2 is the PLR for an egress AC failure, P3 is the PLR for a PE2 failure, and PE4 (the backup PE) is the protector 🧚.
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ------- P3 ----- PE2 ----
/ PLR \ PLR \
/ \ | \
CE1 bypass\ |bypass CE2
\ \ | /
\ \ | /
- PE3 -------------- P2 ---------------- PE4 ----
protector
|<-------------- PW2 --------------->|
Figure 7In S-PE node protection, when a protector gets traffic from the PLR, it forwards that traffic over the next segment of the backup PW 🛤️. The T-PE of the backup PW then forwards the traffic to the CE through a backup AC 💌. Figure 8 shows this, where P1 is the PLR for an SPE1 failure, and SPE2 (the backup S-PE) is the protector for SPE1 🎯. SPE2 receives traffic from P1, swaps SEG1's label to SEG4's label, and forwards the traffic over a transport tunnel to TPE4 🌷.
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 -------------- TPE2 -
/ PLR \ \
/ \ \
CE1 bypass\ CE2
\ \ /
\ \ /
- TPE3 --------------- SPE2 -------------- TPE4 -
protector
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 8In the co-located protector model, the number of context identifiers a network needs is the number of distinct {primary PE, backup PE} pairs 🔢. From a scalability point of view, this model is a good fit for networks where the number of primary PEs and the average number of backup PEs per primary PE are both relatively low 📉.
4.4.2. Centralized Protector 🌟
In this model, the protector is a dedicated P router or PE router that just does this job 🫡. In egress AC protection and egress PE node protection, the protector may or may not be a backup PE that's directly connected to the target CE. In S-PE node protection, the protector may or may not be a backup S-PE on the backup PW 🤷♀️.
In egress AC protection and egress PE node protection, if the protector isn't directly connected to the CE, it forwards the traffic to a backup PE. That backup PE then forwards the traffic to the CE through a backup AC 🔁. Figure 9 shows this, where the protector gets traffic from P3 (the PLR for an egress PE failure) or PE2 (the PLR for an egress AC failure). It swaps PW1's label to PW2's label and forwards the traffic over a transport tunnel to PE4 (the backup PE) 💫. The protector may be protecting other PWs and other primary PEs too. That isn't shown in the figure, just to keep things clear 🧼.
|<------------- PW1 --------------->|
- PE1 ------------- P1 ------- P3 ----- PE2 --
/ PLR \ PLR \
/ \ / \
/ bypass\ /bypass \
/ \ / \
CE1 protector CE2
\ \ /
\ transport\ /
\ tunnel \ /
\ \ /
- PE3 ------------- P2 -----------------PE4 --
|<------------- PW2 --------------->|
Figure 9In S-PE node protection, if the protector isn't a backup S-PE, it forwards the traffic to the backup S-PE. The backup S-PE then forwards the traffic over the next segment of the backup PW 🪜. Finally, the T-PE of the backup PW forwards the traffic to the CE through the backup AC 🎁. Figure 10 shows this, where the protector gets traffic from P1 (the PLR), swaps SEG1's label to SEG3's label, and forwards the traffic over a transport tunnel to SPE2 (the backup S-PE) 🚚. SPE2 then does MS-PW switching from SEG3's label to SEG4's label, and forwards the traffic over a transport tunnel to TPE4 (the backup T-PE) 🫧. The protector may be protecting other PW segments and other primary S-PEs as well. For clarity, that isn't shown in the figure 🙈.
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 -------------- TPE2 -
/ PLR \ \
/ \ \
/ bypass\ \
/ \ \
CE1 protector CE2
\ \ /
\ transport\ /
\ tunnel \ /
\ \ /
- TPE3 --------------- SPE2 -------------- TPE4 -
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
Figure 10The centralized protector model lets multiple primary PEs share one protector 🤝. Each primary PE may need only one protector 💜. So the number of context identifiers a network needs may be tied to the number of primary PEs 🧮.
4.5. Transport Tunnel 🚇✨
okay so a PW is tied to a pair of {primary PE, protector} 👯, and that pairing gets its own unique context identifier 🆔. The ingress PE sets up or resolves its transport tunnel by using that context identifier as the destination, not the primary PE's private IP address 🙅♀️. why? bc it makes sure the PW gets carried to the primary PE, and it also helps set up bypass tunnels at the PLR, since the context identifier carries the protector's identity too 🧠. it's the same deal for a multi-segment PW, where the ingress PE and egress PE are T-/S-PEs 💅.
An ingress PE learns the association between a PW and a context identifier from the primary PE, which MUST advertise the context identifier as a "third-party next hop" via the IPv4/v6 Interface_ID TLV [RFC3471] [RFC3472] in the LDP Label Mapping message of the PW 📨.
In an ECMP scenario, a transport tunnel may have multiple penultimate hop routers 🌿. Each of them SHOULD act as a PLR independently 🫶. Also in an ECMP scenario, a penultimate hop router may have ECMPs to the primary PE. At least one path of the ECMPs must be a direct link to the primary PE, and that's what qualifies the router as a penultimate hop 👑. The other paths of the ECMPs may be direct links or indirect paths to the primary PE. In egress PE node protection and S-PE node protection, when a node failure is detected, or a link failure is detected on a direct link and treated as a node failure, the penultimate hop router SHOULD act as a PLR and reroute the entire traffic of the ECMPs to the protector 🦋.
4.6. Bypass Tunnel 🛡️
A PLR may protect multiple PWs, and those PWs may be associated with one or multiple pairs of {primary PE, protector} 🧺. The PLR MUST establish a bypass tunnel to each protector for each context identifier associated with that protector. The destination of the bypass tunnel MUST be the context identifier (Section 4.3.1). Since the PLR is a transit router of the transport tunnel, it SHOULD derive the context identifier from the destination of the transport tunnel 🎀.
For example, in Figures 7 and 9, a bypass tunnel is established from PE2 (PLR for egress AC failure) to the protector, and another bypass tunnel is established from P3 (PLR for egress node failure) to the protector. In Figures 8 and 10, a bypass tunnel is established from P1 (PLR for S-PE failure) to the protector 🧚.
In local repair, a PLR reroutes traffic to the protector through a bypass tunnel, with the PW label intact in the packets 📦. This normally involves pushing a label to the label stack if the bypass tunnel is an MPLS tunnel, or pushing an IP header to the packets if the bypass tunnel is an IP tunnel. Upon receipt of the packets, the protector forwards them based on the PW label. Specifically, the protector uses the bypass tunnel as a context to figure out the primary PE's label space 🔑. If the bypass tunnel is an MPLS tunnel, the protector should have assigned a non-reserved label to the bypass tunnel, so this label can serve as the context. This label is also called a "context label", since it's actually bound to the context identifier. If the bypass tunnel is an IP tunnel, the context identifier should be the destination address of the IP header.
To be useful for local repair, a bypass tunnel MUST have the property that it is not affected by any topology changes caused by the failure. It MUST NOT traverse the primary PE or the penultimate link of the transport tunnel, or share any SRLG with the penultimate link. 🚫
A bypass tunnel may be a TE tunnel with reserved bandwidth, which helps avoid traffic congestion for rerouted traffic 🚦. A bypass tunnel should remain effective during local repair, until the traffic is moved to an alternative path, i.e., either the same PW over a fully functional transport tunnel or another fully functional PW ✨.
There is little or no benefit to protect a bypass tunnel. Therefore, a bypass tunnel SHOULD NOT be protected against a transit link failure, transit node failure, or egress node failure 🙈.
4.7. Examples of Forwarding State 🔍
This section provides some detailed examples of forwarding state on the PLR, protector, and other relevant routers 💜.
A protector learns PW labels from all the primary PEs that it protects (Section 6.2), and it maintains the PW labels in separate label spaces on a per-primary-PE basis. In the control plane, each label space is identified by the context identifier of the corresponding {primary PE, protector}. In the forwarding plane, the label space is indicated by the bypass tunnel(s) destined for the context identifier 🗂️.
4.7.1. Co-located Protector Model
In Figure 11, PE4 is a co-located protector that protects PW1 against egress AC failure and egress node failure 🌸. It maintains a label space for PE2, which is identified by the context identifier of {PE2, PE4}. It learns PW1's label from PE2 and installs a forwarding entry for the label in that label space. The next hop of the forwarding entry indicates a label pop with an outgoing interface pointing to the backup AC PE4-CE2 💅.
|<-------------- PW1 --------------->|
- PE1 -------------- P1 ------- P3 ----- PE2 ------
/ PLR \ PLR \
/ \ | \
/ \ | \
CE1 bypass P4 P5 bypass CE2
\ \ | /
\ \ | /
\ \ | /
- PE3 -------------- P2 ---------------- PE4 ------
protector
|<-------------- PW2 --------------->|
PW1's label assigned by PE2: 100
PW2's label assigned by PE4: 200
On P3: </t>
Incoming label of transport tunnel to PE2: 1000
Outgoing label of transport tunnel to PE2: implicit null
Outgoing label of bypass tunnel to PE4: 2000
On PE2:
Outgoing label of bypass tunnel to PE4: 3000
On PE4:
Context label (incoming label of bypass tunnels): 999
Forwarding state on P3:
label 1000 -- primary next hop: pop, to PE2
backup next hop: swap 2000, to P4
Forwarding state on PE2:
label 100 -- primary next hop: pop, to CE2
backup next hop: push 3000, to P5
Forwarding state on P4:
label 2000 -- next hop: swap 999, to PE4
Forwarding state on P5:
label 3000 -- next hop: swap 999, to PE4
Forwarding state on PE4:
label 200 -- next hop: pop, to CE2
label 999 -- next hop: label table of PE2's label space
Label table of PE2's label space on PE4:
label 100 -- next hop: pop, to CE2
Figure 11In Figure 12, SPE2 is a co-located protector that protects PW1 against S-PE failure 🧜♀️. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, SPE2}. It learns SEG1's label from SPE1 and installs a forwarding entry in the label space. The next hop of the forwarding entry indicates a label swap to SEG4's label and a label push with the label of a transport tunnel to TPE4 🌈.
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 --- P3 ------- TPE2 -
/ PLR \ \
/ \ \
CE1 bypass P2 CE2
\ \ /
\ \ /
- TPE3 --------------- SPE2 --- P4 ------- TPE4 -
protector
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
SEG1's label assigned by SPE1: 100
SEG2's label assigned by TPE2: 200
SEG3's label assigned by SPE2: 300
SEG4's label assigned by TPE4: 400
On P1:
Incoming label of transport tunnel to SPE1: 1000
Outgoing label of transport tunnel to SPE1: implicit null
Outgoing label of bypass tunnel to SPE2: 2000
On SPE1:
Outgoing label of transport tunnel to TPE2: 3000
On SPE2:
Outgoing label of transport tunnel to TPE4: 4000
Context label (incoming label of bypass tunnel): 999
Forwarding state on P1:
label 1000 -- primary next hop: pop, to SPE1
backup next hop: swap 2000, to P2
Forwarding state on SPE1:
label 100 -- next hop: swap 200, push 3000, to P3
Forwarding state on P2:
label 2000 -- next hop: swap 999, to SPE2
Forwarding state on SPE2:
label 300 -- next hop: swap 400, push 4000, to P4
label 999 -- next hop: label table of SPE1's label space
Label table of SPE1's label space on SPE2:
label 100 -- next hop: swap 400, push 4000, to P4
Figure 124.7.2. Centralized Protector Model 💖
okay so in the centralized protector model 🧚, every primary PW where the protector is NOT a backup (S-)PE needs the protector to also learn the label of the backup PW from the backup (S-)PE (Section 6.3). that backup (S-)PE is where the protector is going to forward traffic, so it's a must-know. the protector MUST also learn that label, and then it MUST install a forwarding entry that does a label swap from the primary PW's label to the backup PW's label, plus a label push with the label of a transport tunnel to the backup (S-)PE. literally the whole plot 🎀
In Figure 13, the protector is a centralized protector protecting PW1 against egress AC failure and egress node failure. it keeps a label space for PE2, identified by the context identifier {PE2, protector} 👑. it learns PW1's label from PE2 and PW2's label from PE4, then installs a forwarding entry for PW1's label in that label space. the next hop of that entry does a label swap to PW2's label and a label push with the label of a transport tunnel to PE4. so cute 🦋
|<-------------- PW1 --------------->|
- PE1 ------------- P1 ------- P3 ------ PE2 ----
/ PLR \ PLR \
/ \ / \
/ bypass P5 P6 bypass \
/ \ / \
/ \/ \
CE1 protector CE2
\ \ /
\ transport \ /
\ tunnel P7 /
\ \ /
\ \ /
- PE3 ------------- P2 ----------------- PE4 ----
|<-------------- PW2 --------------->|
PW1's label assigned by PE2: 100
PW2's label assigned by PE4: 200
On P3:
Incoming label of transport tunnel to PE2: 1000
Outgoing label of transport tunnel to PE2: implicit null
Outgoing label of bypass tunnel to protector: 2000
On PE2:
Outgoing label of bypass tunnel to protector: 3000
On protector:
Context label (incoming label of bypass tunnels): 999
Outgoing label of transport tunnel to PE4: 4000
Forwarding state on P3:
label 1000 -- primary next hop: pop, to PE2
backup next hop: swap 2000, to P5
Forwarding state on PE2:
label 100 -- primary next hop: pop, to CE2
backup next hop: push 3000, to P6
Forwarding state on P5:
label 2000 -- next hop: swap 999, to protector
Forwarding state on P6:
label 3000 -- next hop: swap 999, to protector
Forwarding state on P7:
label 4000 -- next hop: pop, to PE4
Forwarding state on PE4:
label 200 -- next hop: pop, to CE2
Forwarding state on protector:
label 999 -- next hop: label table of PE2's label space
Label table of PE2's label space on protector:
label 100 -- next hop: swap 200, push 4000, to P7
Figure 13In Figure 14, the protector is a centralized protector protecting the PW segment SEG1 of PW1 against the node failure of SPE1 🫶. it keeps a label space for SPE1, identified by the context identifier {SPE1, protector}. it learns SEG1's label from SPE1 and SEG3's label from SPE2, then installs a forwarding entry for SEG1's label in the label space. that entry's next hop does a label swap to SEG3's label and a label push with the label of a transport tunnel to TPE4. the plot thickens 🔥
|<--------------- PW1 --------------->|
|<----- SEG1 ----->|<----- SEG2 ----->|
- TPE1 ----- P1 ----- SPE1 --- P2 -------- TPE2 -
/ PLR \ \
/ \ \
/ bypass P4 \
/ \ \
/ \ \
CE1 protector CE2
\ \ /
\ \ /
\ transport P5 /
\ tunnel \ /
\ \ /
- TPE3 -------------- SPE2 --- P3 -------- TPE4 -
|<----- SEG3 ----->|<----- SEG4 ----->|
|<--------------- PW2 --------------->|
SEG1's label assigned by SPE1: 100
SEG2's label assigned by TPE2: 200
SEG3's label assigned by SPE2: 300
SEG4's label assigned by TPE4: 400
On P1:
Incoming label of transport tunnel to SPE1: 1000
Outgoing label of transport tunnel to SPE1: implicit null
Outgoing label of bypass tunnel to protector: 2000
On SPE1:
Outgoing label of transport tunnel to TPE2: 3000
On SPE2:
Outgoing label of transport tunnel to TPE4: 4000
On protector:
Context label (incoming label of bypass tunnel): 999
Outgoing label of transport tunnel to SPE2: 5000
Forwarding state on P1:
label 1000 -- primary next hop: pop, to SPE1
backup next hop: swap 2000, to P4
Forwarding state on SPE1:
label 100 -- next hop: swap 200, push 3000, to P2
Forwarding state on P4:
label 2000 -- next hop: swap 999, to protector
Forwarding state on P5:
label 5000 -- next hop: pop, to SPE2
Forwarding state on SPE2:
label 300 -- next hop: swap 400, push 4000, to P3
Forwarding state on protector:
label 999 -- next hop: label table of SPE1's label space
Label table of SPE1's label space on protector:
label 100 -- next hop: swap 300, push 5000, to P5
Figure 145. Restorative and Revertive Behaviors ✨
okay so once local repair has kicked in, there are three strategies a network can use to bring traffic back to a fully working alternative path 🛤️
- Global repair 🌸 If the ingress CE is multihomed (Figure 1), it MAY switch the traffic to the backup AC, which is bound to the backup PW. or, if the ingress PE hosts a backup PW (Figure 2), the ingress PE MAY switch the traffic to the backup PW. these procedures are called global repair. possible triggers include PW status notification, Virtual Circuit Connectivity Verification (VCCV) [RFC5085] [RFC5885], BFD, end-to-end OAM between CEs, and others.
- Control-plane convergence 🧠 in egress PE node protection and S-PE node protection, the failure might only be on the link between the PLR and the primary PE, while the primary PE is still totally alive 💅. in that case, the PLR or an upstream router on the transport tunnel MAY reroute the tunnel around that link through an alternative path to the primary PE. so the transport tunnel can heal and keep carrying the PW to the primary PE. this is driven by control-plane convergence on the new topology.
- Local reversion 🦋 the PLR MAY move traffic back to the primary PW once the failure is resolved. in egress AC protection, when it detects the primary AC is back, the PLR MAY start forwarding traffic over the AC again. likewise, in egress PE node protection and S-PE node protection, when it detects the primary PE is restored, the PLR MAY re-establish the transport tunnel to the primary PE and move the traffic from the bypass tunnel back to the transport tunnel. these procedures are called local reversion.
ngl this part is so important 😭. It is RECOMMENDED that the fast protection mechanism SHOULD be used together with global repair. especially with egress PE and S-PE node failures: if the ingress PE or the protector loses contact with the egress PE or S-PE for a long time, the LDP session may go down. then the ingress PE might tear down the primary PW completely, or the protector might remove the forwarding entry for the primary PW label. either way, the service breaks 💀. so yeah, the mechanism can temporarily fix traffic, but control-plane state can expire if the failure sticks around. therefore, global repair SHOULD take place in a timely manner to move traffic onto a fully functional alternative path.
control-plane convergence may happen automatically as control-plane protocols react to the new topology 🌈. however, it only applies to the specific link failure scenario described above.
local reversion is optional 🎀. when the failure is caused by resource flapping, local reversion MAY be dampened to limit potential disruption. local reversion MAY also be disabled completely by configuration.
6. LDP Extensions 🧚
as we covered in earlier sections, a targeted LDP session MUST be established between each pair of primary PE and protector 🫶. the primary PE sends a Label Mapping message over this session to advertise the primary PW labels to the protector. in the centralized protector model, a targeted LDP session MUST also be established between a backup (S-)PE and the protector. the backup PE then sends a Label Mapping message over that session to advertise the backup PW labels to the protector.
to make all this work, this document defines a brand-new "Protection FEC Element" TLV ✨. the Label Mapping messages of both LDP sessions above MUST carry this TLV to identify a primary PW. specifically, in the centralized protector model, the Protection FEC Element TLV advertised by a backup (S-)PE MUST match the one advertised by the primary PE, so the protector can match up the primary PW's label with the backup PW's label and do a label swap 💜. the backup (S-)PE builds that TLV based on local configuration.
this document also defines a new "Egress Protection Capability" TLV as a new type of Capability Parameter TLV [RFC5561]. it lets a protector announce that it can process the Protection FEC Element TLV above and do context-specific label switching for PW labels 👑.
the procedures in this section only apply if the protector advertises the Egress Protection Capability TLV, the primary PE supports advertising the Protection FEC Element TLV, and, in the centralized protector model, the backup PE also supports advertising the Protection FEC Element TLV 🍓.
6.1. Egress Protection Capability TLV 💖
okay bestie, a protector MUST advertise the Egress Protection Capability TLV in its Initialization message and its Capability message over the LDP session with a primary PE. in the centralized protector model, the protector MUST also advertise the TLV over the LDP session with a backup PE. the TLV carries one or multiple context identifiers. to the primary PE, the TLV MUST carry the context identifier of the {primary PE, protector}. in the centralized protector model, the TLV MUST carry multiple context identifiers to the backup PE, one for each {primary PE, protector} where the backup PE serves as a backup for the primary PE. this TLV MUST NOT be advertised by the primary PE or the backup PE to the protector 🙈
the way receiving routers process this TLV MUST follow the procedures defined in [RFC5561]. so, the router MUST advertise PW information to the protector by using the Protection FEC Element TLV, but only after it has received the Egress Protection Capability TLV from the protector. it MUST validate each context identifier included in the TLV and advertise the information of only the PWs that are associated with that context identifier. if the protector withdraws a previously advertised context identifier, or withdraws the entire Egress Protection Capability TLV via a Capability message, the router MUST withdraw the Protection FEC TLVs it previously advertised 🔥
the encoding is defined below. it conforms to the format of the Capability Parameter TLV specified in [RFC5561] 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Egress Protection (0x0974)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ |
| |
~ Capability Data = context identifier(s) ~
| |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15- U-bit: the U-bit MUST be set to 1, so that a receiver MUST silently ignore this TLV if unknown to it and continue processing the rest of the message. ✨
- F-bit: the F-bit MUST be set to 0, since this TLV is sent only in Initialization and Capability messages, which are not forwarded. 🦋
- TLV code point: the TLV code point is
0x0974. - S-bit: the S-bit indicates whether the sender is advertising (
S=1) or withdrawing (S=0) the capability. 💅 - Capability Data: this field is encoded with the context identifiers of the {primary PE, protector} pairs for which the advertiser is the protector. 🌸
6.2. PW Label Distribution from Primary PE to Protector 🎀
so a primary PE MUST advertise a primary PW's label to a protector by sending a Label Mapping message. that message includes a Protection FEC Element TLV (see Section 6.4 for encoding) and an Upstream-Assigned Label TLV [RFC6389] encoded with the PW's label. the combo of the Protection FEC Element TLV and the PW label is what represents the primary PE's forwarding state for the PW, so it's kind of the whole vibe 😭 the Label Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [RFC3471] [RFC6389] encoded with the context identifier of the {primary PE, protector}.
when the protector gets this Label Mapping message, it MUST install a forwarding entry for the PW label in the label space identified by the context identifier. the next hop of that forwarding entry MUST ensure that packets are sent towards the target CE via a backup AC or a backup (S-)PE, depending on the protection scenario 🫶 and if the included context identifier is unknown to the protector, the protector MUST silently discard the Label Mapping message. no drama, just gone 💀
6.3. PW Label Distribution from Backup PE to Protector 🧚
in the centralized protector model, a backup PE MUST advertise a backup PW's label to the protector by sending a Label Mapping message. this message includes a Protection FEC Element TLV and a Generic Label TLV encoded with the backup PW's label. the Protection FEC Element MUST be identical to the Protection FEC Element TLV that the primary PE advertises to the protector (Section 6.2). this is achieved through configuration on the backup PE 🍓 and the context identifier MUST NOT be encoded in an Interface_ID TLV in this message.
now the protector that receives this Label Mapping message MUST associate the backup PW with the primary PW, based on the common Protection FEC Element TLV. it MUST distinguish between the Label Mapping message from the primary PE and the one from the backup PE, based on the respective presence and absence of a context identifier in the Interface_ID TLV. it MUST install a forwarding entry for the primary PW's label in the label space identified by the context identifier. the next hop of that forwarding entry MUST indicate a label swap to the backup PW's label, followed by a label push or IP header push for a transport tunnel to the backup PE 👑
6.4. Protection FEC Element TLV 🌈
the Protection FEC Element TLV has type 0x83. here's its format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Encoding Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ PW Information ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16- Encoding Type: this tells you the encoding format of the PW Information field. it corresponds to the PWid FEC Element and Generalized PWid FEC Element defined in [RFC8077]. the types are:
1- PWid FEC Element with IPv4 PE addresses (Section 6.4.1).2- Generalized PWid FEC Element with IPv4 PE addresses (Section 6.4.2).3- PWid FEC Element with IPv6 PE addresses (Section 6.4.3).4- Generalized PWid FEC Element with IPv6 PE addresses (Section 6.4.4).
- Length: the length of the PW Information field, in octets. 🦋
- PW Information: a field of variable length that specifies a PW. ✨
6.4.1. Encoding Format for PWid with IPv4 PE Addresses 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(1) | Length(20) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17- Ingress PE IPv4 Address: the IPv4 address of the ingress PE of the PW. 💖
- Egress PE IPv4 Address: the IPv4 address of the egress PE of the PW. 💖
- Group ID: an arbitrary 32-bit value that represents a group of PWs and is used to create groups in the PW space. 🫧
- PW ID: a non-zero 32-bit connection ID that, together with the PW Type field, identifies a particular PW. 🫶
- Control word bit (C): a bit that flags the presence of a control word on this PW. if C = 1, the control word is present; if C = 0, it is not present. 🙈
- PW Type: a 15-bit quantity that represents the type of PW. 👑
6.4.2. Encoding Format for Generalized PWid with IPv4 PE Addresses 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18- Ingress PE IPv4 Address: the IPv4 address of the ingress PE of the PW. 💖
- Egress PE IPv4 Address: the IPv4 address of the egress PE of the PW. 💖
- Control word bit (C): a bit that flags the presence of a control word on this PW. if C = 1, the control word is present; if C = 0, it is not present. 🙈
- PW Type: a 15-bit quantity that represents the type of PW. 👑
- AGI Type, Length, AGI Value: the Attachment Group Identifier of the PW. 🧚
- AII Type, Length, SAII Value: the Source Attachment Individual Identifier of the PW. 🌈
- AII Type, Length, TAII Value: the Target Attachment Individual Identifier of the PW. 🌸
6.4.3. Encoding Format for PWid with IPv6 PE Addresses ✨
okay so this is the IPv6 version of the PWid format 🦋 the layout looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(3) | Length(44) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ingress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Egress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19here's what each piece does 💅
Ingress PE IPv6 Address: the IPv6 address of the ingress PE of the PW, and it's 16 octets long 🌸Egress PE IPv6 Address: the IPv6 address of the egress PE of the PW, also 16 octets 🌸Group ID: an arbitrary 32-bit value that stands for a group of PWs and gets used to make groups in the PW space 🧚PW ID: a non-zero 32-bit connection ID that, together with thePW Typefield, pins down one specific PW 💜Control word bit (C): this bit flags whether a control word is on this PW. If C = 1, the control word is present, and if C = 0, it's not present 🙈PW Type: a 15-bit value that says what type of PW it is 🍓
6.4.4. Encoding Format for Generalized PWid with IPv6 PE Addresses 👑
this one is the generalized version, so it's got the AGI, SAII, and TAII bits too. the layout is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ingress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Egress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20the field breakdown:
Ingress PE IPv6 Address: the IPv6 address of the ingress PE of the PW, 16 octets 🌸Egress PE IPv6 Address: the IPv6 address of the egress PE of the PW, 16 octets 🌸Control word bit (C): flags a control word on this PW. If C = 1, control word is present; if C = 0, control word is not present ✨PW Type: a 15-bit quantity that represents the type of PW 🍓AGI Type, Length, AGI Value: the Attachment Group Identifier of the PW 🫶AII Type, Length, SAII Value: the Source Attachment Individual Identifier of the PW 🦋AII Type, Length, TAII Value: the Target Attachment Individual Identifier of the PW 🌈
7. IANA Considerations ✨
okay IANA stuff, but make it cute 🎀 this doc defines a new Egress Protection Capability TLV (see Section 6), and IANA gave it value 0x0974 in the "TLV Type Name Space" registry 💖
this doc also defines a new Protection FEC Element TLV (see Section 6). IANA assigned it value 0x83 in the "Forwarding Equivalence Class (FEC) Type Name Space" registry per RFC 7358, and they updated that registry so it also references this document 📋🫶
8. Security Considerations 💀
okay this part is serious bestie, so read closely 🔥 PW traffic can be temporarily rerouted by a PLR to a protector. in the centralized protector scenario, the traffic can be rerouted again to a backup PE. on the control plane, there's a targeted LDP session between a primary PE and a protector, and in the centralized protector scenario there's also a targeted LDP session between a backup PE and a protector 🌊
in every scenario, traffic rerouting through PLRs, protectors, and backup PEs is planned and expected, and backup PEs can be used anyway to host PWs and LDP sessions. so the rerouted traffic and the LDP sessions introduced in this document should not be viewed as a new security threat 🙌
in general, [RFC5920] describes the security framework for MPLS networks. [RFC3209] describes the security considerations for RSVP Label Switched Paths (LSPs). [RFC5036] describes the security considerations for the base LDP specification. [RFC5561] describes the security considerations that apply when you use the LDP capability mechanism. all of these security frameworks and considerations apply to this document too 🔐✨
9. References 📚
9.1. Normative References
- [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>. - [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<http://www.rfc-editor.org/info/rfc8077>. - [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008,
<http://www.rfc-editor.org/info/rfc5331>. - [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009,
<http://www.rfc-editor.org/info/rfc5561>. - [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>. - [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, January 2003,
<http://www.rfc-editor.org/info/rfc3472>. - [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, November 2011,
<http://www.rfc-editor.org/info/rfc6389>. - [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>. - [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008,
<http://www.rfc-editor.org/info/rfc5286>. - [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<http://www.rfc-editor.org/info/rfc7812>. - [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
9.2. Informative References
- [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>. - [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>. - [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. - [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>. - [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, DOI 10.17487/RFC5659, October 2009,
<http://www.rfc-editor.org/info/rfc5659>. - [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010,
<http://www.rfc-editor.org/info/rfc5714>. - [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>. - [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007,
<http://www.rfc-editor.org/info/rfc5085>. - [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010,
<http://www.rfc-editor.org/info/rfc5885>. - [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<http://www.rfc-editor.org/info/rfc7880>.
Acknowledgements 🫶
this doc builds on work by Hannes Gredler, Yakov Rekhter, Minto Jeyananth, Kevin Wang, and several others on MPLS edge protection 🌟 huge thanks to Nischal Sheth and Bhupesh Kothari for their contributions 💜 and to John E. Drake, Andrew G. Malis, Alexander Vainshtein, Stewart Bryant, and Mach(Guoyi) Chen for the valuable comments that helped shape the doc and make it clearer 👑✨
Authors' Addresses ✨
okay bestie, here are the humans behind this spec 🫶 they're all super talented, so if you ever need to reach them, here's where they hang out 💜
Yimin Shen 🌸
Yimin Shen
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Phone: +1 9785890722
Email: yshen@juniper.netRahul Aggarwal 🦋
Rahul Aggarwal
Arktan, Inc.
Email: raggarwa_1@yahoo.comWim Henderickx 🎀
Wim Henderickx
Nokia
Copernicuslaan 50
2018 Antwerp
Belgium
Email: wim.henderickx@nokia.comYuanlong Jiang 🧚
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129
China
Email: jiangyuanlong@huawei.comand that's the whole RFC, periodt 🌈💅
📦 where this page comes from
- ietf: rfc8104 2017-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms