Subject: Timer Manipulation

From: "Avi Ezra" <[email-masked]>
Date: Thu, 3 Jul 2008 08:49:58 +0300

Hi
I have a question regarding the BFD protocol,
In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt 
section 6.8.3 Timer Manipulation written:
 
When bfd.SessionState is not Up, the system MUST set
   bfd.DesiredMinTxInterval to a value of not less than one second
   (1,000,000 microseconds.)  This is intended to ensure that the
   bandwidth consumed by BFD sessions that are not Up is negligible,
   particularly in the case where a neighbor may not be running BFD.
 
Please follow this scenario:
1. The Timer Negotiation is finished and the DesireMinTXInterval set to 10 ms in both direction
2. The session is already  in Up  state  for long time
3. There is a failure in the line and the session state goes to Down state 
 
My question is:
Do I have to set the DesireMinTXInterval to one second again and to send BFD messages in one second interval?
or can I continue to send BFD messages in 10 ms interval in order to get fast detection of the line recovery 
 
Best Regards
Avi Ezra

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 00:00

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 03 Jul 2008 12:43:44 -0700

Hi Avi,

Once the BFD session goes DOWN (or even to INIT), you need to set the BFD
messages to 1sec. interval
The BFD failure could be do to tons of reasons  BFD being deconfigured on
peer router for instance.

One should not continue to send packets at 10ms interval....since in DOWN
state one doesn¹t know at what rate
the peer wants to accept packets at.

Fast failure detection is only possible when the BFD session is UP. I see
your point that there is a small time between
the time when the BFD session comes UP and the time the intervals are reset
to 10ms (from 1sec)  and one won¹t get fast failure detection
in that  interval, but I think that¹s too much of a corner case to be
worried about.

You can try optimizing these corner cases with not resetting the interval,
but it might start having other side-effects.

Thanks
Nitin

---

From: "Avi Ezra" <[email-masked]>
Date: Sun, 6 Jul 2008 07:55:16 +0300

Hi Nitin
Thank you for your answer
 
My point is to achieve fast detection of the RECOVERY of the line.
If I'll go to 1 sec. interval I'll achieve fast failure detection but very slow detection of the recovery
 
Thanks
Avi 

   _____  

From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 10:44 PM
To: Avi Ezra; [email-masked]
Subject: Re: Timer Manipulation 

Hi Avi,

Once the BFD session goes DOWN (or even to INIT), you need to set the BFD messages to 1sec. interval 
The BFD failure could be do to tons of reasons – BFD being deconfigured on peer router for instance.

One should not continue to send packets at 10ms interval....since in DOWN state one doesn’t know at what rate
the peer wants to accept packets at.

Fast failure detection is only possible when the BFD session is UP. I see your point that there is a small time between
the time when the BFD session comes UP and the time the intervals are reset to 10ms (from 1sec)  and one won’t get fast failure detection 
in that  interval, but I think that’s too much of a corner case to be worried about.

You can try optimizing these corner cases with not resetting the interval, but it might start having other side-effects.

Thanks
Nitin

Hi

My question is:

Best Regards
Avi Ezra

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: 03/07/2008 00:00

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: 05/07/2008 10:15

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 14 Jul 2008 01:06:39 -0700

Hello Avi.
 
Another point to consider is that if you allow BFD session to flap
(UP->DOWN->UP) too fast, you maybe triggering two route convergences in
a very short period of time.
 
    - UP-> DOWN - Routes converge away from failed link.
    - DOWN -> UP - Routes converge back to original.
 
That could cause quite lot of churn at both system and network level,
worse if the flapping continues.
 
Thanx,
Nobo

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Ezra
	Sent: Sunday, July 06, 2008 1:55 PM
	To: Nitin Bahadur; [email-masked]
	Subject: RE: Timer Manipulation 

	Hi Nitin
	 
	My point is to achieve fast detection of the RECOVERY of the
line.
	If I'll go to 1 sec. interval I'll achieve fast failure
detection but very slow detection of the recovery
	 
	Thanks
	Avi 

