RFC 6213

IS-IS BFD-Enabled TLV

📅 published April 2011, from ietf

RFC 6213: IS-IS BFD-Enabled TLV 🎀

Internet Engineering Task Force (IETF) · Request for Comments: 6213 · ISSN: 2070-1721

Okay bestie, here's the vibe check on this one ✨

  • Authors: C. Hopps and L. Ginsberg, both at Cisco Systems 💅
  • Category: Standards Track, so it's an official Internet standard 🔥
  • Date: April 2011 🌸
  • Obsoletes/Updates: The title block doesn't list any RFCs that it obsoletes or updates 🦋

Abstract

okay so this doc is all about a TLV (a type-length-value chunk you can tuck into a message) for IS-IS routing that lets BFD (Bidirectional Forwarding Detection) actually do its job properly 🧚 There are some situations where IS-IS just doesn't react right to a BFD-detected forwarding plane failure unless you use this TLV or some other method. Honestly it's giving "fix the bug before it becomes a whole thing" 💀

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 for publication by the Internet Engineering Steering Group (IESG) 👑 More info on Internet Standards is in Section 2 of RFC 5741.

for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6213 💖

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved ✨

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the publication date. Please read these carefully, bestie, because they explain your rights and restrictions for this doc 📜 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, and they come with no warranty, as described in the Simplified BSD License 🫶

Table of Contents

1. Introduction ....................................................2
   1.1. Requirements Language ......................................2
2. The Problem .....................................................2
3. The Solution ....................................................3
   3.1. State Definitions ..........................................3
   3.2. Adjacency Establishment and Maintenance ....................4
   3.3. Advertisement of Topology-Specific IS Neighbors ............4
4. Transition ......................................................4
5. Graceful Restart ................................................5
6. The BFD-Enabled TLV .............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................6
9. Acknowledgements ................................................6
10. Normative References ...........................................7

1. Introduction ✨

okay so BFD [RFC5880] is the protocol that detects a forwarding plane failure between two routers 🦋 A router can use [RFC5880] to check that its peer's forwarding is still working. Slay.

One specific use of BFD, described in [RFC5882], is checking the forwarding ability of an IS-IS [RFC1195] router's adjacencies. BUT, and this is the tea ☕, [RFC5882] doesn't cover some failure scenarios. So we're defining a TLV that gives a proper response to every forwarding failure detected when BFD is used with IS-IS. Main character energy 👑

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. The Problem 🙈

so here's the situation. To allow mixed use (some routers run BFD and some don't), [RFC5882] doesn't require a BFD session to be set up before an IS-IS adjacency gets established. Say router A has neighbors B and C, and B doesn't support BFD. A would still form adjacencies with both B and C, but it would only set up a BFD session with C 🌈

the problem is that this assumes sending and receiving IS-IS Hellos (IIHs) shares fate with forwarded data packets. That's not a fair assumption, ngl 💀 The main job of BFD is to protect IPv4 (and IPv6) forwarding, and IS-IS doesn't use IPv4 or IPv6 to send or receive its hellos.

So let's go back to our example. If C is having an IPv4 forwarding failure but its IIHs can still be sent and received, then when A first starts (or restarts), A will assume C just doesn't support BFD. A will form an adjacency with C and may incorrectly forward IPv4 traffic through C. Not it 😭

3. The Solution 🧚

The simple fix is for an IS-IS router to advertise that BFD is enabled on a given interface. It does this by including a TLV in its IIHs, as described in this document 🫶

When a router that supports this extension sends an IIH on a BFD enabled interface, it MUST include the BFD-enabled TLV in that IIH. The contents of the TLV MUST indicate which topologies/protocols [RFC5120] have been enabled for BFD, by including the right Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier (NLPID) pairs 💖

When a router sends an IIH on an interface where BFD is NOT enabled, it MUST NOT include the BFD-enabled TLV 🙅‍♀️

3.1. State Definitions

The following definitions apply to each IS-IS neighbor 🔍

For each locally supported MTID/NLPID pair, a ISIS_TOPO_NLPID_BFD_REQUIRED variable gets assigned. If BFD is supported by both the local system and the neighbor for that MTID/NLPID, this variable is set to TRUE. Otherwise, it's set to FALSE.

For each locally supported MTID, an ISIS_TOPO_BFD_REQUIRED variable is set to the logical OR of all the ISIS_TOPO_NLPID_BFD_REQUIRED variables associated with that MTID.

An ISIS_BFD_REQUIRED variable is set to the logical AND of all the ISIS_TOPO_BFD_REQUIRED variables.

For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE variable gets assigned. If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this variable follows the BFD session state for that MTID/NLPID (UP == TRUE). Otherwise, the variable is set to TRUE.

For each locally supported topology (MTID), an ISIS_TOPO_USEABLE variable is set to the logical AND of the set of ISIS_TOPO_NLPID_STATE variables associated with that MTID.

An ISIS_NEIGHBOR_USEABLE variable is set to the logical OR of all the ISIS_TOPO_USEABLE variables ✨

3.2. Adjacency Establishment and Maintenance

