IS-IS BFD-Enabled TLV
Extracted elements (18)
RFC 5882 permits IS-IS adjacencies to form without a prior BFD session to allow mixed deployments. However, IS-IS hellos (IIHs) do not travel over IPv4/IPv6, so they do not share fate with IPv4/IPv6 forwarded data. A neighbor experiencing an IPv4 forwarding failure can still exchange IIHs, causing a restarting router to incorrectly assume BFD is unsupported and forward traffic through the broken path.
The solution is to have each IS-IS router explicitly advertise, via a new TLV in its IIHs, which topologies/protocols have BFD enabled on that interface. This allows a neighbor to distinguish 'BFD not supported' from 'BFD enabled but session not yet UP', enabling correct reaction to forwarding failures.
To allow a non-disruptive transition when ISIS_BFD_REQUIRED becomes TRUE (due to introduction or modification of a BFD TLV), an implementation SHOULD delay bringing down an UP adjacency by not updating the adjacency hold time until ISIS_NEIGHBOR_USEABLE becomes TRUE.
When IS-IS graceful restart (RFC 5306) and BFD are co-deployed, BFD session failure may coincide with control-plane restart. Premature abort of graceful restart due to BFD failure is undesirable; some mechanism to temporarily ignore BFD session failure is beneficial. The detailed interaction is described in RFC 5882 and is outside the scope of this document.
If ISIS_TOPO_USEABLE is TRUE for a given topology (MTID), the topology-specific IS neighbor is advertised and used in the decision process; if FALSE, the neighbor is not advertised.
On a LAN circuit, whenever ISIS_NEIGHBOR_USEABLE is FALSE, the IS Neighbors TLV advertising the MAC address of the neighbor MUST be omitted in all transmitted IIHs.
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 (RFC 5303) in all transmitted IIHs.
The BFD-Enabled TLV SHALL only be included in an IIH, and only when BFD is enabled for one or more supported MTID/protocols on the interface over which the IIH is being sent.
When a BFD session is administratively shut down and the state change impacts ISIS_NEIGHBOR_USEABLE, IS-IS SHOULD allow time for the MTID/NLPID to be removed from the neighbor's BFD TLV by not updating the adjacency hold time until ISIS_BFD_REQUIRED becomes FALSE.
When sending an IIH on a BFD-enabled interface, a router that supports this extension MUST include the BFD-enabled TLV in its IIH, with contents indicating all MTID/NLPID pairs enabled for BFD.
When sending an IIH on an interface on which BFD is NOT enabled, a router MUST NOT include the BFD-enabled TLV.
When the IS-IS adjacency is UP and ISIS_NEIGHBOR_USEABLE becomes FALSE, the IS-IS adjacency MUST transition to DOWN.
Whenever ISIS_BFD_REQUIRED is TRUE, ISIS_NEIGHBOR_USEABLE MUST be TRUE before the IS-IS adjacency can transition from INIT to UP state.
Each entry in the BFD-Enabled TLV value field is a 3-octet MTID/NLPID pair: the first 2 octets carry 4 reserved bits followed by a 12-bit Multi-Topology Identifier (MTID), and the third octet carries the Network Layer Protocol Identifier (NLPID) identifying the protocol/address family for which BFD is enabled.
IS-IS TLV Codepoint 148 is assigned to the BFD-Enabled TLV. It is valid in IIH PDUs only (IIH=y, LSP=n, SNP=n, Purge=n). The IS-IS TLV Codepoint registry has been updated accordingly.
Inappropriate manipulation of the BFD-Enabled TLV could prevent IS-IS adjacency formation or cause failure to detect bidirectional forwarding failures, both of which are forms of denial of service. However, an attacker capable of manipulating this TLV already has the capability to disrupt IS-IS routing by other means. The introduction of this TLV has no impact on the use or non-use of IS-IS or BFD authentication.
For each IS-IS neighbor, six logical state variables are defined: ISIS_TOPO_NLPID_BFD_REQUIRED (TRUE if both sides support BFD for that MTID/NLPID), ISIS_TOPO_BFD_REQUIRED (OR over all NLPIDs for an MTID), ISIS_BFD_REQUIRED (AND over all MTIDs), ISIS_TOPO_NLPID_STATE (tracks BFD session state when required, else TRUE), ISIS_TOPO_USEABLE (AND of NLPID states for an MTID), and ISIS_NEIGHBOR_USEABLE (OR over all MTIDs).
The BFD-Enabled TLV has Type 148, a Length field indicating the number of octets in the value field (3 to 255), and a Value field consisting of 3-octet MTID/NLPID entries: 2 octets for the MTID (with 4 reserved bits, then a 12-bit MTID) and 1 octet for the NLPID (as defined in ISO 9577).