Re: Small LC Comment on bfd-base-07

[David Ward <[e-mail]>]

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