Re: BFD stability follow-up from IETF-91

[Manav Bhatia <[e-mail]>]

Hi Sam,

> Ideally even if there is some bit of congestion i would like the BFD
> packet to get through.
>
> I understand the queuing problems but I am not clear how the ID is going
> to solve the problem, if there is only congestion and not
>

It would help.

Assume the last sequence number you saw before the flap was s1. You timed
out since you did not see s2 and s3 before the timeout. Now further assume
that you know that you did receive s2 and s3, however they arrived after
the BFD expiry interval then you know that there wasnt a drop, and the
packet arrived late because of some queing issue. Now how you determine
whether this delay was seen at the TX or RX side is open to discussion.

Without a sequence number you have no idea whether the packet was dropped
or whether it arrived/processed late.

If by some out-of-band mechanism you can figure out that the TX was done on
time and the delay was at RX end then its an implementation issue on the RX
side. If the TX was delayed then its an implementation issue at the TX side.

This helps isolating the node that needs to fix the issue, otherwise we're
only shooting in the dark.

packet drop. In that case just the sequence # doesn't help and timestamping
> is needed. Even if timestamping is to be done, realistically it cannot
> happen the same way across multi vendor i.e. where the timestamping
> should/could be done. For ex: Before it is queued or after OR
> LC/RP/SP/Process etc.
>

This isnt a new problem. Each vendor time stamps 1588 packets differently.
However, the aggregate solution works across multiple vendors.

While it may not solve all the issues because of the vagaries of how each
vendor does time stamping it would certainly help debugging large number of
BFD flaps.


> Secondly, if the congestion happens, the CIR/PIR should apply to data
> packets too. In that case BFD flap is at least a good indicator of the
> problem, isn't it?
>

There is usually a separate CIR/PIR for different CPU bound packets. So
based on some parameters you might impose a different CIR/PIR for BFD than
say, ssh and radius packets. If BFD flaps and you know you missed a few
sequence numbers and you see drops in that queue then all of this could be
co-related and you could fix the CPU queue parameters for BFD. I understand
that this is a very implementation specific issue, but then thats what i
had said earlier -- such a mechanism can help in isolating implementation
specific issues as well.


> Lastly, these improvements is change from the existing BFD model/protocol.
> I do not see why it shouldn't be part of BFD v2 OR lead to v2 :D
>

Sure, that would make Marc very happy ! :-)

I am not sure if we have enough momentum right now that can propel us
towards BFD v2.

OTOH, if the WG believes that this is an opportune time for us to start
looking at BFDv2, then i would be more than willing to participate!

Cheers, Manav

>
> -sam
>
>
> Cheers, Manav
>
> - I see concerns regarding timestamps and sequence numbers expressed in
>> emails. In that case, the proposed model is still not going to identify the
>> problem completely. Am I reading it right?
>>
>> -sam
>> On Dec 4, 2014, at 7:47 AM, Gregory Mirsky wrote:
>>
>> > Hi Jeff,
>> > I can reference RFC 5357 here. The Appendix describes what is called
>> TWAMP-Light mode with Stateless Reflector. About year and a half the Errata
>> been accepted that describes Stateful Reflector, which supports measurement
>> of one-way latency/jitter and packet loss metrics.
>> >
>> >       Regards,
>> >               Greg
>> >
>> > -----Original Message-----
>> > From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Jeffrey
>> Haas
>> > Sent: Thursday, December 04, 2014 7:17 AM
>> > To: Nobo Akiya (nobo)
>> > Cc: [e-mail]
>> > Subject: Re: BFD stability follow-up from IETF-91
>> >
>> > On Thu, Dec 04, 2014 at 03:14:50PM +0000, Nobo Akiya (nobo) wrote:
>> >> If what you say is the only requirement not met, one approach may be
>> to pursue a non-standard-track document describing some suggested
>> implementation techniques to locally store TX/RX timestamp.
>> >>
>> >> Given that echo approach will be less accurate and given that we seem
>> to be having difficulty converging, I thought I???ll throw out another idea.
>> >
>> > I think my biggest concern is that the echo approach has bidirectional
>> packet loss possibilities.  Async at least lets the receiver know about
>> unidirectional packet loss.
>> >
>> > Of course, if your goal is to notify the sender that their packets are
>> being lost, you need a backchannel anyway.  I just don't know if we want
>> that back channel to be bfd.
>> >
>> > - Jeff
>> >
>>
>>
>
>