idnits 2.17.00 (12 Aug 2021) /tmp/idnits25312/draft-ietf-isis-bfd-tlv-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 239 has weird spacing: '... Value three...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2, 2011) is 4150 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO9577' ** Obsolete normative reference: RFC 5306 (Obsoleted by RFC 8706) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets C. Hopps 3 Internet-Draft L. Ginsberg 4 Intended status: Standards Track Cisco Systems 5 Expires: July 6, 2011 January 2, 2011 7 IS-IS BFD Enabled TLV 8 draft-ietf-isis-bfd-tlv-03 10 Abstract 12 This document describes a type-length-value (TLV) for use in the 13 IS-IS routing protocol that allows for the proper use of the 14 Bidirectional Forwarding Detection protocol (BFD). There exist 15 certain scenarios in which IS-IS will not react appropriately to a 16 BFD detected forwarding plane failure without use of either this TLV 17 or some other method. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 6, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The Solution . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. State Definitions . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Adjacency Establishment and Maintenance . . . . . . . . . . 4 64 3.3. Advertisement of Topology Specific IS Neighbors . . . . . . 5 65 4. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. The BFD Enabled TLV . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 71 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is a 77 protocol that allows for detection of a forwarding plane failure 78 between two routers. A router can use [RFC5880] to validate that a 79 peer router's forwarding ability is functioning. 81 One specific application of BFD as described in [RFC5882] is to 82 verify the forwarding ability of an IS-IS [RFC1195] router's 83 adjacencies; however, the method described in [RFC5882] does not 84 allow for certain failure scenarios. We will define a TLV that will 85 allow for proper response to the detection of all forwarding failures 86 where the use of BFD is employed with IS-IS. 88 2. The Problem 90 We observe that to allow for mixed use (i.e., some routers running 91 BFD and some not) [RFC5882] does not require a BFD session be 92 established prior to the establishment of an IS-IS adjacency. Thus, 93 if a router A has neighbors B and C, and B does not support BFD, A 94 would still form adjacencies with B and C, and would only establish a 95 BFD session with C. 97 The problem with this solution is that it assumes that the 98 transmission and receipt of IS-IS Hellos (IIHs) shares fate with 99 forwarded data packets. This is not a fair assumption to make given 100 that the primary use of BFD is to protect IPv4 (and IPv6) forwarding 101 and IS-IS does not utilize IPv4 or IPv6 for sending or receiving its 102 hellos. 104 Thus, if we consider our previous example, and if C is currently 105 experiencing an IPv4 forwarding failure that allows for IIHs to be 106 sent and received, when A first starts (or restarts) A will assume 107 that C simply does not support BFD, will form an adjacency with C, 108 and may incorrectly forward IPv4 traffic through C. 110 3. The Solution 112 A simple solution to this problem is for an IS-IS router to advertise 113 that it has BFD enabled on a given interface. It can do this through 114 the inclusion of a TLV in its IIHs as described in this document. 116 When sending an IIH on a BFD enabled interface, a router which 117 supports this extension MUST include the BFD enabled TLV in its IIH. 118 The contents of the TLV MUST indicate what topologies/protocols 119 [RFC5120] have been enabled for BFD by including the appropriate 120 Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier 121 (NLPID) pairs. 123 When sending an IIH on an interface on which BFD is NOT enabled a 124 router MUST NOT include the BFD enabled TLV. 126 3.1. State Definitions 128 The following definitions apply to each IS-IS neighbor: 130 For each locally supported MTID/NLPID pair, an 131 "ISIS_TOPO_NLPID_BFD_REQUIRED" variable is assigned. If BFD is 132 supported by both the local system and the neighbor for the MTID/ 133 NLPID this variable is set to "TRUE". Otherwise the variable is set 134 to "FALSE". 136 For each locally supported MTID, an "ISIS_TOPO_BFD_REQUIRED" variable 137 is set to the logical "OR" of all "ISIS_TOPO_NLPID_BFD_REQUIRED" 138 variables associated with that MTID. 140 An "ISIS_BFD_REQUIRED" variable is set to the logical "AND" of all 141 "ISIS_TOPO_BFD_REQUIRED" variables. 143 For each locally supported MTID/NLPID pair, an 144 "ISIS_TOPO_NLPID_STATE" variable is assigned. If 145 "ISIS_TOPO_NLPID_BFD_REQUIRED" is "TRUE", this variable follows the 146 BFD session state for that MTID/NLPID ("UP == TRUE"). Otherwise the 147 variable is set to "TRUE". 149 For each locally supported topology (MTID), an "ISIS_TOPO_USEABLE" 150 variable is set to the logical "AND" of the set of 151 "ISIS_TOPO_NLPID_STATE" variables associated with that MTID. 153 An "ISIS_NEIGHBOR_USEABLE" variable is set to the logical "OR" of all 154 "ISIS_TOPO_USEABLE" variables. 156 3.2. Adjacency Establishment and Maintenance 158 Whenever "ISIS_BFD_REQUIRED" is "TRUE" the following extensions to 159 the rules for adjacency establishment and maintenance MUST apply: 161 o "ISIS_NEIGHBOR_USEABLE" MUST be "TRUE" before the adjacency can 162 transition from "INIT" to "UP" state 164 o When the IS-IS adjacency is "UP" and "ISIS_NEIGHBOR_USEABLE" 165 becomes "FALSE" the IS-IS adjacency MUST transition to "DOWN". 167 o On a Point-to-Point circuit whenever "ISIS_NEIGHBOR_USEABLE" is 168 "FALSE", the Three-Way adjacency state MUST be set to "DOWN" in 169 the Point-to-Point Three Way Adjacency TLV[RFC5303] in all 170 transmitted IIHs. 172 o On a LAN circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the 173 IS Neighbors TLV advertising the MAC address of the neighbor MUST 174 be omitted in all transmitted IIHs. 176 3.3. Advertisement of Topology Specific IS Neighbors 178 The advertisement of a topology specific IS-neighbor (as well as the 179 use of the neighbor in the topology specific decision process) is 180 determined by the value of "ISIS_TOPO_USEABLE" for each topology. If 181 "ISIS_TOPO_USEABLE" is "TRUE" then the topology specific neighbor is 182 advertised. If "ISIS_TOPO_USEABLE" is "FALSE" then the topology 183 specific neighbor is not advertised. 185 4. Transition 187 To allow for a non-disruptive transition to the use of BFD some 188 amount of time should be allowed before bringing down an "UP" 189 adjacency on a BFD enabled interface when the value of 190 "ISIS_BFD_REQUIRED" becomes "TRUE" as a result of the introduction of 191 the BFD TLV or the modification (by adding a new supported MTID/ 192 NLPID) of an existing BFD TLV in a neighbor's IIH. A simple way to 193 do this is to not update the adjacency hold-time when receiving such 194 an IIH from a neighbor with whom we have an "UP" adjacency until 195 "ISIS_NEIGHBOR_USEABLE" becomes "TRUE". 197 If the value of "ISIS_BFD_REQUIRED" becomes "FALSE" as a result of 198 the removal the BFD TLV or the modification (by removing a supported 199 MTID/NLPID) of an existing BFD TLV in a neighbor's IIH then BFD 200 session establishment is no longer required to maintain the adjacency 201 or transition the adjacency to the "UP" state. 203 If a BFD session is administratively shut down [RFC5880] and the BFD 204 session state change impacts the value of "ISIS_NEIGHBOR_USEABLE", 205 then IS-IS SHOULD allow time for the corresponding MTID/NLPID to be 206 removed from the neighbor's BFD TLV by not updating the adjacency 207 hold time until "ISIS_BFD_REQUIRED" becomes "FALSE". Note that while 208 this allows a non-disruptive transition, it still enforces 209 consistency between the administrative state of the BFD session and 210 the MTID/NLPID(s) advertised in the BFD TLV. This is necessary to 211 provide consistent behavior regardless of whether the BFD AdminDown 212 state is introduced before or after an IS-IS adjacency "UP" state has 213 been achieved. 215 5. Graceful Restart 217 This section describes IS-IS implementation considerations when both 218 both IS-IS graceful restart [RFC5306] and BFD are co-deployed. 220 In cases where BFD shares fate with the control plane, it can be 221 expected that BFD session failure may occur in conjunction with the 222 control plane restart. In such cases premature abort of IS-IS 223 graceful restart as a result of BFD session failure is undesirable. 224 Therefore, some mechanism to ignore the BFD session failure for a 225 limited period of time would be beneficial. The issue of the 226 interaction between graceful restart and BFD is described at length 227 in RFC5882. The implementation of this interaction is outside the 228 scope of this document. 230 6. The BFD Enabled TLV 232 The BFD enabled TLV is formatted as shown below. The TLV SHALL only 233 be included in an IIH and only when BFD is enabled for one or more 234 supported MTID/protocols on the interface over which the IIH is being 235 sent. The NLPIDs encoded in the TLV are defined in [ISO9577] 237 Type 139 (suggested - to be assigned by IANA) 238 Length # of octets in the value field (3 to 255) 239 Value three octets specifying the MTID/NLPID for each 240 topology/data protocol for which BFD support is enabled 242 No. of octets 243 +-----------------------+ 244 |R|R|R|R| MTID | 2 245 +-----------------------+ 246 | NLPID | 1 247 +-----------------------+ 248 : : 249 : : 250 +-----------------------+ 251 |R|R|R|R| MTID | 2 252 +-----------------------+ 253 | NLPID | 1 254 +-----------------------+ 256 7. Security Considerations 258 The TLV defined within this document describes an addition to the 259 IS-IS Hello protocol. Inappropriate use of this TLV could prevent an 260 IS-IS adjacency from forming or lead to failure to detect 261 bidirectional forwarding failures - each of which is a form of denial 262 of service. However, a party who can manipulate the contents of this 263 TLV is already in a position to create such a denial of service by 264 disrupting IS-IS routing in other ways. 266 Note that the introduction of this TLV has no impact on the use/ 267 non-use of authentication either by IS-IS or by BFD. 269 8. IANA Considerations 271 The following IS-IS TLV type is defined by this draft. 273 Name Value IIH LSP SNP 274 ---------------------- ----- --- --- --- 275 BFD Enabled TLV 139 y n n 277 Please update the IS-IS TLV Codepoint Registry accordingly. 279 9. Acknowledgements 281 The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz, 282 Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett and 283 David Ward, for various input on this document. 285 10. Normative References 287 [ISO9577] International Organization for Standardization, "Protocol 288 identification in the network layer(ISO/IEC 9577)", ISO/ 289 IEC 9577:1999, Fourth Edition, Dec 1999. 291 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 292 dual environments", RFC 1195, December 1990. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 298 Topology (MT) Routing in Intermediate System to 299 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 301 [RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way 302 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 303 October 2008. 305 [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 306 RFC 5306, October 2008. 308 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 309 (BFD)", RFC 5880, June 2010. 311 [RFC5882] Katz, D. and D. Ward, "Generic Application of 312 Bidirectional Forwarding Detection (BFD)", RFC 5882, 313 June 2010. 315 Authors' Addresses 317 Christian E. Hopps 318 Cisco Systems 319 170 W. Tasman Dr. 320 San Jose, California 95134 321 USA 323 Email: chopps@cisco.com 325 Les Ginsberg 326 Cisco Systems 327 510 McCarthy Blvd. 328 Milpitas, Ca. 95035 329 USA 331 Email: ginsberg@cisco.com