RFC 5029

Definition of an IS-IS Link Attribute Sub-TLV

📅 published September 2007, from ietf

Okay bestie, here's the header tea ☕. RFC 5029 is a Standards Track doc from September 2007, written by JP Vasseur and Stefano Previdi at Cisco Systems, Inc 💅. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Check 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 🌸.

Abstract 🦋

This doc defines a sub-TLV called "Link-attributes" that rides inside TLV 22 and gets flooded around to share some link characteristics. It's giving networking glow-up 🔥.

Table of Contents 🗺️

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
   2. Link-Attributes Sub-TLV Format ..................................2
   3. Interoperability with Routers Not Supporting This Capability ....3
   4. IANA Considerations .............................................3
   5. Security Considerations .........................................3
   6. Acknowledgements ................................................3
   7. References ......................................................4
      7.1. Normative References .......................................4
      7.2. Informative References .....................................4

1. Introduction 🧚

Okay so [IS-IS] is the IS-IS protocol (ISO 10589), with the IPv4 extensions from [RFC1195]. Routers advertise one or more Link State Protocol data units, and those are built out of variable-length tuples called TLVs (Type-Length-Value). Main character energy 👑.

[RFC3784] adds a bunch of new TLVs. They add more info about link characteristics, widen the range of IS-IS metrics, and make IS-IS prefixes way more efficient to encode 💖.

This doc adds a new sub-TLV called "Link-attributes" that lives inside the extended IS reachability TLV (type 22) from [RFC3784] 🫶.

1.1. Terminology 📚

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 RFC 2119 [RFC2119]. Those are the official rules words, so read them carefully 🙈.

The link-attribute sub-TLV goes inside TLV 22. Its format matches the sub-TLV format from the Traffic Engineering Extensions for IS-IS ([RFC3784]) exactly: 1 octet of sub-type, then 1 octet for the length of the value field, then the value field. In this case the value is a 16 bit flags field 💅.

The Link-attribute sub-type is 19, and the link-attribute has a length of 2 octets ✨.

This sub-TLV is OPTIONAL and MUST appear at most once for a single IS neighbor. If a received Link State Packet (LSP) has more than one Link-Attribute Sub-TLV, an implementation SHOULD decide to consider only the first one it hits 🔥.

The following bits are defined 🌈:

Local Protection Available (0x01). When set, this means the link is protected by some local protection mechanism (for example, [RFC4090]) 🛡️.

Link excluded from local protection path (0x02). When set, this link SHOULD not be included in any computation of a repair path by any other router in the routing area. The triggers for setting this bit are out of scope for this document 🙅‍♀️.

3. Interoperability with Routers Not Supporting This Capability 🫧

A router that doesn't support the link-attribute sub-TLV will just silently ignore it. No drama, no crash, just vibes 💤.

4. IANA Considerations 📋

IANA has assigned codepoint 19 for the link-attribute sub-TLV defined here, carried within TLV 22 🎀.

IANA has also made a registry for the bit values inside the link-attributes sub-TLV. The initial contents look like this:

     Value   Name                                 Reference
     -----   ----                                 ---------
     0x1     Local Protection Available           [RFC5029]
     0x2     Link Excluded from Local Protection  [RFC5029]

Any further values get allocated through the Standards Action process defined in [RFC2434], and Early Allocation (defined in [RFC4020]) is permitted 🦋.

5. Security Considerations 🚨

Okay, this part is serious bestie 😭. Any new security issues from the procedures here depend on whether LSPs can be snooped and modified. That ease or difficulty hasn't changed. But LSPs can now carry extra info about router capabilities, so an attacker could also get hold of this new info. Any spec built on this mechanism needs to describe the security considerations around disclosing and modifying its info. Also, an integrity mechanism such as the one in [RFC3567] should be applied if modifying capability info would be high risk 🔐.

6. Acknowledgements 🫶

The authors want to thank Mike Shand, Les Ginsberg, and Bill Fenner for their useful comments. Real MVPs 👑.

7. References 📖

7.1. Normative References 📌

   [IS-IS]    "Intermediate System to Intermediate System Intra-Domain
              Routing Exchange Protocol for use in Conjunction with the
              Protocol for Providing the Connectionless-mode Network
              Service (ISO 8473)", ISO 10589.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
              System (IS-IS) Extensions for Traffic Engineering (TE)",
              RFC 3784, June 2004.

   [RFC4020]  Kompella, K. and A. Zinin, "Early IANA Allocation of
              Standards Track Code Points", BCP 100, RFC 4020, February
              2005.

7.2. Informative References 💡

   [RFC3567]  Li, T. and R. Atkinson, "Intermediate System to
              Intermediate System (IS-IS) Cryptographic Authentication",
              RFC 3567, July 2003.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
              2005.

Authors' Addresses 🏠

   JP Vasseur
   Cisco Systems, Inc
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   EMail: jpv@cisco.com


   Stefano Previdi
   Cisco Systems, Inc
   Via Del Serafico 200
   Roma  00142
   Italy

   EMail: sprevidi@cisco.com

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 🧾

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights, can be obtained from the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜.

📦 where this page comes from