Subject: Poll - working group adoption of draft-akiya-bfd-intervals

From: Jeffrey Haas <[email-masked]>
Date: Tue, 12 Nov 2013 15:37:01 -0500

Working Group,

Part of our discussion at IETF 88 in Vancouver was with regard to the draft
"Standardized interval support in BFD", draft-akiya-bfd-intervals.

Prior discussion of this draft suggested that making the intervals mandatory
was probably over-reaching the work we'd like to do.  However, there's
interest in pursuing this work in an Informational context.  A longer term
goal of the document would be to achieve Best Current Practice (BCP) status.

A poll of the room in Vancouver indicated good support to take on this work.
Since this is somewhat out of our current charter, we'd be seeking a
re-charter to cover this specific task.

Please indicate to the Working Group mailing list if you'd support or don't
support adoption of this draft as a Working Group document.

If there is sufficient support, we'll initiate the re-chartering, probably
along with the S-BFD work.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 12 Nov 2013 13:12:08 -0800

Support.

Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 12 Nov 2013 21:20:59 +0000

Speaking as a co-author of the draft, I believe such BCP document will significantly reduce potential interoperability issues with HW based BFD, thus support.

-Nobo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jeffrey Haas
> Sent: Tuesday, November 12, 2013 3:37 PM
> To: [email-masked]
> Subject: Poll - working group adoption of draft-akiya-bfd-intervals
> 
> Working Group,
> 
> Since this is somewhat out of our current charter, we'd be seeking a re-
> charter to cover this specific task.
> 
> If there is sufficient support, we'll initiate the re-chartering, probably along
> with the S-BFD work.
> 
> -- Jeff

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 12 Nov 2013 21:32:07 +0000

Hi Jeff,

I support defining a list of intervals that must be supported. However I would like to propose matching the rates to the

ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM.

Y.1731 rates are:

3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min.

Thx

Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: [email-masked]
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

Working Group,

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 12 Nov 2013 16:54:56 -0500

> "Standardized interval support in BFD", draft-akiya-bfd-intervals.

The authors have been requested to refresh the document.  At the moment,
here's a link to the last published version.

http://tools.ietf.org/html/draft-akiya-bfd-intervals-03

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 12 Nov 2013 21:55:09 +0000

Hi Shahram,

Agree, there are specific base timer values that would be beneficial to support. For next revision (for BCP) is really to aim for much wider interval spectrum by describing techniques using few timer sets: i.e. few timers & multiple of those timers + jitter considerations.

-Nobo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, November 12, 2013 4:32 PM
To: Jeffrey Haas; [email-masked]
Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals

Hi Jeff,

Y.1731 rates are:

Thx

Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

Working Group,

-- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 12 Nov 2013 21:57:16 +0000

Hello,
I'd note that current version is targeting document for Standard track. Hope authors would consider changing to Informational track instead.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 1:55 PM
To: [email-masked]
Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals

On Tue, Nov 12, 2013 at 03:37:01PM -0500, Jeffrey Haas wrote:
> Part of our discussion at IETF 88 in Vancouver was with regard to the 
> draft "Standardized interval support in BFD", draft-akiya-bfd-intervals.

The authors have been requested to refresh the document.  At the moment, here's a link to the last published version.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 12 Nov 2013 14:02:03 -0800

Hello Shahram,

this is on the list of things to be updated and further discussed. 

Point is: where it doesn't hurt existing BFD implementations: ok. But 
BFD is not a greenfield protocol anymore and in reality you find quite 
a number of (software-based) implementations that run as fast as 50msec 
while 10msec is a bit of a stretch. 

The Y.1731 intervals would not necessarily fit the demand in the 
mid-milisecond range.

Regards, Marc

On Tue, 12 Nov 2013 21:32:07 +0000, Shahram Davari wrote:
> Hi Jeff,
>  
> I support defining a list of intervals that must be supported. 
> However I would like to propose matching the rates to the

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 12 Nov 2013 14:10:41 -0800

Hello Gregory,

yes, that's the agreement: make it informational.
We are jut updating the document, mainly these few formal aspects, to 
have a cleaner re-start situation.

Regards, Marc

On Tue, 12 Nov 2013 21:57:16 +0000, Gregory Mirsky wrote:
> Hello,
> I'd note that current version is targeting document for Standard 
> track. Hope authors would consider changing to Informational track 
> instead.
> 
> 	Regards,
> 		Greg
> 
> The authors have been requested to refresh the document.  At the 
> moment, here's a link to the last published version.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 12 Nov 2013 22:11:59 +0000

