Re: BFD stability follow-up from IETF-91

[Manav Bhatia <[e-mail]>]

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]] 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
> >
>
>