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,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
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