Network Working Group Palpandi Perumal Internet Draft Pluribus Networks Updates: 5880 (if approved) Intended status: Proposed Standard Expires: April 14, 2021 October 13, 2020 FSM health status support in BFD draft-bfd-fsm-health-status-00 Abstract Bidirectional Forwarding Detection operates in different modes. When BFD runs in asynchronous mode requires hello packet needs to be transmitted and received on regular intervals. In software based BFD application, hello packets processing path may be heavy weight which may involve many processing levels to reach BFD application. On a scaled system, processing delay may not be constant at all the time and this processing delay does appear at any point between software path entry point and BFD application. This delay needs to be identified and suppressed otherwise system may end up on false link failure detection. This internet draft deals on this particular case. Since introducing new Diagnostic bit, it requires to update RFC5880. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 14, 2021 Palpandi Perumal Expires April 14, 2021 [Page 1] ----------------------------------------------------------------------- Internet-Draft BFD FSM health status October 13, 2020 Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. FSM Diagnostic bit . . . . . . . . . . . . . . . . . . . . . 2 3. Setting up tolerance point on FSM health status . . . . . . . 3 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions used in this document . . . . . . . . . . . . . . 4 5. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The Bidirectional Forwarding Detection describes how to calculate the FSM timer(Detection timeout). It is calculated basically by multiplying negotiated transmit interval and detection multiplier. On a complex software architecture, reaching to BFD application may involve many queue processing, may require shared critical common resources and also may involve IP/UDP header processing in kernel or customised IP stack. Theoretically on a steady system, this software path should not be delayed. On some critical occasions, this path may not be in steady state and may introduces some delays. This latency will be added as variant in the software path. To monitor this variant, proposing a new diag bit (FSM health status) in the BFD packet. 2. FSM Diagnostic bit Currently Bidirectional Forwarding Detection has 8 diagnostic bits totally to find out the last state change in the local system. Introducing a new diagnostic bit called FSM health status. Basically FSM timer value will be set as detection timeout (multiplication of negotiated transmit interval and detection multiplier). On asynchronous mode, FSM timer will be reseted once the BFD application receives the packet. If there is no packet received till the detection timeout, BFD will decide this as link failure and will notify to all routing protocols. Sometime keep alive packet would have reached to the peer system and from there, reaching to the BFD application would have been delayed by some critical events in the software path. This bit will be set when the FSM timer reaches to certain threshold level upon not receiving any BFD packet. Palpandi Perumal Expires April 14, 2021 [Page 2] ---------------------------------------------------------------------- Internet-Draft BFD FSM health status October 13, 2020 3. Setting up tolerance point on FSM health status 3.1 Examples Assuming both sides, same values are configured 1. rx-interval - 250ms, tx-interval - 250ms, detect multiplier - 4 In this case, FSM timer will be running for 1000ms. BFD packet will be sent on every 250ms interval. If there is no packet received for 1000ms, FSM timer will be expired, BFD will detect this as link failure. FSM health status as 50% Once FSM timer reaches to 500ms or 50% of the time gets expire and there is no BFD packet received. At that time, BFD will set the newly introduced FSM health status in Diagnosis bits. After eliminating tx-interval 250ms, This bit indicates the delay variant involved on the software path is minimum of 250ms. FSM health status as 60% Once FSM timer reaches to 600ms or 60% of the time gets expired. BFD will set this FSM health status bit. 2. rx-interval - 300ms, tx-interval - 300ms, detect multiplier - 3 In this case, FSM timer will be running for 900ms. FSM health status as 50% Once FSM timer reaches to 450ms or 50% of the time gets expired and there is no BFD packet received. At that time, BFD will set the FSM health status bits. Based on the FSM diag bit indication from the packet, user will be alerted by respective timestamps in the logging system. User will further analyse the software path components for eliminating the BFD software path latency. Palpandi Perumal Expires April 14, 2021 [Page 3] ---------------------------------------------------------------------- Internet-Draft BFD FSM health status October 13, 2020 4. Conventions used in this document BFD - Bidirectional Forwarding Detection FSM - Finite State Mechaine 5. Echo BFD Support for echo BFD is outside the scope of this document. 6. IANA Considerations This specification has no IANA action requested. This section may be deleted before the publication. 7. Security Consideration Other than concerns raised in BFD [RFC5880], BFD FSM health status [draft-bfd-fsm-health-status] has no new concerns with this proposal. 8. Contributor Palpandi Perumal (Pluribus Networks) 9. Reference: 9.1 Normative Reference [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . Authors' Addresses Palpandi Perumal Pluribus Networks Bangaluru, India Email: palpandi9891@gmail.com Palpandi Perumal Expires April 14, 2021 [Page 4] ---------------------------------------------------------------------- Internet-Draft BFD FSM health status October 13, 2020