Re: BFD stability follow-up from IETF-91

["MALLIK MUDIGONDA (mmudigon)" <[e-mail]>]

Hi Marc,

Nothing has been dismissed yet :-). Trying to see what can be done.

Thanks

Regards
Mallik

From: Marc Binderberger <[e-mail]<mailto:[e-mail]>>
Date: Monday, 8 December 2014 1:19 pm
To: Manav Bhatia <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: BFD stability follow-up from IETF-91

Hello Manav,

For the echo mechanism to work, do you agree that you would have to
continuously send Echos so that you can detect the issue?
that's what I had in mind, yes
.. and i dont like this. Are you saying that for each BFD session now you
will run a parallel BFD echo session that would carry the debug data? Your
scaling just went for a toss !!

Just by a factor of 2 ;-)

But seriously: if you run echo at hight speed you would usually avoid running
the control packets at high speed too. Just what RFC5880 describes.

This would help if the flap is deterministic-ally reproducible. If its not,

Correct. Good for some problems, not good for others. As I said, interesting
option but not what I had in mind in first place.

then how long do you run the Echo BFD? And what happens to the original BFD
session? You run the two parallel-ly?

The "original" session?  I'm talking here about an echo session that is
controlled by the corresponding control packet exchange. As described in
RFC5880. Echo not defined for 5884 or 7130? Ah well, one probably could.

Echo seems at least an option to me, in the context of debugging, that can be
discussed. The freedom of defining the packet is interesting, some parameters
like RTT are measured easily. Other aspects, like Multihop, are a problem, no
doubt. I was simply surprised how quickly this idea was dismissed ... .


Regards, Marc





Or are you suggesting that once BFD flaps we will start sending Echoes
overloaded with debug information to detect the issue?
interesting idea - that would be an alternative use, collecting forensic
data. Maybe we should support that too!
This would help if the flap is deterministic-ally reproducible. If its not,
then how long do you run the Echo BFD? And what happens to the original BFD
session? You run the two parallel-ly?
Cheers, Manav
My biggest problem with the echo idea is so far BFD-over-LAG. But maybe it
is
not a real problem, any echo stamping/updating in the forwarding path would
require an hardware update (or reprogramming, if your hardware allows) and
in
this case one could boldly state that the echo packet must leave via the
ingress port :-)
Regards, Marc
On Mon, 8 Dec 2014 09:33:05 +0530, Manav Bhatia wrote:
Hi Marc,



* Greg's echo idea is of course do-able - when you think timestamping in
hardware can be done then it can be done in the forwarding path for
echos
as
well. Depends on your hardware :-) and on an agreed (minimal) format for
echo. As mentioned BFD echo is not defined/used for multiple BFD
features,
which limits it's use though.


For the echo mechanism to work, do you agree that you would have to
continuously send Echos so that you can detect the issue?

Or are you suggesting that once BFD flaps we will start sending Echoes
overloaded with debug information to detect the issue?

I'd like to understand this before the mailing list sees a barrage of
emails. Alternatively, we can also take it offline and only report the
summary of our discussion to the list.

Cheers, Manav