idnits 2.17.1 draft-ietf-bfd-stability-07.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: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jan 14, 2021) is 1197 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) == Outdated reference: A later version (-15) exists of draft-ietf-bfd-optimizing-authentication-11 == Outdated reference: A later version (-13) exists of draft-ietf-bfd-secure-sequence-numbers-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Mishra 2 Internet-Draft SES 3 Intended status: Standards Track M. Jethanandani 4 Expires: July 18, 2021 Kloud Services 5 A. Saxena 6 Ciena Corporation 7 S. Pallagatti 8 VmWare 9 M. Chen 10 Huawei 11 P. Fan 12 China Mobile 13 Jan 14, 2021 15 BFD Stability 16 draft-ietf-bfd-stability-07 18 Abstract 20 This document describes extensions to the Bidirectional Forwarding 21 Detection (BFD) protocol to measure BFD stability. Specifically, it 22 describes a mechanism for detection of BFD packet loss. 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 July 18, 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. BFD Null-Authentication Type . . . . . . . . . . . . . . . . 3 62 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 63 5.1. Loss Measurement . . . . . . . . . . . . . . . . . . . . 3 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 7. Security Consideration . . . . . . . . . . . . . . . . . . . 4 66 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 4 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 The Bidirectional Forwarding Detection ( BFD) [RFC5880] protocol 74 operates by transmitting and receiving BFD control packets, generally 75 at high frequency, over the datapath being monitored. In order to 76 prevent significant data loss due to a datapath failure, BFD session 77 detection time as defined in BFD [RFC5880] is set to the smallest 78 feasible value. 80 This document proposes a mechanism to detect lost packets in a BFD 81 session in addition to the datapath fault detection mechanisms of 82 BFD. Such a mechanism presents significant value to measure the 83 stability of BFD sessions and provides data to the operators for the 84 cause of a BFD failure. 86 This document does not propose any BFD extension to measure data 87 traffic loss or delay on a link or tunnel and the scope is limited to 88 BFD packets. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119] and 95 RFC 8174 [RFC8174]. 97 The reader is expected to be familiar with the BFD [RFC5880], 98 Optimizing BFD Authentication 99 [I-D.ietf-bfd-optimizing-authentication] and BFD Secure Sequence 100 Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 102 3. Use Cases 104 Bidirectional Forwarding Detection as defined in BFD [RFC5880] cannot 105 detect any BFD packet loss if the loss does not last for detection 106 time. This document proposes a method to detect a dropped packet on 107 the receiver. For example, if the receiver receives BFD control 108 packet k at time t but receives packet k+3 at time t+10ms, and never 109 receives packet k+1 and/or k+2, then it has experienced a drop. 111 This proposal enables BFD implementations to generate diagnostic 112 information on the health of each BFD session that could be used to 113 preempt a failure on a datapath that BFD was monitoring by allowing 114 time for a corrective action to be taken. 116 In a faulty datapath scenario, an operator can use BFD health 117 information to trigger delay and loss measurement OAM protocol 118 (Connectivity Fault Management (CFM) or Loss Measurement (LM)-Delay 119 Measurement (DM)) to further isolate the issue. 121 4. BFD Null-Authentication Type 123 The functionality proposed for BFD stability measurement is achieved 124 by appending an authentication section with the NULL Authentication 125 type (as defined in Optimizing BFD Authentication 126 [I-D.ietf-bfd-optimizing-authentication] ) to the BFD control packets 127 that do not have authentication enabled. 129 5. Theory of Operation 131 This mechanism allows operators to measure the loss of BFD control 132 packets. 134 When using MD5 or SHA authentication, BFD uses an authentication 135 section that carries the Sequence Number. However, if non-meticulous 136 authentication is being used, or no authentication is in use, then 137 the non-authenticated BFD control packets MUST include an 138 authentication section with the NULL Authentication type. 140 5.1. Loss Measurement 142 Loss measurement counts the number of BFD control packets missed at 143 the receiver during any Detection Time period. The loss is detected 144 by comparing the Sequence Number field in the Auth TLV (NULL or 145 otherwise) in successive BFD control packets. The Sequence Number in 146 each successive control packet generated on a BFD session by the 147 transmitter is incremented by one. 149 The first BFD authentication section with a non-zero sequence number, 150 in a valid BFD control packet, processed by the receiver is used for 151 bootstrapping the logic. When using secure sequence numbers, if the 152 expected values are pre-calculated, the value must be matched to 153 detect lost packets as defined in BFD secure sequence numbers 154 [I-D.ietf-bfd-secure-sequence-numbers]. 156 6. IANA Considerations 158 This document has no actions for IANA. 160 7. Security Consideration 162 Other than concerns raised in BFD [RFC5880], Optimizing BFD 163 Authentication [I-D.ietf-bfd-optimizing-authentication] and BFD 164 Secure Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 165 There are no new concerns with this proposal. 167 8. Contributors 169 Manav Bhatia 171 9. Acknowledgements 173 Authors would like to thank Nobo Akiya, Jeffery Haas, Peng Fan, 174 Dileep Singh, Basil Saji, Sagar Soni and Mallik Mudigonda who also 175 contributed to this document. 177 10. Normative References 179 [I-D.ietf-bfd-optimizing-authentication] 180 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 181 "Optimizing BFD Authentication", draft-ietf-bfd- 182 optimizing-authentication-11 (work in progress), July 183 2020. 185 [I-D.ietf-bfd-secure-sequence-numbers] 186 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 187 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 188 secure-sequence-numbers-07 (work in progress), December 189 2020. 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, 193 DOI 10.17487/RFC2119, March 1997, 194 . 196 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 197 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 198 . 200 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 201 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 202 May 2017, . 204 Authors' Addresses 206 Ashesh Mishra 207 SES 209 Email: mishra.ashesh@gmail.com 211 Mahesh Jethanandani 212 Kloud Services 213 CA 214 USA 216 Email: mjethanandani@gmail.com 218 Ankur Saxena 219 Ciena Corporation 220 3939 North 1st Street 221 San Jose, CA 95134 222 USA 224 Email: ankurpsaxena@gmail.com 225 URI: www.ciena.com 227 Santosh Pallagatti 228 VmWare 229 Bangalore, Karnataka 560103 230 India 232 Email: santosh.pallagatti@gmail.com 233 Mach Chen 234 Huawei 236 Email: mach.chen@huawei.com 238 Peng Fan 239 China Mobile 240 32 Xuanwumen West Street 241 Beijing, Beijing 242 China 244 Email: fanp08@gmail.com