RE: BFD stability follow-up from IETF-91

[Gregory Mirsky <[e-mail]>]

Hi Jeff,
I absolutely agree with continuing discussion and sharing experiences from real-life deployments and interoperability of BFD in IP and MPLS networks, single-, multi-hop and over LAG constituents. From that we're learning and that helps us make our implementations more robust, reliable, and interoperable. And certainly, where it benefits the community informational RFCs, like BFD intervals or RFC 7325 MPLS Forwarding Compliance and Performance Requirements, to document the cases and our recommendations. But I'm somewhat concerned with anything that targets standard status, even as optional functionality, even though it is not proven that the problem is in the standard, not in an implementation.

	Regards,
		Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Friday, November 28, 2014 11:56 AM
To: Gregory Mirsky
Cc: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; [e-mail]
Subject: Re: BFD stability follow-up from IETF-91

[Speaking as an individual contributor...]

On Fri, Nov 28, 2014 at 07:36:30PM +0000, Gregory Mirsky wrote:
> this is very interesting scenario. I think that if BFD experiences ~30% packet loss, then highly likely so are affected other applications. Then it is not just BFD issue but condition that should be detected  by performance measurement method, whether active or passive packet loss measurement.
> I'm convinced that overloading BFD with performance measurement provisions is counter-productive and is inappropriate.

My opinion is about halfway between your opinion, Greg.

I agree that we wish to be very cautious about overloading BFD with components that are in other OAM mechanisms.  Among my desire for such caution is that IEEE has expressed interest in not having us step on their technologies and this would create paperwork for the chairs. :-)

But where I think we diverge slightly comes from experience in helping the working group and vendors wend their way through implementing BFD for LAG.
During that discussion, it was very clear that depending on the vendor, the architecture and sometimes specific chipsets that "BFD" lived in very different pieces of underlying architecture.

What this means is that trying to do very tight timing things will run into practical issues in having to figure out what the perspective of the timings are.  Is it some underlying L2? L3? Something between?  At what point do you realize you are measuring contradictory things?

But similarly, when trying to measure and account for loss, having some data is useful simply because it helps you determine that the component that is *responsible for BFD* may be experiencing loss.  Depending on your architecture, this may be the underlying layer-1, layer-2 or something else.
In such cases, the lower-layer OAM is better to troubleshoot.  But in cases where your lower-layer OAM doesn't indicate the loss, you still need to understand that there is BFD-level loss.

I encourage participants in this discussion to remember this detail: We are trying to help measure BFD loss.  Trying to read too much detail into what that means outside of BFD may lead you to erroneous conclusions depending on a given implementation.

Thus, consider what is best for BFD.

-- Jeff