________________________________

	Hi Avi,
	
	Once the BFD session goes DOWN (or even to INIT), you need to
set the BFD messages to 1sec. interval 
	The BFD failure could be do to tons of reasons - BFD being
deconfigured on peer router for instance.
	
	One should not continue to send packets at 10ms
interval....since in DOWN state one doesn't know at what rate
	the peer wants to accept packets at.
	
	Fast failure detection is only possible when the BFD session is
UP. I see your point that there is a small time between
	the time when the BFD session comes UP and the time the
intervals are reset to 10ms (from 1sec)  and one won't get fast failure
detection 
	in that  interval, but I think that's too much of a corner case
to be worried about.
	
	You can try optimizing these corner cases with not resetting the
interval, but it might start having other side-effects.
	
	Thanks
	Nitin

		Hi
		I have a question regarding the BFD protocol,
		In Bidirectional Forwarding Detection
draft-ietf-bfd-based-08.txt 
		section 6.8.3 Timer Manipulation written:
		
		When bfd.SessionState is not Up, the system MUST set
		   bfd.DesiredMinTxInterval to a value of not less than
one second
		   (1,000,000 microseconds.)  This is intended to ensure
that the
		   bandwidth consumed by BFD sessions that are not Up is
negligible,
		   particularly in the case where a neighbor may not be
running BFD.
		
		Please follow this scenario:
		1. The Timer Negotiation is finished and the
DesireMinTXInterval set to 10 ms in both direction
		2. The session is already  in Up  state  for long time
		3. There is a failure in the line and the session state
goes to Down state 
		
		My question is:
		Do I have to set the DesireMinTXInterval to one second
again and to send BFD messages in one second interval?
		or can I continue to send BFD messages in 10 ms interval
in order to get fast detection of the line recovery 
		
		Best Regards
		Avi Ezra

		No virus found in this outgoing message.
		Checked by AVG.
		Version: 7.5.524 / Virus Database: 270.4.3 - Release
Date: 28/06/2008 00:00

	No virus found in this incoming message.
	Checked by AVG.
	Version: 7.5.524 / Virus Database: 270.4.5 - Release Date:
03/07/2008 00:00

	No virus found in this outgoing message.
	Checked by AVG.
	Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date:
05/07/2008 10:15

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Jul 2008 14:44:16 +0300

Avi, Nobo and all,
I concur with Nobo's comment. It is quite customary to stabilize DOWN-->UP transitions in order to prevent flapping.

Regards,
    Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Monday, July 14, 2008 11:07 AM
To: Avi Ezra; Nitin Bahadur; [email-masked]
Subject: RE: Timer Manipulation

Hello Avi.

Another point to consider is that if you allow BFD session to flap (UP->DOWN->UP) too fast, you maybe triggering two route convergences in a very short period of time.

That could cause quite lot of churn at both system and network level, worse if the flapping continues.

Thanx,
Nobo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Avi Ezra

Hi Nitin

Thanks
Avi

Hi Avi,

Once the BFD session goes DOWN (or even to INIT), you need to set the BFD messages to 1sec. interval
The BFD failure could be do to tons of reasons - BFD being deconfigured on peer router for instance.

One should not continue to send packets at 10ms interval....since in DOWN state one doesn't know at what rate
the peer wants to accept packets at.

Fast failure detection is only possible when the BFD session is UP. I see your point that there is a small time between
the time when the BFD session comes UP and the time the intervals are reset to 10ms (from 1sec)  and one won't get fast failure detection
in that  interval, but I think that's too much of a corner case to be worried about.

Thanks
Nitin

Hi

My question is:

Best Regards
Avi Ezra

---

From: "Nakamoto, Glen" <[email-masked]>
Date: Mon, 14 Jul 2008 09:17:52 -0400

