Re: Reflections on new state machine

[Dave Katz <[e-mail]>]

On Mar 24, 2005, at 9:23 AM, Chris Nogradi wrote:

> Dave,
>
> section 6.7.6 of the new base document (v2) reads:
>
>       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 AdminDown
>               Discard the packet
>
> shouldn't the local state remain AdminDown even if the received state 
> is AdminDown?

Yep, good point.  If both sides are AdminDown they should stay there.  
The intent is that AdminDown is an administrative state and is 
"clamped" there until administrative action is taken to exit it.  I'll 
make this more explicit.

>
> Two other observations:
> 1. we remain indefinitely in the init state if peer keeps sending down 
> state since packet is not discarded and timer is reset

This is true;  this should only happen if there is one-way 
communication.  The net result is that the session doesn't come up, 
which is the intent.  There's no magic about the difference between 
Down and Init operationally.

> 2. we remain in the up state if the peer keeps sending init state 
> since packet is not discarded and timer is reset

This can only happen if the peer is broken, since the peer cannot stay 
in init state indefinitely if properly implemented.  If the peer hears 
you sending Up, he must go Up.  If he's not hearing you, he times out 
and goes Down.  So this scenario can only happen for a Detection Time, 
and only if communications goes one-way during session establishment, 
which is what you'd expect.


--Dave