Whenever ISIS_BFD_REQUIRED is TRUE, the following extensions to the rules for adjacency establishment and maintenance MUST apply 🔥

  • ISIS_NEIGHBOR_USEABLE MUST be TRUE before the adjacency can move from INIT to UP state.
  • When the IS-IS adjacency is UP and ISIS_NEIGHBOR_USEABLE becomes FALSE, the IS-IS adjacency MUST transition to DOWN.
  • On a Point-to-Point circuit, whenever ISIS_NEIGHBOR_USEABLE is FALSE, the Three-Way adjacency state MUST be set to DOWN in the Point-to-Point Three-Way Adjacency TLV [RFC5303] in all transmitted IIHs.
  • On a LAN circuit, whenever ISIS_NEIGHBOR_USEABLE is FALSE, the IS Neighbors TLV advertising the Media Access Control (MAC) address of the neighbor MUST be omitted from all transmitted IIHs 💅

3.3. Advertisement of Topology-Specific IS Neighbors

Whether a topology-specific IS neighbor gets advertised (and used in the topology-specific decision process) depends on the value of ISIS_TOPO_USEABLE for each topology. If ISIS_TOPO_USEABLE is TRUE, the topology-specific neighbor is advertised. If ISIS_TOPO_USEABLE is FALSE, it isn't advertised 🦋

4. Transition 🌸

okay so, to make the move to BFD non-disruptive, some amount of time should be allowed before bringing down an "UP" adjacency on a BFD enabled interface. This applies when ISIS_BFD_REQUIRED becomes TRUE because the BFD TLV was introduced, or because an existing BFD TLV in a neighbor's IIH was modified (by adding a new supported MTID/NLPID). A simple way to do this is to not update the adjacency hold time when you receive such an IIH from a neighbor you have an "UP" adjacency with, until ISIS_NEIGHBOR_USEABLE becomes TRUE ✨

If ISIS_BFD_REQUIRED becomes FALSE because the BFD TLV was removed, or because an existing BFD TLV in a neighbor's IIH was modified (by removing a supported MTID/NLPID), then a BFD session is no longer required to maintain the adjacency or to move the adjacency to the "UP" state 🧚

If a BFD session is administratively shut down [RFC5880] and that BFD session state change affects the value of ISIS_NEIGHBOR_USEABLE, then IS-IS SHOULD allow time for the matching MTID/NLPID to be removed from the neighbor's BFD TLV. It does this by not updating the adjacency hold time until ISIS_BFD_REQUIRED becomes FALSE. Note that while this allows a non-disruptive transition, it still enforces consistency between the administrative state of the BFD session and the MTID/NLPID(s) advertised in the BFD TLV. That's necessary to give consistent behavior whether the BFD AdminDown state is introduced before or after an IS-IS adjacency has reached the "UP" state 🫶

⚠️ Heads up: the consistency rule above still applies even though this transition is non-disruptive. Don't skip it just because the adjacency is being kept around.
💖 Part 1 of 2! Part 2 picks up with Graceful Restart and the full BFD-Enabled TLV layout. Stay tuned 🌈

7. Security Considerations 🔐

okay bestie, this part is serious but make it make sense 🥺 The TLV in this document is an addition to the IS-IS Hello protocol. If somebody uses it the wrong way, it could stop an IS-IS adjacency from forming, or it could lead to bidirectional forwarding failures not getting detected. Both of those are a form of denial of service 😭 That's a big deal, so yes, it's giving serious energy.

BUT here's the tea: anyone who can mess with the contents of this TLV is already in a position to cause that same denial of service just by disrupting IS-IS routing in other ways. So it's not like this TLV opens a brand new door, fr fr 🚪✨

Also, adding this TLV has no impact on whether authentication gets used, whether it's IS-IS doing the auth or BFD doing it. Not me saying the vibe changes, the facts stay the same 💅

8. IANA Considerations 📋

okay so IANA needs to know about the new IS-IS TLV type defined here 🎀 Here's the table, copied exactly:

Name                                  Value  IIH  LSP  SNP  Purge
----------------------                -----  ---  ---  ---  -----
BFD-Enabled TLV                         148   y    n    n     n

The IS-IS TLV Codepoint registry has been updated accordingly. Slay, the registry is all set 🌸

9. Acknowledgements 🫶

The authors wanna give a shoutout to Jeffrey Haas, Matthew Jones, Dave Katz, Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett, and David Ward for all their various input on this document. Iconic squad 👑

10. Normative References 📚

Here's the reading list, bestie 🧚

[ISO9577] International Organization for Standardization, "Protocol identification in the network layer(ISO/IEC 9577)", ISO/ IEC 9577:1999, Fourth Edition, December 1999.

[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.

[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 2008.

[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.

[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.

[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.

Authors' Addresses 💌

Christian E. Hopps Cisco Systems 170 W. Tasman Dr. San Jose, California 95134 USA EMail: chopps@cisco.com

Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, California 95035 USA EMail: ginsberg@cisco.com

That's the whole RFC, bestie! You did amazing 🌈💖

📦 where this page comes from