idnits 2.17.1 draft-bfd-fsm-health-status-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5880, but the abstract doesn't seem to directly say this. It does mention RFC5880 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2020) is 1284 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) == Unused Reference: 'RFC5881' is defined on line 174, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Palpandi Perumal 2 Internet Draft Pluribus Networks 3 Updates: 5880 (if approved) 4 Intended status: Proposed Standard 5 Expires: April 14, 2021 October 13, 2020 7 FSM health status support in BFD 8 draft-bfd-fsm-health-status-00 10 Abstract 12 Bidirectional Forwarding Detection operates in different modes. 13 When BFD runs in asynchronous mode requires hello packet needs 14 to be transmitted and received on regular intervals. In software 15 based BFD application, hello packets processing path may be 16 heavy weight which may involve many processing levels to reach 17 BFD application. On a scaled system, processing delay may not 18 be constant at all the time and this processing delay does appear 19 at any point between software path entry point and BFD application. 20 This delay needs to be identified and suppressed otherwise system 21 may end up on false link failure detection. This internet draft 22 deals on this particular case. 24 Since introducing new Diagnostic bit, it requires to update RFC5880. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 14, 2021 43 ----------------------------------------------------------------------- 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. FSM Diagnostic bit . . . . . . . . . . . . . . . . . . . . . 2 61 3. Setting up tolerance point on FSM health status . . . . . . . 3 62 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Conventions used in this document . . . . . . . . . . . . . . 4 64 5. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 8.2. Informative References . . . . . . . . . . . . . . . . . 4 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 72 1. Introduction 74 The Bidirectional Forwarding Detection describes how to calculate 75 the FSM timer(Detection timeout). It is calculated basically by 76 multiplying negotiated transmit interval and detection multiplier. 77 On a complex software architecture, reaching to BFD application may 78 involve many queue processing, may require shared critical common 79 resources and also may involve IP/UDP header processing in kernel 80 or customised IP stack. Theoretically on a steady system, this software 81 path should not be delayed. On some critical occasions, this path 82 may not be in steady state and may introduces some delays. This 83 latency will be added as variant in the software path. To monitor 84 this variant, proposing a new diag bit (FSM health status) in the BFD 85 packet. 87 2. FSM Diagnostic bit 89 Currently Bidirectional Forwarding Detection has 8 diagnostic bits 90 totally to find out the last state change in the local system. 91 Introducing a new diagnostic bit called FSM health status. 92 Basically FSM timer value will be set as detection timeout 93 (multiplication of negotiated transmit interval and detection 94 multiplier). On asynchronous mode, FSM timer will be reseted once 95 the BFD application receives the packet. If there is no packet 96 received till the detection timeout, BFD will decide this as link 97 failure and will notify to all routing protocols. Sometime keep alive 98 packet would have reached to the peer system and from there, 99 reaching to the BFD application would have been delayed by some 100 critical events in the software path. This bit will be set when 101 the FSM timer reaches to certain threshold level upon not receiving 102 any BFD packet. 104 ---------------------------------------------------------------------- 105 3. Setting up tolerance point on FSM health status 107 3.1 Examples 109 Assuming both sides, same values are configured 111 1. rx-interval - 250ms, tx-interval - 250ms, detect multiplier - 4 112 In this case, FSM timer will be running for 1000ms. 113 BFD packet will be sent on every 250ms interval. 114 If there is no packet received for 1000ms, FSM timer will be 115 expired, BFD will detect this as link failure. 117 FSM health status as 50% 118 Once FSM timer reaches to 500ms or 50% of the time gets expire 119 and there is no BFD packet received. At that time, BFD will 120 set the newly introduced FSM health status in Diagnosis bits. 121 After eliminating tx-interval 250ms, This bit indicates the 122 delay variant involved on the software path is minimum of 123 250ms. 125 FSM health status as 60% 126 Once FSM timer reaches to 600ms or 60% of the time gets 127 expired. BFD will set this FSM health status bit. 129 2. rx-interval - 300ms, tx-interval - 300ms, detect multiplier - 3 130 In this case, FSM timer will be running for 900ms. 132 FSM health status as 50% 133 Once FSM timer reaches to 450ms or 50% of the time gets 134 expired and there is no BFD packet received. At that time, 135 BFD will set the FSM health status bits. 137 Based on the FSM diag bit indication from the packet, user will be 138 alerted by respective timestamps in the logging system. User will 139 further analyse the software path components for eliminating the 140 BFD software path latency. 142 ---------------------------------------------------------------------- 143 4. Conventions used in this document 145 BFD - Bidirectional Forwarding Detection 146 FSM - Finite State Mechaine 148 5. Echo BFD 150 Support for echo BFD is outside the scope of this document. 152 6. IANA Considerations 154 This specification has no IANA action requested. This section may be 155 deleted before the publication. 157 7. Security Consideration 159 Other than concerns raised in BFD [RFC5880], BFD FSM health status 160 [draft-bfd-fsm-health-status] has no new concerns with this proposal. 162 8. Contributor 164 Palpandi Perumal (Pluribus Networks) 166 9. Reference: 168 9.1 Normative Reference 170 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 171 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 172 . 174 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 175 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 176 DOI 10.17487/RFC5881, June 2010, 177 . 179 Authors' Addresses 181 Palpandi Perumal 182 Pluribus Networks 183 Bangaluru, India 185 Email: palpandi9891@gmail.com 187 ----------------------------------------------------------------------