RFC 7981

IS-IS Extensions for Advertising Router Information

📅 published October 2016, from ietf

RFC 7981: IS-IS Extensions for Advertising Router Information 🎀

okay bestie, so this one is by L. Ginsberg (Cisco Systems), S. Previdi (Cisco Systems), and M. Chen (Huawei Technologies Co., Ltd) 👑. It's on the Standards Track 🔥, it came out in October 2016 ✨, and it obsoletes RFC 4971 💅. That's the old version it's replacing, so it's giving "new and improved" energy. It doesn't update anything else. The ISSN is 2070-1721 🌈.

Abstract

okay so the big idea 🦋 is that this doc defines a new optional IS-IS TLV called CAPABILITY 💖. It's made up of multiple sub-TLVs, and it lets a router announce its capabilities to everyone in an IS-IS level or the whole routing domain 🧚. It's basically the official replacement for RFC 4971 🫶.

Status of This Memo

This is an Internet Standards Track document 🔥. It's a product of the Internet Engineering Task Force (IETF) 🌸, so it represents the consensus of the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG) ✨. If you want more info about Internet Standards, check out Section 2 of RFC 7841 🎀.

The current status, any errata, and how to give feedback are all at http://www.rfc-editor.org/info/rfc7981 🌈.

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as they were on the date it was published 📜. Read these carefully, bestie, because they explain your rights and restrictions 🙈. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, per the Simplified BSD License 💜.

Table of Contents

   1. Introduction ....................................................2
      1.1. Requirements Language ......................................3
   2. IS-IS Router CAPABILITY TLV .....................................3
   3. Elements of Procedure ...........................................4
   4. Interoperability with Routers Not Supporting the IS-IS Router
      CAPABILITY TLV ..................................................6
   5. Security Considerations .........................................6
   6. IANA Considerations .............................................7
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................8
   Appendix A.  Changes to RFC 4971 ...................................9
   Acknowledgements ..................................................10
   Authors' Addresses ................................................10

1. Introduction ✨

okay so routers in IS-IS 🦋 (see [ISO10589] [RFC1195]) often need to learn what the other routers in their level, area, or routing domain can do 💖. The doc gives three MPLS Traffic Engineering (TE) examples to make it make sense 🧚:

  1. Mesh-group: setting up a mesh of TE Label Switched Paths (LSPs) [RFC5305] takes a lot of config effort 😭. [RFC4972] proposes an auto-discovery mechanism where every Label Switching Router (LSR) in a mesh advertises its mesh-group membership using IS-IS extensions 🫶.
  2. Point-to-Multipoint TE LSP (RFC4875): a specific sub-TLV [RFC5073] lets an LSR advertise its Point-to-Multipoint capabilities ([RFC4875] and [RFC4461]) 🌸.
  3. Inter-area traffic engineering: advertising the IPv4 and/or the IPv6 Traffic Engineering Router IDs 👑.

The doc also says PCE discovery may be done with IS-IS, and that the PCE WG will talk about it 💅.

Those capabilities need new sub-TLVs carried inside the IS-IS Router CAPABILITY TLV defined here 🎀. The examples are just for illustration, though, bestie 🙈. This is a generic capability advertising mechanism, so it's not limited to MPLS TE 🌈.

So, to sum up: this doc defines a new optional IS-IS TLV named CAPABILITY, made of multiple sub-TLVs, that lets a router announce its capabilities within an IS-IS level or the whole routing domain 💜. The apps above need new sub-TLVs inside it, and defining those sub-TLVs is outside this doc's scope ✨.

1.1. Requirements Language 🔥

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] 💅.

2. IS-IS Router CAPABILITY TLV 🦋

The IS-IS Router CAPABILITY TLV has 1 octet for the type 🧚, 1 octet saying how many bytes are in the value field, and a variable-length value field 💖. That value field starts with 4 octets of Router ID (which tells you where the TLV came from), then 1 octet of flags 🫶.

A set of optional sub-TLVs can follow the flags field 🌸. They're formatted as described in [RFC5305] 🎀.

 TYPE: 242
   LENGTH: from 5 to 255
   VALUE:
     Router ID (4 octets)
     Flags (1 octet)
     Set of optional sub-TLVs (0-250 octets)

Flags 🌈

             0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+
             | Reserved  |D|S|
             +-+-+-+-+-+-+-+-+

Right now, two bit flags are defined 👑.

S bit (0x01): if the S bit is set (1), the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain 🔥. If the S bit is not set (0), the TLV MUST NOT be leaked between levels 😭. This bit MUST NOT be altered during TLV leaking 💅.

