RE: BFD stability follow-up from IETF-91

[Gregory Mirsky <[e-mail]>]

Hi Manav, et. al,
you’ve said:
Ideally even if there is some bit of congestion i would like the BFD packet to get through.
Assume that the congestion is in egress queue, related to the fast forwarding path. Then wouldn’t pushing BFD control packets ahead of every other packet of the same DSCP be hiding the problem in the network, rather than detecting it, doing exactly what BFD intended to do? Perhaps that, tuning DSCP marking of BFD, is something to look into before changing BFD?

                Regards,
                                Greg

From: Manav Bhatia [mailto:[e-mail]]
Sent: Thursday, December 04, 2014 5:05 PM
To: Sam K. Aldrin
Cc: Gregory Mirsky; [e-mail]
Subject: Re: BFD stability follow-up from IETF-91

Hi Sam,


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 was looking at it to help debug scenarios where its not just the network but implementation issues as well that cause sporadic BFD flaps. If you have a BFD pkt lying in your buffer for too long before its gets scheduled out, then perhaps there is a case for you to look at your pkt TX scheduler. Similarly, you could look at issues on the RX side -- perhaps the queue isnt being drained fast enough, or the CIR/PIR values are aggressive and you drop certain packets when you have scaled up BFD sessions.

Ideally even if there is some bit of congestion i would like the BFD packet to get through.

Cheers, Manav

- 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]<mailto:[e-mail]>] On Behalf Of Jeffrey Haas
> Sent: Thursday, December 04, 2014 7:17 AM
> To: Nobo Akiya (nobo)
> Cc: [e-mail]<mailto:[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
>