Exiting loss of connectivity state

[[e-mail]]

According to the current base draft "The Detect Mult value is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down." So, if the TX Interval is 1sec and the Detect Mult is 3 (in both directions), and a unidirectional failure occurs in the direction A->B, then:

- B will declare the session down (roughly speaking, due to jitter) after non receipt of BFD packets over a 3 second period.
- A will declare the session down after the time it takes B to detect the failure (about 3 secs in this example) and then send a BFD packet to A with I Hear You 0 and Local Diag 1.

This approach is consistent with other OAM mechanisms, i.e. by configuring the TX Interval to be 1sec and the Detect Mult to be 3, the loss of connectivity state is entered after non-receipt of packets over a 3sec period. However, how long does it take for a BFD session to be declared up again after connectivity has been restored, i.e. what is the exit criteria for the loss of connectivity state? 

Other OAM mechanisms use exit criteria that is consistent with the entry criteria, i.e. the loss of connectivity state is exited after receiving the expected number of OAM packets over a 3 second period. In BFDs case, the time taken and number of packets TX/RX required to transition from the Down/Failing/Init state to the Up state is dependant on the current session states at the time connectivity is restored, and how quickly an implementation sends BFD packets (i.e. whether or not between schedule BFD sessions are sent and for which state changes). I have worked through a few scenarios, and depending on the variables, it could take a less than a second or several seconds for a session to come back up again (or a session might not ever come back up under specific conditions based on discussions on a previous thread "Re: Between schedule transmissions").

MPLS BFD has been proposed as a connection verification tool for MPLS LSPs. It seems to me that the current BFD draft allows an operator to determine when connectivity has been lost (i.e. following detection timeout) but does not allow operators to determine with any certainty if/when connectivity has been restored. This information is important in checking that SLAs are being met, i.e. how long connectivity has been lost for. This information is also important for protection switching as the backup path may be expensive to use or may not have sufficient resource for all traffic (i.e. lower priority traffic is dropped), and therefore we need to switch back over to the primary as soon as possible after connectivity has been restored.

It appears to me that extensive work will need to be carried out by operators in analysing different failure scenarios in order to determine what the effect of sessions being declared back up at different time periods will be, and to ensure that the probability of BFD sessions not coming back up at all is as close to zero as possible. Testing will be particularly important where BFD sessions are used across multiple levels of hierarchy (e.g. a BFD session could be declared up at a client layer before a BFD session at server layer), and also in multivendor environments where implementations may or may not send between schedule transmissions for different state transitions.

Does anyone have any comments/solutions regarding this problem?

Thanks,
Richard