Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15)

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 2 Jul 2014 14:07:08 +0000

Hi Jeff,

As a co-author of this document, I believe the document provides helpful information and is ready for publication.

Thanks!

-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Monday, June 30, 2014 12:39 PM
> To: [email-masked]
> Subject: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15)
> 
> Working Group,
> 
> We would like to initiate the start of Working Group Last Call for Common
> Interval Support in BFD:
> 
> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01
> 
> Note that the intended status of this document is INFORMATIONAL.
> 
> Please send your comments, including whether you think the draft is ready
> for publication or not, to the list no later than July 15.
> 
> -- Jeff and Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 2 Jul 2014 18:51:38 +0000

Hi Jeff,
I completely agree with my co-author Nobo.
The document is concise and would help to improve interoperability of BFD implementations.
The document is ready for publication.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Wednesday, July 02, 2014 7:07 AM
To: Jeffrey Haas; [email-masked]
Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15)

Hi Jeff,

Thanks!

-Nobo

> We would like to initiate the start of Working Group Last Call for 
> Common Interval Support in BFD:
> 
> Please send your comments, including whether you think the draft is 
> ready for publication or not, to the list no later than July 15.
> 
> -- Jeff and Nobo

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 2 Jul 2014 19:45:09 +0000

Hi,

Support this draft, not much to add to the points authors have already brought.

Regards,
Jeff

> On Jul 2, 2014, at 11:51 AM, "Gregory Mirsky" <[email-masked]> wrote:
> 
> Hi Jeff,

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 4 Jul 2014 00:40:30 -0700

Hello Jeff et al.,

it won't surprise you when I think it's an awesome draft and that I support 
the publication :-)

Seriously: the draft will help vendors to support the "right" intervals and 
customers will benefit from the interoperability. I consider the set of 
intervals a fair compromise of the various objectives and the feedback 
received from this list.

Regards, Marc

---

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Fri, 4 Jul 2014 08:02:11 +0000

As a member of the team which is involved in the contents of the draft, I
support this draft and find it ready for publication.

Thanks
Srihari

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 6 Jul 2014 18:51:03 -0400

We are coming up on the second week of this WGLC and have thus far only
heard from one non-author. :-)  Please take a moment and review this draft,
especially if you are an implementor. 

-- Jeff

---

From: Binny Jeshan <[email-masked]>
Date: Mon, 7 Jul 2014 13:07:54 +0530

Hi,

I honestly do not support a need of a new draft to impose Timing standards
to BFD Intervals.
As someone who had implemented BFD across various granularity of intervals
and testing them with interop environment, i would say it wasn't difficult
to get things right. And as a SW implementor, i just see that if this Draft
is referred in my System Requirements, i may just verify BFD sessions with
these timers to ensure conformance. I do not see any additional pain relief
:)

AFAIK, Just like the SW flexibility, HW was too able to pick up varied
timer intervals - and if it did not, it was known and agreed with the
requirements.

However, as i see that its an Informational Document, and i do remember a
discussion about an year back to make it so.

So, you may keep this as a guide of operators to set requirements to
Vendors. That's it what i would look at it.

Thanks,
Binny.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Jul 2014 10:31:06 -0400

Binny,

> discussion about an year back to make it so.

It is.

> Vendors. That's it what i would look at it.

And given that context, would you support the document?

-- Jeff

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 7 Jul 2014 16:12:13 +0000

Hello Jeff,
  From an implementer's perspective, I see this draft adds value by steering implementations towards a point of convergence. I support this draft for publication.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, July 07, 2014 4:21 AM
To: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15)

We are coming up on the second week of this WGLC and have thus far only heard from one non-author. :-)  Please take a moment and review this draft, especially if you are an implementor. 

-- Jeff

---

From: Pablo Frank <[email-masked]>
Date: Mon, 7 Jul 2014 14:49:41 -0400

