idnits 2.17.1 draft-ketant-lsr-ospf-bfd-strict-mode-01.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 -- The document date (March 11, 2019) is 1845 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link State Routing K. Talaulikar 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: September 12, 2019 March 11, 2019 7 OSPF BFD Strict-Mode 8 draft-ketant-lsr-ospf-bfd-strict-mode-01 10 Abstract 12 This document specifies the extensions to OSPF that enables a router 13 and its neighbor to signal their intention to use Bidirectional 14 Forwarding Detection (BFD) for their adjacency using link-local 15 advertisement between them. The signaling of this BFD enablement, 16 allows the router to block and not allow the establishment of 17 adjacency with its neighbor router until a BFD session is 18 successfully established between them. The document describes this 19 "strict-mode" of BFD establishment as a prerequisite to OSPF 20 adjacency formation. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 12, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. LLS B-bit Flag . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Operations & Management Considerations . . . . . . . . . . . 5 68 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 9.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Bidirectional Forwarding Detection (BFD) [RFC5880] enables routers to 80 monitor dataplane connectivity over links between them and to detect 81 faults in the bidirectional path between them. This capability is 82 leveraged by routing protocols like Open Shortest Path First (OSPFv2) 83 [RFC2328] and OSPFv3 [RFC5340] to detect connectivity failures for 84 their adjacencies and trigger the rerouting of traffic around this 85 failure more quickly than their periodic hello messaging based 86 detection mechanism. 88 The use of BFD for monitoring routing protocols adjacencies is 89 described in [RFC5882]. When BFD monitoring is enabled for OSPF 90 adjacencies, the BFD session is bootstrapped based on the neighbor 91 address information discovered by the exchange of OSPF hello 92 messages. Faults in the bidirectional forwarding detected via BFD 93 then result in the bringing down of the OSPF adjacency. Note that it 94 is possible in some failure scenarios for the network to be in a 95 state such that the OSPF adjacency is capable of coming up, but the 96 BFD session cannot be established, and, more particularly, data 97 cannot be forwarded. In certain other scenarios, a degraded or poor 98 quality link may result in OSPF adjacency formation to succeed only 99 to result in BFD session establishment not being successful or the 100 BFD session going down frequently due to its faster detection 101 mechanism. 103 To avoid such situations which result in routing churn in the 104 network, it would be beneficial not to allow OSPF to establish a 105 neighbor adjacency until the BFD session is successfully established 106 and stabilized. However, this would preclude the OSPF operation in 107 an environment in which not all OSPF routers support BFD and are 108 enabled for BFD monitoring. A solution would be to block the 109 establishment of OSPF adjacencies if both systems are willing to 110 establish a BFD session but a BFD session cannot be established. 111 Such a mode of BFD use by OSPF is referred to as "strict-mode" 112 wherein BFD session establishment becomes a prerequisite for OSPF 113 adjacency coming up. 115 This document specifies the OSPF protocol extensions using link-local 116 signaling (LLS) [RFC5613] for a router to indicate to its neighbor 117 the willingness to establish a BFD session in the "strict-mode". 119 A similar functionality for IS-IS is specified [RFC6213]. 121 2. LLS B-bit Flag 123 A new B-bit is defined in the LLS Type 1 Extended Options and Flags 124 field. This bit is defined for the LLS block included in Hello 125 packets and indicates that BFD is enabled on the link and that the 126 router supports BFD strict-mode. Section 6 describes the position of 127 this new B-bit. 129 A router MUST include the LLS block with the LLS Type 1 Extended 130 Options and Flags TLV with the B-bit set its Hello messages when BFD 131 is enabled on the link. 133 3. Procedures 135 A router supporting BFD strict-mode advertises this capability 136 through its hello messages as described in Section 2 above. When a 137 router supporting BFD strict-mode, detects a new neighbor router that 138 also supports BFD strict-mode, then it proceeds to establish 139 adjacency with that neighbor as described further in this section. 141 This document updates the OSPF neighbor state machine as described in 142 [RFC2328] specifically the operations related to the Init state as 143 below when BFD strict-mode is used: 145 Init (without BFD strict-mode) 147 In this state, an Hello packet has recently been seen from the 148 neighbor. However, bidirectional communication has not yet been 149 established with the neighbor (i.e., the router itself did not 150 appear in the neighbor's Hello packet). All neighbors in this 151 state (or higher) are listed in the Hello packets sent from the 152 associated interface. 154 Init (with BFD strict-mode) 156 In this state, an Hello packet has recently been seen from the 157 neighbor. However, bidirectional communication has not yet been 158 established with the neighbor (i.e., the router itself did not 159 appear in the neighbor's Hello packet). A BFD session 160 establishment to the neighbor is requested, if not already done 161 (e.g. in the event of transition from 2-way state). All neighbors 162 in higher than Init state and those in Init state with BFD session 163 up are listed in the Hello packets sent from the associated 164 interface. 166 Whenever the neighbor state transitions to Down state, the removal of 167 the BFD session associated with that neighbor SHOULD be requested by 168 OSPF and the session re-setup SHOULD similarly be requested by OSPF 169 after transitioning into Init state. This may result in the deletion 170 and creation of BFD session respectively when OSPF is the only client 171 interested in BFD session to the neighbor address. 173 An implementation MUST NOT wait for BFD session establishment in Init 174 state unless BFD strict-mode is enabled on the router and the 175 specific neighbor indicates BFD strict-mode capability via its Hello 176 messages. When BFD is enabled, but the strict-mode of operation 177 cannot be used, then an implementation SHOULD start the BFD session 178 establishment only in 2-Way or higher state. This makes it possible 179 for router to operate a mix of BFD operation in strict-mode or normal 180 mode across different interfaces or even different neighbors on the 181 same multi-access LAN interface. 183 Once the OSPF state machine has moved beyond the Init state, any 184 change in the B-bit advertised in subsequent Hello messages MUST NOT 185 result in any trigger in either the OSPF adjacency or the BFD session 186 management (i.e. the B-bit is considered only when in the Init 187 state). The disabling of BFD (or BFD strict-mode) on a router would 188 result in its not setting the B-bit in its subsequent Hello messages. 190 The disabling of BFD strict-mode has no change on the BFD operations 191 and would not result in bringing down of any established BFD session. 192 The disabling of BFD would result in the BFD session brought down due 193 to Admin reason and hence would not bring down the OSPF adjacency. 195 When BFD is enabled on an interface over which we already have an 196 existing OSPF adjacency, it would result in the router setting the 197 B-bit in its subsequent Hello messages. If the adjacency is already 198 up (i.e. in its terminal state of Full or 2-way with non-DR routers 199 on a LAN) with a neighbor that also support BFD strict-mode, then an 200 implemantion SHOULD NOT bring this adjacency down and instead use the 201 BFD strict-mode of operations after the next transition into Init 202 state. However, if the adjacency is not up, then an implementation 203 MAY bring such an adjacency down so it can use the BFD strict-mode 204 for its bring up. 206 4. Operations & Management Considerations 208 An implementation SHOULD report the BFD session status along with the 209 OSPF Init adjacency state when operating in BFD strict-mode and 210 perform logging operations on state transitions to include the BFD 211 events. This allows an operator to detect scenarios where an OSPF 212 adjacency may be stuck waiting for BFD session establishment. 214 5. Backward Compatibility 216 An implementation MUST support OSPF adjacency formation and 217 operations with a neighbor router that does not advertise the BFD 218 strict-mode capability - both when that neighbor router does not 219 support BFD and when it does support BFD but not in the strict-mode 220 of operation as described in this document. Implementations MAY 221 provide an option to specifically enable BFD operations only in the 222 strict-mode in which case, OSPF adjacency with a neighbor that does 223 not support BFD strict-mode would not be established successfully. 224 Implementations MAY provide an option to disable BFD strict-mode 225 which results in the router not advertising the B-bit and BFD 226 operations being performed in the same way as before this 227 specification. 229 The signaling specified in this document happens at a link-local 230 level between routers on that link. A router which does not support 231 this specification would ignore the B-bit in the LLS block of hello 232 messages from its neighbors and continue to bootstrap BFD sessions, 233 if enabled, without holding back the OSPF adjacency formation. Since 234 the router which does not support this specification would not have 235 set the B-bit in the LLS block of its own hello messages, its 236 neighbor routers that support this specification would not use BFD 237 strict-mode with it. As a result, the behavior would be the same as 238 before this specification. Therefore, there are no backward 239 compatibility related issues or considerations that need to be taken 240 care of when implementing this specification. 242 6. IANA Considerations 244 This specification updates Link Local Signaling TLV Identifiers 245 registry. 247 Following values are requested for allocation: 249 o B-bit from "LLS Type 1 Extended Options and Flags" registry at bit 250 position 0x00000010. 252 7. Security Considerations 254 The security considerations for "OSPF Link-Local Signaling" [RFC5613] 255 also apply to the extension described in this document. 256 Inappropriate use of the B-bit in the LLS block of an OSPF hello 257 message could prevent an OSPF adjacency from forming or lead to 258 failure to detect bidirectional forwarding failures. If 259 authentication is being used in the OSPF routing domain 260 [RFC5709][RFC7474], then the Cryptographic Authentication TLV 261 [RFC5613] SHOULD also be used to protect the contents of the LLS 262 block. 264 8. Acknowledgements 266 The authors would like to acknowledge the review and inputs from Acee 267 Lindem, Manish Gupta and Balaji Ganesh. 269 9. References 271 9.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 279 DOI 10.17487/RFC2328, April 1998, 280 . 282 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 283 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 284 . 286 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 287 Yeung, "OSPF Link-Local Signaling", RFC 5613, 288 DOI 10.17487/RFC5613, August 2009, 289 . 291 [RFC5882] Katz, D. and D. Ward, "Generic Application of 292 Bidirectional Forwarding Detection (BFD)", RFC 5882, 293 DOI 10.17487/RFC5882, June 2010, 294 . 296 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 297 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 298 May 2017, . 300 9.2. Informative References 302 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 303 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 304 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 305 2009, . 307 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 308 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 309 . 311 [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", 312 RFC 6213, DOI 10.17487/RFC6213, April 2011, 313 . 315 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 316 "Security Extension for OSPFv2 When Using Manual Key 317 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 318 . 320 Authors' Addresses 322 Ketan Talaulikar 323 Cisco Systems, Inc. 324 India 326 Email: ketant@cisco.com 327 Peter Psenak 328 Cisco Systems, Inc. 329 Apollo Business Center 330 Mlynske nivy 43 331 Bratislava 821 09 332 Slovakia 334 Email: ppsenak@cisco.com