idnits 2.17.1 draft-ietf-bfd-stability-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 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 (May 11, 2017) is 2535 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-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Working Group A. Mishra 3 Internet-Draft O3b Networks 4 Intended status: Standards Track M. Jethanandani 5 Expires: November 12, 2017 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 May 11, 2017 16 BFD Stability 17 draft-ietf-bfd-stability-00.txt 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 http://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 November 12, 2017. 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 (http://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. Each 141 successive frame after this is expected to have a Sequence Number 142 that is one greater than the Sequence Number in the previous frame. 144 When the Sequence Number wraps around it should start from 1 instead 145 of 0. 147 5. IANA Requirements 149 N/A 151 6. Security Consideration 153 Other than concerns raised in BFD [RFC5880] there are no new concerns 154 with this proposal. 156 7. Contributors 158 Manav Bhatia 160 8. Acknowledgements 162 Authors would like to thank Nobo Akiya, Jeffery Haas, Peng Fan, 163 Dileep Singh, Basil Saji, Sagar Soni and Mallik Mudigonda who also 164 contributed to this document. 166 9. Normative References 168 [I-D.ietf-bfd-optimizing-authentication] 169 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 170 "Optimizing BFD Authentication", draft-ietf-bfd- 171 optimizing-authentication-02 (work in progress), January 172 2017. 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, 176 DOI 10.17487/RFC2119, March 1997, 177 . 179 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 180 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 181 . 183 Authors' Addresses 185 Ashesh Mishra 186 O3b Networks 188 Email: mishra.ashesh@outlook.com 189 Mahesh Jethanandani 190 Cisco Systems 191 170 W. Tasman Drive 192 San Jose, CA 95134 193 USA 195 Email: mjethanandani@gmail.com 196 URI: www.cisco.com 198 Ankur Saxena 199 Ciena Corporation 200 3939 North 1st Street 201 San Jose, CA 95134 202 USA 204 Email: ankurpsaxena@gmail.com 205 URI: www.ciena.com 207 Santosh Pallagatti 208 Juniper Networks 209 Juniper Networks, Exora Business Park 210 Bangalore, Karnataka 560103 211 India 213 Email: santoshpk@juniper.net 215 Mach Chen 216 Huawei 218 Email: mach.chen@huawei.com 220 Peng Fan 221 China Mobile 222 32 Xuanwumen West Street 223 Beijing, Beijing 224 China 226 Email: fanp08@gmail.com