idnits 2.17.1 draft-wang-bfd-one-arm-use-case-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5880], [RFC5881]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 18, 2019) is 1622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD Working Group R. Wang 3 Internet-Draft W. Cheng 4 Intended status: Informational China Mobile 5 Expires: May 21, 2020 Y. Zhao 6 A. Liu 7 ZTE 8 November 18, 2019 10 Using One-Arm BFD in Cloud Network 11 draft-wang-bfd-one-arm-use-case-00 13 Abstract 15 Bidirectional Forwarding Detection (BFD) is a fault detection 16 protocol that can quickly determine a communication failure between 17 devices and notify upper-layer applications [RFC5880]. BFD has 18 asynchronous detecting mode and demand detection mode to satisfy 19 different scenarios, also supports echo function to reduce the device 20 requirement for BFD. One-Arm BFD this draft descripted supports 21 another BFD detecting function rather than the echo as described in 22 [RFC5880] [RFC5881], it needs nothing BFD capability to one of the 23 devices deployed BFD detecting. Using One-Arm BFD function, the one 24 device works on BFD detecting normally and the other device just 25 loopback the BFD packets like echo function. One-Arm BFD is suitable 26 for the cloud virtualization network, the One-Arm BFD is deploy on 27 NFV gateways, and NFV virtual machine vNICs just enable the echo/ 28 loopback process. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 21, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 66 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 67 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 68 2. One-Arm BFD Use Case . . . . . . . . . . . . . . . . . . . . 3 69 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 To minimize the impact of device faults on services and improve 79 network availability, a network device must be able to quickly detect 80 faults in communication with adjacent devices. Measures can then be 81 taken to promptly rectify the faults to ensure service continuity. 83 BFD is a low-overhead, short-duration method to detect faults on the 84 path between adjacent forwarding engines. The faults can be 85 interface, data link, and even forwarding engine faults. It is a 86 single, unified mechanism to monitor any media and protocol layers in 87 real time. 89 BFD has asynchronous detecting mode and demand detection mode to 90 satisfy different scenarios, also supports echo function to reduce 91 the device requirement for BFD. BFD echo function is used when two 92 devices are connected but only one of them supports full BFD 93 capability. When the echo function is activated, the local system 94 sends a BFD control packet and the remote system loops back the 95 packet through the forwarding channel. If several consecutive echo 96 packets are not received, the session is declared to be Down. BFD 97 echo function reduces one of the two devices requirement for BFD. 99 With the development of network cloud and NFV virtualization, there 100 are many connections between gateway devices and the virtual machine 101 devices. The virtual machine devices don't support BFD capacity at 102 all. There is difficult to deploy BFD between the gateway devices 103 and the virtual machine vNICs. One-Arm BFD supports this scenario, 104 it supports gateway enable full BFD capability and virtual machine 105 don't support BFD at all, just simply loopback BFD packets on vNICs. 107 1.1. Conventions Used in This Document 109 1.1.1. Terminology 111 BFD: Bidirectional Forwarding Detection 113 NFV: Network Function Virtualization 115 1.1.2. Requirements Language 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. One-Arm BFD Use Case 125 With the development of network cloud and NFV virtualization, there 126 are many connections between gateway devices and the virtual machine 127 devices. The virtual machine(VM) devices don't support BFD capacity 128 at all. If the gateway devices are deployed BFD protocol, there are 129 some problems including scalability, detecting period and so on. And 130 the VM can't support BFD protocol currently. One-Arm echo BFD can 131 resolve these problems. One-arm echo BFD is used when two devices 132 are connected and only one of them supports BFD. A one-arm BFD echo 133 session can be established on the device that supports BFD, the other 134 device just loopback BFD packets. 136 After receiving a one-arm BFD echo session packet, the device that 137 does not support BFD immediately loops back the packet, implementing 138 quick link failure detection. As shown in Figure 1, Device A such as 139 a NFV gateway supports BFD, whereas Device B such as a virtual 140 machine does not. To rapidly detect faults in the link between 141 Device A and Device B, configure a one-arm BFD echo session on Device 142 A. After receiving a one-arm BFD echo session packet from Device A, 143 Device B immediately loops back the packet, implementing rapid link 144 fault detection. 146 Device A One-Arm Echo Device B 147 +--------+ BFD session +---------+ 148 | A |---------------------------------| B | 149 | |Inf 1 Inf 1| | 150 +--------+10.1.1.1/24 10.1.1.2/24+---------+ 151 BFD is supported. BFD is not supported. 153 Figure 1: One-Arm BFD deploying scenario 155 3. Discussion 157 One-Arm BFD detecting function is better than BFD echo function mode. 158 First One-Arm BFD can use full BFD capacity in the BFD-supported 159 device. So One-Arm BFD can also support fast detecting and manage 160 BFD sessions effectively. Second it is scalable using one-arm BFD 161 detecting to adapt the NFV virtualization. Finally, it is the same 162 process in the non-BFD-supported devices with echo function. So one- 163 arm BFD can be deployed to the cloud network, and the VMs don't 164 require to support BFD capacity. 166 4. Security Considerations 168 TBD. 170 5. IANA Considerations 172 This document has no IANA action requested. 174 6. Acknowledgements 176 TBD. 178 7. Normative References 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, 182 DOI 10.17487/RFC2119, March 1997, 183 . 185 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 186 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 187 . 189 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 190 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 191 DOI 10.17487/RFC5881, June 2010, 192 . 194 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 195 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 196 May 2017, . 198 Authors' Addresses 200 Ruixue Wang 201 China Mobile 202 Beijing 203 CN 205 Email: wangruixue@chinamobile.com 207 Weiqiang Cheng 208 China Mobile 209 Beijing 210 CN 212 Email: chengweiqiang@chinamobile.com 214 Yanhua Zhao 215 ZTE 216 Nanjing 217 CN 219 Email: zhao.yanhua3@zte.com.cn 221 Aihua Liu 222 ZTE 223 Shenzhen 224 CN 226 Email: liu.aihua@zte.com.cn