Re: BFD stability follow-up from IETF-91

[Manav Bhatia <[e-mail]>]

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
> >
>