Found 3 records.

Status: Verified (1)

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Errata ID: 2530
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mach Chen
Date Reported: 2010-09-24
Verifier Name: Adrian Farrel
Date Verified: 2010-09-26

Section 4.3 says:

Sequence Number

      The sequence number for this packet.  For Keyed MD5
      Authentication, this value is incremented occasionally.  For
      Meticulous Keyed MD5 Authentication, this value is incremented for
      each successive packet transmitted for a session.  This provides
      protection against replay attacks.

It should say:

Sequence Number

      The sequence number for this packet.  For Keyed MD5
      Authentication, this value is incremented (by one) occasionally.  For
      Meticulous Keyed MD5 Authentication, this value is incremented by one for
      each successive packet transmitted for a session.  This provides
      protection against replay attacks.

Notes:

This change clarifies the amount by which the sequence number is incremented.

Status: Held for Document Update (2)

RFC 5880, "Bidirectional Forwarding Detection (BFD)", June 2010

Errata ID: 5205
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Katz
Date Reported: 2017-12-14
Held for Document Update by: Alvaro Retana
Date Held: 2018-03-14

Section 6.8.4 says:

If Demand mode is not active, and a period of time equal to the
Detection Time passes without receiving a BFD Control packet from the
remote system, and bfd.SessionState is Init or Up, the session has
gone down -- the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired).

It should say:

If Demand mode is not active, and a period of time equal to the
Detection Time passes without receiving a BFD Control packet from the
remote system, the session has
gone down -- the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired).

Notes:

This is based on an email I received from Anil Kumar of Nokia (anil.kumar_t_v@nokia.com).

The language as originally written made a session timeout a no-op when in Down state. This was a gratuitous attempt to avoid a null state transition, but had the side effect of not setting the diag code (and otherwise is no different).

This turns out to be problematic in the case where system "A" signals AdminDown, causing system "B" to respond with Down state. If the link then fails, the existing verbiage implies that "B" will not report the detection timeout, even locally.

If the link fails in a unidirectional manner (such that "B" is deaf), B will give no indication of a timeout in its outgoing Control packets back to A (which can in fact hear them).

Making the suggested change should ensure that the diagnostic code is always set to Detection Time Expired when Control packets stop arriving, even if the far end system was previously reporting AdminDown.

Errata ID: 4410
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2015-07-07
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16

Section 6.8.4 says:

If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set), the session
has gone down

It should say:

If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set),and without 
receiving a BFD Control packet with the Final (F) bit set from the
remote system, the session has gone down

Notes:

If has received BFD Control packet with the Final (F) bit set from the
remote system, the session will not gone down

Report New Errata