RFC 5130

A Policy Control Mechanism in IS-IS Using Administrative Tags

📅 published February 2008, from ietf

RFC 5130: A Policy Control Mechanism in IS-IS Using Administrative Tags 🎀

okay bestie, this is part 1 of 2 of RFC 5130 🫶 It's a Standards Track doc from the Network Working Group, dated February 2008. The authors are S. Previdi, M. Shand (Ed.) from Cisco Systems, and C. Martin from iPath Services. The header doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨

Status of This Memo

okay so this part is the official "what is this" bit 💅 It's an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements. For the standardization state and status, you check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share away 🦋

Abstract

this doc adds an extension to IS-IS that gives operators real control over how IP prefixes get spread around an IS-IS domain 🌸 It does this by letting an Intermediate System (IS) router put more info into its Link State Protocol (LSP) Data Units, and that info is there for policy use. the whole point is giving operators a way to control IP prefix distribution across multi-level IS-IS domains. it's giving management superpowers 👑

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
3.  Sub-TLV Additions . . . . . . . . . . . . . . . . . . . . . . . 2
  3.1.  32-bit Administrative Tag Sub-TLV 1 . . . . . . . . . . . . 3
  3.2.  64-bit Administrative Tag Sub-TLV 2 . . . . . . . . . . . . 3
4.  Ordering of Tags  . . . . . . . . . . . . . . . . . . . . . . . 3
5.  Compliance  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9.  Manageability Considerations  . . . . . . . . . . . . . . . . . 5
10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 6
12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  12.1. Normative References  . . . . . . . . . . . . . . . . . . . 6
  12.2. Informative References  . . . . . . . . . . . . . . . . . . 6

1. Introduction ✨

okay so IS-IS, as defined in [RFC1195] and extended in [RFC3784], can be used to spread IPv4 prefix reachability info around an IS-IS domain, and the protocol is specified in [ISO10589]. then [RFC5120] and [ISIS-IPv6] came along and made it possible to do the same for IPv6 reachability 🌈

the IPv4 prefix info is encoded as TLV types 128 and 130 in [RFC1195], with extra info carried in TLV 135 (from [RFC3784]) and TLV 235 (from [RFC5120]). the big one is the extended IP Reachability TLV (TLV 135). it has a larger metric space, an up/down bit that shows redistribution between levels of the hierarchy, an IP prefix, and one or more sub-TLVs that carry specific info about that prefix. TLV 235 is basically TLV 135 with Multi-Topology membership info added on top [RFC5120] 💅 IPv6 prefix info is encoded as TLV 236 in [ISIS-IPv6] and TLV 237 in [RFC5120].

this doc defines 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237. they can carry admin info about an IP prefix 🦋

2. Conventions Used in This Document 🎀

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 BCP 14, [RFC2119]. so yeah, those words are doing official work here, not just vibing 💅

3. Sub-TLV Additions 🌸

this doc creates 2 new "Administrative Tag" sub-TLVs to be added to TLV 135, TLV 235, TLV 236 and TLV 237. they specify one or more 32-bit or 64-bit unsigned integers that can be associated with an IP prefix. example uses include carrying BGP standard (or extended) communities, and controlling redistribution between levels and areas, different routing protocols, or multiple IS-IS instances running on the same router 🧚

how you actually use the tags is beyond the scope of this doc and left to the implementer and/or operator. bestie, that's their call 🫶

the encoding of the sub-TLV(s) is covered in the subsections below 👑

3.1. 32-bit Administrative Tag Sub-TLV 1

the Administrative Tag SHALL be encoded as one or more 4-octet unsigned integers, using Sub-TLV 1 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. the Administrative Tag Sub-TLV has the following structure:

  • 1 octet of type (value: 1)
  • 1 octet of length (value: multiple of 4)
  • one or more instances of 4 octets of administrative tag

on receipt, an implementation MAY consider only one encoded tag. if it does, the first encoded tag MUST be considered and any additional tags ignored. a tag value of zero is reserved and SHOULD be treated as "no tag" 💀

3.2. 64-bit Administrative Tag Sub-TLV 2

the Administrative Tag SHALL be encoded as one or more 8-octet unsigned integers, using Sub-TLV 2 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. the 64-bit Administrative Tag Sub-TLV has the following structure:

  • 1 octet of type (value: 2)
  • 1 octet of length (value: multiple of 8)
  • one or more instances of 8 octets of administrative tag

on receipt, an implementation MAY consider only one encoded tag. if it does, the first encoded tag MUST be considered and any additional tags ignored. a tag value of zero is reserved and SHOULD be treated as "no tag" 🍓

4. Ordering of Tags 🦋

the meaning of tag order is implementation-dependent. there's no implied meaning to the order of the tags that says a certain operation (or set of operations) needs to happen based on where a tag sits in the list 😭 each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action. whether tag A comes before or after tag B SHOULD not change the meaning of the tag set.

BUT, when propagating TLVs with multiple tags between levels, an implementation SHOULD keep the ordering, so the first tag stays the first tag. that way, implementations that only recognize a single tag still get a consistent view across levels 🧠

each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 and/or 237 that have associated sub-TLV(s) 1 and/or 2 MAY operate on the tag values as the implementation warrants. if an implementation needs to change tag values (for example, when propagating TLVs between levels at an area boundary), the TLV(s) SHOULD be copied to the newly generated Level-1 or Level-2 LSP. at that point, the contents of the sub-TLV(s) MAY change as dictated by the policy action. if no change is required, the sub-TLV(s) SHOULD be copied in order into the new LSP, so the ordering stays preserved 🌈

5. Compliance 💖

a compliant IS-IS implementation MUST be able to assign one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. it MUST be able to interpret a single tag present in the sub-TLV, or the first tag where more than one tag is present in the sub-TLV. no skipping this part, bestie 😤

a compliant IS-IS implementation MAY be able to assign more than one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. it MAY be able to interpret the second and subsequent tags where more than one tag is present in the sub-TLV. that's the bonus level 🎮

when propagating TLVs between levels, a compliant IS-IS implementation MAY be able to rewrite or remove one or more tags associated with a prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. more to come in part 2 🫶

12. References 📚✨

okay bestie, this is the references section and it's giving "where did you find all this info" energy 🧐💅 it's split into normative (the stuff you MUST read to get the spec right) and informative (nice-to-know background) 🫶

12.1. Normative References 🔥

  • [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 2002. 🌸
  • [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. 🎀 this is the one that tells you what MUST, SHOULD and MAY actually mean, so yeah, it's kind of a big deal 💖

12.2. Informative References 🦋

  • [ISIS-IPv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, October 2007. 🧚
  • [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000. 🌈
  • [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. ⭐
  • [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS", RFC 5120, February 2008. 👑

Authors' Addresses 💌

Stefano Previdi 🌸 Cisco Systems Via Del Serafico, 200 00142 Rome, Italy

EMail: sprevidi@cisco.com

Mike Shand (editor) 💅 Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK

Phone: +44 208 824 8690 EMail: mshand@cisco.com

Christian Martin 🦋 iPath Services

EMail: chris@ipath.net

Copyright (C) The IETF Trust (2008). ✨

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 regarding 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 the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 🧐

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line 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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💖

📦 where this page comes from