I'm working on a HW implementation that supports the proposed intervals and
the draft was useful in that context.  I can see that the non-Y.1731
standard intervals (i.e. 20ms, 50ms) could prove a challenge for some
existing hardware implementations, but these rates should be within the
capability of most software implementations.  Even for existing hardware
implementations, since the new rates are a multiple of 10ms, it's usually
not *that* challenging.  So yes/support.

regards,
Pablo

On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) <
[email-masked]> wrote:

> Hello Jeff,
>   From an implementer's perspective, I see this draft adds value by
> steering implementations towards a point of convergence. I support this
> draft for publication.
> Thanks
> Prasad
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 8 Jul 2014 17:42:41 -0700

Jeff et. all,

Having just tried an interoperability BFD test between two vendor boxes, I
can see why having the defined common intervals would be useful. So yes, a
support for the draft.

Would it be helpful to have some rational for why the said intervals were
selected? Typical rationals that I have heard for the faster intervals are
that operators want a 50ms protection switchover. For that 3.3ms and 10ms
meet the detection requirements. What goal is 20ms trying to achieve?

A 100ms and 1s intervals are helpful for applications that do not have
stringent requirements (e.g. protection of a voice stream) but can benefit
from a quick detection. Examples include routing protocols that use BFD as
a hello protocol.

On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank <[email-masked]> wrote:

> I'm working on a HW implementation that supports the proposed intervals
> and the draft was useful in that context.  I can see that the non-Y.1731

-- 
Mahesh Jethanandani
[email-masked]

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 8 Jul 2014 21:27:58 -0700

Hello Mahesh,

appendix A of the draft is explaining the selection.

Best regards,
Marc

On Tue, 8 Jul 2014 17:42:41 -0700, Mahesh Jethanandani wrote:
>> On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) 
>> <[email-masked]> wrote:
>>> Hello Jeff,
>>> heard from one non-author. :-)  Please take a moment and review this 
>>> draft, especially if you are an implementor.
>>> 
>>> -- Jeff
>>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 10 Jul 2014 06:46:40 -0700

That is what happens when you have read the complete draft :-(

Question around the explanation provided in Appendix A. 

For 3.3ms: required by MPLS-TP -  is there a reference you can cite? Also, is this a requirement only for MPLS-TP?

The rational for 20ms applies to 10ms (with a multiplier of 3) and explains the why. Better than saying general consensus and not explaining the why. Would you agree?

Mahesh Jethanandani
[email-masked]

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 13 Jul 2014 23:53:55 -0700

Hello Mahesh,

> That is what happens when you have read the complete draft :-(

the full 8 pages, yes ;-)

> is this a requirement only for MPLS-TP?

MPLS-TP was at least driving this requirement. I have to ask my MPLS 
colleagues if this has been written down explicitly meanwhile.

> The rational for 20ms applies to 10ms (with a multiplier of 3) and explains 
> the why. Better than saying general consensus and not explaining the why. 
> Would you agree?

Various people have expressed their strong interest to have 10msec in the set 
of intervals. For various reasons. The ability to detect/restore in 50-60msec 
is of course important but even more important was the fact that many vendors 
are about to implement or have already implemented 10msec. That's why I wrote 
"general consensus" instead of trying to rationalize the value.

Regards, Marc

>>>>> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals 
>>>>> (ending 
>>>>> July 15)
>>>>>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Jul 2014 17:08:31 +0000

Hi Marc, Mahesh, et. al,
to the best of my knowledge, I've added MPLS WG to the discussion in case I have missed it, there's no explicit requirement to support 3.3 msec for the benefit of MPLS-TP. But as we consider MPLS-TP to be foundation for packet-switched transport and that there's explicit requirement to support sub-50 msec protection switchover, then we conclude that, like in TDM transport, 10 msec is budgeted to detect a defect. Hence CFM/Y.1731 require support of 3.3 msec. I think that support of 3.3 msec by a BFD implementation is a requirement if sub-50 msec protection to be provided in a network. (Note, that actual detection by CFM/Y.1731 and BFD will vary slightly.)

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Sunday, July 13, 2014 11:54 PM
To: Mahesh Jethanandani
Cc: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15)

