Subject: Small LC Comment on bfd-base-07

From: Carlos Pignataro <[email-masked]>
Date: Wed, 13 Feb 2008 16:53:45 -0500

Hi,

A quick comment on a possible small inconsistency that was brought up in 
pwe3: In concatenated paths/iw, the Diag can have values of 6/8 without 
the Session State being (Admin)Down:

http://tools.ietf.org/html/draft-ietf-bfd-base-07#section-6.8.17

    Two diagnostic codes are defined for this purpose:  Concatenated Path
    Down and Reverse Concatenated Path Down.
...
    A system MAY signal one of these failure states by simply setting
    bfd.LocalDiag to the appropriate diagnostic code.  Note that the BFD
    session is not taken down.  If Demand mode is not active on the
    remote system, no other action is necessary, as the diagnostic code
    will be carried via the periodic transmission of BFD Control packets.

But the definition of Diag (and bfd.LocalDiag) says (or implies) that 
there needs to be a state change to Down or AdminDown:

     Diagnostic (Diag)

        A diagnostic code specifying the local system's reason for the
        last session state change to states Down or AdminDown.

        bfd.LocalDiag

           The diagnostic code specifying the reason for the most recent
           local session state change to states Down or AdminDown.

Thanks,

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: Dave Katz <[email-masked]>
Date: Thu, 14 Feb 2008 10:16:31 -0800

Good catch.  The Diag field has morphed over the long lifetime of BFD,  
and the language about Down/AdminDown has obviously been overtaken by  
events.  We'll have to wordsmith some vague language that points out  
that the Diag field says something about the last event of interest  
other than the session coming up.

--Dave

On Feb 13, 2008, at 1:53 PM, Carlos Pignataro wrote:

> Hi,
>
> A quick comment on a possible small inconsistency that was brought  
> up in pwe3: In concatenated paths/iw, the Diag can have values of  
> 6/8 without the Session State being (Admin)Down:
>
> But the definition of Diag (and bfd.LocalDiag) says (or implies)  
> that there needs to be a state change to Down or AdminDown:
>
>    Diagnostic (Diag)
>

---

From: David Ward <[email-masked]>
Date: Thu, 14 Feb 2008 12:33:51 -0600

Vague language is also good if we need to add new/more diags and not  
be "trapped."

-DWard

On Feb 14, 2008, at 12:16 PM, Dave Katz wrote:

> Good catch.  The Diag field has morphed over the long lifetime of  
> BFD, and the language about Down/AdminDown has obviously been  
> overtaken by events.  We'll have to wordsmith some vague language  
> that points out that the Diag field says something about the last  
> event of interest other than the session coming up.
>
> --Dave
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 14 Feb 2008 14:49:38 -0500

> Vague language is also good if we need to add new/more diags and not  

I think this may be less dire than you're implying.

Consider the case where a session not in one of the down states always
resets the Diagnostic to 0 when not in an error state.  In order for the
session to be reset, you must also reset to the down state.  In the mean
time, you've had the opportunity to pull the current Diagnostic off the
wire.  The BFD protocol itself need not necessarily cache this, but the
management infrastructure probably should as part of the "I'm down!"
callback.

Thus, for example, the MIB could have a bfdSessDiagLastDown object along
with the bfdSessDiag object which would represent the current diag value
in the protocol.  Trap objects become slightly more interesting because
they'd might want to represent a transition out of diagnostic state 0
and potentially back.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 14 Feb 2008 14:54:28 -0500

> Thus, for example, the MIB could have a bfdSessDiagLastDown object along

Tom and Zafar had already caught this:
bfdSessPerfLastCommLostDiag

-- Jeff