We have an application where we are simulating two radios (with
different transceiver characteristics) on a mobile platform where rapid
flapping may be a desired trait (however, this is very much localized
to prevent spread).  In our scenario, we are using static routes (one
high and the other low) to traverse this RF chasm.  We are working on
the assumption that one of the two radios will be available close to
100% of the time even though a single radio can be interrupted
regularly (due to obstructions such as buildings or trees).  Our model
has a preferred path (lower cost $$) and a secondary path ($$/byte).
As such we would like to use the preferred path as much as possible and
only use the secondary path when the preferred path is unavailable.  We
have coded up a Linux box with BFD that talks to the RF side and when
the signal is about to cut, we "shut down" the BFD with the Cisco
router (which uses the higher cost static route to the other radio in
about 150 ms (3 X 50 ms).  While we haven't done so yet, we also plan
on sending a signal to the other peer Linux box to inform them that we
are doing the switch.  When the preferred path signal is good for some
time period (TBD), we reactivate the BFD (Linux box talking to Cisco)
and the router switches back in 10 ms (preferred path goes UP).  We can
switch back and forth very rapidly (every few seconds or less) and
maintain a fairly stable communication link between the two radio
links.  Even when terminated abruptly (pull the plug so to speak), we
lose about 15 packets (at 1.5 Mbps) vice thousands if waiting on
optimized OSPF to detect the failure.  We are still trying to figure
out if we can "drop" the link in 50 ms or less (rather than the 3
failures of 50 ms).  This is a very specialized situation (and somewhat
constrained) and I wouldn't recommend it in general but it does seem to
work (so far) in our experiments in rapid detection and recovery for
mobile platforms that support multihoming.  We are currently looking at
other "failure" modes to see what other troubles we may get into.  If
anyone has been doing any work with BFD in mobile situations, I would
appreciate any feedback.

Glen ...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexander Vainshtein
Sent: Monday, July 14, 2008 7:44 AM
To: Nobo Akiya (nobo); Avi Ezra
Cc: [email-masked]
Subject: RE: Timer Manipulation 

Avi, Nobo and all,
I concur with Nobo's comment. It is quite customary to stabilize
DOWN-->UP transitions in order to prevent flapping.
 
Regards,
    Sasha

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
	Sent: Monday, July 14, 2008 11:07 AM
	To: Avi Ezra; Nitin Bahadur; [email-masked]
	Subject: RE: Timer Manipulation 

	Hello Avi.
	 
	Another point to consider is that if you allow BFD session to
flap (UP->DOWN->UP) too fast, you maybe triggering two route
convergences in a very short period of time.

	That could cause quite lot of churn at both system and network
level, worse if the flapping continues.
	 
	Thanx,
	Nobo

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Avi Ezra
		Sent: Sunday, July 06, 2008 1:55 PM
		To: Nitin Bahadur; [email-masked]
		Subject: RE: Timer Manipulation 

		Hi Nitin
		 
		My point is to achieve fast detection of the RECOVERY
of the line.
		If I'll go to 1 sec. interval I'll achieve fast failure
detection but very slow detection of the recovery
		 
		Thanks
		Avi 

		Hi Avi,
		
		Once the BFD session goes DOWN (or even to INIT), you
need to set the BFD messages to 1sec. interval 
		The BFD failure could be do to tons of reasons - BFD
being deconfigured on peer router for instance.

		Fast failure detection is only possible when the BFD
session is UP. I see your point that there is a small time between
		the time when the BFD session comes UP and the time the
intervals are reset to 10ms (from 1sec)  and one won't get fast failure
detection 
		in that  interval, but I think that's too much of a
corner case to be worried about.
		
		You can try optimizing these corner cases with not
resetting the interval, but it might start having other side-effects.
		
		Thanks
		Nitin

			Hi
			
			When bfd.SessionState is not Up, the system
MUST set
			   bfd.DesiredMinTxInterval to a value of not
less than one second
			   (1,000,000 microseconds.)  This is intended
to ensure that the
			   bandwidth consumed by BFD sessions that are
not Up is negligible,
			   particularly in the case where a neighbor
may not be running BFD.
			
			Please follow this scenario:
			1. The Timer Negotiation is finished and the
DesireMinTXInterval set to 10 ms in both direction
			2. The session is already  in Up  state  for
long time
			3. There is a failure in the line and the
session state goes to Down state 
			
			My question is:
			Do I have to set the DesireMinTXInterval to one
second again and to send BFD messages in one second interval?
			or can I continue to send BFD messages in 10 ms
interval in order to get fast detection of the line recovery 
			
			Best Regards
			Avi Ezra

			No virus found in this outgoing message.
			Checked by AVG.
			Version: 7.5.524 / Virus Database: 270.4.3 -
Release Date: 28/06/2008 00:00

		No virus found in this incoming message.
		Checked by AVG.
		Version: 7.5.524 / Virus Database: 270.4.5 - Release
Date: 03/07/2008 00:00

		No virus found in this outgoing message.
		Checked by AVG.
		Version: 7.5.524 / Virus Database: 270.4.5/1536 -
Release Date: 05/07/2008 10:15

---

From: Dave Katz <[email-masked]>
Date: Mon, 14 Jul 2008 17:47:45 -0600

Note that the spec explicitly allows for rapid exchange of BFD packets  
if the contents are changing (typically state transitions)--see  
section 6.8.7.  There is nothing in the spec blocking the rapid  
reestablishment of a BFD session.

As others have mentioned, the point of slowing down the transmit  
interval is to not spew BFD packets when the other guy is dead, or has  
BFD turned off, etc.  Sending BFD packets at 10 msec intervals  
indefinitely after a session failure would be a bad thing.

--Dave

On Jul 14, 2008, at 5:44 AM, Alexander Vainshtein wrote:

> Behalf Of Nobo Akiya (nobo)
> (UP->DOWN->UP) too fast, you maybe triggering two route convergences  
> in a very short period of time.
>
> Behalf Of Avi Ezra
> The BFD failure could be do to tons of reasons – BFD being  
> Fast failure detection is only possible when the BFD session is UP.  
> I see your point that there is a small time between
> the time when the BFD session comes UP and the time the intervals  
> are reset to 10ms (from 1sec)  and one won’t get fast failure  
> detection
> Do I have to set the DesireMinTXInterval to one second again and to  
> send BFD messages in one second interval?

---

From: "Avi Ezra" <[email-masked]>
Date: Thu, 17 Jul 2008 09:24:13 +0300

Hi
The BFD protocol concentrate in the detection of failure of the connection between the two ends, it gives us all the options to set the speed of failure detection, i.e Tx/Rx interval and Detect time multiplier.
BUT 
In other hand the protocol not gives us any option to determine the speed of recovery detection (MUST to resume with 1 second). 
Why not to give to the APPLICATION the decision how rapidly it want to detect the recovery of the line, It can be done by it decision to use this connection only after a receiving X times UP packets to prevent flapping. 
I'm not worry to spew BFD packets to a dead or turned off system in the same rate like I sent before the failure, it is not harm the system and it not harm the network since I did it few second ago in double rate (Tx packets from both ends), Just to mention that the packets rate determined by the capabilities of both ends and not by the network capability.
 
Some applications have no redundant path and when the session is Down there is no service, because of that I need to get the Up state very fast to resume the services even if I'll get some flaps.
 
...Avi
 
   _____  

From: Dave Katz [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 2:48 AM
To: Alexander Vainshtein
Cc: Nobo Akiya (nobo); Avi Ezra; [email-masked]
Subject: Re: Timer Manipulation 

Note that the spec explicitly allows for rapid exchange of BFD packets if the contents are changing (typically state transitions)--see section 6.8.7.  There is nothing in the spec blocking the rapid reestablishment of a BFD session. 

As others have mentioned, the point of slowing down the transmit interval is to not spew BFD packets when the other guy is dead, or has BFD turned off, etc.  Sending BFD packets at 10 msec intervals indefinitely after a session failure would be a bad thing.

--Dave

Avi, Nobo and all,
 
Regards,
    Sasha

   _____  

From: [email-masked] [HYPERLINK "mailto:[email-masked]"mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Monday, July 14, 2008 11:07 AM
To: Avi Ezra; Nitin Bahadur; HYPERLINK "mailto:[email-masked]"[email-masked]
Subject: RE: Timer Manipulation 

Hello Avi.

 
 
Thanx,
Nobo

   _____  

From: [email-masked] [HYPERLINK "mailto:[email-masked]"mailto:[email-masked]] On Behalf Of Avi Ezra
Sent: Sunday, July 06, 2008 1:55 PM
To: Nitin Bahadur; HYPERLINK "mailto:[email-masked]"[email-masked]
Subject: RE: Timer Manipulation 

Hi Nitin

Thanks
Avi 

   _____  

From: Nitin Bahadur [HYPERLINK "mailto:[email-masked]"mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 10:44 PM
To: Avi Ezra; HYPERLINK "mailto:[email-masked]"[email-masked]
Subject: Re: Timer Manipulation 

Hi Avi,

Thanks
Nitin

On 7/2/08 10:49 PM, "Avi Ezra" <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

Hi

My question is:

Best Regards
Avi Ezra

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: 12/07/2008 00:00

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: 12/07/2008 00:00

---

From: Dave Katz <[email-masked]>
Date: Thu, 17 Jul 2008 11:22:16 -0600

As I mentioned earlier, the one second transmit interval does not  
preclude rapid session establishment, so it shouldn't matter.

One of the driving design criteria for BFD was to make it self- 
stabilize when things go south.  Pretty much every large-scale network  
collapse of any sort (AOL '95, ATT SS7, MCI frame relay for 10 days,  
lots of others) ultimately had the same problem--the network put  
itself into a metastable failure condition that it couldn't recover  
from (not unlike ventricular fibrillation) because the underlying  
liveness detection ultimately could not compete with the flood of  
control traffic, which in turn caused even more control traffic, and  
in each case it took manual intervention to recover.

BFD tries to avoid this situation by allowing any participant in the  
protocol to control both the transmit and receive rates (in the hope  
of staving off failure) and additionally by automatically dropping the  
transmit rate if the session actually *does* fail.

This veteran of the trenches has seen way too many networks go under,  
and the pressure for faster detection times only makes it more likely  
to occur unless proper protocol mechanisms are in place.

Besides, not only can BFD come up quickly, but there's nothing to stop  
an implementation from using a link while BFD is in the process of  
coming up.  There is a risk of black holes for the amount of time it  
takes to determine that the link isn't really working.  And there is  
room for endless creativity in how BFD interacts with its clients.

In any case, this is an implementation issue, and not a protocol issue.

--Dave

On Jul 17, 2008, at 12:24 AM, Avi Ezra wrote:

> Hi
> The BFD protocol concentrate in the detection of failure of the  
> connection between the two ends, it gives us all the options to set  
> the speed of failure detection, i.e Tx/Rx interval and Detect time  
> multiplier.
> BUT
> In other hand the protocol not gives us any option to determine the  
> speed of recovery detection (MUST to resume with 1 second).
> Why not to give to the APPLICATION the decision how rapidly it want  
> to detect the recovery of the line, It can be done by it decision to  
> use this connection only after a receiving X times UP packets to  
> prevent flapping.
> I'm not worry to spew BFD packets to a dead or turned off system in  
> the same rate like I sent before the failure, it is not harm the  
> system and it not harm the network since I did it few second ago in  
> double rate (Tx packets from both ends), Just to mention that the  
> packets rate determined by the capabilities of both ends and not by  
> the network capability.
>
> Some applications have no redundant path and when the session is  
> Down there is no service, because of that I need to get the Up state  
> very fast to resume the services even if I'll get some flaps.
>
> ...Avi
>
> Note that the spec explicitly allows for rapid exchange of BFD  
> packets if the contents are changing (typically state transitions)-- 
> see section 6.8.7.  There is nothing in the spec blocking the rapid  
> interval is to not spew BFD packets when the other guy is dead, or  
> has BFD turned off, etc.  Sending BFD packets at 10 msec intervals  
>> (UP->DOWN->UP) too fast, you maybe triggering two route  
>> One should not continue to send packets at 10ms interval....since  
>> in DOWN state one doesn’t know at what rate
>> or can I continue to send BFD messages in 10 ms interval in order  
>> to get fast detection of the line recovery
>>
>> Best Regards
>> Avi Ezra
>>
>>
>>

---

From: "Nitin Bahadur" <[email-masked]>
Date: Thu, 17 Jul 2008 14:42:22 -0700

Behalf Of Dave Katz

Just to clarify what Dave is saying. Let's say A and B are peers and B
goes down. Consequently A goes into BFD Down state.

When B comes up, B immediately sends a BFD packet. On receipt of that
packet, A will immediately transition to Init state and should
immediately send a BFD packet (it doesn't have to wait for 1 second). On
receipt of packet from A, B will immediately change it's state and send
a packet (immediately) to A. Thus packets sent on state transitions DO
NOT have to wait for the 1 second. Thus the BFD session will come up
ASAP. I hope this clarifies things.

Nitin

---

From: Dave Katz <[email-masked]>
Date: Thu, 17 Jul 2008 21:01:21 -0600

Yep.  And note that the spec allows the extra packet to be sent when  
*any* of its contents change (other than the P/F bits) which can help  
some cases along.

This also works on initial session establishment.  On average there  
will be a delay of 250 msec between the point where the path becomes  
viable and one or the other end tries to send the next packet (which  
will bring the session up.)  If there is a datalink protocol running  
(like PPP) then BFD can be rigged to send the first packet as soon as  
the datalink comes up, reducing that 250 msec to nearly zero.

And don't forget that the total time budget has to include the link  
latency, which can be significant for long and/or slow paths and will  
put an upper bound on what's possible.

--Dave

On Jul 17, 2008, at 3:42 PM, Nitin Bahadur wrote:

> Just to clarify what Dave is saying. Let’s say A and B are peers and  
> B goes down. Consequently A goes into BFD Down state.
>
> When B comes up, B immediately sends a BFD packet. On receipt of  
> that packet, A will immediately transition to Init state and should  
> immediately send a BFD packet (it doesn’t have to wait for 1  
> second). On receipt of packet from A, B will immediately change it’s  
> state and send a packet (immediately) to A. Thus packets sent on  
> state transitions DO NOT have to wait for the 1 second. Thus the BFD  
> session will come up ASAP. I hope this clarifies things.
>
> Nitin

---

From: David Ward <[email-masked]>
Date: Thu, 17 Jul 2008 22:53:20 -0500

Note that good news (interface, etc UP) should travel through the  
system slowing and bad news (interface, etc DOWN) should be  
instantaneous. Be very careful optimizing bringing things up too  
quickly.

caveat emptor

-DWard

On Jul 17, 2008, at 10:01 PM, Dave Katz wrote:

> Yep.  And note that the spec allows the extra packet to be sent  
> when *any* of its contents change (other than the P/F bits) which  
> can help some cases along.
>
> will be a delay of 250 msec between the point where the path  
> becomes viable and one or the other end tries to send the next  
> packet (which will bring the session up.)  If there is a datalink  
> protocol running (like PPP) then BFD can be rigged to send the  
> first packet as soon as the datalink comes up, reducing that 250  
> msec to nearly zero.
>
> latency, which can be significant for long and/or slow paths and  
> will put an upper bound on what's possible.
>
> --Dave
>
>
>> On Behalf Of Dave Katz
>> Just to clarify what Dave is saying. Let’s say A and B are peers  
>> and B goes down. Consequently A goes into BFD Down state.
>>
>> that packet, A will immediately transition to Init state and  
>> should immediately send a BFD packet (it doesn’t have to wait for  
>> 1 second). On receipt of packet from A, B will immediately change  
>> it’s state and send a packet (immediately) to A. Thus packets sent  
>> on state transitions DO NOT have to wait for the 1 second. Thus  
>> the BFD session will come up ASAP. I hope this clarifies things.
>>
>> Nitin
>