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

[Gregory Mirsky <[e-mail]>]

Hi Jeff,
thank you for your interest in this discussion. If you agree, we can add IPPM WG to it.
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. 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. Would like to note that IPPM WG is in discussion of IP flow measurement method that uses marking method that I consider operationally more useful comparing to straight IPFIX.
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.

	Regards,
		Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Friday, December 19, 2014 1:02 PM
To: Gregory Mirsky
Cc: Manav Bhatia; [e-mail]
Subject: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91)

[I'm running behind in discussions as usual]

On Thu, Dec 04, 2014 at 04:33:17PM +0000, Gregory Mirsky wrote:
> Hi Manav,
> I hope you don???t expect me to give a lecture on how to design and implement debugable implementation using logging and packet tracing.

For what it's worth, I always find such "drive-by" comments about "well, there already exists something that does <foo>, it's here - go do your homework!" to be a bit frustrating myself. :-)  

Not being personally familiar with TWAMP, I spend a few minutes digging through the spec for TWAMP and OWAMP for some details about the control and test traffic.  It has some properties that are problematic for the pieces of the ecosystem covered by various portions of BFD deployment:

TCP control channel.  The implication is not only bidirectional reachability, but a control IP stack that may not involve the nodes being tested.  (Nodes in this case potentially being anything from host systems all the way down to line card components.)

The data channel is UDP, which is good.  The problem though is there's no guarantee it'll cover the layers of the hardware stack covered by the BFD sessions.  As one example, BFD on LAG, we not only may not have a full IP stack running at the point it's coming up, there's a chance that the receiver isn't really much of an IP speaker.  It may be effectively using the IP+UDP framing as dumb framing rather than protocol in order to bootstrap the session.  IP may not come up until constituent LAG elements have been put into service.

There's also the matter that to get TWAMP running at the appropriate layer, it would be similarly necessary to embed it in the same general paths that BFD covers.

Thus, at first very coarse analysis, TWAMP neither seems to share enough of the forwarding fate on a guaranteed basis as we'd want to supplement BFD debugging.  The control channel also seems a bit heavy-weight, but it's potentially no worse than architecture of some LACP implementations I'm aware of.

Is there something missing or incorrect in the above thinking?

-- Jeff