Subject: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt

From: Santosh P K <[email-masked]>
Date: Thu, 11 Jun 2015 06:18:04 +0000

Hello All,

   A new version of draft has been submitted. Below are the changes made.

1.       Added use cases for BFD stability.

2.       Addressed review comments given in BFD working group.

3.       Added delay measurement details.

Please do review and get back to us with review comments.

Thanks

Santosh P K

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]]

> Sent: Wednesday, June 10, 2015 2:19 PM

> To: Mach Chen; Ankur Saxena; Mahesh Jethanandani; Santosh P K; Santosh P

> K; Ankur Saxena; Ashesh Mishra; Peng Fan; Mach Chen; Mahesh

> Jethanandani; Peng Fan; Ashesh Mishra

> Subject: New Version Notification for draft-ashesh-bfd-stability-03.txt

> A new version of I-D, draft-ashesh-bfd-stability-03.txt has been successfully

> submitted by Santosh Pallagatti and posted to the IETF repository.

> Name:                               draft-ashesh-bfd-stability

> Revision:          03

> Title:                  BFD Stability

> Document date:           2015-06-10

> Group:                              Individual Submission

> Pages:                               7

> URL:            https://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-<https://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-03.txt>

> 03.txt<https://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-03.txt>

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

> Htmlized:       https://tools.ietf.org/html/draft-ashesh-bfd-stability-03

> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ashesh-bfd-stability-03

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

> 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: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Fri, 12 Jun 2015 08:33:14 +0000

Hi,

I need a quick clarification on the need for the sender time stamp here. If the delay is measured by comparing the time stamps of two consecutive packets, it can be done on the local end. Why send it to the other end? Receive time stamp can still happen to measure the Rx path delays. I understand that we need to always maintain the previous packets TS to achieve this. Asking this because we can measure these delays independently at both ends unless you are also looking at accommodating transit delays over the link.

Thanks

Regards
Mallik

From: Santosh P K <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 11 June 2015 11:48
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: FW: New Version Notification for draft-ashesh-bfd-stability-03.txt

Hello All,

Thanks

Santosh P K

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Jun 2015 16:20:42 -0400

Santosh,

Thanks for the update.  A few comments upon my most recent reading of the
draft:

- Please consider starting the auth-key-id at 1 rather than 0 and leave 0
  reserved.
- You don't document the sender timestamp format.  :-)

Going back to prior discussion from the Working Group, you probably require
more clarification as to how you intend to use this mechanism.  Since you
are building upon authentication, choices include some of these and perhaps
others that haven't been raised:

- This is fine for the case where no authentication was intended to be used
  for the session. In this case, state transitions within this BFD session
  are suitable for standard use.
- This is intended only for an adjunct session.  In this case, perhaps you
  want to further document behavior in not taking the session to the Down
  state in order to permit continuous measurement at rate.
- You intend to toggle into and out of this mode?  (I suspect not, it
  complicates key rollover situations which are already a bit weak in our
  RFCs.)

-- Jeff

---

From: Santosh P K <[email-masked]>
Date: Tue, 16 Jun 2015 13:43:29 +0000

Mallik,
   We have made delay measurement an optional feature secondly we can measure RX side delay locally it is Tx side which is a problem and hence we have time stamping. We did mention that we can send timestamping info to central unit where the calculation can be done in that case BFD packet need not carry any timestamp. Did I answer your question?

Thanks
Santosh P K

From: MALLIK MUDIGONDA (mmudigon) [mailto:[email-masked]]
Sent: Friday, June 12, 2015 2:03 PM
To: Santosh P K; [email-masked]
Subject: Re: New Version Notification for draft-ashesh-bfd-stability-03.txt

Hi,

Thanks

Regards
Mallik

Hello All,

Thanks

Santosh P K

---

From: Santosh P K <[email-masked]>
Date: Tue, 16 Jun 2015 13:49:18 +0000

Jeff,

> - You don't document the sender timestamp format.  :-)

Sure will make the changes. 

> more clarification as to how you intend to use this mechanism.  Since you are
> building upon authentication, choices include some of these and perhaps

You mean how will auth work along with this change? 

>   complicates key rollover situations which are already a bit weak in our

Thanks for raising this point. I think you are right we should put in more details on this. The whole purpose of using AUTH TLV for this mechanism is because we want this to work along with normal authentication. I will add more text on how auth and this mechanism can work together. 

Thanks
Santosh P K