idnits 2.17.1 draft-ietf-bfd-stability-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 21, 2017) is 2348 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-03 Summary: 1 error (**), 0 flaws (~~), 2 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 O3b Networks 4 Intended status: Standards Track M. Jethanandani 5 Expires: May 25, 2018 Cisco Systems 6 A. Saxena 7 Ciena Corporation 8 S. Pallagatti 9 Juniper Networks 10 M. Chen 11 Huawei 12 P. Fan 13 China Mobile 14 November 21, 2017 16 BFD Stability 17 draft-ietf-bfd-stability-01 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 frame loss. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 25, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. BFD Null-Authentication TLV . . . . . . . . . . . . . . . . . 3 68 4. Theory of Operations . . . . . . . . . . . . . . . . . . . . 3 69 4.1. Loss Measurement . . . . . . . . . . . . . . . . . . . . 3 70 5. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 4 71 6. Security Consideration . . . . . . . . . . . . . . . . . . . 4 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 77 1. Introduction 79 The Bidirectional Forwarding Detection (BFD) [RFC5880] protocol 80 operates by transmitting and receiving control frames, generally at 81 high frequency, over the datapath being monitored. In order to 82 prevent significant data loss due to a datapath failure, the 83 tolerance for lost or delayed frames in the Detection Time, as 84 defined in BFD [RFC5880] is set to the smallest feasible value. 86 This document proposes a mechanism to detect lost frames in a BFD 87 session in addition to the datapath fault detection mechanisms of 88 BFD. Such a mechanism presents significant value to measure the 89 stability of BFD sessions and provides data to the operators for the 90 cause of a BFD failure. 92 This document does not propose BFD extension to measure data traffic 93 loss or delay on a link or tunnel and the scope is limited to BFD 94 frames. 96 2. Use Cases 98 Legacy BFD cannot detect any BFD frame loss if loss does not last for 99 dead interval. This draft proposes a method to detect a dropped 100 frame on the receiver. For example, if the receiver receives BFD CC 101 frame k at time t but receives frame k+3 at time t+10ms, and never 102 receives frame k+1 and/or k+2, then it has experienced a drop. 104 This proposal enables BFD engine to generate diagnostic information 105 on the health of each BFD session that could be used to preempt a 106 failure on a link that BFD was monitoring by allowing time for a 107 corrective action to be taken. 109 In a faulty datapath scenario, operator can use BFD health 110 information to trigger delay and loss measurement OAM protocol 111 (Connectivity Fault Management (CFM) or Loss Measurement (LM)-Delay 112 Measurement (DM)) to further isolate the issue. 114 3. BFD Null-Authentication TLV 116 The functionality proposed for BFD stability measurement is achieved 117 by appending the Null-Authentication TLV (as defined in Optimizing 118 BFD Authentication [I-D.ietf-bfd-optimizing-authentication] ) to the 119 BFD control frame that do not have authentication enabled. 121 4. Theory of Operations 123 This mechanism allows operator to measure the loss of BFD CC frames. 125 When using MD5 or SHA authentication, BFD uses authentication TLV 126 that carries the Sequence Number. However, if non-meticulous 127 authentication is being used, or no authentication is in use, then 128 the non-authenticated BFD frames MUST include NULL-Auth TLV. 130 4.1. Loss Measurement 132 Loss measurement counts the number of BFD control frames missed at 133 the receiver during any Detection Time period. The loss is detected 134 by comparing the Sequence Number field in the Auth TLV (NULL or 135 otherwise) in successive BFD CC frames. The Sequence Number in each 136 successive control frame generated on a BFD session by the 137 transmitter is incremented by one. 139 The first BFD NULL-Auth TLV processed by the receiver that has a non- 140 zero sequence number is used for bootstrapping the logic. When using 141 secure sequence numbers, if the expected values are pre-calculated, 142 the matched value must be appropriately recorded to detect lost 143 frames. 145 5. IANA Requirements 147 N/A 149 6. Security Consideration 151 Other than concerns raised in BFD [RFC5880] there are no new concerns 152 with this proposal. 154 7. Contributors 156 Manav Bhatia 158 8. Acknowledgements 160 Authors would like to thank Nobo Akiya, Jeffery Haas, Peng Fan, 161 Dileep Singh, Basil Saji, Sagar Soni and Mallik Mudigonda who also 162 contributed to this document. 164 9. Normative References 166 [I-D.ietf-bfd-optimizing-authentication] 167 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 168 "Optimizing BFD Authentication", draft-ietf-bfd- 169 optimizing-authentication-03 (work in progress), June 170 2017. 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, 174 DOI 10.17487/RFC2119, March 1997, 175 . 177 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 178 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 179 . 181 Authors' Addresses 183 Ashesh Mishra 184 O3b Networks 186 Email: mishra.ashesh@gmail.com 187 Mahesh Jethanandani 188 Cisco Systems 189 170 W. Tasman Drive 190 San Jose, CA 95134 191 USA 193 Email: mjethanandani@gmail.com 194 URI: www.cisco.com 196 Ankur Saxena 197 Ciena Corporation 198 3939 North 1st Street 199 San Jose, CA 95134 200 USA 202 Email: ankurpsaxena@gmail.com 203 URI: www.ciena.com 205 Santosh Pallagatti 206 Juniper Networks 207 Juniper Networks, Exora Business Park 208 Bangalore, Karnataka 560103 209 India 211 Email: santoshpk@juniper.net 213 Mach Chen 214 Huawei 216 Email: mach.chen@huawei.com 218 Peng Fan 219 China Mobile 220 32 Xuanwumen West Street 221 Beijing, Beijing 222 China 224 Email: fanp08@gmail.com