Re: Small LC Comment on bfd-base-07

[Dave Katz <[e-mail]>]

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:
>
> 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
>
>