RFC 4874
Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ✨
okay bestie, this is RFC 4874 🎀 It's a Standards Track document, which means it's a real spec for the Internet, not just vibes. It was dated April 2007 and written by CY. Lee and A. Farrel (Old Dog Consulting) plus S. De Cnodder (Alcatel-Lucent), all under the Network Working Group. It updates RFC 3209 and RFC 3473, so it's adding onto those two, not replacing them 🦋
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 📨
Copyright Notice
Copyright (C) The IETF Trust (2007). ©️
Abstract
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). 🌸
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. 🙈 That's the gap this doc fills.
In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. 🧚
Table of Contents 💅
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Scope of Exclude Routes ....................................4
1.3. Relationship to MPLS TE MIB ................................5
2. Shared Risk Link Groups .........................................6
2.1. SRLG Subobject .............................................6
3. Exclude Route List ..............................................7
3.1. EXCLUDE_ROUTE Object (XRO) .................................7
3.1.1. IPv4 Prefix Subobject ...............................8
3.1.2. IPv6 Prefix Subobject ...............................9
3.1.3. Unnumbered Interface ID Subobject ..................10
3.1.4. Autonomous System Number Subobject .................10
3.1.5. SRLG Subobject .....................................11
3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO) .......11
4. Explicit Exclusion Route .......................................13
4.1. Explicit Exclusion Route Subobject (EXRS) .................13
4.2. Processing Rules for the Explicit Exclusion Route
Subobject (EXRS) ..........................................15
5. Processing of XRO together with EXRS ...........................16
6. Minimum Compliance .............................................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................17
8.1. New ERO Subobject Type ....................................17
8.2. New RSVP-TE Class Numbers .................................18
8.3. New Error Codes ...........................................18
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Applications ..........................................21
A.1. Inter-Area LSP Protection .................................21
A.2. Inter-AS LSP Protection ...................................22
A.3. Protection in the GMPLS Overlay Model .....................24
A.4. LSP Protection inside a Single Area .......................251. Introduction ✨
The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup, using the Explicit Route Object (ERO). 🦋
In some systems, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. This may be because loose hops or abstract nodes need to be prevented from selecting a route through a specific resource. This is a special case of distributed path calculation in the network. 💖
For example, route exclusion could be used in the case where two non-overlapping Label Switched Paths (LSPs) are required. In this case, one option might be to set up one path and collect its route using route recording, and then to exclude the routers on that first path from the setup for the second path. Another option might be to set up two parallel backbones, dual home the provider edge (PE) routers to both backbones, and then exclude the local router on backbone A the first time that you set up an LSP (to a particular distant PE), and exclude the local router on backbone B the second time that you set up an LSP. 🌈
Two types of exclusions are required:
- Exclusion of certain abstract nodes or resources on the whole path. This set of abstract nodes is referred to as the Exclude Route list.
- Exclusion of certain abstract nodes or resources between a specific pair of abstract nodes present in an ERO. Such specific exclusions are referred to as Explicit Exclusion Route.
To convey these constructs within the signaling protocol, a new RSVP object and a new ERO subobject are introduced respectively. 👑
- A new RSVP-TE object is introduced to convey the Exclude Route list. This object is the EXCLUDE_ROUTE object (XRO).
- The second type of exclusion is achieved through a modification to the existing ERO. A new ERO subobject type the Explicit Exclusion Route Subobject (EXRS) is introduced to indicate an exclusion between a pair of included abstract nodes.
The knowledge of SRLGs, as defined in [RFC4216], may be used to compute diverse paths that can be used for protection. In systems where it is useful to signal exclusions, it may be useful to signal SRLGs to indicate groups of resources that should be excluded on the whole path or between two abstract nodes specified in an explicit path. 🫶
This document introduces a subobject to indicate an SRLG to be signaled in either of the two exclusion methods described above. This document does not assume or preclude any other usage for this subobject. This subobject might also be appropriate for use within an Explicit Route object (ERO) or Record Route object (RRO), but this is outside the scope of this document. 💅
1.1. Requirements Notation 📝
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]. 🔥
1.2. Scope of Exclude Routes 🍓
This document does not preclude a route exclusion from listing arbitrary nodes or network elements to avoid. The intent is, however, to indicate only the minimal number of subobjects to be explicitly avoided. For instance, it may be necessary to signal only the SRLGs (or Shared Risk Link Groups) to avoid. That is, the route exclusion is not intended to define the actual route by listing all of the choices to exclude at each hop, but rather to constrain the normal route selection process where loose hops or abstract nodes are to be expanded by listing certain elements to be avoided. 🎀
It is envisaged that most of the conventional inclusion subobjects are specified in the signaled ERO only for the area where they are pertinent. The number of subobjects to be avoided, specified in the signaled XRO, may be constant throughout the whole path setup, or the subobjects to be avoided may be removed from the XRO as they become irrelevant in the subsequent hops of the path setup. ⭐
For example, consider an LSP that traverses multiple computation domains. A computation domain may be an area in the administrative or IGP sense, or may be an arbitrary division of the network for active management and path computational purposes. Let the primary path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where:
- Xn denotes a node in domain X, and
- XYn denotes a node on the border of domain X and domain Y.
Note that Ingress is a node in domain A, and Egress is a node in domain C. This is shown in Figure 1 where the domains correspond with areas. 🗺️
area A area B area C
<-------------------> <----------------> <------------------>
Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
^ \ / | \ / | \ /
| \ / | \ / | \ /
| A3----------A4--AB2--B3--------B4--BC2--C3----------C4
| ^ ^
| | |
| | |
| | ERO: (C3-strict, C4-strict,
| | Egress-strict)
| | XRO: Not needed
| |
| ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
| XRO: (BC1, C1, C2)
|
ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
XRO: (AB1, B1, B2, BC1, C1, C2, Egress)
Figure 1: Domains Corresponding to IGP AreasConsider the establishment of a node-diverse protection path in the example above. The protection path must avoid all nodes on the primary path. The exclusions for area A are handled during Constrained Shortest Path First (CSPF) computation at Ingress, so the ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, AB2-strict, Egress-loose) and (AB1, B1, B2, BC1, C1, C2), respectively. At AB2, the ERO and XRO could be (B3-strict, B4-strict, BC2-strict, Egress-loose) and (BC1, C1, C2), respectively. At BC2, the ERO could be (C3-strict, C4-strict, Egress-strict) and an XRO is not needed from BC2 onwards. 🧩
In general, consideration SHOULD be given (as with explicit route) to the size of signaled data and the impact on the signaling protocol. 📦
1.3. Relationship to MPLS TE MIB 🦋
[RFC3812] defines managed objects for managing and modeling MPLS-based traffic engineering. Included in [RFC3812] is a means to configure explicit routes for use on specific LSPs. This configuration allows the exclusion of certain resources. 🌸
In systems where the full explicit path is not computed at the ingress (or at a path computation site for use at the ingress), it may be necessary to signal those exclusions. This document offers a means of doing this signaling. 💜
2. Shared Risk Link Groups ✨
okay so an SRLG ID is a 32-bit number, and that's defined over in [RFC4202] 🧚 this doc introduces an SRLG subobject so you can use it in the exclusion methods we're about to get into. this doc doesn't assume or rule out any other use for the subobject, no cap. it might also fit inside an Explicit Route object (ERO) or Record Route object (RRO), but that's outside the scope of this doc, so we're not going there today 🙈
2.1. SRLG Subobject
the new SRLG subobject is defined here, and it's modeled on the ERO subobjects from [RFC3209] 💖 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L 🦋 The L bit is an attribute of the subobject. It's set if the subobject represents a loose hop in the explicit route. If it's not set, the subobject represents a strict hop instead.
For exclusions (the XRO and EXRS stuff defined in this doc), the L bit SHOULD be set to zero and ignored. 💅
Type 🌸 The type of the subobject is 34.
Length 🎀 The Length is the total length of the subobject in bytes, including the Type and Length fields. It's always 8, so no surprises there ✨
SRLG Id 🍓 The 32-bit identifier of the SRLG.
Reserved 🫶 This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
3. Exclude Route List
the exclude route is basically a list of abstract nodes that SHOULD NOT get traversed on the path of the LSP being set up 🧚 it is RECOMMENDED that the size of this list gets limited to a value that's local to the node originating the exclude route list. main character energy for keeping it small 👑
3.1. EXCLUDE_ROUTE Object (XRO)
abstract nodes you want left out of the path get specified through the EXCLUDE_ROUTE object, aka the XRO 💜
right now there's just one C_Type defined: Type 1 EXCLUDE_ROUTE. The object looks like this:
Class = 232, C_Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+so the contents are a bunch of variable-length items called subobjects 🌈 this spec takes ERO subobjects from [RFC3209], [RFC3473], and [RFC3477] and adapts them for route exclusions. the SRLG subobject from Section 2 of this document is brand new, it hasn't been defined anywhere before, and it's defined here specifically for route exclusions. iconic 🙌
these are the subobject types that are supported:
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLGthe defined values for Type up there are specified in [RFC3209] and in this document, so you can look in both places 🔥
okay now the L bit, because this is the important bit ✨ loose and strict hops mean nothing in route exclusion 🙈 so the L bit (defined for ERO subobjects in [RFC3209]) gets reused here to say whether an abstract node MUST be excluded (value 0) or SHOULD be avoided (value 1). the vibe is: the path of an LSP must not traverse an abstract node listed in the XRO with the L bit clear, but it's allowed to traverse one with the L bit set 💅
a node that's routing an LSP (say, when it's expanding a loose hop) should attempt to minimize how many abstract nodes listed in the XRO with the L bit set end up getting traversed by the LSP, according to local policy 🦋 and a node generating XRO subobjects with the L bit set must be prepared to accept an LSP that traverses one, some, or all of the matching abstract nodes. no drama, just be ready 🫶
subobjects 1, 2, and 4 refer to an interface or a set of interfaces. so an Attribute octet gets introduced in these subobjects to say what kind of thing (interface, node, SRLG, etc.) is associated with the interfaces that should be excluded from the path 💖 for example, the node attribute lets you exclude a whole node just by naming one of its interfaces in the XRO subobject 👑 the interface attribute, on the other hand, lets you exclude one specific interface (or several) without taking the entire node out 🍓 and the SRLG attribute lets you exclude all the SRLGs associated with an interface 🧚
3.1.1. IPv4 Prefix Subobject
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| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L 🌸 0 means the attribute specified MUST be excluded. 1 means the attribute specified SHOULD be avoided.
Attribute 💅
Interface attribute values 🦋 0 means the interface or set of interfaces associated with the IPv4 prefix should be excluded or avoided.
Node attribute value 🎀 1 means the node or set of nodes associated with the IPv4 prefix should be excluded or avoided.
SRLG attribute values 🍓 2 means all the SRLGs associated with the IPv4 prefix should be excluded or avoided.
the rest of the fields are as defined in [RFC3209] 🫶
3.1.2. IPv6 Prefix Subobject
same energy as the IPv4 one, just bigger because IPv6 addresses are 16 bytes 🌈
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| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L ✨ 0 means the attribute specified MUST be excluded. 1 means the attribute specified SHOULD be avoided.
Attribute 💖
Interface attribute value 🧚 0 means the interface or set of interfaces associated with the IPv6 prefix should be excluded or avoided.
Node attribute value 👑 1 means the node or set of nodes associated with the IPv6 prefix should be excluded or avoided.
SRLG attribute value 🍓 2 means all the SRLGs associated with the IPv6 prefix should be excluded or avoided.
the rest of the fields are as defined in [RFC3209] 💅
3.1.3. Unnumbered Interface ID Subobject
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| Type | Length | Reserved | Attribute |
| | | |(must be zero) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L 🦋 0 means the attribute specified MUST be excluded. 1 means the attribute specified SHOULD be avoided.
Attribute 🎀
Interface attribute value 🌸 0 means the Interface ID specified should be excluded or avoided.
Node attribute value 💜 1 means the node with the Router ID should be excluded or avoided. yes, you can get this with an IPv4/v6 subobject too 🙈 but it's here because it may be convenient to use info from subobjects of an RRO (defined in [RFC3477]) when you're specifying the exclusions 🧚
SRLG attribute value 🍓 2 means all the SRLGs associated with the interface should be excluded or avoided.
Reserved 🫶 This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
the rest of the fields are as defined in [RFC3477] 💅
3.1.4. Autonomous System Number Subobject
the L bit here means:
0 indicates that the abstract node specified MUST be excluded.
1 indicates that the abstract node specified SHOULD be avoided.the rest of the fields are as defined in [RFC3209]. There is no Attribute octet defined for this one 🌈
3.1.5. SRLG Subobject
the L bit here means:
0 indicates that the SRLG specified MUST be excluded
1 indicates that the SRLG specified SHOULD be avoidedthe Attribute octet is not present, and the rest of the fields are as defined in the "SRLG Subobject" section of this document 🔥
3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO) 🎀
okay so the exclude route list is basically a bunch of subobjects all packed inside one EXCLUDE_ROUTE object 📦✨. Each subobject names one abstract node on the list 💅.
Each abstract node can be a super precise IP address that belongs to one node 🫶, or an IP address with a prefix that covers the interfaces of a whole group of nodes, or an Autonomous System, or an SRLG 🦋.
The Explicit Route and routing processing works exactly like it does in [RFC3209] 💖, just with these extra bits:
- okay bestie, when a Path message shows up at a node, the node MUST check that it is not a member of any of the abstract nodes in the XRO, if the Path message even has one 👀. If the node IS a member of any abstract node in the XRO with the L-flag set to "exclude", it SHOULD send back a PathErr with the error code
"Routing Problem"and the error value"Local node in Exclude Route"💀. If there are SRLGs in the XRO, the node SHOULD check that the resources it uses aren't part of any SRLG with the L-flag set to "exclude" that's specified in the XRO. If they are, it SHOULD return a PathErr with the error code"Routing Problem"and the error value"Local node in Exclude Route"🙈. - every subobject MUST be consistent 🍓. If a subobject isn't consistent, the node SHOULD return a PathErr with the error code
"Routing Problem"and the error value"Inconsistent Subobject". An example of an inconsistent subobject is an IPv4 Prefix subobject that contains the IP address of a node while the attribute field is set to "interface" or "SRLG". it's giving contradiction energy 😭. - the subobjects in the ERO and XRO SHOULD NOT contradict each other 🌸. If a Path message comes in with contradicting ERO and XRO subobjects, then:
- XRO subobjects with the L flag not set (zero) MUST take precedence over the subobjects in the ERO. So a mandatory exclusion expressed in the XRO MUST be honored, and an implementation MUST reject that Path message 🔥. This means a PathErr with the error code
"Routing Problem"and the error value"Route blocked by Exclude Route"gets returned. - XRO subobjects with the L flag set do NOT take precedence over ERO subobjects. So an implementation MAY choose to reject a Path message because of the contradiction, but it MAY also keep going and set up the LSP, ignoring the XRO subobjects that contradict the ERO subobjects ✨.
- XRO subobjects with the L flag not set (zero) MUST take precedence over the subobjects in the ERO. So a mandatory exclusion expressed in the XRO MUST be honored, and an implementation MUST reject that Path message 🔥. This means a PathErr with the error code
- when a node is choosing a next hop or expanding an explicit route to include more subobjects, it:
a. MUST NOT introduce an explicit node or an abstract node that equals, or is a member of, any abstract node specified in the EXCLUDE_ROUTE object with the L-flag set to "exclude". The number of introduced explicit nodes or abstract nodes with the L flag set to "avoid" (which means it's not mandatory to exclude them, just less preferred) SHOULD be minimized in the computed path 🧚.
b. MUST NOT introduce links, nodes, or resources identified by the SRLG Id specified in the SRLG subobject(s). The number of introduced SRLGs with the L flag set to "avoid" SHOULD be minimized 💜.
If these rules preclude further forwarding of the Path message, the node SHOULD return a PathErr with the error code "Routing Problem" and the error value "Route blocked by Exclude Route" 💀.
Note that the subobjects in the XRO is an unordered list of subobjects 🌈.
A node that receives a Path message carrying an XRO MAY reject the message if the XRO is too large or complicated for the local implementation or the rules of local policy 🙅♀️. In this case, the node MUST send a PathErr message with the error code "Routing Error" and the error value "XRO Too Complex". An ingress LSR that gets this error code and value combo MAY reduce the complexity of the XRO or route around the node that rejected the XRO 🦋.
The XRO Class-Num is of the form 11bbbbbb, so nodes that don't support the XRO forward it uninspected and don't apply the extensions to ERO processing described above 🫶. This approach is chosen so route exclusion can traverse parts of the network that aren't capable of parsing or handling the new function 🌸. Note that Record Route may be used to let computing nodes observe violations of route exclusion and try to re-route the LSP accordingly 👀.
If a node supports the XRO but not a particular subobject, or part of that subobject, then that particular subobject is ignored 💅. Examples of a part of a subobject that can be supported are: (1) only prefix 32 of the IPv4 prefix subobject could be supported, or (2) a particular subobject is supported but not the particular attribute field 🎀.
When a node forwards a Path message, it can do the following three operations related to the XRO, besides the processing rules mentioned above 💖:
- If no XRO was present, an XRO may be included.
- If an XRO was present, it may remove the XRO if it is sure that the next nodes don't need this information anymore. An example is where a node can expand the ERO to a full strict path towards the destination. See Figure 1, where BC2 is removing the XRO from the Path message 🧚.
- If an XRO was present, the content of the XRO can be modified. Subobjects can be added or removed. See Figure 1 for an example where AB2 is stripping off some subobjects ✂️.
In any case, a node MUST NOT introduce any explicit or abstract node in the XRO (irrespective of the value of the L flag) that it also has introduced in the ERO. bestie this one is a hard no 🚫💀.
4. Explicit Exclusion Route 🌈
okay the Explicit Exclusion Route is where we define abstract nodes or resources (like links, unnumbered interfaces, or labels) that must not or should not be used on the path between two inclusive abstract nodes or resources in the explicit route 🦋.
4.1. Explicit Exclusion Route Subobject (EXRS) 💖
a brand new ERO subobject type gets defined here 🎀. The Explicit Exclusion Route Subobject (EXRS) has type 33. Even though the EXRS is an ERO subobject and the XRO is reusing the ERO subobject, an EXRS MUST NOT be present in an XRO 🙅♀️. An EXRS is an ERO subobject that holds one or more subobjects of its own, called EXRS subobjects 🫶.
Here's the format of the EXRS:
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| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// one or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- L: this MUST be set to zero on transmission and MUST be ignored on receipt 🌸. (Note: The L bit in an EXRS subobject is as defined for the XRO subobjects.)
- Type: the type of the subobject, which is 33 ✨.
- Reserved: this field is reserved 🍓. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
- EXRS subobjects: an EXRS subobject indicates the abstract node or resource to be excluded 🦋. The format of an EXRS subobject is exactly the same as the format of a subobject in the XRO. An EXRS may include all subobjects defined in this document for the XRO 💅.
So an EXRS for an IP hop might look 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2. Processing Rules for the Explicit Exclusion Route Subobject (EXRS) 🧚
each EXRS can carry multiple exclusions 💜. The exclusion is encoded exactly like XRO subobjects, prefixed by an additional Type and Length.
The scope of the exclusion is the step between the previous ERO subobject that identifies an abstract node and the next ERO subobject that identifies an abstract node 🦋. The processing rules of the EXRS are the same as the processing rules of the XRO within this scope. Multiple exclusions may be present between any pair of abstract nodes ✨.
Exclusions may indicate explicit nodes, abstract nodes, or Autonomous Systems that must not be traversed on the path to the next abstract node indicated in the ERO 🌸.
Exclusions may also indicate resources (such as unnumbered interfaces, link ids, and labels) that must not be used on the path to the next abstract node indicated in the ERO 🫶.
SRLGs can also be marked for exclusion from the path to the next abstract node in the ERO, by including an EXRS that contains an SRLG subobject 🦋. If the L bit in the SRLG subobject is zero, the resources (nodes, links, etc.) identified by the SRLG MUST NOT be used on the path to the next abstract node indicated in the ERO 🚫. If the L bit is set, the resources identified by the SRLG SHOULD be avoided 💅.
If a node is called upon to process an EXRS and doesn't support handling exclusions, it will behave as described in [RFC3209] when an unrecognized ERO subobject is encountered 🙈. That means this node will return a PathErr with the error code "Routing Error" and the error value "Bad EXPLICIT_ROUTE object", with the EXPLICIT_ROUTE object included, truncated (on the left) to the offending EXRS 💀.
If the presence of the EXRS precludes further forwarding of the Path message, the node SHOULD return a PathErr with the error code "Routing Problem" and the error value "Route Blocked by Exclude Route" 🍓.
A node MAY reject a Path message if the EXRS is too large or complicated for the local implementation, or as governed by local policy 🙅♀️. In this case, the node MUST send a PathErr message with the error code "Routing Error" and the error value "EXRS Too Complex". An ingress LSR that receives this error code and value combo MAY reduce the complexity of the EXRS or route around the node that rejected the EXRS ✨.
5. Processing of XRO together with EXRS 👑
when an LSR does ERO expansion and finds both the XRO in the Path message and an EXRS in the ERO, it MUST exclude all the SRLGs, nodes, links, and resources listed in both places 🔥. Where some elements appear in both lists, it MUST be handled according to the stricter exclusion request 💅. That is, if one list says that an SRLG, node, link, or resource must be excluded, and the other says only that it should be avoided, then the element MUST be excluded 💖.
6. Minimum Compliance 🎀
Okay so this is the bare minimum an implementation MUST be at least compliant with, bestie 💅:
- The XRO MUST be supported with the following restrictions:
- The IPv4 Prefix subobject MUST be supported with a prefix length of 32, and an attribute value of
"interface"and"node". Other prefix values and attribute values MAY be supported. - The IPv6 Prefix subobject MUST be supported with a prefix length of 128, and an attribute value of
"interface"and"node". Other prefix values and attribute values MAY be supported.
- The IPv4 Prefix subobject MUST be supported with a prefix length of 32, and an attribute value of
- The EXRS MAY be supported 🦋. If it is supported, the same restrictions as for the XRO apply. If it is not supported, an EXRS encountered during normal ERO processing MUST be rejected as an unknown ERO subobject, as described in Section 4.2. Note that a node SHOULD NOT parse ahead into an ERO, and if it does, it MUST NOT reject the ERO if it discovers an EXRS that applies to another node. Not me being the one who rejects someone else's stuff 🙈
- If XRO or EXRS are supported, the implementation MUST be compliant with the processing rules of the supported, not supported, or partially supported subobjects as specified within this document. Basically, follow the rules for whatever you actually support, periodt ✨
7. Security Considerations 🔒
Okay, security is serious, so listen up 🫶 The security considerations for MPLS-TE and GMPLS signaling are covered in [RFC3209] and [RFC3473]. This document does not introduce any new messages or any substantive new processing, so those security considerations continue to apply. No new drama, just the old drama 💀
Any security concerns that exist with explicit routes should be considered with regard to route exclusions. For example, some administrative boundaries may consider explicit routes to be security violations and may strip EROs from the Path messages that they process. In this case, the XRO should also be considered for removal from the Path message. Lowkey the XRO and the ERO should be treated as a team 💜
It is possible that an arbitrarily complex XRO or EXRS sequence could be introduced as a form of denial-of-service attack, since its presence will potentially cause additional processing at each node on the path of the LSP. It should be noted that such an attack assumes that an otherwise trusted LSR (i.e., one that has been authenticated by its neighbors) is misbehaving. A node that receives an XRO or EXRS sequence that it considers too complex according to its local policy may respond with a PathErr message carrying the error code"Routing Error"and error value"XRO Too Complex"or"EXRS Too Complex". Denial of service with a too-complex XRO is absolutely not the vibe 💀🔥
8. IANA Considerations 🍓
It might be considered that an alternative approach would be to assign one of the bits of the ERO subobject type field (perhaps the top bit) to identify that a subobject is intended for inclusion rather than exclusion. However, [RFC3209] states that the type field (seven bits) should be assigned as 0 - 63 through IETF consensus action, 64 - 95 as first come first served, and 96 - 127 are reserved for private use. It would not be acceptable to disrupt existing implementations, so the only option would be to split the IETF consensus range, leaving only 32 subobject types. It is felt that 32 would be an unacceptably small number for future expansion of the protocol. Nah, we are not shrinking the pool 😤
8.1. New ERO Subobject Type 🧚
Here's the registry situation 👑
IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class TypesA new subobject has been added to the existing entry for:
20 EXPLICIT_ROUTEThe registry reads:
33 Explicit Exclusion Route subobject (EXRS)The Explicit Exclusion Route subobject (EXRS) is defined in Section 4.1, "Explicit Exclusion Route Subobject (EXRS)". This subobject may be present in the Explicit Route Object, but not in the Route Record Object or in the new EXCLUDE_ROUTE object, and it should not be listed among the subobjects for those objects. Keep it in its lane, ngl ✨
8.2. New RSVP-TE Class Numbers 🌸
Here's the next registry, obsessed with it 🫶
IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class TypesA new class number has been added for the EXCLUDE_ROUTE object (XRO), as defined in Section 3.1, "EXCLUDE_ROUTE Object (XRO)".
EXCLUDE_ROUTE
Class-Num of type 11bbbbbb
Value: 232
Defined CType: 1 (EXCLUDE_ROUTE)Subobjects 1, 2, 4, and 32 are as defined for the Explicit Route Object. An additional subobject has been registered as requested in Section 8.1, "New ERO Subobject Type". The text should appear as:
Sub-object type
1 IPv4 address [RFC3209]
2 IPv6 address [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
33 Explicit Exclusion Route subobject (EXRS) [RFC4874]
34 SRLG [RFC4874]The SRLG subobject is defined in Section 3.1.5, "SRLG Subobject". The value 34 has been assigned. Iconic, the SRLG finally got its number 🦋
8.3. New Error Codes 💖
Here's the error code situation 😭 The registry is RSVP PARAMETERS, under Error Codes and Globally-Defined Error Value Sub-Codes. New Error Values sub-codes have been registered for the Error Code 'Routing Problem' (24):
64 = Unsupported Exclude Route Subobject Type
65 = Inconsistent Subobject
66 = Local Node in Exclude Route
67 = Route Blocked by Exclude Route
68 = XRO Too Complex
69 = EXRS Too Complex9. Acknowledgments 🫶
This document reuses text from [RFC3209] for the description of EXCLUDE_ROUTE. Credit where it's due 💅
The authors would like to express their thanks to Lou Berger, Steffen Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and Richard Rabbat for their considered opinions on this document. Also thanks to Yakov Rekhter for reminding us about SRLGs! Literally the SRLG hero 👑
Thanks to Eric Gray for providing the GenArt review, and to Ross Callon for his comments. The real MVPs 🌈
10. References 📚
10.1. Normative References 🧠
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.10.2. Informative References 📖
[CRANKBACK] Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S.
Marshall-Unitt, "Crankback Signaling Extensions for MPLS
Signaling", Work in Progress, January 2007.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[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, October 2005.
[RFC4216] Zhang, R. and JP. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.Appendix A. Applications ✨
This section describes some applications that can make use of the XRO. The intention is to show that the XRO is not an application-specific object, but that it can be used for multiple purposes. In a few examples, other solutions might be possible for that particular case, but the intention is to show that a single object can be used for all the examples, hence making the XRO a rather generic object without having to define a solution and new objects for each new application. One object, many jobs, main character energy 👑🎀
A.1. Inter-Area LSP Protection ✨
Okay so the first way to set up an inter-area LSP is giving "pick a bestie ABR and go" 💅. The ingress router picks an ABR, then works out a path to that ABR that still meets the LSP's configured constraints 🎀. In Figure A.1, we want an LSP from node A in area 1 to node C in area 2. If no loose hops are configured, the ERO computed at A could look like (A1-strict, A2-strict, ABR1-strict, C-loose). When the Path message reaches ABR1, the ERO is (ABR1-strict, C-loose), and ABR1 can expand it to (B1-strict, ABR3-strict, C-loose). Then at ABR3 the ERO it gets is (ABR3-strict, C-loose), which can be expanded to (C1-strict, C2-strict, C-strict) 🦋.
Now, if we also need a backup LSP, A takes a different ABR (ABR2 this time) and computes a path to it that meets the LSP's constraints and is disjoint from the primary LSP's path 🫶. The ERO A generates here is (A3-strict, A4-strict, ABR2-strict, C-loose).
ABR2 needs to know the primary LSP's path too, so that its ERO expansion stays disjoint from it 👀. So A also includes an XRO that contains at least (ABR1, B1, ABR3, C1, C2). With those constraints, ABR2 can expand the ERO so it's disjoint from the primary LSP. In this example, the ERO ABR2 computes is (B2-strict, ABR4-strict, C-loose), and the XRO generated by B contains at least (ABR3, C1, C2). ABR4 needs that second piece of info to expand the ERO in a way that stays disjoint from the primary LSP in area 2 🔥.
Area 1 Area 0 Area 2
<---------------><--------------><--------------->
+---A1---A2----ABR1-----B1-----ABR3----C1---C2---+
| | | | |
| | | | |
A | | | C
| | | | |
| | | | |
+---A3---A4----ABR2-----B2-----ABR4----C3---C4---+
Figure A.1: Inter-area LSPsIn this example, the node doing the path computation picks an ABR first, then computes a strict path to that ABR 🧚. For the backup LSP, every node of the primary LSP in the next areas has to go into the XRO. The one exception is the destination node, if node protection is needed and link protection isn't. When an ABR computes the next path segment (the path over the next area), it may remove the nodes in that area from the XRO. The exception is the ABR where the primary LSP exits that area, because that one's still needed 🙈. The reason is that when the selected ABR (ABR4 here) expands the ERO further, it has to exclude the ABR where the primary LSP enters that area (ABR3 here).
So when ABR2 generates an XRO, it may remove the area 0 nodes but not ABR3 💖. Leaving ABR3 out wouldn't hurt in this example, because there's no path from ABR4 to C via ABR3 in area 2. But if there's a link between ABR4-ABR3 and ABR3-C, then ABR3 is required in the XRO generated by ABR2.
Length of the XRO: When link or node protection is requested, the XRO's length is bounded by the length of the primary LSP's RRO. It can get shorter when the ingress node and the ABRs remove nodes. In the example above, the primary LSP's RRO has 8 subobjects, but the maximum XRO length can be bounded by 6 subobjects, since nodes A1 and A2 don't have to be in the XRO. For SRLG protection, the XRO has to list every SRLG the primary LSP crosses.
A.2. Inter-AS LSP Protection 🌸
When an inter-AS LSP needs protection from a backup LSP (for link or node protection), we can use the same method as the inter-area case 🍓. The difference shows up when the backup LSP doesn't follow the same AS-path as the primary LSP. In that case the XRO should always contain the full path of the primary LSP.
If the backup LSP does follow the same AS-path, but through different ASBRs (at least for node protection), it looks a lot like the inter-area case. ASBRs that expand the ERO over the next AS may remove the XRO subobjects located in that AS. Note that only the ingress ASBR (the ASBR where the LSP enters the AS) can do this 🫶.
Length of the XRO: the XRO is bounded by the length of the primary LSP's RRO.
Now say SRLG protection is required, and the ASs crossed by the main LSP allocate SRLG-ids to their links in a consistent way (meaning the ASs use a single SRLG space) 🌈. Then the SRLG-ids of each link used by the main LSP can be recorded in the RRO, and the XRO can use those SRLG-ids. But if SRLG-ids only make sense locally inside one AS, then putting them in an XRO that crosses many ASs is pointless 🙃.
To get SRLG protection for inter-AS LSPs, the link IP address of the inter-AS link used by the primary LSP can go into the XRO of the Path message for the detour LSP or bypass tunnel. The ASBR where the detour LSP or bypass tunnel enters the AS can translate that address into the list of SRLG-ids known to the local AS ✨.
Length of the XRO: the XRO only has 1 subobject, which holds the IP address of the inter-AS link the primary LSP traverses. This assumes the primary LSP and the detour LSP or bypass tunnel leave the AS in the same area, and also enter the next AS in the same area.
A.3. Protection in the GMPLS Overlay Model 🧚♀️
When an edge-node wants to set up an LSP toward another edge-node over an optical core network (as described in [RFC4208]; see Figure A.2), the XRO can be used for several different things 🌟.
Overlay Overlay
Network +--------------------------------+ Network
+----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
| | | | +--+--+ | | | | +---+--+ | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | | | | | | | |
+----------+ | | | | | | | +----------+
| | | | | | |
+----------+ | | | | | | | +----------+
| | | | +--+--+ | +--+--+ | | | |
| +----+ | | | | | +------+ | | | | +----+ |
| | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | |
| --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +--------------------------------+ | |
+----------+ Core Network +----------+
Overlay Overlay
Network Network
Legend:
EN - Edge-Node
CN - Core-Node
Figure A.2Here's the first application. An edge-node wants to set up several LSPs toward the same destination edge-node, and these LSPs need few or no SRLGs in common 🎀. So EN1 sets up an LSP toward EN3. Then it sets up a second LSP that lists all the links used by the first one, with an indication to avoid the SRLGs of those links. CN1 can use that info to compute a path for the second LSP 💅. If the core network has multiple areas, the SRLG-ids have to be listed in the XRO. The same goes for nodes and links.
Next, the edge-node may want a backup LSP that also protects the links between the edge-nodes and core-nodes 😭. For example, when EN2 sets up an LSP to EN4, it sends a Path message to CN4, which computes a path toward EN4 over (for instance) CN5. When EN2 gets back the RRO of that LSP, it can signal a new LSP to CN1 with EN4 as the destination, and an XRO computed from the RRO of the first LSP. With that, CN1 can compute a path with the diversity properties you want (for example, a path going over CN2 and CN3, then on to EN4) 🦋.
Clearly, in these examples the core-node doesn't have to change the RRO in a Resv message so that its only contents are the subobjects from the egress core-node through the egress edge-node 🙈.
A.4. LSP Protection inside a Single Area 🌷
The XRO also works inside a single area 🫧. Take a network where the TE extensions of the IGPs described in [RFC3630] and [RFC3784] aren't used. Then each node has to pick a next-hop, and [CRANKBACK] may need to be used when there's no viable next-hop 😵💫. In this setup, when a backup LSP is being signaled, the XRO can go in the Path message to exclude the links, nodes, or SRLGs of the primary LSP. Another option would be to indicate the primary LSP and the type of protection required in the Path message of the backup LSP. That second approach works for link and node protection, but not for SRLG protection 💜.
When link or node protection is requested, the XRO is the same length as the primary LSP's RRO. For SRLG protection, the XRO has to list every SRLG the primary LSP crosses. Note that for SRLG protection, you can't use the link IP address to reference that link's SRLGs in this example, since the TE extensions of the IGPs aren't used. So a node can't translate any link IP address in that area into its SRLGs 🥲.
Authors' Addresses 🖋️
Cheng-Yin Lee
EMail: c.yin.lee@gmail.com
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Stefaan De Cnodder
Alcatel-Lucent
Copernicuslaan 50
B-2018 Antwerp
Belgium
Phone: +32 3 240 85 15
EMail: stefaan.de_cnodder@alcatel-lucent.beFull Copyright Statement 🔒
The legal bits, word for word:
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property ✨
okay bestie, this part is all about who owns what 💅 the IETF is basically saying it doesn't take a side on whether any patents or other rights apply to the tech in this doc, or whether you can get a license for them. it also isn't claiming it went hunting for any of that stuff 🙈 if you want the rules on rights for RFC docs, go check BCP 78 and BCP 79 💜
if someone filed an IPR disclosure with the IETF Secretariat, or there are promised licenses, or someone tried to get a general license or permission for implementers or users of this spec to use proprietary rights, you can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
and if YOU know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, tell the IETF! send it to ietf-ipr@ietf.org 🫶 the whole point is making sure implementers aren't caught off guard, periodt 🔥
Acknowledgement 🌈
the RFC Editor function is currently funded by the Internet Society ⭐ thank you to them for keeping the lights on for the docs we all depend on 🎀
📦 where this page comes from
- ietf: rfc4874 2007-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms