Re: BFD stability follow-up from IETF-91

[Marc Binderberger <[e-mail]>]

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
>