Subject: RE: a draft about how BFD notifying the state change to applications

From: [email-masked]
Date: Wed, 24 Aug 2005 12:22:06 +0100

Pingan,

If I understand correctly, the problem you are trying to solve is the case where we get a flapping BFD session (i.e. the session is going up and down repeatedly), e.g. due to an intermittent link failure. Your solution is to use hold timers to delay any actions to be taken by applications as a result of a session going up or down.

IMO your solution does not solve the problem. If a session is flapping then the flapping needs to be detected and the appropriate action taken. Your solution does not reliably detect flapping and I assume is based on ignoring flaps that occur within the configured hold times.

The current text in section 4 states: "When BFD session goes up, if HOLD timer is running, then stop HOLD timer and does not notify application the state change of the session. Otherwise start WTR timer." The effect of this proposal is that when you get a BFD session going up and down, although it will be detected by BFD, the application will never take any action if the flap interval is less than the hold timer. For example, lets say the flap interval is 5secs and the hold timer is set to 10secs. When the session goes down the hold timer will start but after 5 secs the session will come back up and the hold timer will be stopped and no action taken. This cycle will continue indefinitely, i.e. traffic will continue to be dropped intermittently and the flapping will not be detected.

Even if you don't stop the hold timer when the session comes back up, you still won't reliably detect flapping. Lets say a session goes down and you start the hold timer (set to say 10 secs). The session might go up and down 5 times during the 10 sec hold time, but by chance when the hold timer expires the session may be up. In which case, the application won't take any action despite traffic being lost intermittently over the 10 sec period.

Also, the main purpose of using BFD is to provide fast fault detection. If hold timers are introduced to delay any actions to be taken following fault detection (e.g. failover to a backup route), then what's the point of having fast detection in the first place?

An alternative solution would be to use a BFD session up/down state transition alarm threshold. If the number of times a session goes up/down within a configured time period exceeds the threshold, then the session can i) be disabled or administratively shut down (under control of OSS or the BFD system itself), ii) an alarm raised to instigate fault diagnosis/correction activities, or iii) both. This solution does not require any changes to the BFD protocol and could be implemented today.

