idnits 2.17.1 draft-ietf-bfd-unaffiliated-echo-00.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 (September 9, 2020) is 1317 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: March 13, 2021 A. Liu 7 ZTE Corp. 8 R. Rahman 9 Cisco Systems 10 R. Boddireddy 11 Juniper Networks 12 September 9, 2020 14 Unaffiliated BFD Echo Function 15 draft-ietf-bfd-unaffiliated-echo-00 17 Abstract 19 Bidirectional Forwarding Detection (BFD) is a fault detection 20 protocol that can quickly determine a communication failure between 21 two forwarding engines. This document proposes a use of BFD echo 22 where the local system supports BFD but the neighboring system does 23 not support BFD. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 13, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Unaffiliated BFD Echo Behavior . . . . . . . . . . . . . . . 3 61 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 7.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 To minimize the impact of device faults on services and improve 73 network availability, a network device must be able to quickly detect 74 faults in communication with adjacent devices. Measures can then be 75 taken to promptly rectify the faults to ensure service continuity. 77 BFD [RFC5880] is a low-overhead, short-duration method to detect 78 faults on the path between adjacent forwarding engines. The faults 79 can be interface, data link, and even forwarding engine faults. It 80 is a single, unified mechanism to monitor any media and protocol 81 layers in real time. 83 BFD defines asynchronous mode to satisfy various deployment 84 scenarios, also supports echo function to reduce the device 85 requirement for BFD. When the echo function is activated, the local 86 system sends a BFD echo packet and the remote system loops back the 87 packet through the forwarding path. If several consecutive echo 88 packets are not received, the session is declared to be Down. 90 When using BFD echo function, it is not clear whether the devices 91 using echo function need to support the full BFD procotol, including 92 maintaining the state machine of BFD session as described in 93 [RFC5880] and [RFC5881]. According to different understanding, there 94 are two typical scenarios as below: 96 1. Full BFD procotol capability with affiliated echo function: 97 this scenario requires both the local device and the neighboring 98 device to support BFD protocol. 100 2. Only BFD echo function without full BFD procotol capability: 101 this scenario requires only the local device to support sending 102 BFD packets. 104 The two typical scenarios are both reasonable and useful, and the 105 latter is referred to as unaffiliated BFD echo function in this 106 document. 108 Unaffiliated BFD echo function described in this document reuses the 109 BFD echo function as described in [RFC5880] and [RFC5881], but 110 independent of BFD asynchronous mode, that means it doesn't need BFD 111 protocol capability of state machine, but only BFD echo function to a 112 deployed device supporting BFD detection. When using unaffiliated 113 BFD echo function, just the local device works on BFD protocol and 114 the BFD peer doesn't, which only loopback the received BFD echo 115 packets as usual data packets without enabling BFD protocol. 117 Section 6.2.2 of [BBF-TR-146] describes one use case of the 118 unaffiliated BFD echo function, and at least one more use case is 119 known in the field BFD deployment. 121 2. Unaffiliated BFD Echo Behavior 123 With the more and more application of BFD detection, there are some 124 scenarios the BFD echo function is deployed. And due to the 125 different capabilities of the devices deploying BFD echo function, 126 it's required to apply unaffiliated BFD echo to the devices that 127 couldn't afford the overhead of the full BFD protocol capablity, such 128 as the servers running virtual machines or some Internet of Things 129 (IoT) devices. Unaffiliated BFD echo can be used when two devices 130 are connected and only one of them supports BFD protocol capability. 131 A BFD echo session can be established at the device that supports 132 BFD, and the device will send the BFD echo packets with the IP 133 address destined for itself, whereas the other peer device just 134 loopback the received BFD echo packets. 136 After receiving a BFD echo packet, the device that does not support 137 BFD protocol immediately loops back the packet by normal IP 138 forwarding, implementing quick link failure detection. As shown in 139 Figure 1, device A supports BFD, whereas device B does not support 140 BFD. To rapidly detect any faults with the IP link between device A 141 and device B, a BFD echo session can be provisioned and created at 142 device A, and device A starts sending BFD echo packets, which should 143 include a BFD echo session demultiplexing field, such as BFD 144 discriminator defined in [RFC5880]. After receiving the BFD echo 145 packets sent from device A, device B immediately loops back them, 146 this allows device A to rapidly detect a connectivity loss to device 147 B. 149 Device A Device B 150 BFD echo session 151 BFD Enabled BFD Echo packets loopback 152 +--------+ +---------+ 153 | A |---------------------------------| B | 154 | |Inf 1 Inf 1| | 155 +--------+10.1.1.1/24 10.1.1.2/24+---------+ 156 BFD is supported. BFD is not supported. 158 Figure 1: Unaffiliated BFD Echo deployment scenario 160 3. Discussion 162 Unaffiliated BFD echo function is reasonable and useful. Firstly, 163 unaffiliated BFD echo can use BFD protocol capability in the local 164 BFD-supported device, while using IP forwarding capability in the 165 peer non-BFD-supported device, so unaffiliated BFD echo can support 166 fast detecting and manage BFD sessions very effectively. Secondly, 167 it is scalable when using unaffiliated BFD echo to adapt to different 168 capabilities of devices. 170 4. Security Considerations 172 Unicast Reverse Path Forwarding (uRPF), as specified in [RFC3704] and 173 [RFC8704], is a security feature that prevents the IP address 174 spoofing attacks which is commonly used in DoS, DDoS. uRPF has two 175 modes called strict mode and loose mode. uRPF strict mode means that 176 the router will perform checks for all incoming packets on a certain 177 interface: whether the router has a matching entry for the source IP 178 in the routing table and whether the router uses the same interface 179 to reach this source IP as where the router received this packet on. 180 Note that the use of BFD echo function would prevent the use of uRPF 181 in strict mode. 183 5. IANA Considerations 185 This document has no IANA action requested. 187 6. Acknowledgements 189 TBD. 191 7. References 193 7.1. Normative References 195 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 196 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 197 . 199 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 200 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 201 DOI 10.17487/RFC5881, June 2010, 202 . 204 7.2. Informative References 206 [BBF-TR-146] 207 Broadband Forum, "BBF Technical Report - Subscriber 208 Sessions Issue 1", 2013, . 211 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 212 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 213 2004, . 215 [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced 216 Feasible-Path Unicast Reverse Path Forwarding", BCP 84, 217 RFC 8704, DOI 10.17487/RFC8704, February 2020, 218 . 220 Authors' Addresses 222 Weiqiang Cheng 223 China Mobile 224 Beijing 225 CN 227 Email: chengweiqiang@chinamobile.com 228 Ruixue Wang 229 China Mobile 230 Beijing 231 CN 233 Email: wangruixue@chinamobile.com 235 Xiao Min 236 ZTE Corp. 237 Nanjing 238 CN 240 Email: xiao.min2@zte.com.cn 242 Aihua Liu 243 ZTE Corp. 244 Shenzhen 245 CN 247 Email: liu.aihua@zte.com.cn 249 Reshad Rahman 250 Cisco Systems 251 Kanata 252 CA 254 Email: rrahman@cisco.com 256 Raj Chetan Boddireddy 257 Juniper Networks 259 Email: rchetan@juniper.net