Hello Mahesh,

> For 3.3ms: required by MPLS-TP -  is there a reference you can cite? 
> Also, is this a requirement only for MPLS-TP?

MPLS-TP was at least driving this requirement. I have to ask my MPLS colleagues if this has been written down explicitly meanwhile.

Regards, Marc

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 15 Jul 2014 09:49:02 -0700

Hello Greg et al.,

indeed, I got a similar feedback from my colleagues working on MPLS-TP. Have 
to look into the particular documents (e.g. G.783) to see it with my own eyes 
but it seems the budget is 10msec detection + 50msec restoration. Always 
thought it's the other way around.

Then the 10msec detection time lead to 3 x 3.3msec, yes.

I will update our document with a sentence, especially as I haven't found any 
IETF reference (draft/RFC) with an explicit requirement for MPLS-TP. It's 
"borrowed" from Sonet/SDH specs.

Thanks for confirming!

Regards, Martc

On Mon, 14 Jul 2014 17:08:31 +0000, Gregory Mirsky wrote:
> Hi Marc, Mahesh, et. al,
> to the best of my knowledge, I've added MPLS WG to the discussion in case I 
> have missed it, there's no explicit requirement to support 3.3 msec for the 
> benefit of MPLS-TP. But as we consider MPLS-TP to be foundation for 
> packet-switched transport and that there's explicit requirement to support 
> sub-50 msec protection switchover, then we conclude that, like in TDM 
> transport, 10 msec is budgeted to detect a defect. Hence CFM/Y.1731 require 
> support of 3.3 msec. I think that support of 3.3 msec by a BFD 
> implementation is a requirement if sub-50 msec protection to be provided in 
> a network. (Note, that actual detection by CFM/Y.1731 and BFD will vary 
> slightly.)
> 
> 	Regards,
> 		Greg
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Jul 2014 14:04:44 -0400

> for publication or not, to the list no later than July 15.

WGLC has concluded.  My judgment is that while support from non-authors is
somewhat weak, there has been no objection to the draft.  

Given that the author set also represents multiple vendors and that the
status of this Informational draft is to assist in the creation of BFD
stacks that are cross-vendor interoperable, I believe this document has
sufficient consensus to continue.

Marc had one additional clarification regarding the 3.3ms value to be added
to the document.  Once an I-D has been published containing this
information, the document will be submitted to the IESG.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 27 Jul 2014 13:01:46 -0700

Hello Jeff & BFD experts,

> information, the document will be submitted to the IESG.

version -02 uploaded:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-bfd-intervals-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-02

Thanks & Regards,
Marc

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 27 Jul 2014 20:38:19 +0000

Many thanks, Marc! 

		Regards,
			Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Sunday, July 27, 2014 1:02 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: WGLC concluded for draft-ietf-bfd-intervals 

> Marc had one additional clarification regarding the 3.3ms value to be 
> added to the document.  Once an I-D has been published containing this 

version -02 uploaded:

Thanks & Regards,
Marc

On Wed, 16 Jul 2014 14:04:44 -0400, Jeffrey Haas wrote:
> WGLC has concluded.  My judgment is that while support from 
> non-authors is somewhat weak, there has been no objection to the draft.
> 
> Given that the author set also represents multiple vendors and that 
> the status of this Informational draft is to assist in the creation of 
> BFD stacks that are cross-vendor interoperable, I believe this 
> document has sufficient consensus to continue.
> 
> Marc had one additional clarification regarding the 3.3ms value to be 
> added to the document.  Once an I-D has been published containing this

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Jul 2014 12:28:21 -0400

> https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/

The change covers the lingering discussion item.  I've done the shepherd
writeup and have submited the document to the IESG for publication.

-- Jeff