RFC 8390
RSVP-TE Path Diversity Using Exclude Route
RFC 8390: RSVP-TE Path Diversity Using Exclude Route 💖
okay bestie, let's get into this one. RFC 8390 is all about keeping two LSPs from sharing the same network bits so one cable cut doesn't take out both 🔥
- RFC number: 8390
- Title: RSVP-TE Path Diversity Using Exclude Route
- Category: Standards Track
- Date: July 2018
- Updates: RFC 4874
- ISSN: 2070-1721
- Authors (all Editors):
- Z. Ali (Ed.), Cisco Systems
- G. Swallow (Ed.), SETC
- F. Zhang (Ed.), Huawei
- D. Beller (Ed.), Nokia
Abstract ✨
okay so RSVP-TE can already send exclusion info while an LSP is being set up 🎀 A typical diversity use case is protection: two LSPs take different paths so there's no single point of failure, and service availability gets way better 💅 This doc specifies a way to do that when the full path isn't necessarily known, using an abstract identifier for the path. There are three flavours of abstract identifier: client based, Path Computation Element (PCE) based, and network based 🦋 It also defines two new diversity subobjects, one for the RSVP eXclude Route Object (XRO) and one for the Explicit Exclusion Route Subobject (EXRS) 💜
For protection, LSPs usually get created at a slow rate and then hang around for a long time. So it's reasonable to assume a reference path that already exists, with a well-known identifier, will keep existing and can be used as the reference when creating the new diverse path 🌸 Re-routing the existing reference LSP before the new path is set up is out of scope ngl 🙈
Status of This Memo ✨
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc8390 🧚
Copyright Notice 🌈
Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 6
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 6
1.3. Client-Initiated Identifier . . . . . . . . . . . . . . . 7
1.4. PCE-Allocated Identifier . . . . . . . . . . . . . . . . 7
1.5. Network-Assigned Identifier . . . . . . . . . . . . . . . 9
2. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . 10
2.1. Diversity XRO Subobject . . . . . . . . . . . . . . . . . 10
2.2. Diversity EXRS Subobject . . . . . . . . . . . . . . . . 16
2.3. Processing Rules for the Diversity XRO and EXRS
Subobjects . . . . . . . . . . . . . . . . . . . . . . . 16
3. Security Considerations . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. New XRO Subobject Types . . . . . . . . . . . . . . . . . 21
4.2. New EXRS Subobject Types . . . . . . . . . . . . . . . . 21
4.3. New RSVP Error Sub-codes . . . . . . . . . . . . . . . . 22
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Normative References . . . . . . . . . . . . . . . . . . 22
5.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 261. Introduction 🦋
Path diversity for multiple connections is a well-known operational requirement, no cap 💅 Diversity constraints make sure LSPs can be set up without sharing network resources, which hugely cuts down the odds of simultaneous connection failures 🫶
The source node can compute diverse paths when it has the full network topology and is allowed to signal an Explicit Route Object (ERO). But sometimes different nodes do the path computations, so the relevant diversity constraints have to be signaled to those nodes. Examples include (but aren't limited to):
- LSPs with loose hops in the Explicit Route Object, e.g., inter-domain LSPs; and
- Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI), where the core node may perform path computation [RFC4208].
[RFC4874] introduced a way to specify nodes and resources to exclude from a route, using the eXclude Route Object (XRO) and Explicit Exclusion Route Subobject (EXRS) ✨ It helps calculate diverse paths for LSPs based on known properties of those paths, like the addresses of links and nodes traversed and the Shared Risk Link Groups (SRLGs) of traversed links 🍓 Using these mechanisms means the source node that starts signaling needs to know the relevant properties of the path(s) it wants diversity from. That's not always possible or desirable, though, including (but not limited to) these situations:
- Excluding a path that doesn't originate, terminate, or traverse the source node of the diverse LSP. In that case, the addresses of links and SRLGs of the path you need diversity from are unknown to the source node.
- Excluding a path the source node of the diverse LSP knows about, but has incomplete or no path information for, e.g., due to operator policy. Here the source node knows the reference path exists, but it doesn't fully know the info needed to build an XRO that guarantees diversity from that reference path. Inter-domain and GMPLS overlay networks can impose such restrictions 😭
This is illustrated in Figure 1, where the overlay reference model from [RFC4208] is shown.
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | UNI | | | | | | | | UNI | | | |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| | | | +--+--+ | | | | | | +---+-| | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
+---------+ | | | | | | | +---------+
| | | | | | |
+---------+ | | +--+--+ | +--+--+ | | +---------+
| +----+ | | | | | +-------+ +-----+ | +----+ |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | UNI | +-----+ +-----+ | UNI | | | |
| +----+ | | | | +----+ |
+---------+ +----------------------------------+ +---------+
Overlay Core Network Overlay
Network Network
Legend: EN - Edge Node
CN - Core Node
Figure 1: Overlay Reference Model [RFC4208]Figure 1 shows two kinds of UNI connectivity: single-homed and dual-homed ENs (which also applies to higher-order multihomed connectivity) 🌸 Single-homed EN devices connect to a single CN device over a single UNI link. That one UNI link could be a single point of failure. The UNI connection between EN1 and CN1 is an example of single-homed UNI connectivity.
You can avoid that single point of failure when the EN device connects to two different CN devices, like EN2 does in Figure 1 👑 For the dual-homing case, it's possible to set up two different UNI connections from the same source EN device to the same destination EN device. For example, two connections from EN2 to EN3 could use the two UNI links EN2-CN1 and EN2-CN4. To avoid single points of failure inside the provider network, you also need to make sure the LSP paths are diverse within the core network 💖
In a network that provides a set of UNI interfaces between ENs and CNs like the one in Figure 1, the CNs usually do the path computation. Info sharing across the UNI boundary is restricted by the policy rules the core network imposes. Usually the core network topology info and LSP path info aren't exposed to the ENs 😭 Take the network in Figure 1: say an LSP from EN2 to EN4 needs to be SRLG diverse from an LSP from EN1 to EN3. EN2 may not know the SRLG attributes of the EN1-EN3 LSP, so it can't build an XRO to exclude those SRLGs. In this example, EN2 can't use the procedures in [RFC4874]. Similarly, an LSP from EN2 to EN3 that goes through CN1 needs to be diverse from an LSP from EN2 to EN3 going via CN4. Again, exclusions based on [RFC4874] can't be used here either 🙈
This document handles these diversity requirements by introducing an approach that excludes the path taken by these particular LSP(s) 🦋 Each reference LSP or route that diversity is needed from is identified by an abstract "identifier". Which type of identifier to use really depends on the core network operator's deployment scenario: it could be client initiated (provided by the EN), provided by a PCE, or allocated by the (core) network. This document defines three identifier types for these three cases: a client-initiated identifier, a PCE-allocated identifier, and an identifier allocated by the CN ingress node (UNI-N), i.e., a network-assigned identifier ✨
1.1. Conventions Used in This Document 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀
That's the end of part 1! 💅 Keep an eye out for part 2, where we get into the identifier types and the signaling extensions 🧚
1.2. Terms and Abbreviations 📖
Diverse LSP: okay so a diverse Label Switched Path (LSP) is an LSP whose path doesn't share any link or SRLG with the path of a given LSP 🦋 diverse LSPs only really matter in the context of protection or restoration, so that's where you'll see them show up 🛡️
ERO: the Explicit Route Object, as defined in [RFC3209] 🎀
EXRS: the Explicit Exclusion Route Subobject, as defined in [RFC4874] 💜
SRLG: the Shared Risk Link Group, as defined in [RFC4202] ✨
Reference Path: the reference path is the path of an existing LSP that the path of a diverse LSP shall be diverse from. Main character energy, the existing LSP sets the baseline 👑
XRO: eXclude Route Object, as defined in [RFC4874] 🧚
1.3. Client-Initiated Identifier 🫶
okay bestie, so the fields you MUST use to represent the client-initiated identifier are: IPv4/IPv6 tunnel sender address, IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended Tunnel ID. That's the core squad 💖 Based on local policy, the client MAY also include the LSP ID to pick out one specific LSP inside the tunnel. These fields are defined in Sections 4.6.1.1 and 4.6.2.1 of [RFC3209], so go check them if you want the receipts 🤓
Figure 1 shows how this all plays out. Picture this: an LSP from EN2 to EN4 needs to be diverse with respect to an LSP from EN1 to EN3. Iconic behaviour from both of them, honestly 💅
The LSP identifier of the EN1-EN3 LSP is LSP-IDENTIFIER1, and it's defined by this tuple:
(tunnel-id = T1,
LSP ID = L1,
source address = EN1.RID (Route Identifier),
destination address = EN3.RID,
extended tunnel-id = EN1.RID).Then the EN2-EN4 LSP gets its own identifier, LSP-IDENTIFIER2, which is defined by this tuple:
(tunnel-id = T2,
LSP ID = L2,
source address = EN2.RID,
destination address = EN4.RID,
extended tunnel-id = EN2.RID).So the EN1-EN3 LSP gets signaled with an exclusion requirement from LSP-IDENTIFIER2, and the EN2-EN4 LSP gets signaled with an exclusion requirement from LSP-IDENTIFIER1. Ngl, that's a very healthy friendship boundary 🙈 To keep diversity between these two connections inside the core network, the core network SHOULD implement crankback signaling extensions as defined in [RFC4920]. Heads up though, crankback signaling is known to lead to slower setup times and suboptimal paths under some circumstances, as described by [RFC4920] 💀
1.4. PCE-Allocated Identifier 🌸
okay so in scenarios where a PCE is deployed and used to do path computation, the ingress node of the core network (for example, node CN1 in Figure 1) could consult a PCE to allocate identifiers. Those identifiers are what get used to signal path diversity constraints 🧚 In other deployment scenarios, a PCE lives at a network node (or nodes), or it's part of a Network Management System (NMS). Either way, the PCE is consulted, and the Path Key, as defined in [RFC5520], can be used in RSVP signaling as the identifier to make sure things stay diverse 🌈
Now let's look at an example of LSP diversity using a Path Key. Figure 2 shows a simple network with two domains. The goal is to set up a pair of path-disjoint LSPs from the source in Domain 1 to the destination in Domain 2, but the domains are extremely private about their path and topology info. Respect the boundaries, girls 🔒
--------------------- -----------------------------
| Domain 1 | | Domain 2 |
| | | |
| --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ |
| ---/ | | / / \--- |
| |Src| | | / / |Dst| |
| ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- |
| | | |
--------------------- -----------------------------Figure 2: A Simple Multi-domain Network
Here's the tea ☕ The first LSP is signaled by the source with the ERO {A, B, loose Dst}, and it gets set up along the path {Src, A, B, U, V, W, Dst}. But when node U sends the Record Route Object (RRO) out of Domain 2, it would normally strip the path and replace it with a loose hop to the destination. With that little info, the source can't include enough detail in the ERO of the second LSP to stop it taking, for example, the path {Src, C, D, X, V, W, Dst} for path-disjointness. Not okay 😭
So, to support LSP diversity, node U consults the PCE and replaces the path segment {U, V, W} in the RRO with a Path Key subobject. The PCE function assigns an "identifier" and puts it into the Path Key field of the Path Key subobject. The PCE ID in the message shows that node U is the one who did this replacement 🫧
With that extra info, the source node can signal the subsequent LSPs with the ERO set to {C, D, exclude Path Key (signaled in the EXRS RSVP subobject), loose Dst}. When the signaling message reaches node X, it can consult the PCE function associated with node U to expand the Path Key, so it can calculate a path that's diverse with respect to the first LSP 💖 Alternatively, the source node could use an ERO of {C, D, loose Dst} and include an XRO containing the Path Key. Two paths to slay ✨
This mechanism works with all the Path Key resolution mechanisms, as detailed in Section 3.1 of [RFC5553]. A PCE, co-located or not, may be used to resolve the Path Key. The node (a Label Switching Router (LSR)) can also use the Path Key information to index a path segment that was previously supplied to it by the entity that originated the Path Key, such as the LSR that inserted the Path Key in the RRO or a management system 🧚♀️
1.5. Network-Assigned Identifier 🎀
There are scenarios where the network provides diversity-related information for a service, and that lets the client device include this info in the signaling message. If the Shared Risk Link Group (SRLG) identifier information is both available and shareable (by policy) with the ENs, the procedure defined in [RFC8001] can be used to collect SRLG identifiers associated with an LSP (LSP1). Then, when a second LSP (LSP2) needs to be diverse with respect to LSP1, the EN building the RSVP signaling message for LSP2 can insert the SRLG identifiers associated with LSP1 as diversity constraints into the XRO, using the procedure described in [RFC4874]. Ah, but if the core network SRLG identifiers are either not available, or not shareable with the ENs based on policies the core network enforces, then the existing mechanisms just can't be used 😤
So in this document, a signaling mechanism is defined where information signaled to the CN via the UNI does not require shared knowledge of core network SRLG information. For this, the concept of a Path Affinity Set (PAS) is defined to abstract SRLG information. The whole motive behind the PAS is to minimize the exchange of diversity information between the core network (CNs) and the client devices (ENs). The PAS contains an abstract SRLG identifier associated with a given path, rather than a detailed SRLG list. It's a single identifier that can be used to both request diversity and associate diversity, which is very efficient energy 🍓 How the processing node figures out the path that corresponds to the PAS is beyond the scope of this document 🫶
A CN on the core network boundary interprets a specific PAS identifier (for example, "123") as meaning "exclude the core network SRLG information (or equivalent) that has been allocated by LSPs associated with this PAS identifier value." For example, if a path exists for the LSP with the PAS identifier "123", the CN would use local knowledge of the core network SRLGs associated with the LSPs tagged with PAS attribute "123", and use those SRLGs as constraints for path computation. And if a PAS identifier is used as an exclusion identifier in the connection request, the CN (UNI-N) in the core network is assumed to be able to determine the existing core network SRLG information and calculate a path that meets the determined diversity constraints 🧠
When a CN satisfies a connection setup for an SRLG-diverse signaled path, the CN may optionally record the core network SRLG information for that connection in terms of CN-based parameters, and associate that with the EN addresses in the Path message. Specifically, for Layer 1 Virtual Private Networks (L1VPNs), Port Information Tables (PITs) [RFC5251] can be leveraged to translate between client (EN) addresses and core network addresses 🌷
The means to distribute the PAS information within the core network is beyond the scope of this document. For example, the PAS and the associated SRLG information can be distributed within the core network by an Interior Gateway Protocol (IGP), or by other means such as configuration. Regardless of which means is used to distribute the PAS information, that information is kept inside the core network and is not shared with the overlay network (see Figure 1). Secrets stay in the core, bestie 🤫🔐
2. RSVP-TE Signaling Extensions ⚡
This section describes the signaling extensions required to address the aforementioned requirements and use cases. Let's get into the good stuff 💅
2.1. Diversity XRO Subobject 🦋
New Diversity XRO subobjects are defined below for the IPv4 and IPv6 address families. Most of the fields in the IPv4 and IPv6 Diversity XRO subobjects are common, and they're described after the definition of the two subobjects, so no need to memorize the same thing twice 🧚
The IPv4 Diversity XRO subobject is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Similarly, the IPv6 Diversity XRO subobject is defined as follows:
Okay so the first thing you need to know is the header layout, bestie 🎀 Everything after this is just labelling the bits of it:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L: The L flag works exactly the same way as it does for the XRO subobjects defined in [RFC4874], so:
0means the diversity constraints MUST be satisfied, and1means the diversity constraints SHOULD be satisfied.
XRO Type: It's set to 38 for the IPv4 Diversity XRO subobject, and 39 for the IPv6 Diversity XRO subobject. 🦋
Length: Following [RFC4874], the Length is the total size of the IPv4/IPv6 subobject in bytes, counting the XRO Type and Length fields too. It's variable, because it depends on how big the Diversity Identifier Value is. 📏
Diversity Identifier Type (DI Type): This one tells you how the reference LSP(s) or route(s) that you want to be diverse from get identified inside the IPv4/IPv6 Diversity subobjects. This document defines exactly three DI Type values, and they look like this:
DI Type value Definition
------------- --------------------------------
1 Client-Initiated Identifier
2 PCE-Allocated Identifier
3 Network-Assigned IdentifierAttribute Flags (A-Flags): The A-Flags tell everyone about the nice-to-have traits of the LSP being signaled in the IPv4/IPv6 Diversity subobjects. Each flag works on its own, and you're allowed to combine any of them. 💅
0x01= Destination node exception: the exclusion doesn't apply to the destination node of the LSP being signaled.0x02= Processing node exception: the exclusion doesn't apply to the node(s) doing ERO expansion for the LSP being signaled. An ingress UNI-N node is one example of that kind of node.0x04= Penultimate node exception: the penultimate node of the LSP being signaled MAY be shared with the excluded path, even if that breaks the exclusion flags. This comes in handy when an EN isn't dual homed, like EN4 in Figure 1, where every LSP has to go through CN5. 🧚0x08= LSP ID to be ignored: this one is for tunnel-level exclusion. If the diversity identifier has an LSP ID field, that LSP ID gets ignored, and the exclusion covers any LSP that matches the rest of the diversity identifier. 🌸
The "Penultimate node exception" flag is usually set when the destination node is single homed, like EN1 or EN4 in Figure 2. In that case, LSP diversity can only be achieved inside the core network up to the egress node, and the penultimate hop has to be the same for all the LSPs. 😭
Exclusion Flags (E-Flags): These say what kind(s) of exclusion you're asking for in the IPv4/IPv6 Diversity subobjects. The flags defined are below, and you can mix and match any of them. Also, the A-Flags can change what exclusion actually applies, so keep that in mind. For example, the node exclusion flag gets ignored for the penultimate node when the "Penultimate node exception" flag of the A-Flags is set. 👑
0x01= SRLG exclusion: the path of the LSP being signaled is requested to be SRLG disjoint with respect to the excluded path given by the IPv4/IPv6 Diversity XRO subobject.0x02= Node exclusion: the path of the LSP being signaled is requested to be "node diverse" from the excluded path given by the IPv4/IPv6 Diversity XRO subobject.0x04= Link exclusion: the path of the LSP being signaled is requested to be "link diverse" from the path given by the IPv4/IPv6 Diversity XRO subobject.0x08= Reserved: this flag is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt, for both the IPv4/IPv6 Diversity XRO subobjects. 🙈
Resvd: This field is reserved too. It MUST be set to zero on transmission and MUST be ignored on receipt, for both the IPv4/IPv6 Diversity XRO subobjects. 🍓
IPv4/IPv6 Diversity Identifier Source Address: This field MUST be set to the IPv4/IPv6 address of the node that assigns the diversity identifier. Depending on the Diversity Identifier Type, that source could be a client node, a PCE entity, or a network node. Specifically:
- When the Diversity Identifier Type is set to the "Client-Initiated Identifier", the value MUST be set to the IPv4/IPv6 tunnel sender address of the reference LSP that diversity is wanted against. The IPv4/IPv6 tunnel sender address is defined in [RFC3209].
- When the Diversity Identifier Type is set to "PCE-Allocated Identifier", the value MUST be set to the IPv4/IPv6 address of the node that assigned the Path Key identifier and that can either return an expansion of the Path Key or use the Path Key as an exclusion in a path computation. The Path Key is defined in [RFC5553]. The PCE ID is carried in the Diversity Identifier Source Address field of the subobject.
- When the Diversity Identifier Type is set to "Network-Assigned Identifier", the value MUST be set to the IPv4/IPv6 address of the node allocating the Path Affinity Set (PAS). 🦄
Diversity Identifier Value: How this field is encoded depends on the Diversity Identifier Type, so here's each one. ✨
When the Diversity Identifier Type is set to "Client-Initiated Identifier" in the IPv4 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The IPv4 Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and LSP ID all work the way they're defined in [RFC3209]. 🎀
When the Diversity Identifier Type is set to "Client-Initiated Identifier" in the IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The IPv6 Tunnel Endpoint Address, Tunnel ID, IPv6 Extended Tunnel ID, and LSP ID all work the way they're defined in [RFC3209]. 🧁
When the Diversity Identifier Type is set to "PCE-Allocated Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Path Key is defined in [RFC5553]. 🔑
When the Diversity Identifier Type is set to "Network-Assigned Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Path Affinity Set (PAS) Identifier field is a 32-bit value that's only meaningful when it's used together with the Diversity Identifier Source Address field. There are no restrictions on how a node picks a PAS identifier value. Section 1.3 defines the PAS term and gives context on how values may be selected. 💜
2.2. Diversity EXRS Subobject ✨
okay so [RFC4874] is the one that defines the EXRS ERO subobject 💅 an EXRS is how you flag abstract nodes or resources that must not or should not get used on the path between two inclusive abstract nodes or resources in the explicit route 🦋 and an EXRS can hold one or more subobjects of its own, which are called EXRS subobjects [RFC4874] 🧚
bestie, an EXRS MAY include a Diversity subobject as specified in this document 🎀 and the same type values 38 and 39 MUST be used 💜
2.3. Processing Rules for the Diversity XRO and EXRS Subobjects 🌸
the procedure in [RFC4874] for processing the XRO and EXRS is not changed by this document 🙌 the rules for the Diversity XRO and EXRS subobjects are basically the same unless it's explicitly called out 💖 and IPv4 and IPv6 Diversity XRO subobjects follow the same rules as IPv4 and IPv6 Diversity EXRS subobjects, so no drama there ✨
if the processing node can't recognize the Diversity XRO/EXRS subobject, it's expected to follow the procedure in [RFC4874] 🫶
now the multiple subobjects part, which is giving main character energy 👑 an XRO/EXRS object MAY contain multiple Diversity subobjects of the same DI Type 🌈 for example, if you want to exclude multiple Path Keys, a node MAY include multiple Diversity XRO subobjects, each with a different Path Key 🍓 same vibe for excluding the routes taken by multiple LSPs: a node MAY include multiple Diversity XRO/EXRS subobjects, each with a different LSP identifier 🦋 and to exclude multiple PAS identifiers, a node MAY include multiple Diversity XRO/EXRS subobjects, each with a different PAS identifier 💅
BUT, and this is the important part 😭 all Diversity subobjects in an XRO/EXRS MUST contain the same Diversity Identifier Type ⚠️ if a Path message has an XRO/EXRS with multiple Diversity subobjects of different DI Types, the processing node MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "XRO/EXRS Too Complex" (68/69) 💀
if the processing node recognizes the Diversity XRO/EXRS subobject but doesn't support the DI Type, it MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "Unsupported Diversity Identifier Type" (36) 🙈
for DI Type "Client-Initiated Identifier", all nodes along the path SHOULD process the diversity info signaled in the XRO/EXRS Diversity subobjects so they can check that the diversity constraint is satisfied 🔥 and if a diversity violation is detected, crankback signaling MAY be initiated 🌸
for DI Types "PCE-Allocated Identifier" and "Network-Assigned Identifier", the nodes in the domain that do path computation SHOULD process the diversity info signaled in the XRO/EXRS Diversity subobjects like this ✨ in the PCE case, the ingress node of a domain sends a path computation request from the ingress node to the egress node, including the diversity constraints, to a PCE 🧚 or, in the PAS case, the ingress node can calculate the path for the new LSP from the ingress node to the egress node, taking the diversity constraints into account 🎀 the calculated path then gets carried in the Explicit Route Object (ERO) 💜 so, transit nodes in a domain and the domain egress node SHOULD NOT process the signaled diversity info unless path computation is performed 🙅♀️
while processing the EXRS object, if a loose hop expansion creates another loose hop in the outgoing ERO, the processing node MAY include the EXRS in the newly created loose hop so downstream nodes can process it further 🫶
the A-Flags change how the Diversity XRO/EXRS subobject gets processed 👑
- when the
"Processing node exception"flag is set, the exclusion MUST be ignored for the node processing the XRO or EXRS subobject 🙌 - when the
"Destination node exception"flag is set, the exclusion MUST be ignored for the destination node when processing the XRO subobject 💖 the destination node exception for the EXRS subobject applies to the explicit node identified by the ERO subobject that identifies the next abstract node 🦋 and when the"Destination node exception"flag is set in the EXRS subobject, exclusion MUST be ignored for said node (i.e., the next abstract node) ✨ - when the
"Penultimate node exception"flag is set in the XRO subobject, the exclusion MUST be ignored for the penultimate node on the path of the LSP being established 🌈
the penultimate node exception for the EXRS subobject applies to the node before the explicit node identified by the ERO subobject that identifies the next abstract node 🍓 and when the "Penultimate node exception" flag is set in the EXRS subobject, the exclusion MUST be ignored for said node (i.e., the node before the next abstract node) 💅
if the L-flag of the Diversity XRO subobject or Diversity EXRS subobject is NOT set, the processing node does the following 🌸 (oops, let me be clear: the original says "not set", so it's just not set, no caps needed, lol)
- if the Diversity Identifier Type is
"Client-Initiated Identifier", the processing node MUST ensure that the path calculated or expanded for the signaled LSP is diverse from the route taken by the LSP identified in the Diversity Identifier Value field 🔥 - if the Diversity Identifier Type is
"PCE-Allocated Identifier", the processing node MUST ensure that any path calculated for the signaled LSP is diverse from the route identified by the Path Key 🧚 it MAY use the PCE identified by the Diversity Identifier Source Address in the subobject for route computation 🎀 and it MAY use the Path Key resolution mechanisms described in [RFC5553] 💜 - if the Diversity Identifier Type is
"Network-Assigned Identifier", the processing node MUST ensure that the path calculated for the signaled LSP is diverse with respect to the values associated with the PAS Identifier and Diversity Identifier Source Address fields 🦋 - regardless of whether path computation happens locally or at a remote node (e.g., a PCE), the processing node MUST ensure that any path calculated for the signaled LSP is diverse from the requested Exclusion Flags 🙌
- if the excluded path referenced in the XRO subobject is unknown to the processing node, the processing node SHOULD ignore the Diversity XRO subobject and SHOULD proceed with the signaling request 🫶 then, after sending the Resv for the signaled LSP, the processing node MUST return a PathErr with the error code
"Notify Error"(25) and error sub-code"Route of XRO LSP identifier unknown"(14) for the signaled LSP 😭 - if the processing node can't find a path that meets the requested constraint, it MUST return a PathErr with the error code
"Routing Problem"(24) and error sub-code"Route blocked by Exclude Route"(67) 💀
if the L-flag of the Diversity XRO subobject or Diversity EXRS subobject IS set, the processing node does this instead 👑 (again, the L-flag is set here, the flag just means it's on)
- if the Diversity Identifier Type is
"Client-Initiated Identifier", the processing node SHOULD ensure that the path calculated or expended for the signaled LSP is diverse from the route taken by the LSP identified in the Diversity Identifier Value field 🌸 - if the Diversity Identifier Type is
"PCE-Allocated Identifier", the processing node SHOULD ensure that the path calculated for the signaled LSP is diverse from the route identified by the Path Key 🧚 - if the Diversity Identifier Type is
"Network-Assigned Identifier", the processing node SHOULD ensure that the path calculated for the signaled LSP is diverse with respect to the values associated with the PAS Identifier and Diversity Identifier Source Address fields 🦋 - if the processing node can't find a path that meets the requested constraint, it SHOULD proceed with signaling using a suitable path that meets the constraint as far as possible 🍓 after sending the Resv for the signaled LSP, it MUST return a PathErr message with error code
"Notify Error"(25) and error sub-code"Failed to satisfy Exclude Route"(15) to the source node 💖
now, if, after the initial signaling of a diverse LSP, an excluded path referenced in the XRO subobject becomes known to the processing node (or a change in the excluded path becomes known), the processing node MUST re-evaluate the exclusion and diversity constraints requested by the diverse LSP to see whether they're still satisfied 🔥
- in the case where the L-flag was not set in the initial setup message, the exclusion and diversity constraints were satisfied at the time of the initial setup 🌈 if the processing node re-evaluating them for a diverse LSP detects that they're no longer met, it MUST send a PathErr message for the diverse LSP with the error code
"Routing Problem"(24) and error sub-code"Route blocked by Exclude Route"(67) 💅 the Path_State_Removed (PSR) flag [RFC3473] MUST NOT be set 🙅♀️ and a source node receiving a PathErr message with this error code and sub-code combination SHOULD take appropriate actions and move the diverse LSP to a new path that meets the original constraints 🎀 - in the case where the L-flag was set in the initial setup message, the exclusion and diversity constraints may or may not be satisfied at any given time 🦋 if the exclusion constraints for a diverse LSP were satisfied before, and the processing node re-evaluating them detects that the exclusion and diversity constraints are no longer met, it MUST send a PathErr message for the diverse LSP with the error code
"Notify Error"(25) and error sub-code"Failed to satisfy Exclude Route"(15) ✨ the PSR flag MUST NOT be set 🙅♀️ and the source node MAY take no consequent action and keep the LSP along the path that doesn't meet the original constraints 🫶 similarly, if the exclusion constraints for a diverse LSP were NOT satisfied before, and the processing node re-evaluating them detects that the exclusion constraints are met, it MUST send a PathErr message for the diverse LSP with the error code"Notify Error"(25) and a new error sub-code"Compliant path exists"(16) 🌈 the PSR flag MUST NOT be set 🙅♀️ and a source node receiving a PathErr message with this error code and sub-code combination MAY move the diverse LSP to a new path that meets the original constraints 💖
3. Security Considerations 🔐
okay bestie, this part is super important so pay attention 🫶 this document doesn't add any new security issues on top of the ones already covered in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC2747], [RFC4874], [RFC5520], and [RFC5553] ✨
the diversity mechanisms here rely on the new diversity subobject, which gets carried in the XRO or the EXRS (whichever one you're using) 💅 in Section 7 of [RFC4874], it's noted that some administrative boundaries may remove the XRO because of security concerns about exchanging explicit route information 😬
BUT here's the tea 🍵 if you're using the diversity subobjects from this doc, removing an XRO that contains them at the boundary means the diversity request just gets dropped right there, and path computation would be unlikely to come back with the diverse path you asked for 💀 so diversity subobjects MUST be retained in an XRO crossing an administrative boundary, even if other subobjects are removed 🔥 whether that retention happens is based on operator policy 📜
also the use of diversity subobjects is based on mutual agreement, and that's iconic because it avoids the need to share the identity of network resources when supporting diversity 🦋🫶
4. IANA Considerations 📋
IANA has assigned the new values defined in this document, and they're all summarized right here in this section 🌸
4.1. New XRO Subobject Types 🎀
in the IANA registry for RSVP parameters, under "Class Names, Class Numbers, and Class Types", this document defines two new subobjects for the EXCLUDE_ROUTE object [RFC4874], C-Type 1 (see "Class Types or C-Types - 232 EXCLUDE_ROUTE" on <https://www.iana.org/assignments/rsvp-parameters>) ✨
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+4.2. New EXRS Subobject Types 🧚
the Diversity XRO subobjects are also defined as new EXRS subobjects (see "Class Types or C-Types - 20 EXPLICIT_ROUTE" on <https://www.iana.org/assignments/rsvp-parameters>) 💖 they got the same numeric values too:
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+4.3. New RSVP Error Sub-codes 🚨
in the IANA registry for RSVP parameters, under "Error Codes and Globally Defined Error Value Sub-Codes", for Error Code "Routing Problem" (24) (see [RFC3209]), the following sub-codes are defined (see "Sub-Codes - 24 Routing Problem" on <https://www.iana.org/assignments/rsvp-parameters>) 🍓
+-------+---------------------------------------+-----------+
| Value | Description | Reference |
+-------+---------------------------------------+-----------+
| 36 | Unsupported Diversity Identifier Type | RFC 8390 |
+-------+---------------------------------------+-----------+for Error Code "Notify Error" (25) (see [RFC3209]), the following sub-codes are defined (see "Sub-Codes - 25 Notify Error" on <https://www.iana.org/assignments/rsvp-parameters>) 🌈
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 14 | Route of XRO LSP identifier unknown | RFC 8390 |
| 15 | Failed to satisfy Exclude Route | RFC 8390 |
| 16 | Compliant path exists | RFC 8390 |
+-------+-------------------------------------+-----------+5. References 📚
5.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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <https://www.rfc-editor.org/info/rfc2747>.
[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,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/info/rfc4202>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
April 2007, <https://www.rfc-editor.org/info/rfc4874>.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N.,
and G. Ash, "Crankback Signaling Extensions for MPLS and
GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007,
<https://www.rfc-editor.org/info/rfc4920>.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, DOI 10.17487/RFC5553, May 2009,
<https://www.rfc-editor.org/info/rfc5553>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.5.2. Informative References 🦋
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>.
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode",
RFC 5251, DOI 10.17487/RFC5251, July 2008,
<https://www.rfc-editor.org/info/rfc5251>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520,
DOI 10.17487/RFC5520, April 2009,
<https://www.rfc-editor.org/info/rfc5520>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC8001] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C.,
Hartley, M., and Z. Ali, "RSVP-TE Extensions for
Collecting Shared Risk Link Group (SRLG) Information",
RFC 8001, DOI 10.17487/RFC8001, January 2017,
<https://www.rfc-editor.org/info/rfc8001>.Acknowledgements 🙏
big thank you from the authors to Xihua Fu for his contributions 🫶 they also want to thank Luyuan Fang and Walid Wakim for reviewing and commenting ✨
Contributors 🌟
Igor Bryskin
Huawei Technologies
Email: Igor.Bryskin@huawei.com
Daniele Ceccarelli
Ericsson
Email: Daniele.Ceccarelli@ericsson.com
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Don Fedyk
Hewlett-Packard Enterprise
Email: don.fedyk@hpe.com
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Gabriele Maria Galimberti
Cisco Systems
Email: ggalimbe@cisco.com
Ori Gerstel
SDN Solutions Ltd.
Email: origerstel@gmail.com
Oscar Gonzalez de Dios
Telefonica I+D
Email: ogondio@tid.es
Matt Hartley
Cisco Systems
Email: mhartley@cisco.com
Kenji Kumaki
KDDI Corporation
Email: ke-kumaki@kddi.com
Ruediger Kunze
Deutsche Telekom AG
Email: Ruediger.Kunze@telekom.de
Lieven Levrau
Nokia
Email: Lieven.Levrau@nokia.com
Cyril Margaria
Email: cyril.margaria@gmail.com
Julien Meuric
France Telecom Orange
Email: julien.meuric@orange.com
Yuji Tochio
Fujitsu
Email: tochio@jp.fujitsu.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.comAuthors' Addresses 🦋
Zafar Ali (editor)
Cisco Systems.
Email: zali@cisco.com
George Swallow (editor)
Southend Technical Center
Email: swallow.ietf@gmail.com
Fatai Zhang (editor)
Huawei Technologies
Email: zhangfatai@huawei.com
Dieter Beller (editor)
Nokia
Email: Dieter.Beller@nokia.com📦 where this page comes from
- ietf: rfc8390 2018-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms