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

[Jeffrey Haas <[e-mail]>]

[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