idnits 2.17.1 draft-ietf-bfd-unaffiliated-echo-02.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document updates RFC5880, but the abstract doesn't seem to mention this, which it should. 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 (June 22, 2021) is 1039 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 (~~), 2 warnings (==), 3 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 6 Expires: December 24, 2021 ZTE Corp. 7 R. Rahman 8 Individual 9 R. Boddireddy 10 Juniper Networks 11 June 22, 2021 13 Unaffiliated BFD Echo Function 14 draft-ietf-bfd-unaffiliated-echo-02 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 function where the local system supports BFD but the neighboring 22 system does not support BFD. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 24, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 60 2. Updates to RFC 5880 . . . . . . . . . . . . . . . . . . . . . 3 61 3. Unaffiliated BFD Echo Procedures . . . . . . . . . . . . . . 6 62 4. Unaffiliated BFD Echo Applicability . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 9.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 To minimize the impact of device/link faults on services and improve 75 network availability, a network device must be able to quickly detect 76 faults in communication with adjacent devices. Measures can then be 77 taken to promptly rectify the faults to ensure service continuity. 79 BFD [RFC5880] is a low-overhead, short-duration method to detect 80 faults on the communication path between adjacent forwarding engines. 81 The faults can be on interfaces, data link(s), and even the 82 forwarding engines. It is a single, unified mechanism to monitor any 83 media and protocol layers in real time. 85 BFD defines an Asynchronous mode to satisfy various deployment 86 scenarios. It also supports an Echo function to reduce the device 87 requirement for BFD. When the Echo function is activated, the local 88 system sends BFD Echo packets and the remote system loops back the 89 received Echo packets through the forwarding path. If several 90 consecutive BFD Echo packets are not received by the local system, 91 then the BFD session is declared to be Down. 93 When using BFD Echo function, there are two typical scenarios as 94 below: 96 o Full BFD protocol capability with affiliated Echo function: This 97 scenario requires both the local device and the neighboring device 98 to support the full BFD protocol. 100 o BFD Echo-Only function without full BFD protocol capability: This 101 scenario requires only the local device to support sending and 102 demultiplexing BFD Control packets. 104 The latter scenario is referred to as Unaffiliated BFD Echo function 105 in this document. 107 Section 6.2.2 of [BBF-TR-146] describes one use case of the 108 Unaffiliated BFD Echo function, and at least one more use case is 109 known to be deployed. 111 This document describes the use of the Unaffiliated BFD Echo function 112 over IPv4 and IPv6 for single IP hop. 114 1.1. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. Updates to RFC 5880 124 The Unaffiliated BFD Echo function described in this document reuses 125 the BFD Echo function as described in [RFC5880] and [RFC5881], but 126 does not require BFD Asynchronous mode. When using the Unaffiliated 127 BFD Echo function, only the local system has the BFD protocol 128 enabled; the remote system just loops back the received BFD Echo 129 packets as regular data packets. 131 This document updates [RFC5880] with respect to its descriptions on 132 the BFD Echo function as follows. 134 o The 4th paragraph of Section 3.2 of [RFC5880] is updated as below: 136 OLD TEXT 138 An adjunct to both modes is the Echo function. 140 NEW TEXT 142 An adjunct or complement to both modes is the Echo function. 144 OLD TEXT 146 Since the Echo function is handling the task of detection, the 147 rate of periodic transmission of Control packets may be reduced 148 (in the case of Asynchronous mode) or eliminated completely (in 149 the case of Demand mode). 151 NEW TEXT 153 Since the Echo function is handling the task of detection, the 154 rate of periodic transmission of Control packets may be reduced 155 (in the case of Asynchronous mode) or eliminated completely (in 156 the case of Demand mode). The Echo function may also be used 157 independently, with neither Asynchronous nor Demand mode. 159 o The 3rd and 9th paragraphs of Section 6.1 of [RFC5880] are updated 160 as below: 162 OLD TEXT 164 Once the BFD session is Up, a system can choose to start the Echo 165 function if it desires and the other system signals that it will 166 allow it. 168 NEW TEXT 170 When a system is running with Asynchronous mode, once the BFD 171 session is Up, it can choose to start the Echo function if it 172 desires and the other system signals that it will allow it. 174 OLD TEXT 176 If the session goes Down, the transmission of Echo packets (if 177 any) ceases, and the transmission of Control packets goes back to 178 the slow rate. 180 NEW TEXT 182 In Asynchronous mode, if the session goes Down, the transmission 183 of Echo packets (if any) ceases, and the transmission of Control 184 packets goes back to the slow rate. 186 o The 2nd paragraph of Section 6.4 of [RFC5880] is updated as below: 188 OLD TEXT 189 When a system is using the Echo function, it is advantageous to 190 choose a sedate reception rate for Control packets, since liveness 191 detection is being handled by the Echo packets. 193 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. 200 o The 2nd paragraph of Section 6.8 of [RFC5880] is updated as below: 202 OLD TEXT 204 When a system is said to have "the Echo function active" it means 205 that the system is sending BFD Echo packets, implying that the 206 session is Up and the other system has signaled its willingness to 207 loop back Echo packets. 209 NEW TEXT 211 When a system in Asynchronous or Demand mode is said to have "the 212 Echo function active" it means that the system is sending BFD Echo 213 packets, implying that the session is Up and the other system has 214 signaled its willingness to loop back Echo packets. 216 o The 7th paragraph of Section 6.8.3 of [RFC5880] is updated as 217 below: 219 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). 225 NEW TEXT 227 When the Echo function is active with Asynchronous mode, a system 228 SHOULD set bfd.RequiredMinRxInterval to a value of not less than 229 one second (1,000,000 microseconds). 231 o The 1st and 2nd paragraphs of Section 6.8.9 of [RFC5880] are 232 updated as below: 234 OLD TEXT 235 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is 236 not Up. BFD Echo packets MUST NOT be transmitted unless the last 237 BFD Control packet received from the remote system contains a 238 nonzero value in Required Min Echo RX Interval. 240 NEW TEXT 242 When a system is using the Echo function with either Asynchronous 243 or Demand mode, BFD Echo packets MUST NOT be transmitted when 244 bfd.SessionState is not Up, and BFD Echo packets MUST NOT be 245 transmitted unless the last BFD Control packet received from the 246 remote system contains a nonzero value in Required Min Echo RX 247 Interval. 249 OLD TEXT 251 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. 252 The interval between transmitted BFD Echo packets MUST NOT be less 253 than the value advertised by the remote system in Required Min 254 Echo RX Interval... 256 NEW TEXT 258 When a system is using the Echo function with either Asynchronous 259 or Demand mode, BFD Echo packets MAY be transmitted when 260 bfd.SessionState is Up, and the interval between transmitted BFD 261 Echo packets MUST NOT be less than the value advertised by the 262 remote system in Required Min Echo RX Interval... 264 3. Unaffiliated BFD Echo Procedures 266 As shown in Figure 1, device A supports BFD, whereas device B does 267 not support BFD. Device A would send BFD Echo packets, and after 268 receiving the BFD Echo packets sent from device A, the one-hop-away 269 BFD peer device B immediately loops them back by normal IP 270 forwarding, this allows device A to rapidly detect a connectivity 271 loss to device B. Note that device B would not intercept any 272 received BFD Echo packet or parse any BFD protocol field within the 273 BFD Echo packet. 275 To rapidly detect any IP forwarding faults between device A and 276 device B, a BFD Echo session MUST be created at device A, and the BFD 277 Echo session is RECOMMENDED to follow the BFD state machine defined 278 in Section 6.2 of [RFC5880], except that the received state is not 279 sent but echoed from the remote system, and AdminDown state is ruled 280 out because AdminDown effectively means removal of BFD Echo session. 281 In this case, although BFD Echo packets are transmitted with 282 destination UDP port 3785 as defined in [RFC5881], the BFD Echo 283 packets sent by device A are BFD Control packets too, the looped BFD 284 Echo packets back from device B would drive BFD state change at 285 device A, substituting the BFD Control packets sent from the BFD 286 peer. Also note that when device A receives looped BFD Control 287 packets, the validation procedures of [RFC5880] are used. 289 Once a BFD Echo session is created at device A, it starts sending BFD 290 Echo packets, which SHOULD include a BFD Echo session demultiplexing 291 field, such as BFD "Your Discriminator" defined in [RFC5880] (BFD "My 292 Discriminator" can be set to 0 to avoid confusion), except that 293 device A can use IP source address or UDP source port to demultiplex 294 BFD Echo session, or there is only one BFD Echo session running at 295 device A. Device A would send BFD Echo packets with IP destination 296 address destined for itself, such as the IP address of interface 1 of 297 device A. All BFD Echo packets for the session MUST be sent with a 298 Time to Live (TTL) or Hop Limit value of 255. 300 "Desired Min TX Interval" and "Required Min RX Interval" defined in 301 [RFC5880] may be populated with one second within the BFD Echo 302 packet, which however has no real application and would be ignored by 303 the receiver. 305 Considering the BFD peer wouldn't advertise "Required Min Echo RX 306 Interval" as defined in [RFC5880], the transmission interval for 307 sending BFD Echo packets MUST be provisioned at device A, how to make 308 sure the BFD peer is willing and able to loop back BFD Echo packets 309 sent with the provisioned transmission interval is outside the scope 310 of this document. Similar to what's specified in [RFC5880], the BFD 311 Echo session begins with the periodic, slow transmission of BFD Echo 312 packets, the slow transmission rate SHOULD be no less then one second 313 per packet, until the session is Up, after that the provisioned 314 transmission interval is applied, and reverting back to the slow rate 315 once the session goes Down. Considering the BFD peer wouldn't 316 advertise "Detect Mult" as defined in [RFC5880], the "Detect Mult" 317 for calculating the Detection Time MUST be provisioned at device A, 318 the Detection Time in device A is equal to the provisioned "Detect 319 Mult" multiplied by the provisioned transmission interval. 321 Device A Device B 323 BFD Enabled BFD Echo packets loopback 324 +--------+ BFD Echo session +---------+ 325 | A |--------------------------------| B | 326 | |Inf 1 Inf 1| | 327 +--------+10.1.1.1/24 10.1.1.2/24+---------+ 328 BFD is supported. BFD is not supported. 330 Figure 1: Unaffiliated BFD Echo diagram 332 4. Unaffiliated BFD Echo Applicability 334 Some devices that would benefit from the use of BFD may be unable to 335 support the full BFD protocol. Examples of such devices include 336 servers running virtual machines, or Internet of Things (IoT) 337 devices. The Unaffiliated BFD Echo function can be used when two 338 devices are connected and only one of them supports the BFD protocol, 339 and the other is capable of looping BFD Echo packets. 341 5. Security Considerations 343 All Security Considerations from [RFC5880] and [RFC5881] apply. 345 Note that the Unaffiliated BFD Echo function prevents the use of 346 Unicast Reverse Path Forwarding (URPF) [RFC3704] [RFC8704] in strict 347 mode. 349 As specified in Section 5 of [RFC5880], since BFD Echo packets may be 350 spoofed, some form of authentication SHOULD be included. Considering 351 the BFD Echo packets in this document are also BFD Control packets, 352 the "Authentication Section" as defined in [RFC5880] for BFD Control 353 packet is RECOMMENDED to be included within the BFD Echo packet. 355 In order to mitigate the potential reflector attack by the remote 356 attackers, or infinite loop of the BFD Echo packets, it's RECOMMENDED 357 to put two requirements on the device looping BFD Echo packets, the 358 first one is that a packet SHOULD NOT be looped unless it has a TTL 359 or Hop Limit value of 255, and the second one is that a packet being 360 looped MUST NOT reset the TTL or Hop Limit value to 255, and MUST use 361 a TTL or Hop Limit value of 254. 363 6. IANA Considerations 365 This document has no IANA action requested. 367 7. Acknowledgements 369 The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky 370 and Santosh Pallagatti for their careful review and very helpful 371 comments. 373 The authors would like to acknowledge Jeff Haas for his insightful 374 review and very helpful comments. 376 8. Contributors 378 Liu Aihua 379 ZTE 380 Email: liu.aihua@zte.com.cn 382 Qian Xin 383 ZTE 384 Email: qian.xin2@zte.com.cn 386 Zhao Yanhua 387 ZTE 388 Email: zhao.yanhua3@zte.com.cn 390 9. References 392 9.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 400 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 401 . 403 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 404 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 405 DOI 10.17487/RFC5881, June 2010, 406 . 408 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 409 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 410 May 2017, . 412 9.2. Informative References 414 [BBF-TR-146] 415 Broadband Forum, "BBF Technical Report - Subscriber 416 Sessions Issue 1", 2013, . 419 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 420 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 421 2004, . 423 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 424 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 425 RFC 8704, DOI 10.17487/RFC8704, February 2020, 426 . 428 Authors' Addresses 430 Weiqiang Cheng 431 China Mobile 432 Beijing 433 China 435 Email: chengweiqiang@chinamobile.com 437 Ruixue Wang 438 China Mobile 439 Beijing 440 China 442 Email: wangruixue@chinamobile.com 444 Xiao Min 445 ZTE Corp. 446 Nanjing 447 China 449 Email: xiao.min2@zte.com.cn 451 Reshad Rahman 452 Individual 453 Kanata 454 Canada 456 Email: reshad@yahoo.com 458 Raj Chetan Boddireddy 459 Juniper Networks 461 Email: rchetan@juniper.net