idnits 2.17.00 (12 Aug 2021) /tmp/idnits24575/draft-ietf-bfd-unaffiliated-echo-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 : ---------------------------------------------------------------------------- == 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 209: '...unction is active, a system SHOULD set...' RFC 2119 keyword, line 218: '... SHOULD set bfd.RequiredMinRxInte...' RFC 2119 keyword, line 226: '...BFD Echo packets MUST NOT be transmitt...' RFC 2119 keyword, line 227: '...BFD Echo packets MUST NOT be transmitt...' RFC 2119 keyword, line 231: '...BFD Echo packets MAY be transmitted wh...' (17 more instances...) -- 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 (November 2, 2020) is 564 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: 1 error (**), 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: May 6, 2021 ZTE Corp. 7 R. Rahman 8 Cisco Systems 9 R. Boddireddy 10 Juniper Networks 11 November 2, 2020 13 Unaffiliated BFD Echo Function 14 draft-ietf-bfd-unaffiliated-echo-01 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 May 6, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 2. Updates to RFC 5880 . . . . . . . . . . . . . . . . . . . . . 3 60 3. Unaffiliated BFD Echo Procedures . . . . . . . . . . . . . . 6 61 4. Unaffilicated BFD Echo Applicability . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 9.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 To minimize the impact of device/link faults on services and improve 74 network availability, a network device must be able to quickly detect 75 faults in communication with adjacent devices. Measures can then be 76 taken to promptly rectify the faults to ensure service continuity. 78 BFD [RFC5880] is a low-overhead, short-duration method to detect 79 faults on the communication path between adjacent forwarding engines. 80 The faults can be on interface, data link, and even forwarding 81 engine. It is a single, unified mechanism to monitor any media and 82 protocol layers in real time. 84 BFD defines Asynchronous mode to satisfy various deployment 85 scenarios, and also supports Echo function to reduce the device 86 requirement for BFD. When the Echo function is activated, the local 87 system sends BFD Echo packets and the remote system loops back the 88 received Echo packets through the forwarding path. If several 89 consecutive BFD Echo packets are not received by the local system, 90 then the BFD session is declared to be Down. 92 When using BFD Echo function, there are two typical scenarios as 93 below: 95 o Full BFD protocol capability with affiliated Echo function: this 96 scenario requires both the local device and the neighboring device 97 to support full BFD protocol. 99 o Only BFD Echo function without full BFD protocol capability: 100 this scenario requires only the local device to support sending 101 and demultiplexing BFD Control packets. 103 The two typical scenarios are both reasonable and useful, and the 104 latter is referred to as Unaffiliated BFD Echo function in this 105 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 in the field BFD deployment. 111 This document describes the use of the Unaffiliated BFD Echo function 112 over IPv4 and IPv6 for single IP hop. 114 2. Updates to RFC 5880 116 The Unaffiliated BFD Echo function described in this document reuses 117 the BFD Echo function as described in [RFC5880] and [RFC5881], but 118 does not require BFD asynchronous mode. When using the Unaffiliated 119 BFD Echo function, only the local system has the BFD protocol 120 enabled, the remote system just loops back the received BFD Echo 121 packets as regular data packets. 123 With that said, this document updates [RFC5880] with respect to its 124 descriptions on the BFD Echo function as follows. 126 o [RFC5880] states in the 4th paragraph of Section 3.2: 128 An adjunct to both modes is the Echo function. When the Echo 129 function is active, a stream of BFD Echo packets is transmitted in 130 such a way as to have the other system loop them back through its 131 forwarding path. If a number of packets of the echoed data stream 132 are not received, the session is declared to be down. The Echo 133 function may be used with either Asynchronous or Demand mode. 134 Since the Echo function is handling the task of detection, the 135 rate of periodic transmission of Control packets may be reduced 136 (in the case of Asynchronous mode) or eliminated completely (in 137 the case of Demand mode). 139 * This paragraph is now updated to: 141 An adjunct or complement to both modes is the Echo function. When 142 the Echo function is active, a stream of BFD Echo packets is 143 transmitted in such a way as to have the other system loop them 144 back through its forwarding path. If a number of packets of the 145 echoed data stream are not received, the session is declared to be 146 down. The Echo function may be used with either Asynchronous or 147 Demand mode. Since the Echo function is handling the task of 148 detection, the rate of periodic transmission of Control packets 149 may be reduced (in the case of Asynchronous mode) or eliminated 150 completely (in the case of Demand mode). The Echo function may 151 also be used independently, with neither Asynchronous nor Demand 152 mode. 154 o [RFC5880] states in the 3rd and 9th paragraphs of Section 6.1: 156 Once the BFD session is Up, a system can choose to start the Echo 157 function if it desires and the other system signals that it will 158 allow it. The rate of transmission of Control packets is 159 typically kept low when the Echo function is active. 161 If the session goes Down, the transmission of Echo packets (if 162 any) ceases, and the transmission of Control packets goes back to 163 the slow rate. 165 * The two paragraphs are now updated to: 167 When a system is running with Asynchronous mode, once the BFD 168 session is Up, it can choose to start the Echo function if it 169 desires and the other system signals that it will allow it. The 170 rate of transmission of Control packets is typically kept low when 171 the Echo function is active. 173 In Asynchronous mode, if the session goes Down, the transmission 174 of Echo packets (if any) ceases, and the transmission of Control 175 packets goes back to the slow rate. 177 o [RFC5880] states in the 2nd paragraph of Section 6.4: 179 When a system is using the Echo function, it is advantageous to 180 choose a sedate reception rate for Control packets, since liveness 181 detection is being handled by the Echo packets. This can be 182 controlled by manipulating the Required Min RX Interval field (see 183 section 6.8.3). 185 * This paragraph is now updated to: 187 When a system is using the Echo function with Asynchronous mode, 188 it is advantageous to choose a sedate reception rate for Control 189 packets, since liveness detection is being handled by the Echo 190 packets. This can be controlled by manipulating the Required Min 191 RX Interval field (see section 6.8.3). 193 o [RFC5880] states in the 2nd paragraph of Section 6.8: 195 When a system is said to have "the Echo function active" it means 196 that the system is sending BFD Echo packets, implying that the 197 session is Up and the other system has signaled its willingness to 198 loop back Echo packets. 200 * This paragraph is now updated to: 202 When a system in Asynchronous or Demand mode is said to have "the 203 Echo function active" it means that the system is sending BFD Echo 204 packets, implying that the session is Up and the other system has 205 signaled its willingness to loop back Echo packets. 207 o [RFC5880] states in the 7th paragraph of Section 6.8.3: 209 When the Echo function is active, a system SHOULD set 210 bfd.RequiredMinRxInterval to a value of not less than one second 211 (1,000,000 microseconds). This is intended to keep received BFD 212 Control traffic at a negligible level, since the actual detection 213 function is being performed using BFD Echo packets. 215 * This paragraph is now updated to: 217 When the Echo function is active with Asynchronous mode, a system 218 SHOULD set bfd.RequiredMinRxInterval to a value of not less than 219 one second (1,000,000 microseconds). This is intended to keep 220 received BFD Control traffic at a negligible level, since the 221 actual detection function is being performed using BFD Echo 222 packets. 224 o [RFC5880] states in the 1st and 2nd paragraphs of Section 6.8.9: 226 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is 227 not Up. BFD Echo packets MUST NOT be transmitted unless the last 228 BFD Control packet received from the remote system contains a 229 nonzero value in Required Min Echo RX Interval. 231 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. 232 The interval between transmitted BFD Echo packets MUST NOT be less 233 than the value advertised by the remote system in Required Min 234 Echo RX Interval, except as follows: 236 A 25% jitter MAY be applied to the rate of transmission, such 237 that the actual interval MAY be between 75% and 100% of the 238 advertised value. A single BFD Echo packet MAY be transmitted 239 between normally scheduled Echo transmission intervals. 241 * The two paragraphs are now updated to: 243 When a system is using the Echo function with either Asynchronous 244 or Demand mode, BFD Echo packets MUST NOT be transmitted when 245 bfd.SessionState is not Up, and BFD Echo packets MUST NOT be 246 transmitted unless the last BFD Control packet received from the 247 remote system contains a nonzero value in Required Min Echo RX 248 Interval. 250 When a system is using the Echo function with either Asynchronous 251 or Demand mode, BFD Echo packets MAY be transmitted when 252 bfd.SessionState is Up, and the interval between transmitted BFD 253 Echo packets MUST NOT be less than the value advertised by the 254 remote system in Required Min Echo RX Interval, except as follows: 256 A 25% jitter MAY be applied to the rate of transmission, such 257 that the actual interval MAY be between 75% and 100% of the 258 advertised value. A single BFD Echo packet MAY be transmitted 259 between normally scheduled Echo transmission intervals. 261 3. Unaffiliated BFD Echo Procedures 263 As shown in Figure 1, device A supports BFD, whereas device B does 264 not support BFD. To rapidly detect any IP forwarding faults between 265 device A and device B, a BFD Echo session MUST be created at device 266 A, and the BFD Echo session is RECOMMENDED to follow the BFD state 267 machine defined in Section 6.2 of [RFC5880], except that the received 268 state is not sent but echoed from the remote system. In this case, 269 although BFD Echo packets are transmitted with destination UDP port 270 3785 as defined in [RFC5881], the BFD Echo packets sent by device A 271 are BFD Control packets too, the looped BFD Echo packets back from 272 device B would drive BFD state change at device A, substituting the 273 BFD Control packets sent from the BFD peer. 275 Once a BFD Echo session is created at device A, it starts sending BFD 276 Echo packets, which SHOULD include a BFD Echo session demultiplexing 277 field, such as BFD Your Discriminator defined in [RFC5880] (BFD My 278 Discriminator can be set to 0 to avoid confusion), except that device 279 A can use IP source address or UDP source port to demultiplex BFD 280 Echo session, or there is only one BFD Echo session running at device 281 A. Device A would send BFD Echo packets with IP destination address 282 destined for itself, such as the IP address of interface 1 of device 283 A. All BFD Echo packets for the session MUST be sent with a Time to 284 Live (TTL) or Hop Limit value of 255. 286 Considering the BFD peer wouldn't advertise Required Min Echo RX 287 Interval as defined in [RFC5880], the transmit interval for sending 288 BFD Echo packets MUST be provisioned at device A, how to make sure 289 the BFD peer is willing and able to loop back BFD Echo packets sent 290 with the provisioned transmit interval is outside the scope of this 291 document. Considering the BFD peer wouldn't advertise Detect Mult as 292 defined in [RFC5880], the Detect Mult for calculating the Detection 293 Time MUST be provisioned at device A, the Detection Time in device A 294 is equal to the provisioned Detect Mult multiplied by the provisioned 295 transmit interval. 297 After receiving the BFD Echo packets sent from device A, the one-hop- 298 away BFD peer device B immediately loops them back by normal IP 299 forwarding, this allows device A to rapidly detect a connectivity 300 loss to device B. 302 Device A Device B 303 BFD Echo session 304 BFD Enabled BFD Echo packets loopback 305 +--------+ +---------+ 306 | A |---------------------------------| B | 307 | |Inf 1 Inf 1| | 308 +--------+10.1.1.1/24 10.1.1.2/24+---------+ 309 BFD is supported. BFD is not supported. 311 Figure 1: Unaffiliated BFD Echo deployment scenario 313 4. Unaffilicated BFD Echo Applicability 315 With the more and more application of BFD detection, there are some 316 scenarios the BFD Echo function is deployed. And due to the 317 different capabilities of the devices deploying BFD Echo function, 318 it's required to apply Unaffiliated BFD Echo to the devices that 319 couldn't afford the overhead of the full BFD protocol capability, 320 such as the servers running virtual machines or some Internet of 321 Things (IoT) devices. Unaffiliated BFD Echo can be used when two 322 devices are connected and only one of them supports BFD protocol 323 capability. 325 Unaffiliated BFD Echo function is reasonable and useful. Firstly, 326 Unaffiliated BFD Echo can use BFD protocol capability at the local 327 BFD-supported device, while using IP forwarding capability at the 328 peer BFD-unsupported device, so Unaffiliated BFD Echo can support 329 fast detecting and manage BFD sessions very effectively. Secondly, 330 it is scalable when using Unaffiliated BFD Echo to adapt to different 331 capabilities of devices. 333 5. Security Considerations 335 Unicast Reverse Path Forwarding (uRPF), as specified in [RFC3704] and 336 [RFC8704], is a security feature that prevents the IP address 337 spoofing attacks which is commonly used in DoS, DDoS. uRPF has two 338 modes called strict mode and loose mode. uRPF strict mode means that 339 the router will perform checks for all incoming packets on a certain 340 interface: whether the router has a matching entry for the source IP 341 in the routing table and whether the router uses the same interface 342 to reach this source IP as where the router received this packet on. 343 Note that the use of BFD Echo function would prevent the use of uRPF 344 in strict mode. 346 6. IANA Considerations 348 This document has no IANA action requested. 350 7. Acknowledgements 352 The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky 353 and Santosh Pallagatti for their careful review and very helpful 354 comments. 356 8. Contributors 358 Liu Aihua 359 ZTE 360 Email: liu.aihua@zte.com.cn 362 Qian Xin 363 ZTE 364 Email: qian.xin2@zte.com.cn 366 Zhao Yanhua 367 ZTE 368 Email: zhao.yanhua3@zte.com.cn 370 9. References 372 9.1. Normative References 374 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 375 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 376 . 378 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 379 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 380 DOI 10.17487/RFC5881, June 2010, 381 . 383 9.2. Informative References 385 [BBF-TR-146] 386 Broadband Forum, "BBF Technical Report - Subscriber 387 Sessions Issue 1", 2013, . 390 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 391 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 392 2004, . 394 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 395 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 396 RFC 8704, DOI 10.17487/RFC8704, February 2020, 397 . 399 Authors' Addresses 401 Weiqiang Cheng 402 China Mobile 403 Beijing 404 CN 406 Email: chengweiqiang@chinamobile.com 408 Ruixue Wang 409 China Mobile 410 Beijing 411 CN 413 Email: wangruixue@chinamobile.com 415 Xiao Min 416 ZTE Corp. 417 Nanjing 418 CN 420 Email: xiao.min2@zte.com.cn 421 Reshad Rahman 422 Cisco Systems 423 Kanata 424 CA 426 Email: rrahman@cisco.com 428 Raj Chetan Boddireddy 429 Juniper Networks 431 Email: rchetan@juniper.net