Re: BFD stability follow-up from IETF-91

[Mahesh Jethanandani <[e-mail]>]

Let me try to see if I can bring the focus back on at least what the draft is trying to achieve. And I will do this by way of a customer scenario. 

Customer configures MPLS-TP with working and protect tunnels. Customer then configures BFD on both the working and protect tunnels. BFD flaps and triggers a failover to the protect tunnel. After the fact the customer wants to know why did the failover happen. 

We do not have the option of saying that they needed to change their hardware (to perform echo or hardware based time stamping) or to run other protocols continuously without impacting their network. I am outlining these parameters not because I want the solution to be limited to this situation but because most of the explanations or solutions seemed to have missed the fact that one is dealing with an existing network with existing hardware. So while the solution can extend itself to more configurations/situations it cannot ignore the existing setup.

How do we determine why a BFD session flapped? There are really two explanations to a BFD session flapping. Either the BFD packets were lost or packets were delayed. So the first determination is to do just that.

That essentially is germane to why the draft is written.

Cheers.

p.s. And to tell the customer that we had no way to explain why one of the features used to detect problems in the network cannot explain *why* a particular problem happens also does not help.

Mahesh Jethanandani
[e-mail]