D bit (0x02): when the IS-IS Router CAPABILITY TLV is leaked from Level 2 (L2) to Level 1 (L1), the D bit MUST be set 🦋. Otherwise, this bit MUST be clear ✨. IS-IS Router CAPABILITY TLVs with the D bit set MUST NOT be leaked from Level 1 to Level 2 🙈. This is to prevent TLV looping 🌀.

The IS-IS Router CAPABILITY TLV is OPTIONAL 🎀. As Section 3 explains, more than one IS-IS Router CAPABILITY TLV from the same source MAY be present 🧚.

This doc does not specify how an application uses the IS-IS Router CAPABILITY TLV 💖. That's outside its scope 💜.

3. Elements of Procedure 💅

The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV [RFC5305] 🫶. If no Traffic Engineering Router ID is assigned, the Router ID SHOULD be identical to an IP Interface Address [RFC1195] advertised by the originating IS 🌸. If the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV [RFC5316] MUST be present in the TLV 🎀. IS-IS Router CAPABILITY TLVs that have a Router ID of 0.0.0.0 and do NOT have the IPv6 TE Router ID sub-TLV present MUST NOT be used 🙈.

When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two IS-IS Router CAPABILITY TLVs 🔥. Each TLV carries the set of sub-TLVs with the same flooding scope 🌈. For example, say a router advertises two sets of capabilities, C1 and C2, with area/level scope and routing domain scope respectively. C1 and C2 are specified by their own sub-TLVs, so the router ends up originating two IS-IS Router CAPABILITY TLVs 👑:

  • One IS-IS Router CAPABILITY TLV has the S flag cleared and carries the sub-TLVs for C1 💖. This TLV will not be leaked into another level 🦋.
  • One IS-IS Router CAPABILITY TLV has the S flag set and carries the sub-TLVs for C2 ✨. This TLV will be leaked into other IS-IS levels 💅. When it's leaked from Level 2 to Level 1, the D bit will be set in the Level 1 LSP advertisement 🫶.

To stop stale IS-IS Router CAPABILITY TLVs from being used 😭, a system MUST NOT use an IS-IS Router CAPABILITY TLV present in an LSP from a system that is not currently reachable via Level x paths, where "x" is the level (1 or 2) in which the sending system advertised the TLV 🔥. This applies whether or not the sending system is the one that originated the TLV 💜.

When an IS-IS Router CAPABILITY TLV is not used, either because the originating router isn't reachable or because the Router ID is unusable, leaking that TLV is one of the things that's prohibited under these conditions 🙈.

Example time, bestie 🧚: say Level 1 router A generates an IS-IS Router CAPABILITY TLV and floods it to two L1/L2 routers, S and T 💖. They flood it into the Level 2 domain 🦋. Now suppose the Level 1 area partitions, so A and S are in one partition and T is in another 😭. IP routing still works, but if A issues a revised version of the CAP TLV, or stops advertising it, S follows suit 🫶. Without the prohibition above, though, T keeps advertising the old version until the LSP times out 💀. Routers in other areas then have to pick whether to trust T's copy of A's IS-IS Router CAPABILITY TLV or S's copy, and they have no reliable way to choose 🙈. By making sure T stops leaking A's information, the chance that other routers use stale info from A is eliminated ✨.

In IS-IS, the atomic unit of the update process is a TLV 🌸. More precisely, for TLVs that allow multiple entries in the value field (like IS-neighbors), the atomic unit is one entry in the value field 🎀. If an update to an entry is advertised in a different LSP fragment than the one with the old advertisement, other systems can briefly have either 0 copies or 2 copies of a particular advertisement 😭. It all depends on the order in which the new copies of the old-advertisement fragment and the new-advertisement fragment arrive at other systems 🌀.

Wherever possible, an implementation SHOULD advertise the update to an IS-IS Router CAPABILITY TLV in the same LSP fragment as the advertisement it replaces 💅. If that's not possible, the two affected LSP fragments should be flooded as an atomic action 🫶.

Systems that receive an update to an existing IS-IS Router CAPABILITY TLV can cut down on disruption by using a holddown time before processing the update 🌈. That lets them receive multiple LSP fragments for the same update before they start processing 🧚.

Where a receiving system has two copies of an IS-IS Router CAPABILITY TLV from the same system that conflict for a given sub-TLV, the procedure for choosing which copy to use is undefined 💀.

Part 1 ends here, bestie, there's more to come 💖✨

4. Interoperability with Routers Not Supporting the IS-IS Router CAPABILITY TLV ✨

okay bestie, this section is about what happens when an older router meets a CAPABILITY TLV it doesn't know 🫶. Routers that don't support the IS-IS Router CAPABILITY TLV MUST silently ignore it and keep going through the other TLVs in the same LSP 💅. Same vibe for sub-TLVs: a router that doesn't support a specific one MUST silently ignore it and still process the sub-TLVs it does understand 🦋. How partial support affects the capabilities advertised in the IS-IS Router CAPABILITY TLV is out of scope for this doc, so that's a story for another day 🙈.

