idnits 2.17.1 draft-ietf-bfd-stability-06.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 (July 13, 2020) is 1373 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-09 == Outdated reference: A later version (-13) exists of draft-ietf-bfd-secure-sequence-numbers-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mishra 3 Internet-Draft SES 4 Intended status: Standards Track M. Jethanandani 5 Expires: January 14, 2021 Kloud Services 6 A. Saxena 7 Ciena Corporation 8 S. Pallagatti 9 VmWare 10 M. Chen 11 Huawei 12 P. Fan 13 China Mobile 14 July 13, 2020 16 BFD Stability 17 draft-ietf-bfd-stability-06 19 Abstract 21 This document describes extensions to the Bidirectional Forwarding 22 Detection (BFD) protocol to measure BFD stability. Specifically, it 23 describes a mechanism for detection of BFD packet loss. 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 January 14, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. BFD Null-Authentication Type . . . . . . . . . . . . . . . . 3 63 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 64 5.1. Loss Measurement . . . . . . . . . . . . . . . . . . . . 3 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 7. Security Consideration . . . . . . . . . . . . . . . . . . . 4 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 69 10. Normative References . . . . . . . . . . . . . . . . . . . . 4 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 The Bidirectional Forwarding Detection ( BFD) [RFC5880] protocol 75 operates by transmitting and receiving BFD control packets, generally 76 at high frequency, over the datapath being monitored. In order to 77 prevent significant data loss due to a datapath failure, BFD session 78 detection time as defined in BFD [RFC5880] is set to the smallest 79 feasible value. 81 This document proposes a mechanism to detect lost packet in a BFD 82 session in addition to the datapath fault detection mechanisms of 83 BFD. Such a mechanism presents significant value to measure the 84 stability of BFD sessions and provides data to the operators for the 85 cause of a BFD failure. 87 This document does not propose any BFD extension to measure data 88 traffic loss or delay on a link or tunnel and the scope is limited to 89 BFD packets. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119] and 96 RFC 8174 [RFC8174]. 98 The reader is expected to be familiar with the BFD [RFC5880], 99 Optimizing BFD Authentication 100 [I-D.ietf-bfd-optimizing-authentication] and BFD Secure Sequence 101 Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 103 3. Use Cases 105 Bidirectional Forwarding Detection as defined in BFD [RFC5880] cannot 106 detect any BFD packet loss if loss does not last for detection time. 107 This document proposes a method to detect a dropped packet on the 108 receiver. For example, if the receiver receives BFD control packet k 109 at time t but receives packet k+3 at time t+10ms, and never receives 110 packet k+1 and/or k+2, then it has experienced a drop. 112 This proposal enables BFD implementation to generate diagnostic 113 information on the health of each BFD session that could be used to 114 preempt a failure on a link that BFD was monitoring by allowing time 115 for a corrective action to be taken. 117 In a faulty datapath scenario, an operator can use BFD health 118 information to trigger delay and loss measurement OAM protocol 119 (Connectivity Fault Management (CFM) or Loss Measurement (LM)-Delay 120 Measurement (DM)) to further isolate the issue. 122 4. BFD Null-Authentication Type 124 The functionality proposed for BFD stability measurement is achieved 125 by appending the Null-Authentication type (as defined in Optimizing 126 BFD Authentication [I-D.ietf-bfd-optimizing-authentication] ) to the 127 BFD control packets 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 authentication TLV 135 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 packets MUST include NULL-Auth TLV. 139 5.1. Loss Measurement 141 Loss measurement counts the number of BFD control packets missed at 142 the receiver during any Detection Time period. The loss is detected 143 by comparing the Sequence Number field in the Auth TLV (NULL or 144 otherwise) in successive BFD control packets. The Sequence Number in 145 each successive control packet generated on a BFD session by the 146 transmitter is incremented by one. 148 The first BFD NULL-Auth type processed by the receiver that has a 149 non-zero sequence number is used for bootstrapping the logic. When 150 using secure sequence numbers, if the expected values are pre- 151 calculated, the value must be matched to detect lost packets as 152 defined in BFD secure sequence numbers 153 [I-D.ietf-bfd-secure-sequence-numbers]. 155 6. IANA Considerations 157 This document has no actions for IANA. 159 7. Security Consideration 161 Other than concerns raised in BFD [RFC5880], Optimizing BFD 162 Authentication [I-D.ietf-bfd-optimizing-authentication] and BFD 163 Secure Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 164 There are no new concerns with this proposal. 166 8. Contributors 168 Manav Bhatia 170 9. Acknowledgements 172 Authors would like to thank Nobo Akiya, Jeffery Haas, Peng Fan, 173 Dileep Singh, Basil Saji, Sagar Soni and Mallik Mudigonda who also 174 contributed to this document. 176 10. Normative References 178 [I-D.ietf-bfd-optimizing-authentication] 179 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 180 "Optimizing BFD Authentication", draft-ietf-bfd- 181 optimizing-authentication-09 (work in progress), December 182 2019. 184 [I-D.ietf-bfd-secure-sequence-numbers] 185 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 186 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 187 secure-sequence-numbers-05 (work in progress), February 188 2020. 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, 192 DOI 10.17487/RFC2119, March 1997, 193 . 195 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 196 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 197 . 199 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 200 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 201 May 2017, . 203 Authors' Addresses 205 Ashesh Mishra 206 SES 208 Email: mishra.ashesh@gmail.com 210 Mahesh Jethanandani 211 Kloud Services 212 CA 213 USA 215 Email: mjethanandani@gmail.com 217 Ankur Saxena 218 Ciena Corporation 219 3939 North 1st Street 220 San Jose, CA 95134 221 USA 223 Email: ankurpsaxena@gmail.com 224 URI: www.ciena.com 226 Santosh Pallagatti 227 VmWare 228 Bangalore, Karnataka 560103 229 India 231 Email: santosh.pallagatti@gmail.com 232 Mach Chen 233 Huawei 235 Email: mach.chen@huawei.com 237 Peng Fan 238 China Mobile 239 32 Xuanwumen West Street 240 Beijing, Beijing 241 China 243 Email: fanp08@gmail.com