Re: BFD stability follow-up from IETF-91

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

Hi Manav,

On Dec 4, 2014, at 5:05 PM, Manav Bhatia wrote:

> 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.
I understand the queuing problems but I am not clear how the ID is going to solve the problem, if there is only congestion and not packet drop. In that case just the sequence # doesn't help and timestamping is needed. Even if timestamping is to be done, realistically it cannot happen the same way across multi vendor i.e. where the timestamping should/could be done. For ex: Before it is queued or after OR LC/RP/SP/Process etc.

Secondly, if the congestion happens, the CIR/PIR should apply to data packets too. In that case BFD flap is at least a good indicator of the problem, isn't it? 

Lastly, these improvements is change from the existing BFD model/protocol. 
I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D

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