Regards,
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of yangpingan 30338
> Sent: 24 August 2005 03:26
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: a draft about how BFD notifying the state change to
> applications
> 
> 
> 
> Dear all,
> 
> I have written a draft about how BFD notifying the state 
> change to applications, the purpose is to reduce the effect to system
> when BFD session goes up and down frequently, and reduce the 
> packet loss when defect is recovered. It's 4 pages long, 
> Comments are very welcome.
> 
> Please help to post to the IETF website this draft and thank 
> you for that.
> 
> 
> Thank you and Best regards.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> **************************************************************
> ****************************
>  This email and its attachments contain confidential 
> information from HUAWEI, which is intended only for the 
> person or entity whose address is listed above. Any use of 
> the information contained herein in any way (including, but 
> not limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this e-mail in 
> error, please notify the sender by phone or em
> ail immediately and delete it!
>  
> **************************************************************
> **************************
>

---

From: Yang Pingan <[email-masked]>
Date: Wed, 24 Aug 2005 21:57:24 +0800

Richard,

What you said is just one possible situation of  WTR and HOLD process. Normally the hold time is less than WTR time(The recommended
value of HOLD timer is several seconds or less than one second. and WTR timer several minute). So this cannot  be achieved by alarm threshold.
And another purpose of WTR  is that: before BFD notifying forwarding engine, it gives the chance for preparing forwarding table(especially for 1hop BFD),
so can avoid  traffic lost when defect is recoverd.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 24, 2005 7:22 PM
Subject: RE: a draft about how BFD notifying the state change to applications

Pingan,

Regards,
Richard

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Aug 2005 12:45:44 -0400

Good analysis Richard. One comment below.

> Pingan,
>
> If I understand correctly, the problem you are trying to solve is  
> the case where we get a flapping BFD session (i.e. the session is  
> going up and down repeatedly), e.g. due to an intermittent link  
> failure. Your solution is to use hold timers to delay any actions  
> to be taken by applications as a result of a session going up or down.
>
> IMO your solution does not solve the problem. If a session is  
> flapping then the flapping needs to be detected and the appropriate  
> action taken. Your solution does not reliably detect flapping and I  
> assume is based on ignoring flaps that occur within the configured  
> hold times.
>
> The current text in section 4 states: "When BFD session goes up, if  
> HOLD timer is running, then stop HOLD timer and does not notify  
> application the state change of the session. Otherwise start WTR  
> timer." The effect of this proposal is that when you get a BFD  
> session going up and down, although it will be detected by BFD, the  
> application will never take any action if the flap interval is less  
> than the hold timer. For example, lets say the flap interval is  
> 5secs and the hold timer is set to 10secs. When the session goes  
> down the hold timer will start but after 5 secs the session will  
> come back up and the hold timer will be stopped and no action  
> taken. This cycle will continue indefinitely, i.e. traffic will  
> continue to be dropped intermittently and the flapping will not be  
> detected.
>
> Even if you don't stop the hold timer when the session comes back  
> up, you still won't reliably detect flapping. Lets say a session  
> goes down and you start the hold timer (set to say 10 secs). The  
> session might go up and down 5 times during the 10 sec hold time,  
> but by chance when the hold timer expires the session may be up. In  
> which case, the application won't take any action despite traffic  
> being lost intermittently over the 10 sec period.
>
> Also, the main purpose of using BFD is to provide fast fault  
> detection. If hold timers are introduced to delay any actions to be  
> taken following fault detection (e.g. failover to a backup route),  
> then what's the point of having fast detection in the first place?
>
> An alternative solution would be to use a BFD session up/down state  
> transition alarm threshold. If the number of times a session goes  
> up/down within a configured time period exceeds the threshold, then  
> the session can i) be disabled or administratively shut down (under  
> control of OSS or the BFD system itself), ii) an alarm raised to  
> instigate fault diagnosis/correction activities, or iii) both. This  
> solution does not require any changes to the BFD protocol and could  
> be implemented today.

     Based on the premise that BFD should allow for fast detection,
I think you are right here in that all of the raw alarms should be
forwarded to the applications that are interested in those alarms.
This is indeed how the various implementations that I am familiar
with do this. It is a local decision as to how to process
(i.e.: squelch/forward/aggregate) those alarms. It doesn't seem
under the purview of the BFD protocol however, to stipulate
how the alarms are processed given this point. Also
another important point to include is that different applications
may need different processing algorithms, which also makes
this something too application specific to be stipulated
as part of the BFD protocol.

     --Tom

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Aug 2005 13:44:25 -0400

On Wed, Aug 24, 2005 at 09:57:24PM +0800, Yang Pingan wrote:
> And another purpose of WTR  is that: before BFD notifying forwarding engine,

I think this is one of the key phrases.

BFD need not "notify the forwarding engine".  One's system can be designed
to notify whatever component is appropriate.

The raw "session transitioned up", "session transitioned down" events
can be passed to whatever component you like.  If you wish to damp
behavior of those applications, you could apply your mechanism
and provide an intermediate layer between BFD and your application.

I wonder, based on your example, whether or not a different use of
BFD may be more appropriate.  If you're using BFD in conjuction
with some sort of failover/high availability mechanism, you have
two pieces of information that you are concerned about:

 - If you are verifying connectivity to a given instance of some
   application.
 - You are verifying that forwarding works to this instance.

To give a more concrete example, if you are using BFD for static
routes where the nexthop is a nexthop managed by VRRP, there may
be a forwarding failure to the nexthop.  At some point determined
by VRRP configuration and state, another VRRP host will take over.

If, in this example, you wished to monitor forwarding, BFD to the
VRRP nexthop may be appropriate.  However, the timers probably should
be such that the BFD timeout is higher than the VRRP failover time.

If you wish to monitor a given VRRP host, your BFD session should
be to an address other than the VRRP virtual address.

My apologies if this example misses your point.

-- 
Jeff Haas 
NextHop Technologies