Subject: BFD questions

From: Dave Katz <[email-masked]>
Date: Wed, 1 Oct 2003 10:13:01 -0700

> On Wednesday, Oct 1, 2003, at 07:57 US/Pacific, Phelan, Tom wrote:
>
>> Hi Dave,
>>
>> I have some questions about BFD:
>>
>> When you aren't in the UP state, bfd.DesiredMinTxInterval MUST be at 
>> least
>> one second.  To get sub-second failure detections, then, you need to 
>> change
>> bfd.DesiredMinTxInterval when you enter the UP state.  Does that 
>> change mean
>> you need to send a control packet with the P bit set (a la section 
>> 6.5.3)?
>> In other words, for a transition into UP, do you routinely send a 
>> control
>> packet with the P bit set?
>
> Yes.
>
>>
>> The same thing seems to apply to transitions from UP.
>> bfd.DesiredMinTxInterval needs to be reset to one second.  Do you 
>> routinely
>> send a poll when exiting UP state?
>
> Hm, good question.  As the spec reads now, the transmit rate will 
> never slow down if the neighbor simply goes away, since it will never 
> receive a packet with the Final bit.  This should be gated by the 
> session being in Up state, since the whole point of the exercise is to 
> not drop an active session when the parameters are changing (but if 
> it's already down it doesn't matter.)
>
>>
>> About P/F operation - When you're polling in the UP state, it seems 
>> to me
>> that you want to timeout and go to FAILING if you don't receive an F 
>> bit
>> within the detection timeout.  However, in section 6.5.6, the 
>> detection
>> timer is restarted for each valid control packet, regardless of the 
>> setting
>> of the F bit.  Is this what you intend?  If so, does that imply an
>> additional, unmentioned, timer for poll response timeout?
>
> This would mean that the implementation is badly broken, since the 
> other side MUST eventually reply with F.  The problem with timing it 
> out is that you don't know how long to wait--it may take many packets 
> if the interval is small and the round-trip time is high.  (I've 
> already got a couple of places that say "must be greater than the RTT" 
> and don't want to add any more, since it's arbitrarily difficult to 
> determine.)  It also adds more complexity to the spec, which I'm 
> trying to avoid.  In general, it is impossible to diagnose all ways in 
> which an implementation can be broken.
>
>>
>> When one side is active and the other passive:  Both initialize to the
>> FAILING state, the active side sends packets with H=0.  When the 
>> passive
>> side receives a packet, it can begin sending control packets of its 
>> own
>> (section 6.1), and moves to the DOWN state (section 6.5.6).  The 
>> natural
>> thing is for the passive side to set H=1 (after all, it started 
>> transmitting
>> because it heard the active side).  But the active side will only 
>> leave
>> FAILING if H=0 (section 6.5.6), and therefore the session won't come 
>> UP.
>> You seem to be in the same situation when both sides are active and 
>> one
>> side's initial packet is lost.  Have I missed something?
>
> The missing link is the fact that the detection timer starts to run as 
> soon as you enter Init state.  If the first packet is lost, eventually 
> the guy in Init state will time out and fall back to Failing and 
> things will work.
>
>
> Thanks for the excellent feedback--I've gotten very little thusfar.
>
> --Dave
>
>

---

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 1 Oct 2003 15:27:41 -0400

Hi Dave,

> Receiving the F bit also allows you to actually change the timing 
> parameters to the ones you're advertising;  in the mean time you 
> advertise the new interval but continue to actually use the old one.

Oh.  Thanks for the clarification.

As new questions come up, I'll ask them :-).

Tom P.