RE: BFD stability follow-up from IETF-91

[Gregory Mirsky <[e-mail]>]

Hi Manav,
if WG chairs feel that BFD implementation guide would be good to write we may find willing contributors.
As for granularity of logging, implementation I’m familiar with allows do that per BFD session without context switching.

                Regards,
                                Greg

PS. our discussion grew beyond tolerance level of mail-host, so I’ve snipped part.

From: Manav Bhatia [mailto:[e-mail]]
Sent: Thursday, December 04, 2014 7:02 PM
To: Gregory Mirsky
Cc: Santosh P K; Mahesh Jethanandani; [e-mail]
Subject: Re: BFD stability follow-up from IETF-91

Hi Greg,

I am sure the WG would appreciate such a lecture since that would obviate the need for such an ID. Are you suggesting that i turn on logging and packet tracing for *each* incoming BFD packet for all the sessions that i have? Trying doing that for 25 BFD sessions where few are running at 50ms and 100ms TX intervals. Now trying combing through the logs when 1 BFD session flaps to understand where the issue was.

Cheers, Manav

On Thu, Dec 4, 2014 at 10:03 PM, Gregory Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Manav,
I hope you don’t expect me to give a lecture on how to design and implement debugable implementation using logging and packet tracing.

                Regards,
                                Greg

From: Manav Bhatia [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, December 04, 2014 8:16 AM
To: Gregory Mirsky
Cc: Santosh P K; Mahesh Jethanandani; [e-mail]<mailto:[e-mail]>

Subject: Re: BFD stability follow-up from IETF-91

I am not sure what the confusion is Greg.

Assume i have a BFD session thats up. At some point in time it flaps. Now i need to know whether the issue was at the TX or the RX.

Please tell me how TWAMP can help me here. Also tell me how what tool i can use if its a uBFD session that flapped.

Cheers, Manav

On Thu, Dec 4, 2014 at 9:09 PM, Gregory Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Santosh,
but that is what can be called “feature creep”. BFD is continuity check mechanism and for active performance measurement, even occasional, there are TWAMP in IP and RFC 6374/6375 in MPLS/MPLS-TP. It may be tempting to expand scope of BFD but, I believe, it is successful exactly because it was simple, light-weight and designed to do exactly one thing – continuity check.

                Regards,
                                Greg

From: Santosh P K [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, December 04, 2014 7:02 AM
To: Gregory Mirsky; Mahesh Jethanandani

Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: BFD stability follow-up from IETF-91

Hello Greg,
  Debugging BFD is one of the use case. I also want to bring up one of the use case that Jeff suggested in his earlier  mail. Operator might NOT want to run OAM which does loss and delay measurement all the time due to its overhead. With the extension to BFD (sequence number) we can detect if there is any loss but BFD still stays up. This loss detection can be used as a trigger for loss and delay measurement. Echo can be used only in case of singlehop and in one direction only.

Thanks
Santosh P K

From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Gregory Mirsky
Sent: Thursday, December 04, 2014 12:12 PM
To: Mahesh Jethanandani
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: BFD stability follow-up from IETF-91

Hi Mahesh,
indeed, LSP Ping is part of MPLS OAM tool set as BFD itself that intended to monitor operational state of the network, path continuity between two nodes. And LSP Ping, as primarily on-demand troubleshooting tool, helps localize and, to certain degree, diagnose the problem. But the ultimate debugging is proprietary. This proposal, in my view, helps not monitor behavior of the network but BFD itself, quality of BFD implementation. I’m not saying that it is not useful for implementers and operators, one can find that too many BFD sessions or at too short intervals being  ran. I don’t agree to loading this as extension of the widely used standard. Perhaps we can look into using BFD Echo as self-debugging instrument.

                Regards,
                                Greg