idnits 2.17.1 draft-chopps-isis-bfd-tlv-00.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 240. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 232), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (20 March 2005) is 6948 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) == Missing Reference: 'KEYWORDS' is mentioned on line 48, but not defined == Unused Reference: 'KEYWORD' is defined on line 197, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-01 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-01 -- Obsolete informational reference (is this intentional?): RFC 3373 (ref. 'ISIS-3WAY') (Obsoleted by RFC 5303) -- Obsolete informational reference (is this intentional?): RFC 3847 (ref. 'ISIS-GR') (Obsoleted by RFC 5306) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Christian E. Hopps 2 INTERNET-DRAFT Cisco Systems 3 Expires September 2005 20 March 2005 5 IS-IS BFD Enabled TLV 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society (2005). All Rights Reserved. 35 Abstract 37 This document describes a TLV for use in the IS-IS routing protocol 38 that allows for the proper functioning of the Bidirectional 39 Forwarding Detection protocol (BFD). There exists certain scenarios 40 in which BFD will fail to detect a forwarding plane failure without 41 use of either this TLV or some other method. 43 Conventions used in this document 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 [KEYWORDS]. 49 1. Introduction 51 The Bidirectional Forwarding Detection protocol [BFD] is a protocol 52 that allows for detection of a forwarding plane failure between two 53 routers. A router can use [BFD] to validate that a peer router's 54 forwarding ability is functioning. 56 One specific application of BFD as described in [IP-BFD] is to verify 57 the forwarding ability of an IS-IS [ISIS] router's adjacencies; 58 however, the method described in [IP-BFD] does not allow for certain 59 failure scenarios. We will define a TLV that will allow for proper 60 detection of all forwarding failures where the use of BFD is employed 61 with IS-IS. 63 2. The Problem 65 We observe that to allow for mixed use (i.e., some routers running 66 BFD and some not) [IP-BFD] does not require a BFD session be 67 established prior to the establishment of an IS-IS adjacency. Thus, 68 if a router A has a neighbor B and C, and B does not support BFD, A 69 would still form adjacencies with B and C, and would only establish a 70 BFD session with C. 72 The problem with this solution is that it assumes that the 73 transmission and receipt of an IS-IS IIH shares fate with forwarded 74 packets. This is not a fair assumption to make given that the primary 75 use of BFD is to protect IPv4 (and IPv6) forwarding and IS-IS does 76 not utilize IPv4 or IPv6 for sending or receiving its hellos. 78 Thus, if we consider our previous example, and if C is currently 79 experiencing an IPv4 forwarding failure that allows for IS-IS IIHs to 80 be sent and received, when A first starts (or restarts) A will assume 81 that C simply does not support BFD and may incorrectly forward IPv4 82 traffic through C. 84 3. The Solution 86 A simple solution to this problem is for an IS-IS router to advertise 87 that it has BFD enabled on a given interface. It can do this through 88 the inclusion of a TLV in its IIHs, and indeed that is our proposal. 90 When sending an IIH on a BFD enabled interface, the router SHALL 91 include the BFD enabled TLV in its IIH, otherwise BFD is disabled on 92 the interface and the router SHALL NOT include the BFD enable TLV. 94 When receiving an IIH from a neighbor on an interface with BFD 95 enabled, if the IIH does not have a BFD enabled TLV then no BFD 96 session will be attempted with the given neighbor. 98 When receiving an IIH from a neighbor on an interface with BFD 99 enabled, and if the IIH contains the BFD enabled TLV, then the 100 establishment of a BFD session with that neighbor will be required 101 before allowing the adjacency to the neighbor to reach the UP state. 102 An adjacency can be held in the INIT state by not including the 103 neighbor in the IIHs sent out an interface. This method requires use 104 of the 3-way handshake [ISIS-3WAY] on point-to-point interfaces. 106 If BFD is not enabled on an interface then the BFD enabled TLV is 107 ignored on receipt. 109 4. Transition 111 To allow for a non-disruptive transition to the use of BFD some 112 amount of time should be allowed before bringing down an UP adjacency 113 on a BFD enabled interface when the BFD TLV is first added to a 114 neighbor's IIH. A simple way to do this is to not update the 115 adjacency hold-time when receiving an IIH from an UP adjacency with 116 the BFD enable TLV until a session is established with the neighbor. 118 If a neighbor removes the BFD enabled TLV from its IIH then BFD 119 session establishment is no longer required. It is implementation 120 defined whether any current session is torn down, and because of 121 this, a router wishing to transition away from the use of BFD should 122 first gracefully disable BFD [BFD] before removing the TLV from its 123 IIH. 125 If a BFD session is gracefully shut down [BFD] IS-IS will simply 126 revert to the behavior already defined above. Specifically receiving 127 an IIH with the BFD enabled TLV would be treated as if the neighbor 128 were transitioning to the use of BFD, otherwise no BFD enabled TLV is 129 present and no action is required. 131 5. Graceful Restart 133 It is worth considering what if anything should be done when IS-IS is 134 gracefully restarting [ISIS-GR]. We assume that the BFD session is 135 being maintained, although how this is done is outside the scope of 136 this document. 138 When there is no change in the local and remote BFD enabled state, 139 nothing interesting will occur. If we had a BFD session with a 140 neighbor previously we will continue to have one, and both routers 141 will continue to advertise the BFD enabled state within their IIHs. 142 If we did not have a session we will we continue to not have a 143 session. 145 If the neighbor changes its BFD enabled state from enabled to 146 disabled the TLV will no longer be present. This is the same as the 147 non-restarting case described above, namely BFD session establishment 148 is no longer required, and it is implementation defined whether any 149 current session is torn down. 151 If the neighbor changes its BFD state from disabled to enabled the 152 TLV will be newly present in the IIH. This is the same as the non- 153 restarting case of transitioning to BFD use as defined above, namely 154 we recover the adjacency but allow time for the BFD session to be re- 155 established, and as stated above this can be accomplished by not 156 further updating the hold-time for an adjacency until the BFD session 157 is established. 159 6. The BFD Enabled TLV 161 The BFD enabled TLV has the type (TBD) and length of 0. The TLV SHALL 162 only be included in an IS-IS IIH PDU. The TLV is boolean, and thus if 163 present then the sending router is indicating the BFD is enabled on 164 the sending interface, otherwise BFD is not enabled on the sending 165 interface. 167 7. Security Considerations 169 The TLV defined within this document describes an addition to the IS- 170 IS Hello protocol and does not impact the security mechanism of the 171 IS-IS protocol. 173 8. IANA Considerations 175 The following IS-IS TLV type is defined by this draft. 177 Name Value IIH LSP SNP 178 ---------------------- ----- --- --- --- 179 BFD Enabled TLV TBD y n n 181 Please update the IS-IS TLV Codepoint Registry accordingly. 183 9. Acknowledgments 185 The author wishes to thank Les Ginsberg, Matthew Jones, Dave Katz, 186 Jonathan Moon, Stefano Previdi, Michael Shiplett and David Ward, for 187 various input on this document. 189 10. Normative References 191 [ISIS] 192 Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 193 environments", RFC 1195, December 1990. 195 11. Informative References 197 [KEYWORD] 198 Bradner, S., "Key words for use in RFCs to Indicate Requirement 199 Levels", RFC 2119, March 1997. 201 [BFD] 202 Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 203 draft-ietf-bfd-base-01.txt, February, 2005. 205 [IP-BFD] 206 Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single Hop)", 207 draft-ietf-bfd-v4v6-1hop-01.txt, February, 2005. 209 [ISIS-3WAY] 210 Katz, D., and Saluja, R., "Three-Way Handshake for Intermediate 211 System to Intermediate System (IS-IS) Point-to-Point Adjacencies", 212 RFC 3373, September 2002. 214 [ISIS-GR] 215 Shand, M., and Ginsberg, L., "Restart Signaling for Intermediate 216 System to Intermediate System (IS-IS)", RFC 3847, July 2004 218 12. Author's Address 220 Christian E. Hopps 221 Cisco Systems 222 3750 Cisco Way 223 San Jose, CA 95134 224 U.S.A. 225 Phone: +1 408 525 1684 226 Email: chopps@cisco.com 228 13. Full Copyright Statement 230 Copyright (C) The Internet Society (2005). This document is subject 231 to the rights, licenses and restrictions contained in BCP 78, and 232 except as set forth therein, the authors retain all their rights. 234 This document and the information contained herein are provided on an 235 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 236 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 237 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 238 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 239 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 240 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.