Re: BFD State Machine

[Dave Katz <[e-mail]>]

On Mar 3, 2005, at 12:07 PM, Chris Nogradi wrote:

> Dave,
>
> Since all implementations of BFD that I have observed use a one packet 
> per
> second sedate rate, I never noticed the fact that the draft specified 
> this as
> the MINIMUM interval.   If fact when you described a possible solution 
> for
> the deadlock, requiring the Desired TX and Required RX to match during
> negotiations, the thought occurred to me that you were suggesting that 
> the
> Required RX value should be used during negotiations. For instance, 
> suppose
> that an implementation uses a one second sedate rate but the peer
> implementation is advertising a three second Required RX value. Should 
> this
> Required RX value be used instead of the one second interval during
> negotiations?

Yes, the parameters always apply, even during session bringup.  In the 
case you specify, the local transmitter would be required to send at 3 
second intervals.

My workaround hack ensures that, during session bringup, both sides are 
transmitting at the same rate (since each side advertises the same 
value for TX and RX, then they will converge on the larger value and 
both will transmit at that rate.)  But that's overtaken by events now;  
the new state machine is much cleaner, I think (though the silence has 
been deafening thus far.)

>  I suppose that since the peer's Desired Tx/Multiplier pair is
> used to determine the detection time used during the negotiation while 
> in the
> init state, the Required RX time should also be honored during this 
> time.

Yes, all the timing parameters and procedures apply at all times.

>   I
> guess the confusion arises from the fact that when the session is being
> negotiated, the time values are used without requiring a poll sequence
> (poll/final).  However, when the session is up, timer value changes 
> must be
> communicated using a poll sequence (poll/final).

Hmm, this is not the case;  if the spec is confusing on that aspect, 
please let me know what led you to that conclusion.  It is true that a 
true Demand Mode Poll Sequence requires you to be in Up state, but the 
verbiage in 6.7.3 talks about what to do when Demand Mode is not active 
(which it would not be during session establishment.)  I should 
probably point out in the text that this applies at all times, though 
it is less of an issue in session establishment, since the session is 
already down (the mechanism is designed to avoid dropping the session 
if the parameters change on the fly.)  It's also the case that the 
advertised values are unlikely to change during session bringup, except 
during the transition to Up state.

>
> BTW, assuming that an original draft implementation uses a fixed 
> sedate rate,
> it would seem that it would not run into the deadlock problem unless 
> it has
> to interoperate with an implementation using a different rate.  Is 
> this true?

There should be no permanent deadlock condition, yes.  You may run into 
probabilistic difficulties (recoverable from the timer firing in Init 
state) but it should eventually come up.  However, I am pushing hard 
for completely deprecating the original version.  I've already worked 
up the spec changes, and they're really quite minor.  It would be a 
Really Good Idea to not ship version 0, to avoid having to deal with 
compatibility issues (at least I'm the one suffering the most by this, 
so there is justice after all.)

--Dave