Subject: RE: Question on bfd.LocalDiag variable

From: Binny Jeshan <[email-masked]>
Date: Thu, 10 Oct 2013 08:37:07 +0530

Failures recognized by BFD are communicated to peers through diagnostic codes, and not meant for all state transitions. And IMU, diagnostic codes reflect failure conditions.

Regards,
Binny.
----------
Aricent Group, India.

Sent from Nokia Lumia.

-----Original Message-----
From: "Dave Katz" <[email-masked]>
Sent: ‎09-‎10-‎2013 10:47 PM
To: "Evgeny Sandler" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Question on bfd.LocalDiag variable

The intent was to record the reason for the last session failure (the Up->Down transition) and preserve it so there is a bit of state available in the protocol--since the protocol is inherently unreliable (running over UDP), repeatedly sending the diagnostic provides a crude form of reliability for it.  

The description of the field is, well, underspecified.

Note also:

   This section discusses the normative requirements of the protocol in
   order to achieve interoperability.  It is important for implementors
   to enforce only the requirements specified in this section, as
   misguided pedantry has been proven by experience to affect
   interoperability adversely.

In other words, it's best to not do what's not in the spec…

--Dave

On Oct 9, 2013, at 6:07 AM, Evgeny Sandler <[email-masked]> wrote:

Dear colleague,
 
I have a question regarding the role of Diagnostic Code state variable in BFD protocol.
 
Section 6.8.1 "State Variables" says:
 
    bfd.LocalDiag
 
      The diagnostic code specifying the reason for the most recent
      change in the local session state.  This MUST be initialized to
      zero (No Diagnostic).<<--- The “most recent change” is explicitly mentioned here
 
Section 6.8.4 "Calculating the Detection Time" 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).   <<--- Change in bfd.LocalDiag
 
Section 6.8.6 "Reception of BFD Control Packets" says:
 
    If bfd.SessionState is AdminDown           Discard the packet       If received state is AdminDown          If bfd.SessionState is not Down              Set bfd.LocalDiag to 3 (Neighbor signaled                  session down)              Set bfd.SessionState to Down       Else           If bfd.SessionState is Down              If received State is Down                  Set bfd.SessionState to Init <<--- No change in bfd.LocalDiag              Else if received State is Init                  Set bfd.SessionState to Up <<--- No change in bfd.LocalDiag           Else if bfd.SessionState is Init              If received State is Init or Up                  Set bfd.SessionState to Up <<--- No change in bfd.LocalDiag           Else (bfd.SessionState is Up)              If received State is Down                  Set bfd.LocalDiag to 3 (Neighbor signaled session down) <<--- Change in bfd.LocalDiag                  Set bfd.SessionState to Down
 
I.e.:
·         If the session goes Down-->Init-->Up immediately after creation, bfd.LocalDiag would be 0 (because it has been initialized to 0 and not changed after that)
·         But if the session that has been Up goes Up -->Down for any reason and then recovers Down-->Init-->Up the value of bfd.localDiag that has specified the reason for the last going Up-->Down will be preserved.
 
We would like to know if bfd.LocalDiag value should be set for each session state transition or only for state transition from Up/Init to Down?
 
Regards,
 
Evgeny Sandler
System Engineer
Network Solutions Division
ECI Telecom
Tel: +972-3-9266031
 
This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Oct 2013 13:20:35 -0400

> Failures recognized by BFD are communicated to peers through diagnostic codes, and not meant for all state transitions. And IMU, diagnostic codes reflect failure conditions.

And has been commmented upon elsewhere, the diag code may be very short
lived in some circumstances.  Doing anything with it beyond using it for
user diagnostic feedback is ill-advised.

-- Jeff