Re: [Errata Held for Document Update] RFC5880 (5205)

[Ashesh Mishra <[e-mail]>]

If the BFD session is administratively down then, in my opinion, it should not report any other state. The admin asked it not to do anything else. While there may be loss of connectivity in the admin-down period, it may have been planned. When the admin wants monitoring of the link again and marks the session admin up, then the session should try and re-establish and will fail if the link is down ... with a Detection Time Expired message. But this should happen only when the session is admin-up. 

Thoughts, comments?

Ashesh 

-----Original Message-----
From: Rtg-bfd <[e-mail]> on behalf of RFC Errata System <[e-mail]>
Date: Wednesday, March 14, 2018 at 3:28 PM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [Errata Held for Document Update] RFC5880 (5205)

    The following errata report has been held for document update 
    for RFC5880, "Bidirectional Forwarding Detection (BFD)". 
    
    --------------------------------------
    You may review the report below and at:
    http://www.rfc-editor.org/errata/eid5205
    
    --------------------------------------
    Status: Held for Document Update
    Type: Technical
    
    Reported by: Dave Katz <[e-mail]>
    Date Reported: 2017-12-14
    Held by: Alvaro Retana (IESG)
    
    Section: 6.8.4
    
    Original Text
    -------------
    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).
    
    Corrected Text
    --------------
    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 ([e-mail]).
    
    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.
    
    --------------------------------------
    RFC5880 (draft-ietf-bfd-base-11)
    --------------------------------------
    Title               : Bidirectional Forwarding Detection (BFD)
    Publication Date    : June 2010
    Author(s)           : D. Katz, D. Ward
    Category            : PROPOSED STANDARD
    Source              : Bidirectional Forwarding Detection
    Area                : Routing
    Stream              : IETF
    Verifying Party     : IESG