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

From: Ashesh Mishra <[email-masked]>
Date: Mon, 30 Jun 2014 17:14:54 -0700

Hi everyone.

The first version of the BFD-Stability draft has been posted. Thanks to everyone who contributed to the creation of this document. 

There are still two issues that are being discussed and are yet to be resolved:

- Sequence Number Handling: What's mentioned in the document made sense for one 
particular implementation. However, that mechanism can be refined further and needs more discussion on what the behavior
 should be. I encourage you to continue the 
discussion on this issue. We should have enough time before the Toronto 
meeting to update the section.

- TLV-Type Identification: This issue revolves around how to distinguish 
the three types of TLVs described in this draft (using length, auth-key-id, reserved bits, or 
some other identifier). The logic for using length was that it can be 
interpreted in different ways to maintain compatibility with different implementations. If one node is transmitting a 
fully-loaded TLV (seqNum and two timestamps) and the peer is not capable
 of handling some parts of that TLV, it can choose to process the TLV in
 only IFG mode. That said, we can discuss this over time and update the 
document before the meeting. 

Looking forward to your comments and suggestions.

Thanks,
Ashesh  Mishra

From:  <[email-masked]>

Date: Mon, Jun 30, 2014 at 4:30 PM
Subject: New Version Notification for draft-ashesh-bfd-stability-00.txt
To: Mach Chen <[email-masked]>, Ankur Saxena <[email-masked]>, Mahesh Jethanandani <[email-masked]>, Santosh Pallagatti <[email-masked]>, Ashesh Mishra <[email-masked]>

A new version of I-D, draft-ashesh-bfd-stability-00.txt

has been successfully submitted by Ashesh Mishra and posted to the

IETF repository.

Name:           draft-ashesh-bfd-stability

Revision:       00

Title:          BFD Stability

Document date:  2014-06-30

Group:          Individual Submission

Pages:          7

URL:            http://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-00.txt

Status:         https://datatracker.ietf.org/doc/draft-ashesh-bfd-stability/

Htmlized:       http://tools.ietf.org/html/draft-ashesh-bfd-stability-00

Abstract:

   This document describes extensions to the Bidirectional Forwarding

   Detection (BFD) protocol to measure BFD stability.  Specifically, it

   describes a mechanism for detection of BFD frame loss, of delays in

   frame transmitter and receiver engines, and of inter-frame delays

   that might explain issues with a BFD session.

Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 1 Jul 2014 06:12:41 +0530

Hi Ashesh,

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.

I think it'll be much smarter to say that an implementation MAY carry
multiple authentication TLVs, in which case, the outer one MUST carry
the real authentication information.

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.

More comments once i go through the draft ..

Cheers, Manav

On Tue, Jul 1, 2014 at 5:44 AM, Ashesh Mishra <[email-masked]> wrote:
> Hi everyone.
>
> The first version of the BFD-Stability draft has been posted. Thanks to
> everyone who contributed to the creation of this document.
>
> - Sequence Number Handling: What's mentioned in the document made sense for
> one particular implementation. However, that mechanism can be refined
> further and needs more discussion on what the behavior should be. I
> encourage you to continue the discussion on this issue. We should have
> enough time before the Toronto meeting to update the section.
>
> - TLV-Type Identification: This issue revolves around how to distinguish the
> three types of TLVs described in this draft (using length, auth-key-id,
> reserved bits, or some other identifier). The logic for using length was
> that it can be interpreted in different ways to maintain compatibility with
> different implementations. If one node is transmitting a fully-loaded TLV
> (seqNum and two timestamps) and the peer is not capable of handling some
> parts of that TLV, it can choose to process the TLV in only IFG mode. That
> said, we can discuss this over time and update the document before the
> meeting.
>
> ________________________________
> To: Mach Chen <[email-masked]>, Ankur Saxena <[email-masked]>,
> Mahesh Jethanandani <[email-masked]>, Santosh Pallagatti
> <[email-masked]>, Ashesh Mishra <[email-masked]>
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-00.txt

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 1 Jul 2014 01:09:12 +0000

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.

                Regards,
                                Greg

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Ashesh Mishra
Sent: Monday, June 30, 2014 5:15 PM
To: [email-masked]
Subject: RE: New Version Notification for draft-ashesh-bfd-stability-00.txt

Hi everyone.

- Sequence Number Handling: What's mentioned in the document made sense for one particular implementation. However, that mechanism can be refined further and needs more discussion on what the behavior should be. I encourage you to continue the discussion on this issue. We should have enough time before the Toronto meeting to update the section.

- TLV-Type Identification: This issue revolves around how to distinguish the three types of TLVs described in this draft (using length, auth-key-id, reserved bits, or some other identifier). The logic for using length was that it can be interpreted in different ways to maintain compatibility with different implementations. If one node is transmitting a fully-loaded TLV (seqNum and two timestamps) and the peer is not capable of handling some parts of that TLV, it can choose to process the TLV in only IFG mode. That said, we can discuss this over time and update the document before the meeting.

Thanks,
Ashesh  Mishra
________________________________
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jun 30, 2014 at 4:30 PM
Subject: New Version Notification for draft-ashesh-bfd-stability-00.txt
To: Mach Chen <[email-masked]<mailto:[email-masked]>>, Ankur Saxena <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, Santosh Pallagatti <[email-masked]<mailto:[email-masked]>>, Ashesh Mishra <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 30 Jun 2014 23:00:54 -0400

Greg,

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

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: Mon, 30 Jun 2014 23:08:51 -0400

Manav,

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

> 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