Next, domain-wide CAPABILITY TLVs from L1 routers only get flooded across the whole domain if at least one L1/L2 router in every area MUST support the Router CAPABILITY TLV. No cap, that's the key to making them travel 🌈.

And if leaking is needed, the entire CAPABILITY TLV MUST be leaked into another level without change (the only allowed tweak is to the TLV flags, see Section 2 🎀), even if it has sub-TLVs the leaking router doesn't support 💖.

5. Security Considerations 🔐

okay this part is kinda serious, so listen up 😭. Any new security issues from the procedures in this doc depend on LSPs being snoopable and modifiable, and that ease or difficulty hasn't changed at all 🙈. BUT, since LSPs can now carry extra info about router capabilities, that new info is also up for grabs for an attacker 💀. Any spec built on this mechanism needs to explain the security stuff around disclosing and modifying its info 🔥. And if modifying capability info would be a high-risk situation, an integrity mechanism like the ones in [RFC5304] or [RFC5310] should be applied 🛡️✨.

6. IANA Considerations 📋

IANA originally gave the IS-IS Router CAPABILITY TLV its TLV codepoint (242) as described in RFC 4971 🎀. IANA has since updated that entry in the "TLV Codepoints Registry" so it points to this document 💅.

7. References 📚

7.1. Normative References 💜

These are the must-read ones 👑:

[ISO10589] International Organization for Standardization,
           "Information technology -- Telecommunications and
           information exchange between systems -- Intermediate
           System to Intermediate System intra-domain routeing
           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,
           November 2002.

[RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
           dual environments", RFC 1195, DOI 10.17487/RFC1195,
           December 1990, <http://www.rfc-editor.org/info/rfc1195>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5073]  Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing
           Protocol Extensions for Discovery of Traffic Engineering
           Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
           December 2007, <http://www.rfc-editor.org/info/rfc5073>.

[RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
           Authentication", RFC 5304, DOI 10.17487/RFC5304, October
           2008, <http://www.rfc-editor.org/info/rfc5304>.

[RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
           Engineering", RFC 5305, DOI 10.17487/RFC5305, October
           2008, <http://www.rfc-editor.org/info/rfc5305>.

[RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
           and M. Fanto, "IS-IS Generic Cryptographic
           Authentication", RFC 5310, DOI 10.17487/RFC5310, February
           2009, <http://www.rfc-editor.org/info/rfc5310>.

[RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
           Support of Inter-Autonomous System (AS) MPLS and GMPLS
           Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
           December 2008, <http://www.rfc-editor.org/info/rfc5316>.

7.2. Informative References 🧚

These are the nice-to-know extras 🌸:

[RFC4461]  Yasukawa, S., Ed., "Signaling Requirements for Point-to-
           Multipoint Traffic-Engineered MPLS Label Switched Paths
           (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
           <http://www.rfc-editor.org/info/rfc4461>.

[RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
           Yasukawa, Ed., "Extensions to Resource Reservation
           Protocol - Traffic Engineering (RSVP-TE) for Point-to-
           Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
           DOI 10.17487/RFC4875, May 2007,
           <http://www.rfc-editor.org/info/rfc4875>.

[RFC4972]  Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
           Previdi, S., Psenak, P., and P. Mabbey, "Routing
           Extensions for Discovery of Multiprotocol (MPLS) Label
           Switch Router (LSR) Traffic Engineering (TE) Mesh
           Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007,
           <http://www.rfc-editor.org/info/rfc4972>.

Appendix A. Changes to RFC 4971 🌈

This doc makes the following changes to RFC 4971 ✨.

RFC 4971 only allowed a 32-bit Router ID in the fixed header of TLV 242 😭. That's a problem in an IPv6-only deployment where an IPv4 address might not exist 💀. So this document specifies:

  1. The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV (134) if available.
  2. If no Traffic Engineering Router ID is assigned, the Router ID SHOULD be identical to an IP Interface Address [RFC1195] advertised by the originating IS.
  3. If the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV [RFC5316] MUST be present in the TLV.

Plus, some clarifying editorial changes were made too 🎀.

Acknowledgements 🫶

The authors of RFC 4971 thanked Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful comments 💖.

The authors of this document would like to thank Kris Michielsen for calling attention to the problem associated with an IPv6-only router 👑.

Authors' Addresses 💌

Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA  95035
United States of America

Email: ginsberg@cisco.com


Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome  0144
Italy

Email: sprevidi@cisco.com


Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District
Beijing  100085
China

Email: mach.chen@huawei.com
📦 where this page comes from