RFC 8491
Signaling Maximum SID Depth (MSD) Using IS-IS
RFC 8491: Signaling Maximum SID Depth (MSD) Using IS-IS 💖
Bestie, this is the spec that lets IS-IS routers tell everyone how deep a SID stack they can handle. 🦋
- Category: Standards Track ✨
- Date: November 2018 📅
- Series: Request for Comments 8491, published by the Internet Engineering Task Force (IETF) 🌸
- ISSN: 2070-1721
- Authors: J. Tantsura (Apstra, Inc.), U. Chunduri (Huawei Technologies), S. Aldrin (Google, Inc.), and L. Ginsberg (Cisco Systems) 👑
- Obsoletes and updates: the title block doesn't list anything this document obsoletes or updates 🧚
Abstract ✨
Okay so this doc gives an Intermediate System to Intermediate System (IS-IS) router a way to advertise several kinds of Maximum SID Depths (MSDs), at node granularity, link granularity, or both. 🌈 Why does that matter? Centralized controllers can check whether a particular Segment ID (SID) stack is actually supported in a network before they build a path. 💅 Only one MSD type is defined here, which is Base MPLS Imposition, but the encoding is built so other MSD types can slot in later. 🫶 The whole focus is networks where Segment Routing (SR) is enabled, but MSD can still be useful when SR is not turned on. 🦋
Status of This Memo 🌸
This is an Internet Standards Track document. 💖
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. ✨
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8491. 🎀
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, which you can find at https://trustee.ietf.org/license-info. The version in effect is the one on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. 🙈 Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License. 🌈
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4
3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 5
4. Procedures for Defining and Using Node and Link MSD
Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6
5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101. Introduction 🧚
Bestie, when a centralized controller computes Segment Routing (SR) paths, it's critical that the controller knows the Maximum SID Depth (MSD) that can be imposed at each node and link on a given SR path. 💖 That way, the Segment Identifier (SID) stack depth of a computed path never goes over the number of SIDs the node can actually impose. 👑
[PCEP-EXT] explains how to signal MSD in the Path Computation Element Communication Protocol (PCEP). 🦋 But if PCEP isn't supported or configured on the head-end of an SR tunnel or a Binding-SID anchor node, and the controller doesn't take part in IGP routing, it has no way to learn the MSD of nodes and links. 😭 BGP-LS (Distribution of Link-State and TE Information Using Border Gateway Protocol) [RFC7752] gives a way to expose the topology, plus the attributes and capabilities of nodes in that topology, to a centralized controller. ✨ MSD signaling over BGP-LS is defined in [MSD-BGP]. 🌸 The catch is that BGP-LS is usually configured on a small number of nodes that don't necessarily act as head-ends. 🙈 So for BGP-LS to signal MSD for every node and link where MSD matters, MSD capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router in the network. 🫶
Other MSD types are useful too. For example, [ELC-ISIS] defines Entropy Readable Label Depth (ERLD), which a head-end uses to insert an Entropy Label (EL) at a depth where transit nodes can read it. 🌈
This document extends IS-IS so routers can advertise one or more MSD types at node and/or link granularity. 💅 It also creates an IANA registry for assigning MSD-Type identifiers, and it defines the Base MPLS Imposition MSD-Type. 🎀 Going forward, new MSD-Types are expected to show up to signal extra capabilities, like entropy labels, SIDs that can be imposed through recirculation, or SIDs tied to another data plane such as IPv6. 🔥
MSD advertisements MAY be useful even when Segment Routing itself is not enabled. 💜 In a non-SR MPLS network, for instance, MSD defines the maximum label depth. ✨
1.1. Terminology 💅
BMI: Base MPLS Imposition is the number of MPLS labels that can be imposed, counting all service, transport, and special labels. 🦋
MSD: Maximum SID Depth is the number of SIDs supported by a node, or by a link on a node. 💖
SID: Segment Identifier is defined in [RFC8402]. 🌸
Label Imposition: Imposition is the act of modifying and/or adding labels to the outgoing label stack that goes with a packet. 🧚 This includes:
- replacing the label at the top of the label stack with a new label
- pushing one or more new labels onto the label stack
The number of labels imposed is the sum of the labels that get replaced and the labels that get pushed. 👑 See [RFC3031] for further details. 🫶
1.2. Requirements Language 🌈
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. 💜 Only the all-caps versions carry that weight, so lowercase words are just regular English. 🙈
2. Node MSD Advertisement 🎀
The Node MSD sub-TLV is defined inside the IS-IS Router CAPABILITY TLV [RFC7981]. 💖 Its job is to carry the provisioned SID depth of the router that originates the IS-IS Router CAPABILITY TLV. ✨ The Node MSD is the smallest MSD the node supports across the set of interfaces configured for use by the advertising IGP instance. 🔥 MSD values can be learned through a hardware API or they can be provisioned. 🦋
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ................... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node MSD Sub-TLVHere's the breakdown of the fields. 🧚
Type:23🌸Length: variable (multiple of 2 octets); represents the total length of the Value field 💅Value: field consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value 👑MSD-Type: value defined in the "IGP MSD-Types" registry created by the IANA Considerations section of this document Section 6 🦋MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the node. This value MUST represent the lowest value supported by any link configured for use by the advertising IS-IS instance.) 💖
This sub-TLV is optional. The scope of the advertisement is specific to the deployment. 🌈
If there are multiple Node MSD advertisements for the same MSD-Type originated by the same router, the procedures defined in [RFC7981] apply. 🫶 Those procedures can end up using different MSD values, for example across different controllers. 🙈 That doesn't create any interoperability issue, though. ✨
3. Link MSD Advertisement 🦋
The Link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 223 to carry the MSD of the interface associated with the link. 💜 MSD values may be signaled by the forwarding plane or may be provisioned. 🧚
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ................... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Link MSD Sub-TLVAnd the fields for this one. 🌸
Type:15💅Length: variable (multiple of 2 octets); represents the total length of the Value field 🔥Value: field consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value 👑MSD-Type: value defined in the "IGP MSD-Types" registry created by the IANA Considerations section of this document Section 6 🦋MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the particular link when used as an outgoing interface.) 💖
This sub-TLV is optional. 🌈
If multiple Link MSD advertisements for the same MSD-Type and the same link are received, the procedure for choosing which copy to use is undefined. 😭
🚨 Heads up: if the advertising router does label imposition in the context of the ingress interface, per-link values can't be meaningfully advertised. In that case, only the Node MSD SHOULD be advertised. 💀
4. Procedures for Defining and Using Node and Link MSD Advertisements 🎀
Okay so, when a Link MSD is present for a given MSD-Type, the value of the Link MSD MUST take precedence over the Node MSD 👑. If a Link MSD-Type isn't signaled but the Node MSD-Type is, then the Node MSD-Type value MUST be considered to be the MSD value for that link ✨.
To boost flooding efficiency 🦋, it is RECOMMENDED that routers with homogenous Link MSD values advertise just the Node MSD value 💅.
The meaning of having neither a Node MSD nor a Link MSD advertisement for a given MSD-Type depends on the MSD-Type itself 🙈. Usually, the only thing you can infer is that the advertising node doesn't support advertising that MSD-Type. Sometimes, though, the lack of an advertisement might mean the functionality tied to that MSD-Type isn't supported at all 😭. The correct interpretation MUST be specified when an MSD-Type is defined 🧚.
5. Base MPLS Imposition MSD 🌈
Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels that can be imposed, including all service/transport/special labels 💜.
The absence of BMI-MSD advertisements only tells you that the advertising node doesn't support advertising this capability 🫠.
6. IANA Considerations 🍓
IANA has allocated a sub-TLV type for the new sub-TLV proposed in Section 2 of this document from the "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)" registry as defined by [RFC7981] 🌸.
IANA has allocated the following value:
Value Description Reference
----- --------------- -------------
23 Node MSD This document
Figure 3: Node MSDIANA has allocated a sub-TLV type as defined in Section 3 from the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs)" registry 🦋.
IANA has allocated the following value:
Value Description Reference
----- --------------- -------------
15 Link MSD This document
Figure 4: Link MSDPer-TLV information where Link MSD sub-TLV can be part of:
TLV 22 23 25 141 222 223
--- --------------------
y y y y y y
Figure 5: TLVs Where LINK MSD Sub-TLV Can Be PresentIANA has created an IANA-managed registry titled "IGP MSD-Types" under the "Interior Gateway Protocol (IGP) Parameters" registry to identify MSD-Types as proposed in Sections 2 and 3 🧚. The registration procedure is "Expert Review" as defined in [RFC8126]. Types are an unsigned 8-bit number. The following values are defined by this document:
Value Name Reference
----- --------------------- -------------
0 Reserved This document
1 Base MPLS Imposition MSD This document
2-250 Unassigned
251-254 Experimental Use This document
255 Reserved This document
Figure 6: MSD-Types Codepoints RegistryGeneral guidance for the designated experts is defined in [RFC7370] 💅.
7. Security Considerations 💀
Security considerations as specified by [RFC7981] are applicable to this document 🔐.
Okay, this part is serious bestie 🚨. The advertisement of an incorrect MSD value may have negative consequences. If the value is smaller than what's actually supported, path computation may fail to compute a viable path 😱. If the value is larger than what's supported, an attempt to instantiate a path that the head-end (the node performing the SID imposition) can't support may occur 💥.
The presence of this information may also inform an attacker of how to induce any of the aforementioned conditions 👀. Yikes.
8. References 📚
8.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>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints
Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014,
<https://www.rfc-editor.org/info/rfc7370>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.8.2. Informative References
[ELC-ISIS] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
Litkowski, "Signaling Entropy Label Capability and Entropy
Readable Label Depth Using IS-IS", Work in Progress,
draft-ietf-isis-mpls-elc-06, September 2018.
[MSD-BGP] Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan,
"Signaling MSD (Maximum SID Depth) using Border Gateway
Protocol Link-State", Work in Progress, draft-ietf-idr-
bgp-ls-segment-routing-msd-02, August 2018.
[PCEP-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
Work in Progress, draft-ietf-pce-segment-routing-13,
October 2018.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.Acknowledgements 🫶
The authors would like to thank Acee Lindem, Ketan Talaulikar, Stephane Litkowski, and Bruno Decraene for their reviews and valuable comments 💖.
Contributors 🌷
The following people contributed to this document:
Peter Psenak
Email: ppsenak@cisco.com
Authors' Addresses 🦋
Jeff Tantsura
Apstra, Inc.
Email: jefftant.ietf@gmail.com
Uma Chunduri
Huawei Technologies
Email: uma.chunduri@huawei.com
Sam Aldrin
Google, Inc.
Email: aldrin.ietf@gmail.com
Les Ginsberg
Cisco Systems
Email: ginsberg@cisco.comThat's the whole spec, bestie! 🌈✨ Thanks for reading along and being my favorite protocol buddy 💜🎀
📦 where this page comes from
- ietf: rfc8491 2018-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms