Re: BFD stability follow-up from IETF-91

["Sam K. Aldrin" <[e-mail]>]

Way too many emails to catch up to discussion and to understand clearly, every point.

Here are my questions and concerns

- Is this primarily to debug the debugger i.e. OAM for BFD?
- Is this because the primary BFD protocol is too simple and cannot debug its failure. And this enhancement adds some sort of extension to base protocol? Say BFD 1.1?
- Every OAM tool has issues to debug itself, but is there any reference where there is OAM for OAM which got standardized?

Concern:
- With the sequence number added, one could find(?) that BFD control packets are experiencing congestion or packet delay. So, the assertion is that BFD flapping could be avoided. But if the packets in the network, including BFD, are really experiencing this, shouldn't this be the right behavior?
- I see concerns regarding timestamps and sequence numbers expressed in emails. In that case, the proposed model is still not going to identify the problem completely. Am I reading it right?

-sam
On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote:

> Hi Jeff,
> I can reference RFC 5357 here. The Appendix describes what is called TWAMP-Light mode with Stateless Reflector. About year and a half the Errata been accepted that describes Stateful Reflector, which supports measurement of one-way latency/jitter and packet loss metrics.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Jeffrey Haas
> Sent: Thursday, December 04, 2014 7:17 AM
> To: Nobo Akiya (nobo)
> Cc: [e-mail]
> Subject: Re: BFD stability follow-up from IETF-91
> 
> On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote:
>> If what you say is the only requirement not met, one approach may be to pursue a non-standard-track document describing some suggested implementation techniques to locally store TX/RX timestamp.
>> 
>> Given that echo approach will be less accurate and given that we seem to be having difficulty converging, I thought I???ll throw out another idea.
> 
> I think my biggest concern is that the echo approach has bidirectional packet loss possibilities.  Async at least lets the receiver know about unidirectional packet loss.
> 
> Of course, if your goal is to notify the sender that their packets are being lost, you need a backchannel anyway.  I just don't know if we want that back channel to be bfd.
> 
> - Jeff
>