Re: BFD stability follow-up from IETF-91

[Marc Binderberger <[e-mail]>]

Hello Manav,

> You never send control plane packets at a high rate - but now you send and 
> receive twice as many BFD packets as you were processing earlier. I would 
> wager that this would be a show stopper. 

that depends on implementation details how much impact this has. BFD itself 
is still sending/receiving largely the same number of packets.

The echo U-turn processing would happen in the data/forwarding plane and 
should (well, must) be simple, even with some stamping.


Regards, Marc



On Mon, 8 Dec 2014 18:13:18 +0530, Manav Bhatia wrote:
> Hi Marc,
> 
>>> .. 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 ;-)
> 
> .. and thats quite bad. 
> 
>> 
>> 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.
> 
> You never send control plane packets at a high rate - but now you send and 
> receive twice as many BFD packets as you were processing earlier. I would 
> wager that this would be a show stopper. 
> 
> Cheers, Manav
>  
>> 
>>> 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
>>>
>