idnits 2.17.1 draft-ietf-isis-bfd-tlv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. 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 Copyright Line does not match the current year == Line 232 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 (March 23, 2008) is 5876 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' == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-07 == Outdated reference: A later version (-05) exists of draft-ietf-bfd-generic-04 -- Obsolete informational reference (is this intentional?): RFC 3373 (Obsoleted by RFC 5303) -- Obsolete informational reference (is this intentional?): RFC 3847 (Obsoleted by RFC 5306) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 10 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: September 24, 2008 March 23, 2008 7 IS-IS BFD Enabled TLV 8 draft-ietf-isis-bfd-tlv-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 24, 2008. 35 Abstract 37 This document describes a TLV for use in the IS-IS routing protocol 38 that allows for the proper use of the Bidirectional Forwarding 39 Detection protocol (BFD). There exist certain scenarios in which 40 IS-IS will not react appropriately to a BFD detected forwarding plane 41 failure without use of either this TLV or some other method. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. The Solution . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. State Definitions . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Adjacency Establishment and Maintenance . . . . . . . . . . 4 56 3.3. Advertisement of Topology Specific IS Neighbors . . . . . . 5 57 4. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. The BFD Enabled TLV . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Intellectual Property and Copyright Statements . . . . . . . . . . 9 69 1. Introduction 71 The Bidirectional Forwarding Detection protocol [I-D.ietf-bfd-base] 72 is a protocol that allows for detection of a forwarding plane failure 73 between two routers. A router can use [I-D.ietf-bfd-base] to 74 validate that a peer router's forwarding ability is functioning. 76 One specific application of BFD as described in 77 [I-D.ietf-bfd-generic] is to verify the forwarding ability of an 78 IS-IS [RFC1195] router's adjacencies; however, the method described 79 in [I-D.ietf-bfd-generic] does not allow for certain failure 80 scenarios. We will define a TLV that will allow for proper response 81 to the detection of all forwarding failures where the use of BFD is 82 employed with IS-IS. 84 2. The Problem 86 We observe that to allow for mixed use (i.e., some routers running 87 BFD and some not) [I-D.ietf-bfd-generic] does not require a BFD 88 session be established prior to the establishment of an IS-IS 89 adjacency. Thus, if a router A has neighbors B and C, and B does not 90 support BFD, A would still form adjacencies with B and C, and would 91 only establish a BFD session with C. 93 The problem with this solution is that it assumes that the 94 transmission and receipt of IS-IS IIHs shares fate with forwarded 95 data packets. This is not a fair assumption to make given that the 96 primary use of BFD is to protect IPv4 (and IPv6) forwarding and IS-IS 97 does not utilize IPv4 or IPv6 for sending or receiving its hellos. 99 Thus, if we consider our previous example, and if C is currently 100 experiencing an IPv4 forwarding failure that allows for IS-IS IIHs to 101 be sent and received, when A first starts (or restarts) A will assume 102 that C simply does not support BFD, will form an adjacency with C, 103 and may incorrectly forward IPv4 traffic through C. 105 3. The Solution 107 A simple solution to this problem is for an IS-IS router to advertise 108 that it has BFD enabled on a given interface. It can do this through 109 the inclusion of a TLV in its IIHs, and indeed that is our proposal. 111 When sending an IIH on a BFD enabled interface, a router which 112 supports this extension MUST include the BFD enabled TLV in its IIH. 113 The contents of the TLV MUST indicate what topologies/protocols 114 [RFC5120] have been enabled for BFD by including the appropriate 115 MTID/NLPID pairs. 117 When sending an IIH on an interface on which BFD is NOT enabled a 118 router MUST NOT include the BFD enabled TLV. 120 3.1. State Definitions 122 The following definitions apply to each IS-IS neighbor: 124 For each locally supported MTID/NLPID pair, an 125 ISIS_TOPO_NLPID_BFD_REQUIRED variable is assigned. If BFD is 126 supported by both the local system and the neighbor for the MTID/ 127 NLPID this variable is set to TRUE. Otherwise the variable is set to 128 FALSE. 130 For each locally supported MTID, an ISIS_TOPO_BFD_REQUIRED variable 131 is set to the logical OR of all ISIS_TOPO_NLPID_BFD_REQUIRED 132 variables associated with that MTID. 134 An ISIS_BFD_REQUIRED variable is set to the logical AND of all 135 ISIS_TOPO_BFD_REQUIRED variables. 137 For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE 138 variable is assigned. If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this 139 variable follows the BFD session state for that MTID/NLPID (UP == 140 TRUE). Otherwise the variable is set to TRUE. 142 For each locally supported topology (MTID), an ISIS_TOPO_USEABLE 143 variable is set to the logical AND of the set of 144 ISIS_TOPO_NLPID_STATE variables associated with that MTID. 146 An ISIS_NEIGHBOR_USEABLE variable is set to the logical OR of all 147 ISIS_TOPO_USEABLE variables. 149 3.2. Adjacency Establishment and Maintenance 151 Whenever ISIS_BFD_REQUIRED is TRUE the following extensions to the 152 rules for adjacency establishment and maintenance MUST apply: 154 o ISIS_NEIGHBOR_USEABLE MUST be TRUE before the adjacency can 155 transition from INIT to UP state 157 o When the IS-IS adjacency is UP and ISIS_NEIGHBOR_USEABLE becomes 158 FALSE the IS-IS adjacency MUST transition to DOWN. 160 o On a Point-to-Point circuit whenever ISIS_NEIGHBOR_USEABLE is 161 FALSE, the Three-Way adjacency state MUST be set to DOWN in the 162 Point-to-Point Three Way Adjacency TLV[RFC3373] in all transmitted 163 IIHs. 165 o On a LAN circuit whenever ISIS_NEIGHBOR_USEABLE is FALSE, the IS 166 Neighbors TLV advertising the MAC address of the neighbor MUST be 167 omitted in all transmitted IIHs. 169 3.3. Advertisement of Topology Specific IS Neighbors 171 The advertisement of a topology specific IS-neighbor (as well as the 172 use of the neighbor in the topology specific decision process) is 173 determined by the value of ISIS_TOPO_USEABLE for each topology. If 174 ISIS_TOPO_USEABLE is TRUE then the topology specific neighbor is 175 advertised. If ISIS_TOPO_USEABLE is FALSE then the topology specific 176 neighbor is NOT advertised. 178 4. Transition 180 To allow for a non-disruptive transition to the use of BFD some 181 amount of time should be allowed before bringing down an UP adjacency 182 on a BFD enabled interface when the value of ISIS_BFD_REQUIRED 183 becomes TRUE as a result of the introduction of the BFD TLV or the 184 modification (by adding a new supported MTID/NLPID) of an existing 185 BFD TLV in a neighbor's IIH. A simple way to do this is to not 186 update the adjacency hold-time when receiving such an IIH from a 187 neighbor with whom we have an UP adjacency until 188 ISIS_NEIGHBOR_USEABLE becomes TRUE. 190 If the value of ISIS_BFD_REQUIRED becomes FALSE as a result of the 191 removal the BFD TLV or the modification (by removing a supported 192 MTID/NLPID) of an existing BFD TLV in a neighbor's IIH then BFD 193 session establishment is no longer required to maintain the adjacency 194 or transition the adjacency to the UP state. 196 If a BFD session is administratively shut down [I-D.ietf-bfd-base] 197 and the BFD session state change impacts the value of 198 ISIS_NEIGHBOR_USEABLE, then IS-IS SHOULD allow time for the 199 corresponding MTID/NLPID to be removed from the neighbor's BFD TLV by 200 not updating the adjacency hold time until ISIS_BFD_REQUIRED becomes 201 FALSE. Note that while this allows a non-disruptive transition, it 202 still enforces consistency between the administrative state of the 203 BFD session and the MTID/NLPID(s) advertised in the BFD TLV. This is 204 necessary to provide consistent behavior regardless of whether the 205 BFD AdminDown state is introduced before or after an IS-IS adjacency 206 UP state has been achieved. 208 5. Graceful Restart 210 It is worth considering what if anything should be done when IS-IS is 211 gracefully restarting [RFC3847]. 213 In cases where BFD shares fate with the control plane, it can be 214 expected that BFD session failure may occur in conjunction with the 215 control plane restart. In such cases premature abort of IS-IS 216 graceful restart as a result of BFD session failure is undesirable. 217 Therefore, some mechanism to ignore the BFD session failure for a 218 limited period of time would be beneficial. How this is implemented 219 is beyond the scope of this document. Consult [I-D.ietf-bfd-generic] 220 for further details. 222 6. The BFD Enabled TLV 224 The BFD enabled TLV is formatted as shown below. The TLV SHALL only 225 be included in an IS-IS IIH PDU and only when BFD is enabled for one 226 or more supported MTID/protocols on the interface over which the IIH 227 is being sent. The NLPIDs encoded in the TLV are defined in 228 [ISO9577] 230 Type 139 (suggested - to be assigned by IANA) 231 Length # of octets in the value field (3 to 255) 232 Value three octets specifying the MTID/NLPID for each 233 topology/data protocol for which BFD support is enabled 235 No. of octets 236 +-----------------------+ 237 |R|R|R|R| MTID | 2 238 +-----------------------+ 239 | NLPID | 1 240 +-----------------------+ 241 : : 242 : : 243 +-----------------------+ 244 |R|R|R|R| MTID | 2 245 +-----------------------+ 246 | NLPID | 1 247 +-----------------------+ 249 7. Security Considerations 251 The TLV defined within this document describes an addition to the 252 IS-IS Hello protocol and does not impact the security mechanism of 253 the IS-IS protocol. 255 8. IANA Considerations 257 The following IS-IS TLV type is defined by this draft. 259 Name Value IIH LSP SNP 260 ---------------------- ----- --- --- --- 261 BFD Enabled TLV 139 y n n 263 Please update the IS-IS TLV Codepoint Registry accordingly. 265 Note to RFC Editor: this section may be removed on publication as an 266 RFC. 268 9. Acknowledgements 270 The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz, 271 Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett and 272 David Ward, for various input on this document. 274 10. References 276 10.1. Normative References 278 [ISO9577] International Organization for Standardization, "Protocol 279 identification in the network layer(ISO/IEC 9577)", ISO/ 280 IEC 9577:1999, Fourth Edition, Dec 1999. 282 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 283 dual environments", RFC 1195, December 1990. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 289 Topology (MT) Routing in Intermediate System to 290 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 292 10.2. Informative References 294 [I-D.ietf-bfd-base] 295 Katz, D. and D. Ward, "Bidirectional Forwarding 296 Detection", draft-ietf-bfd-base-07 (work in progress), 297 January 2008. 299 [I-D.ietf-bfd-generic] 300 Katz, D. and D. Ward, "Generic Application of BFD", 301 draft-ietf-bfd-generic-04 (work in progress), 302 January 2008. 304 [RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for 305 Intermediate System to Intermediate System (IS-IS) Point- 306 to-Point Adjacencies", RFC 3373, September 2002. 308 [RFC3847] Shand, M. and L. Ginsberg, "Restart Signaling for 309 Intermediate System to Intermediate System (IS-IS)", 310 RFC 3847, July 2004. 312 Authors' Addresses 314 Christian E. Hopps 315 Cisco Systems 316 170 W. Tasman Dr. 317 San Jose, California 95134 318 USA 320 Email: chopps@cisco.com 322 Les Ginsberg 323 Cisco Systems 324 510 McCarthy Blvd. 325 Milpitas, Ca. 95035 326 USA 328 Email: ginsberg@cisco.com 330 Full Copyright Statement 332 Copyright (C) The IETF Trust (2008). 334 This document is subject to the rights, licenses and restrictions 335 contained in BCP 78, and except as set forth therein, the authors 336 retain all their rights. 338 This document and the information contained herein are provided on an 339 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 340 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 341 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 342 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 343 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 344 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 346 Intellectual Property 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; nor does it represent that it has 353 made any independent effort to identify any such rights. Information 354 on the procedures with respect to rights in RFC documents can be 355 found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the use of 360 such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository at 362 http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at 368 ietf-ipr@ietf.org.