Re: Between schedule transmissions

[Dave Katz <[e-mail]>]

The loop is persistent only if you can guarantee that one system will 
always send two packets prior to receiving one from the other guy.  
This guarantee is hard to make unless the implementation always 
explicitly sends two packets back-to-back (and if an implementation 
does this, your suggestion will not change the outcome.)

Everything after that is probabilistic.  If this situation occurs, one 
side will time out of Init state and try again.  Then the dice are 
rolled once more.

The change you suggest may reduce the odds of this occurring somewhat, 
although it is worth noting that it is the "extra" packet that causes 
the problem in the first place, and additional "extra" packets may 
exacerbate the situation instead.  Note also that as the latency on the 
link increases, your change is less likely to work, as it is predicated 
on the opposite case, namely that exactly one packet is guaranteed to 
be sent, and one sent in return (a round trip time), prior to the 
second packet being sent.

The sedate rate at which packets are sent when the session isn't Up 
helps improve the odds as well.

I think there is no way out of this conundrum, particularly if the 
packet transmit rates are different on each side (getting rid of the 
"extra" packets entirely wouldn't even help.)  Distributed state 
establishment is a sloppy business.

One thing you point out is that the text is not clear as to when the 
state variables are to be initialized;  the answer is that they are 
initialized once when the session is created, and never again (the 
protocol machinery will tinker with the state as necessary as the 
session goes up and down.)  I'll add a little text to that effect.

--Dave


On Feb 22, 2005, at 5:10 PM, [e-mail] wrote:

> In the case of state transitions from 'Down to Up or Init', and from 
> 'Up to Failing' it is obvious that a BFD packet should be sent 
> immediately (rather than waiting for the next scheduled transmission) 
> because the IHY variable changes. However, what about state changes 
> form 'Init to Up' and 'Failing to Down' where the IHY doesn't change? 
> Do these result in BFD packets being sent immediately, or does the 
> system wait until the next scheduled transmission? The answer to this 
> question may be dependant on the bfd.LocalDiag field, the draft states 
> that bfd.LocalDiag MUST be initialised to zero, and describes when it 
> should be changed to reflect failure conditions. However, there is no 
> information (or at least I can't find any) regarding when 
> bfd.LocalDiag should be reset to 0.