Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt

From: Marc Binderberger <[email-masked]>
Date: Tue, 1 Jul 2014 00:03:50 -0700

Hello Jeff, Ashesh et al.,

> - Declaring defeat and creating BFDv2.

hehe ... why did this come to my mind when I was reading the draft. But then 
my appetite for v2 is well known ;-)

It's another example that we have discussions on overload "tricks" with all 
it's potential problems instead of discussing if an idea is viable, if it 
solves a real problem etc..

Anyway, what I take from the draft is this: having a sequence number in the 
BFD packet is a very useful thing to detect packet loss and distinguish a 
transmission delay increase from a lost packet. If we ever create BFDv2 this 
may be something to keep in mind.

For the timestamps my question would be: do we really need them in the BFD 
packet?   Any delay or variation of delay in the transmission or receiver 
engine is something I would have expected to be a local statistics. Why is 
e.g. the transmission delay of interest for the receiver?

Not saying these statistics are not relevant, they are. Locally.

Thanks & Regards,
Marc

On Mon, 30 Jun 2014 23:08:51 -0400, Jeffrey Haas wrote:
> Manav,
> 
> On Tue, Jul 01, 2014 at 06:12:41AM +0530, Manav Bhatia wrote:
>> Security Considerations says:
>> 
>>    Since this method uses an authentication TLV to achive the
>>    functionality, usage of this TLV will prevent the use of other
>>    authentication TLVs.
>> 
>> This is not acceptable. I would not like to see any proposal that
>> precludes the possibility of adding authentication later -- your
>> design stands on tenuous grounds as soon as you say this.
> 
> Exactly how well that survives the sieve of real-world deployment of
> authentication is itself somewhat tenuous grounds. :-)
> 
> But your point about making this feature work with actual authentication is
> work they've identified needing help.  I suspect you'll have opinions on
> that.
> 
>> BTW, i dont feel great about overloading the authentication TLV with
>> information thats completely unrelated to authentication. This breaks
>> all HW that looks at this TLV and sends it for some special
>> processing. You now require HW to peek deeper inside the TLV to know
>> if its something that this would interest it or not.
> 
> The authors of this draft were suggested to come together to work on this
> since they all had very similar ideas for the feature.  The observation that
> has lead to part of the current design is that the sequence number semantics
> needed for the feature are largely carried already through meticulous
> authentiction sequence numbering.  
> 
> At the end of the day, if we eliminated the additional fields, kept some
> well known but inexpensive authentication (such as null or password) and
> simply collected statistics related to expected packet presence based on
> rates and jitter it woudl be possible to derive some amount of loss and
> lantency statistics.  
> 
> The addition of time stamping for additional work seemed to be another
> common factor in each of the suggested designs.
> 
> Keeping with BFDv1 problematically means one of three likely designs for
> such a feature:
> - Overload something like authentication.
> - Packing the additional data after the BFD packet.  (There is room in the
>   spec for this, but depending on how pedantically someone implements it or
>   not may result in the additional data not getting through.)
> - Declaring defeat and creating BFDv2.
> 
> My push, as is well known on the list, is "can we do this without becoming
> backwardly incompatible".  Some day we will.  Is that today?  Let's find
> out!
> 
> -- Jeff
>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Tue, 1 Jul 2014 07:17:42 +0000

Hi Marc,

Replies inline

Thanks

Regards
Mallik

From: Marc Binderberger <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 1 July 2014 12:33 PM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, Ashesh Mishra <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt

Mallik>> Sure, will do if we reach that stage.

Mallik>> The idea behind these timers is to ensure that the BFD interval configurations on the peers take into account these delays so that BFD sessions do not flap and cause network churn. I understand these delays may be transient events, but giving the operator this delay information so that he configures proper intervals at BFD level.

Mallik>> Yes the delays are local, but a Tx delay on the sender side may result in the receiver not receiving the packets on time.

Thanks & Regards,
Marc

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 1 Jul 2014 07:30:28 +0000

Hi Jeff,
I'll follow your advice and will collect my patience to see development of this proposal in the coming days.
And I'd strongly encourage authors to illustrate the solution with use-case(s) that will highlight the stated in the document problem.

	Regards,
		Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Monday, June 30, 2014 8:01 PM
To: Gregory Mirsky
Cc: Ashesh Mishra; [email-masked]
Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt

Greg,

On Tue, Jul 01, 2014 at 01:09:12AM +0000, Gregory Mirsky wrote:
> Hi Ashesh,
> I'm not convinced that the goal stated in the document as quantify instability of the BFD control messages through measurement of inter-packet, a.k.a. inter-frame gap is relevant to BFD. Note, that interval between BFD control messages, according to RFC 5880 is jittered, i.e. randomized, as described in Section 6.8.7 RFC 5880.
> 
> Though it may be tempting to add performance measurements on top of BFD there are already OWAMP/TWAMP for IP PM and MPLS Packet Loss and Packet Delay Measurement RFCs to use for measuring performance metrics.

The guidance given to the various authors of this effort was firmly to avoid trying to replace existing L2 OAM technologies.  I suspect that their success in doing so will show itself over the coming days.

This said, the mechanism described does have enough information given the expected jitter to help determine some amount of the packet timing.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Jul 2014 11:11:21 -0400

Marc,

> may be something to keep in mind.

The key observation that came out of the various proposals that lead to
throwing these authors together as a semi-design group was effectively that
we already had such sequencing. It's called auth. :-)

Features beyond that are there for discussion.  Conveniently the timing is
good for some nice on-list discussion leading to our upcoming session in
Toronto.

-- Jeff (getting out the popcorn)

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 2 Jul 2014 11:24:30 +0530

Jeff,

> authentication is itself somewhat tenuous grounds. :-)

You never know! ;-)

We'll be publishing a draft on authentication which might just make
using authentication for BFD very much usable. The idea will be to
only carry the digest when there is a BFD state change. All other
times, the BFD packet just goes without any authentication TLV.

If you think about this, then this really solves all your problems! ;-)

The draft is coming your way that describes this very soon.

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 2 Jul 2014 10:10:01 -0400

Manav,

> The draft is coming your way that describes this very soon.

That proposal seems one of those things that in retrospect should have been
obvious.  It sounds quite useful.

This typically means some security expert will tell us it's a bad idea, but
I look forward to that discussion!

-- Jeff