Hi Shahram, et. al,
I agree that better alignment with Ethernet OAM is beneficial. Adding 100 ms, 10 sec, and 1 min would be step in that direction. 10 min might be not really practical.
But I want to remind that BFD and Ethernet CFM differently interpret time interval and, as result, when connectivity failure gets detected. For BFD based CC/CV, if Detect Multiplier == 3 and Interval == 100msec, detection would be between 225msec and 300msec. For Ethernet OAM CCM with interval 100msec detection would be between 300msec and 325msec. So, as we see having intervals same in BFD and Ethernet OAM makes interworking only somewhat easier.

                Regards,
                                Greg

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, November 12, 2013 1:32 PM
To: Jeffrey Haas; [email-masked]
Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals

Hi Jeff,

Y.1731 rates are:

Thx

Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

Working Group,

-- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 12 Nov 2013 22:24:15 +0000

Hi Marc,
I think that MPLS-TP CC/CV presents a good case where support of 3.3msec and 10msec is somewhat of a SHOULD if not a MUST. It can be explained in the Informational document, I think. I can write a paragraph or two.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Tuesday, November 12, 2013 2:02 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals

Hello Shahram,

Point is: where it doesn't hurt existing BFD implementations: ok. But BFD is not a greenfield protocol anymore and in reality you find quite a number of (software-based) implementations that run as fast as 50msec while 10msec is a bit of a stretch. 

The Y.1731 intervals would not necessarily fit the demand in the mid-milisecond range.

Regards, Marc

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 12 Nov 2013 15:10:53 -0800

Support. 

Mahesh Jethanandani 
[email-masked]

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 12 Nov 2013 16:22:32 -0800

I support this document to become WG document, informational as opposed to
standards track.
Would prefer it to become BCP with different scenarios captured and
recommended intervals used in various deployments of the same.

cheers
-sam

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Nov 2013 00:57:35 +0000

Agree.

And support the adoption.

Best regards,
Mach

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Wednesday, November 13, 2013 8:23 AM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals

I support this document to become WG document, informational as opposed to standards track.
Would prefer it to become BCP with different scenarios captured and recommended intervals used in various deployments of the same.

cheers
-sam

On Tue, Nov 12, 2013 at 12:37 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Working Group,

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 14 Nov 2013 17:52:09 -0800

I am curious why we would want to support anything at or above 10s for
timeout interval in BFD.

If I look at some of the OSPF implementations out there, they support a
"fast hello timeout" of 10s for ethernet and 30s for a non-broadcast
network.

On Tue, Nov 12, 2013 at 1:32 PM, Shahram Davari <[email-masked]> wrote:

>  Hi Jeff,
>
>
>
> I support defining a list of intervals that must be supported. However I
> would like to propose matching the rates to the
>

-- 
Mahesh Jethanandani
[email-masked]

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 20 Nov 2013 23:17:52 +0000

It'll be a good idea to have terminology section in the document (ex: timeout interval and timer interval are two different things).

Steady state under small scale, 10 seconds "timeout interval" is probably rarely used. With that said, given that software based BFD had use-cases for large intervals, I agree that it'll be beneficial to also discuss about how "high" HW based BFD may go up to.

-Nobo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Thursday, November 14, 2013 8:52 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals

I am curious why we would want to support anything at or above 10s for timeout interval in BFD.

If I look at some of the OSPF implementations out there, they support a "fast hello timeout" of 10s for ethernet and 30s for a non-broadcast network.

On Tue, Nov 12, 2013 at 1:32 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff,

Y.1731 rates are:

Thx

Shahram

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

Working Group,

-- Jeff

--
Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 20 Nov 2013 17:01:00 -0800

Hello,

the larger intervals are one way to do graceful restart in BFD.

Originally we did not have them on our "radar". Personally I assumed 
implementations would use software for the larger intervals. But 
meanwhile I learned the hardware colleagues want it all ;-)

10 sec with a multiplier of 255 is about 42 minutes. 1sec x 255 is 
"only" 4.2 minutes, which is much closer to restart times (not the 
process but the whole OS) I've seen. The 10sec would offer some peace 
of mind.

For 1 and 10 minute I'm curious myself if someone has a use-case?

Regards, Marc

On Wed, 20 Nov 2013 23:17:52 +0000, Nobo Akiya (nobo) wrote:
> It’ll be a good idea to have terminology section in the document (ex: 
> timeout interval and timer interval are two different things).
>  
> Steady state under small scale, 10 seconds “timeout interval” is 
> probably rarely used. With that said, given that software based BFD 
> had use-cases for large intervals, I agree that it’ll be beneficial 
> to also discuss about how “high” HW based BFD may go up to.
>  
> -Nobo
>  
> Behalf Of Mahesh Jethanandani
> If I look at some of the OSPF implementations out there, they support 
> a "fast hello timeout" of 10s for ethernet and 30s for a 
> non-broadcast network.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 22 Nov 2013 09:55:59 -0500

The mailing list shows good interest for adopting this draft as a WG item.
Those who showed interest in the room at IETF-88 in Vancouver were
sufficiently disjoint from those who showed interest on the list for this to
be a pretty good showing in BFD-WG-land. :-)

A re-chartering request will be sent out to our AD next week to take on this
item.

-- Jeff