idnits 2.17.1 draft-ietf-bfd-unaffiliated-echo-04.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 (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- 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 (8 February 2022) is 801 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD Working Group W. Cheng 3 Internet-Draft R. Wang 4 Updates: 5880 (if approved) China Mobile 5 Intended status: Standards Track X. Min, Ed. 6 Expires: 12 August 2022 ZTE Corp. 7 R. Rahman 8 Individual 9 R. Boddireddy 10 Juniper Networks 11 8 February 2022 13 Unaffiliated BFD Echo 14 draft-ietf-bfd-unaffiliated-echo-04 16 Abstract 18 Bidirectional Forwarding Detection (BFD) is a fault detection 19 protocol that can quickly determine a communication failure between 20 two forwarding engines. This document proposes a use of the BFD Echo 21 where the local system supports BFD but the neighboring system does 22 not support BFD. 24 This document updates RFC 5880. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 12 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 61 2. Updates to RFC 5880 . . . . . . . . . . . . . . . . . . . . . 3 62 3. Unaffiliated BFD Echo Procedures . . . . . . . . . . . . . . 6 63 4. Unaffiliated BFD Echo Applicability . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 To minimize the impact of device/link faults on services and improve 76 network availability, a network device must be able to quickly detect 77 faults in communication with adjacent devices. Measures can then be 78 taken to promptly rectify the faults to ensure service continuity. 80 BFD [RFC5880] is a low-overhead, short-duration method to detect 81 faults on the communication path between adjacent forwarding engines. 82 The faults can be on interfaces, data link(s), and even the 83 forwarding engines. It is a single, unified mechanism to monitor any 84 media and protocol layers in real time. 86 BFD defines Asynchronous and Demand modes to satisfy various 87 deployment scenarios. It also supports an Echo function to reduce 88 the device requirement for BFD. When the Echo function is activated, 89 the local system sends BFD Echo packets and the remote system loops 90 back the received Echo packets through the forwarding path. If 91 several consecutive BFD Echo packets are not received by the local 92 system, then the BFD session is declared to be Down. 94 When using BFD Echo function, there are two typical scenarios as 95 below: 97 * Full BFD protocol capability with affiliated Echo function. This 98 scenario requires both the local device and the neighboring device 99 to support the full BFD protocol. 101 * BFD Echo-Only method without full BFD protocol capability. This 102 scenario requires only the local device to support sending and 103 demultiplexing BFD Control packets. 105 The latter scenario is referred to as Unaffiliated BFD Echo in this 106 document. 108 Section 6.2.2 of [BBF-TR-146] describes one use case of the 109 Unaffiliated BFD Echo. Section 2 of [I-D.wang-bfd-one-arm-use-case] 110 describes another use case of the Unaffiliated BFD Echo. 112 This document describes the use of the Unaffiliated BFD Echo over 113 IPv4 and IPv6 for single IP hop. 115 1.1. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. Updates to RFC 5880 125 The Unaffiliated BFD Echo described in this document reuses the BFD 126 Echo function as described in [RFC5880] and [RFC5881], but does not 127 require BFD Asynchronous or Demand mode. When using the Unaffiliated 128 BFD Echo, only the local system has the BFD protocol enabled; the 129 remote system just loops back the received BFD Echo packets as 130 regular data packets. 132 This document updates [RFC5880] with respect to its descriptions on 133 the BFD Echo function as follows. 135 The 4th paragraph of Section 3.2 of [RFC5880] is updated as below: 137 OLD TEXT 138 An adjunct to both modes is the Echo function. 140 NEW TEXT 141 An adjunct to both modes is the Echo function, which can also be 142 running independently. 144 OLD TEXT 145 Since the Echo function is handling the task of detection, the 146 rate of periodic transmission of Control packets may be reduced 147 (in the case of Asynchronous mode) or eliminated completely (in 148 the case of Demand mode). 150 NEW TEXT 151 Since the Echo function is handling the task of detection, the 152 rate of periodic transmission of Control packets may be reduced 153 (in the case of Asynchronous mode) or eliminated completely (in 154 the case of Demand mode). The Echo function may also be used 155 independently, with neither Asynchronous nor Demand mode. 157 The 3rd and 9th paragraphs of Section 6.1 of [RFC5880] are updated as 158 below: 160 OLD TEXT 161 Once the BFD session is Up, a system can choose to start the Echo 162 function if it desires and the other system signals that it will 163 allow it. The rate of transmission of Control packets is 164 typically kept low when the Echo function is active. 166 NEW TEXT 167 When a system is running with Asynchronous or Demand mode, once 168 the BFD session is Up, it can choose to start the Echo function if 169 it desires and the other system signals that it will allow it. 170 The rate of transmission of Control packets is typically kept low 171 for Asynchronous mode or eliminated completely for Demand mode 172 when the Echo function is active. 174 OLD TEXT 175 If the session goes Down, the transmission of Echo packets (if 176 any) ceases, and the transmission of Control packets goes back to 177 the slow rate. 179 NEW TEXT 180 In Asynchronous mode, if the session goes Down, the transmission 181 of Echo packets (if any) ceases, and the transmission of Control 182 packets goes back to the slow rate. Demand mode MUST NOT be 183 active if the session goes Down. 185 The 2nd paragraph of Section 6.4 of [RFC5880] is updated as below: 187 OLD TEXT 188 When a system is using the Echo function, it is advantageous to 189 choose a sedate reception rate for Control packets, since liveness 190 detection is being handled by the Echo packets. This can be 191 controlled by manipulating the Required Min RX Interval field (see 192 section 6.8.3). 194 NEW TEXT 195 When a system is using the Echo function with Asynchronous mode, 196 it is advantageous to choose a sedate reception rate for Control 197 packets, since liveness detection is being handled by the Echo 198 packets. This can be controlled by manipulating the Required Min 199 RX Interval field (see section 6.8.3). Note that a system 200 operating in Demand mode would direct the remote system to cease 201 the periodic transmission of BFD Control packets, by setting the 202 Demand (D) bit in its BFD Control packets. 204 The 2nd paragraph of Section 6.8 of [RFC5880] is updated as below: 206 OLD TEXT 207 When a system is said to have "the Echo function active" it means 208 that the system is sending BFD Echo packets, implying that the 209 session is Up and the other system has signaled its willingness to 210 loop back Echo packets. 212 NEW TEXT 213 When a system in Asynchronous or Demand mode is said to have "the 214 Echo function active" it means that the system is sending BFD Echo 215 packets, implying that the session is Up and the other system has 216 signaled its willingness to loop back Echo packets. 218 The 7th paragraph of Section 6.8.3 of [RFC5880] is updated as below: 220 OLD TEXT 221 When the Echo function is active, a system SHOULD set 222 bfd.RequiredMinRxInterval to a value of not less than one second 223 (1,000,000 microseconds). This is intended to keep received BFD 224 Control traffic at a negligible level, since the actual detection 225 function is being performed using BFD Echo packets. 227 NEW TEXT 228 When the Echo function is active with Asynchronous mode, a system 229 SHOULD set bfd.RequiredMinRxInterval to a value of not less than 230 one second (1,000,000 microseconds). This is intended to keep 231 received BFD Control traffic at a negligible level, since the 232 actual detection function is being performed using BFD Echo 233 packets. While a system operating in Demand mode would not 234 receive BFD Control traffic. 236 The 1st and 2nd paragraphs of Section 6.8.9 of [RFC5880] are updated 237 as below: 239 OLD TEXT 240 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is 241 not Up. BFD Echo packets MUST NOT be transmitted unless the last 242 BFD Control packet received from the remote system contains a 243 nonzero value in Required Min Echo RX Interval. 245 NEW TEXT 246 When a system is using the Echo function with either Asynchronous 247 or Demand mode, BFD Echo packets MUST NOT be transmitted when 248 bfd.SessionState is not Up, and BFD Echo packets MUST NOT be 249 transmitted unless the last BFD Control packet received from the 250 remote system contains a nonzero value in Required Min Echo RX 251 Interval. 253 OLD TEXT 254 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. 255 The interval between transmitted BFD Echo packets MUST NOT be less 256 than the value advertised by the remote system in Required Min 257 Echo RX Interval... 259 NEW TEXT 260 When a system is using the Echo function with either Asynchronous 261 or Demand mode, BFD Echo packets MAY be transmitted when 262 bfd.SessionState is Up, and the interval between transmitted BFD 263 Echo packets MUST NOT be less than the value advertised by the 264 remote system in Required Min Echo RX Interval... 266 3. Unaffiliated BFD Echo Procedures 268 Device A Device B 270 BFD Enabled BFD Echo packets loopback 271 +--------+ BFD Echo session +--------+ 272 | A |--------------------------------| B | 273 | |Interface 1 Interface 1| | 274 +--------+ +--------+ 275 BFD is supported. BFD is not supported. 277 Figure 1: Unaffiliated BFD Echo diagram 279 As shown in Figure 1, device A supports BFD, whereas device B does 280 not support BFD. Device A would send BFD Echo packets, and after 281 receiving the BFD Echo packets sent from device A, the one-hop-away 282 BFD peer device B immediately loops them back by normal IP 283 forwarding, this allows device A to rapidly detect a connectivity 284 loss to device B. Note that device B would not intercept any 285 received BFD Echo packet or parse any BFD protocol field within the 286 BFD Echo packet. 288 To rapidly detect any IP forwarding faults between device A and 289 device B, a BFD Echo session MUST be created at device A, and the BFD 290 Echo session MUST follow the BFD state machine defined in Section 6.2 291 of [RFC5880], except that the received state is not sent but echoed 292 from the remote system, and AdminDown state is ruled out because 293 AdminDown effectively means removal of BFD Echo session. In this 294 case, although BFD Echo packets are transmitted with destination UDP 295 port 3785 as defined in [RFC5881], the BFD Echo packets sent by 296 device A are BFD Control packets too, the looped BFD Echo packets 297 back from device B would drive BFD state change at device A, 298 substituting the BFD Control packets sent from the BFD peer. Also 299 note that when device A receives looped BFD Control packets, the 300 validation procedures of [RFC5880] are used. 302 Once a BFD Echo session is created at device A, it starts sending BFD 303 Echo packets, which MUST include BFD Echo session demultiplexing 304 fields, such as BFD "Your Discriminator" defined in [RFC5880] (BFD 305 "My Discriminator" can be set to 0 to avoid confusion), except for 306 BFD "Your Discriminator", device A can also use IP source address or 307 UDP source port to demultiplex BFD Echo session, or there is only one 308 BFD Echo session running at device A. Device A would send BFD Echo 309 packets with IP destination address destined for itself, such as the 310 IP address of interface 1 of device A. All BFD Echo packets for the 311 session MUST be sent with a Time to Live (TTL) or Hop Limit value of 312 255. 314 Within the BFD Echo packet, the "Desired Min TX Interval" and 315 "Required Min RX Interval" defined in [RFC5880] may be populated with 316 one second, which however has no real application and would be 317 ignored by the receiver. 319 Considering that the BFD peer device B wouldn't advertise "Required 320 Min Echo RX Interval" as defined in [RFC5880], the transmission 321 interval for sending BFD Echo packets MUST be provisioned at device 322 A, how to make sure the BFD peer device B is willing and able to loop 323 back BFD Echo packets sent with the provisioned transmission interval 324 is outside the scope of this document. Similar to what's specified 325 in [RFC5880], the BFD Echo session begins with the periodic, slow 326 transmission of BFD Echo packets, the slow transmission rate SHOULD 327 be no less then one second per packet, until the session is Up, after 328 that the provisioned transmission interval is applied, and reverting 329 back to the slow rate once the session goes Down. Considering that 330 the BFD peer wouldn't advertise "Detect Mult" as defined in 332 [RFC5880], the "Detect Mult" for calculating the Detection Time MUST 333 be provisioned at device A, the Detection Time at device A is equal 334 to the provisioned "Detect Mult" multiplied by the provisioned 335 transmission interval. 337 4. Unaffiliated BFD Echo Applicability 339 Some devices that would benefit from the use of BFD may be unable to 340 support the full BFD protocol. Examples of such devices include 341 servers running virtual machines, or Internet of Things (IoT) 342 devices. The Unaffiliated BFD Echo can be used when two devices are 343 connected and only one of them supports the BFD protocol, and the 344 other is capable of looping BFD Echo packets. 346 5. Security Considerations 348 All Security Considerations from [RFC5880] and [RFC5881] apply. 350 Note that the Unaffiliated BFD Echo prevents the use of Unicast 351 Reverse Path Forwarding (URPF) [RFC3704] [RFC8704] in strict mode. 353 As specified in Section 5 of [RFC5880], since BFD Echo packets may be 354 spoofed, some form of authentication SHOULD be included. Considering 355 the BFD Echo packets in this document are also BFD Control packets, 356 the "Authentication Section" as defined in [RFC5880] for BFD Control 357 packet is RECOMMENDED to be included within the BFD Echo packet. 359 In order to mitigate the potential reflector attack by the remote 360 attackers, or infinite loop of the BFD Echo packets, it's RECOMMENDED 361 to put two requirements on the device looping BFD Echo packets, the 362 first one is that a packet SHOULD NOT be looped unless it has a TTL 363 or Hop Limit value of 255, and the second one is that a packet being 364 looped MUST NOT reset the TTL or Hop Limit value to 255, and MUST use 365 a TTL or Hop Limit value of 254. 367 6. IANA Considerations 369 This document has no IANA action requested. 371 7. Acknowledgements 373 The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky 374 and Santosh Pallagatti for their careful review and very helpful 375 comments. 377 The authors would like to acknowledge Jeff Haas for his insightful 378 review and very helpful comments. 380 8. Contributors 382 Liu Aihua 383 ZTE 384 Email: liu.aihua@zte.com.cn 386 Qian Xin 387 ZTE 388 Email: qian.xin2@zte.com.cn 390 Zhao Yanhua 391 ZTE 392 Email: zhao.yanhua3@zte.com.cn 394 9. References 396 9.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 404 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 405 . 407 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 408 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 409 DOI 10.17487/RFC5881, June 2010, 410 . 412 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 413 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 414 May 2017, . 416 9.2. Informative References 418 [BBF-TR-146] 419 Broadband Forum, "BBF Technical Report - Subscriber 420 Sessions Issue 1", 2013, . 423 [I-D.wang-bfd-one-arm-use-case] 424 Wang, R., Cheng, W., Zhao, Y., and A. Liu, "Using One-Arm 425 BFD in Cloud Network", Work in Progress, Internet-Draft, 426 draft-wang-bfd-one-arm-use-case-00, 18 November 2019, 427 . 430 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 431 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 432 2004, . 434 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 435 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 436 RFC 8704, DOI 10.17487/RFC8704, February 2020, 437 . 439 Authors' Addresses 441 Weiqiang Cheng 442 China Mobile 443 Beijing 444 China 446 Email: chengweiqiang@chinamobile.com 448 Ruixue Wang 449 China Mobile 450 Beijing 451 China 453 Email: wangruixue@chinamobile.com 455 Xiao Min (editor) 456 ZTE Corp. 457 Nanjing 458 China 460 Email: xiao.min2@zte.com.cn 462 Reshad Rahman 463 Individual 464 Kanata 465 Canada 467 Email: reshad@yahoo.com 468 Raj Chetan Boddireddy 469 Juniper Networks 471 Email: rchetan@juniper.net