idnits 2.17.00 (12 Aug 2021) /tmp/idnits23822/draft-ietf-bfd-unaffiliated-echo-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: ---------------------------------------------------------------------------- (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 (24 January 2022) is 116 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 (~~), 0 warnings (==), 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: 28 July 2022 ZTE Corp. 7 R. Rahman 8 Individual 9 R. Boddireddy 10 Juniper Networks 11 24 January 2022 13 Unaffiliated BFD Echo 14 draft-ietf-bfd-unaffiliated-echo-03 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 28 July 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 . . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 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 139 * An adjunct to both modes is the Echo function. 141 * NEW TEXT 143 * An adjunct to both modes is the Echo function, which can also be 144 running independently. 146 * OLD TEXT 148 * Since the Echo function is handling the task of detection, the 149 rate of periodic transmission of Control packets may be reduced 150 (in the case of Asynchronous mode) or eliminated completely (in 151 the case of Demand mode). 153 * NEW TEXT 155 * Since the Echo function is handling the task of detection, the 156 rate of periodic transmission of Control packets may be reduced 157 (in the case of Asynchronous mode) or eliminated completely (in 158 the case of Demand mode). The Echo function may also be used 159 independently, with neither Asynchronous nor Demand mode. 161 * The 3rd and 9th paragraphs of Section 6.1 of [RFC5880] are updated 162 as below: 164 * OLD TEXT 166 * Once the BFD session is Up, a system can choose to start the Echo 167 function if it desires and the other system signals that it will 168 allow it. The rate of transmission of Control packets is 169 typically kept low when the Echo function is active. 171 * NEW TEXT 173 * When a system is running with Asynchronous or Demand mode, once 174 the BFD session is Up, it can choose to start the Echo function if 175 it desires and the other system signals that it will allow it. 176 The rate of transmission of Control packets is typically kept low 177 for Asynchronous mode or eliminated completely for Demand mode 178 when the Echo function is active. 180 * OLD TEXT 182 * If the session goes Down, the transmission of Echo packets (if 183 any) ceases, and the transmission of Control packets goes back to 184 the slow rate. 186 * NEW TEXT 188 * In Asynchronous mode, if the session goes Down, the transmission 189 of Echo packets (if any) ceases, and the transmission of Control 190 packets goes back to the slow rate. Demand mode MUST NOT be 191 active if the session goes Down. 193 * The 2nd paragraph of Section 6.4 of [RFC5880] is updated as below: 195 * OLD TEXT 197 * When a system is using the Echo function, it is advantageous to 198 choose a sedate reception rate for Control packets, since liveness 199 detection is being handled by the Echo packets. This can be 200 controlled by manipulating the Required Min RX Interval field (see 201 section 6.8.3). 203 * NEW TEXT 205 * When a system is using the Echo function with Asynchronous mode, 206 it is advantageous to choose a sedate reception rate for Control 207 packets, since liveness detection is being handled by the Echo 208 packets. This can be controlled by manipulating the Required Min 209 RX Interval field (see section 6.8.3). Note that a system 210 operating in Demand mode would direct the remote system to cease 211 the periodic transmission of BFD Control packets, by setting the 212 Demand (D) bit in its BFD Control packets. 214 * The 2nd paragraph of Section 6.8 of [RFC5880] is updated as below: 216 * OLD TEXT 218 * When a system is said to have "the Echo function active" it means 219 that the system is sending BFD Echo packets, implying that the 220 session is Up and the other system has signaled its willingness to 221 loop back Echo packets. 223 * NEW TEXT 225 * When a system in Asynchronous or Demand mode is said to have "the 226 Echo function active" it means that the system is sending BFD Echo 227 packets, implying that the session is Up and the other system has 228 signaled its willingness to loop back Echo packets. 230 * The 7th paragraph of Section 6.8.3 of [RFC5880] is updated as 231 below: 233 * OLD TEXT 235 * When the Echo function is active, a system SHOULD set 236 bfd.RequiredMinRxInterval to a value of not less than one second 237 (1,000,000 microseconds). This is intended to keep received BFD 238 Control traffic at a negligible level, since the actual detection 239 function is being performed using BFD Echo packets. 241 * NEW TEXT 242 * When the Echo function is active with Asynchronous mode, a system 243 SHOULD set bfd.RequiredMinRxInterval to a value of not less than 244 one second (1,000,000 microseconds). This is intended to keep 245 received BFD Control traffic at a negligible level, since the 246 actual detection function is being performed using BFD Echo 247 packets. While a system operating in Demand mode would not 248 receive BFD Control traffic. 250 * The 1st and 2nd paragraphs of Section 6.8.9 of [RFC5880] are 251 updated as below: 253 * OLD TEXT 255 * BFD Echo packets MUST NOT be transmitted when bfd.SessionState is 256 not Up. BFD Echo packets MUST NOT be transmitted unless the last 257 BFD Control packet received from the remote system contains a 258 nonzero value in Required Min Echo RX Interval. 260 * NEW TEXT 262 * When a system is using the Echo function with either Asynchronous 263 or Demand mode, BFD Echo packets MUST NOT be transmitted when 264 bfd.SessionState is not Up, and BFD Echo packets MUST NOT be 265 transmitted unless the last BFD Control packet received from the 266 remote system contains a nonzero value in Required Min Echo RX 267 Interval. 269 * OLD TEXT 271 * BFD Echo packets MAY be transmitted when bfd.SessionState is Up. 272 The interval between transmitted BFD Echo packets MUST NOT be less 273 than the value advertised by the remote system in Required Min 274 Echo RX Interval... 276 * NEW TEXT 278 * When a system is using the Echo function with either Asynchronous 279 or Demand mode, BFD Echo packets MAY be transmitted when 280 bfd.SessionState is Up, and the interval between transmitted BFD 281 Echo packets MUST NOT be less than the value advertised by the 282 remote system in Required Min Echo RX Interval... 284 3. Unaffiliated BFD Echo Procedures 285 Device A Device B 287 BFD Enabled BFD Echo packets loopback 288 +--------+ BFD Echo session +--------+ 289 | A |--------------------------------| B | 290 | |Interface 1 Interface 1| | 291 +--------+ +--------+ 292 BFD is supported. BFD is not supported. 294 Figure 1: Unaffiliated BFD Echo diagram 296 As shown in Figure 1, device A supports BFD, whereas device B does 297 not support BFD. Device A would send BFD Echo packets, and after 298 receiving the BFD Echo packets sent from device A, the one-hop-away 299 BFD peer device B immediately loops them back by normal IP 300 forwarding, this allows device A to rapidly detect a connectivity 301 loss to device B. Note that device B would not intercept any 302 received BFD Echo packet or parse any BFD protocol field within the 303 BFD Echo packet. 305 To rapidly detect any IP forwarding faults between device A and 306 device B, a BFD Echo session MUST be created at device A, and the BFD 307 Echo session MUST follow the BFD state machine defined in Section 6.2 308 of [RFC5880], except that the received state is not sent but echoed 309 from the remote system, and AdminDown state is ruled out because 310 AdminDown effectively means removal of BFD Echo session. In this 311 case, although BFD Echo packets are transmitted with destination UDP 312 port 3785 as defined in [RFC5881], the BFD Echo packets sent by 313 device A are BFD Control packets too, the looped BFD Echo packets 314 back from device B would drive BFD state change at device A, 315 substituting the BFD Control packets sent from the BFD peer. Also 316 note that when device A receives looped BFD Control packets, the 317 validation procedures of [RFC5880] are used. 319 Once a BFD Echo session is created at device A, it starts sending BFD 320 Echo packets, which MUST include BFD Echo session demultiplexing 321 fields, such as BFD "Your Discriminator" defined in [RFC5880] (BFD 322 "My Discriminator" can be set to 0 to avoid confusion), except for 323 BFD "Your Discriminator", device A can also use IP source address or 324 UDP source port to demultiplex BFD Echo session, or there is only one 325 BFD Echo session running at device A. Device A would send BFD Echo 326 packets with IP destination address destined for itself, such as the 327 IP address of interface 1 of device A. All BFD Echo packets for the 328 session MUST be sent with a Time to Live (TTL) or Hop Limit value of 329 255. 331 Within the BFD Echo packet, the "Desired Min TX Interval" and 332 "Required Min RX Interval" defined in [RFC5880] may be populated with 333 one second, which however has no real application and would be 334 ignored by the receiver. 336 Considering that the BFD peer device B wouldn't advertise "Required 337 Min Echo RX Interval" as defined in [RFC5880], the transmission 338 interval for sending BFD Echo packets MUST be provisioned at device 339 A, how to make sure the BFD peer device B is willing and able to loop 340 back BFD Echo packets sent with the provisioned transmission interval 341 is outside the scope of this document. Similar to what's specified 342 in [RFC5880], the BFD Echo session begins with the periodic, slow 343 transmission of BFD Echo packets, the slow transmission rate SHOULD 344 be no less then one second per packet, until the session is Up, after 345 that the provisioned transmission interval is applied, and reverting 346 back to the slow rate once the session goes Down. Considering that 347 the BFD peer wouldn't advertise "Detect Mult" as defined in 348 [RFC5880], the "Detect Mult" for calculating the Detection Time MUST 349 be provisioned at device A, the Detection Time at device A is equal 350 to the provisioned "Detect Mult" multiplied by the provisioned 351 transmission interval. 353 4. Unaffiliated BFD Echo Applicability 355 Some devices that would benefit from the use of BFD may be unable to 356 support the full BFD protocol. Examples of such devices include 357 servers running virtual machines, or Internet of Things (IoT) 358 devices. The Unaffiliated BFD Echo can be used when two devices are 359 connected and only one of them supports the BFD protocol, and the 360 other is capable of looping BFD Echo packets. 362 5. Security Considerations 364 All Security Considerations from [RFC5880] and [RFC5881] apply. 366 Note that the Unaffiliated BFD Echo prevents the use of Unicast 367 Reverse Path Forwarding (URPF) [RFC3704] [RFC8704] in strict mode. 369 As specified in Section 5 of [RFC5880], since BFD Echo packets may be 370 spoofed, some form of authentication SHOULD be included. Considering 371 the BFD Echo packets in this document are also BFD Control packets, 372 the "Authentication Section" as defined in [RFC5880] for BFD Control 373 packet is RECOMMENDED to be included within the BFD Echo packet. 375 In order to mitigate the potential reflector attack by the remote 376 attackers, or infinite loop of the BFD Echo packets, it's RECOMMENDED 377 to put two requirements on the device looping BFD Echo packets, the 378 first one is that a packet SHOULD NOT be looped unless it has a TTL 379 or Hop Limit value of 255, and the second one is that a packet being 380 looped MUST NOT reset the TTL or Hop Limit value to 255, and MUST use 381 a TTL or Hop Limit value of 254. 383 6. IANA Considerations 385 This document has no IANA action requested. 387 7. Acknowledgements 389 The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky 390 and Santosh Pallagatti for their careful review and very helpful 391 comments. 393 The authors would like to acknowledge Jeff Haas for his insightful 394 review and very helpful comments. 396 8. Contributors 398 Liu Aihua ZTE Email: liu.aihua@zte.com.cn 400 Qian Xin ZTE Email: qian.xin2@zte.com.cn 402 Zhao Yanhua ZTE Email: zhao.yanhua3@zte.com.cn 404 9. References 406 9.1. Normative References 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 414 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 415 . 417 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 418 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 419 DOI 10.17487/RFC5881, June 2010, 420 . 422 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 423 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 424 May 2017, . 426 9.2. Informative References 428 [BBF-TR-146] 429 Broadband Forum, "BBF Technical Report - Subscriber 430 Sessions Issue 1", 2013, . 433 [I-D.wang-bfd-one-arm-use-case] 434 Wang, R., Cheng, W., Zhao, Y., and A. Liu, "Using One-Arm 435 BFD in Cloud Network", Work in Progress, Internet-Draft, 436 draft-wang-bfd-one-arm-use-case-00, 18 November 2019, 437 . 440 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 441 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 442 2004, . 444 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 445 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 446 RFC 8704, DOI 10.17487/RFC8704, February 2020, 447 . 449 Authors' Addresses 451 Weiqiang Cheng 452 China Mobile 453 Beijing 454 China 456 Email: chengweiqiang@chinamobile.com 458 Ruixue Wang 459 China Mobile 460 Beijing 461 China 463 Email: wangruixue@chinamobile.com 465 Xiao Min (editor) 466 ZTE Corp. 467 Nanjing 468 China 470 Email: xiao.min2@zte.com.cn 471 Reshad Rahman 472 Individual 473 Kanata 474 Canada 476 Email: reshad@yahoo.com 478 Raj Chetan Boddireddy 479 Juniper Networks 481 Email: rchetan@juniper.net