Subject: RE: BFD questions

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 1 Oct 2003 13:42:22 -0400

Hi Dave,

See inline ...

Tom P.

> -----Original Message-----
> From: Dave Katz [mailto:[email-masked]]
> Sent: Wednesday, October 01, 2003 1:06 PM
> To: Phelan, Tom
> Cc: Dave Katz
> Subject: Re: BFD questions
> 
> 
> 
> 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.

What I get from this is, you shouldn't exit the Up state just because you
haven't received an F bit, but have continued to receive otherwise valid
control packets.  In other words, all receiving an F bit does is stop you
from continuing to send P bits.  Never receiving an F bit has no real effect
on the session.  I think this is what the spec says, I just didn't consider
the RTT problem.

What I also get from this and the above statement is that you should only
start polling during the Up state - it's the only time you have a reasonable
chance of getting an F bit response.  Polling in other states is probably
fruitless.

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

I think I see what I missed.  You can't send H=1 because of a packet
received in the Failing state.  The normal process with two active ends
coming up more-or-less together is:

Side one starts, enters Failing, sends H=0.
Side two isn't up yet, so packet is lost.
Side two starts, enters Failing, sends H=0.
Side one receives, enters Down, sends H=0 even though is does hear other
side, because packet received in Failing.
Side two receives, enters Down, sends H=0 as above.
Side one receives, enters Init, sends H=1.
Side two receives, enters Up, sends H=1.
Side one receives, enters Up.

The missing piece for me was the rule "You can't send H=1 because of a
packet received in Failing state".  That might need to be spelled out to
avoid other mistakes :-).

> 
> 
> Thanks for the excellent feedback--I've gotten very little thusfar.
> 
> --Dave
>

---

From: Dave Katz <[email-masked]>
Date: Wed, 1 Oct 2003 11:12:47 -0700

> on the session.  I think this is what the spec says, I just didn't 

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.

> chance of getting an F bit response.  Polling in other states is 

Yep, I think that's going to be the change.  I need to think a bit more.

> avoid other mistakes :-).

That's pretty much it.  The spec says to set bfd.RemoteHeard to 1 when 
you receive a control packet in Down state (causing subsequent packets 
to go out with H=1) and since you cannot be in down state without 
receiving an H=0 packet in Failing state, this is effectively the case.

I think the spec is unambiguous, if not totally obvious.  I could add 
more nonnormative descriptive text in 6.1 if you think it really 
necessary.

--Dave