Re: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91)

[Jeffrey Haas <[e-mail]>]

On Fri, Dec 19, 2014 at 10:52:10PM +0000, Gregory Mirsky wrote:
> thank you for your interest in this discussion. If you agree, we can add IPPM WG to it.

I think that would be excessively overloading the conversation at this time.
My primary point was that a performance measuring tech wasn't a fully
appropriate tool for this situation.  At some point if IPPM would like to
have BFD devs visit their session and provide feedback about where
implementation layering issues bias measurement, I suspect we can find
volunteers.

> I agree with your analysis of TWAMP and I would not suggest that
> TWAMP-Test is well suited to debug BFD specific issues. But TWAMP-Test, as
> other active performance measurement mechanisms, i.e. Y.1731 and MPLS PM
> based on RFC 6374, may be used to measure latency and jitter of a network
> or its segment.

But such measurements will depend on where in the implementation the
injectiosn and measurement are done.  The closer you get to IEEE work, the
more the measurements are likely to be implemented in HW as part of L2.  The
closer to IETF, the more likely it will be a layer just above HW L2.  Each
kind of measurement is valuable, and the results are ideally congruent.

>  And even more than active, passive measurement methods may
> provide helpful information to troubleshoot network or BFD. That may be
> done using IPFIX on certain nodes in the network with the data analysis by
> a data collector.

IPFIX typically will give you biased statistics either due to binning
effects or the fact that it's statistically sampled.
(Admittedly, I don't follow current work, only work I've done in the last 5
years with flow.)

To some extent, that observation highlights a difference in what is being
observed.  When you are concerned about flow-level impacts in your network,
the aggregates are the item of concern.  For BFD, and to a lesser extent
things like the other control plane protocols, a small number of lost
packets at inopportune times has significantly negative impacts.  The
granularities become much tighter.

> I agree that debugging and troubleshooting is often an art and operators
> and vendors  need to have and use all tools that are available. We
> probably can do better job of instrumenting BFD debug tools but, I
> believe, not by changing, not by overloading its main functions of
> monitoring continuity and fast detection of the Loss of Continuity defect.
> Whether Down state is indication of the real defect or false negative,
> that is the question to be answered through analysis of available
> information and follow-up with debugging and troubleshooting the BFD
> itself rather than the network if there are concerns that it was not a
> real defect.

That is the fundamental point: What tools do we need in BFD to troubleshoot
BFD especially given the layering issues that are somewhat distinct for its
implementations?  Sequencing information, minimally.  I am becoming more
convinced that the timing information is helpful - if tricky to implement in
a cross-vendor fashion.  I don't believe that BFD with such extensions
should replace mechanisms such as CFM.

-- Jeff