Subject: RE: Commenst on draft-akiya-bfd-intervals-03

From: "Shahram Davari" <[email-masked]>
Date: Mon, 3 Dec 2012 19:02:58 +0000

Hi,

I would like to propose standardizing the same intervals as Y.1731/802.1ag for BFD. This would make the total L2, L3 OAM more homogeneous. So the proposal is:

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

Thank you,
 Shharam

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 3 Dec 2012 20:07:30 +0100

Hello Shahram,

thanks for re-vitalizing this discussion - must admit I was busy with too many other things.

I do agree with including the values you mention in the list of BFD supported values, although I question the large values.

On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD implementations out there. So we likely need to support other values as well to fit into the existing world.

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 3 Dec 2012 19:32:30 +0000

Dear Shahram, Marc, et al.,
I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3 WGs have a stake in this discussion.
I agree that compatibility with intervals standardized for Ether OAM (CFM/Y.1731) makes sense and might be helpful in interworking. But I'll note that even with the same transmission intervals failure detection in BFD-based CC/CV and Ether OAM is different time interval. Not by much but different nevertheless.
And I agree with Marc that BFD-based CC is not only for packet or Ethernet transport applications. And more values of transmission interval are useful. That is why I believe that we should not standardize any values, at least not on Standard Track. At most it could be an informational document. Or, which will be great, have a survey among providers on what interval values being used (similar to great survey on PWE VCCV Control Channels).

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Monday, December 03, 2012 11:08 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: Commenst on draft-akiya-bfd-intervals-03

Hello Shahram,

Regards, Marc

Hi,

--
Marc Binderberger           <[email-masked]<mailto:[email-masked]>>

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 3 Dec 2012 11:53:47 -0800

I echo what Santiago had said in his email. Good to have an informational document and do not support the idea of standardizing the intervals.

-sam
On Dec 3, 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" <[email-masked]> wrote:

> Applicability of BFD is pretty wide.  Mandating a set of intervals driven by Y.1731 doesn’t sound like a good idea to me.  Having lived through most of the BFD CC interop testing in the context of MPLS-TP, I can see some value in having an informational doc that would discuss interval configuration and interoperability.
> Cheers.
>  
> SA
> --
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
> Sent: Monday, December 03, 2012 11:33 AM
> To: Marc Binderberger; Shahram Davari
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03
>  
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 5 Dec 2012 00:49:55 +0100

Hello Sam, Santiago, Gregory, Sharam et al.,

thanks for the feedback. Input from the MPLS and PWE3 list is welcome regarding important timer values for which we would like to have a common support.

Few comments from my side:

I can live with an informal document, at least with respect to the "standard intervals". The document shall help to improve interoperability and even an informal document can become de-facto standard when customers request it ;-)

There is the aspect of the multiple poll/final sequences to find the next common interval. I think it is covered by RFC5880 but this statement may require more discussion on the BFD list. If not covered then we would need a standard, I think.

We will not make any reference to Y.1731 in the text but where intervals we proposed are close to Y.1731 intervals I'm fine to adjust to Y.1731 values, which may make a combined "OAM hardware" simpler/cheaper.

We list the following values in the draft -03 version

   o  3.3msec: required by MPLS-TP

   o  10msec and 20msec: both values allow to detect faster than 50msec,
      when used with a multiplier of 2 or 3 (for 10msec).  A compromise
      could be a single interval of 15msec.

   o  50msec: this seems an interval often supported by software
      implementations, so the assumption here is that for convenience
      this value should be supported.

   o  300msec: this would support large scale of 3 x 300msec setups used
      by customers to have a detection time slightly below 1sec for VoIP
      setups.

   o  1sec: as mentioned in RFC5880

We also discussed some time ago that the 300msec could be replaced by 100msec intervals but this still needs more discussion. And the lower interval range 10-50msec, especially 10-20msec, I personally tend to have more "standard values" than less, providing more common intervals between hardware based BFD and software based BFD; it is at least my impression that in this range most software-based implementations have their lower limit and the more common intervals the easier we can support 50-60msec detect+restore even with software-based BFD (10msec may just push the limit, 100msec is obviously too slow).

This is vague beside the 3.3msec and 1sec, so again if good reasons exist for specific values from the MPLS, MPLS-TP and PWE3 standards or applications: input is very welcome!

Thanks & Regards,
Marc

---

From: Binny Jeshan <[email-masked]>
Date: Sun, 16 Dec 2012 20:14:34 +0530

Hello,

Looks like i missed this discussion.

I second Sam to his point - "Good to have an informational document and do
not support the idea of standardizing the intervals"

And IMHO, i think BFD as it currently supports wide range of adjustable
timer intervals has given good flexibility for troubleshooting faults like
packet drops in high bandwidth links.

Regards,
Binny.
Aricent Group - India.

On 5 December 2012 05:19, Marc Binderberger <[email-masked]> wrote:

> thanks for the feedback. Input from the MPLS and PWE3 list is welcome
> regarding important timer values for which we would like to have a common
> support.
>
> I can live with an informal document, at least with respect to the
> "standard intervals". The document shall help to improve interoperability
> and even an informal document can become de-facto standard when customers
> request it ;-)
>
> There is the aspect of the multiple poll/final sequences to find the next
> common interval. I think it is covered by RFC5880 but this statement may
> require more discussion on the BFD list. If not covered then we would need
> a standard, I think.
>
> We will not make any reference to Y.1731 in the text but where intervals
> we proposed are close to Y.1731 intervals I'm fine to adjust to Y.1731
> values, which may make a combined "OAM hardware" simpler/cheaper.
>
>
> We also discussed some time ago that the 300msec could be replaced by
> 100msec intervals but this still needs more discussion. And the lower
> interval range 10-50msec, especially 10-20msec, I personally tend to have
> more "standard values" than less, providing more common intervals between
> hardware based BFD and software based BFD; it is at least my impression
> that in this range most software-based implementations have their lower
> limit and the more common intervals the easier we can support 50-60msec
> detect+restore even with software-based BFD (10msec may just push the
> limit, 100msec is obviously too slow).
>
>
> This is vague beside the 3.3msec and 1sec, so again if good reasons exist
> for specific values from the MPLS, MPLS-TP and PWE3 standards or
> applications: input is very welcome!
>
>
> Thanks & Regards,
> Marc
>
>
>
>
> I echo what Santiago had said in his email. Good to have an informational
> document and do not support the idea of standardizing the intervals.
>
> -sam
> Applicability of BFD is pretty wide.  Mandating a set of intervals driven
> by Y.1731 doesn’t sound like a good idea to me.  Having lived through most
> of the BFD CC interop testing in the context of MPLS-TP, I can see some
> value in having an informational doc that would discuss interval
> configuration and interoperability.****
> Cheers.****
>
> SA****
> --****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
>  *Gregory Mirsky
> *Sent:* Monday, December 03, 2012 11:33 AM
> *To:* Marc Binderberger; Shahram Davari
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [mpls] Commenst on draft-akiya-bfd-intervals-03****
> ** **
> Dear Shahram, Marc, et al.,****
> I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3
> WGs have a stake in this discussion.****
> I agree that compatibility with intervals standardized for Ether OAM
> (CFM/Y.1731) makes sense and might be helpful in interworking. But I'll
> note that even with the same transmission intervals failure detection in
> BFD-based CC/CV and Ether OAM is different time interval. Not by much but
> different nevertheless.****
> And I agree with Marc that BFD-based CC is not only for packet or Ethernet
> transport applications. And more values of transmission interval are
> useful. That is why I believe that we should not standardize any values, at
> least not on Standard Track. At most it could be an informational document.
> Or, which will be great, have a survey among providers on what interval
> values being used (similar to great survey on PWE VCCV Control Channels).*
> ***
>  ****
>     Regards,****
>         Greg****
> ** **
> ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *Marc Binderberger
> *Sent:* Monday, December 03, 2012 11:08 AM
> *To:* Shahram Davari
> *Cc:* [email-masked]
> *Subject:* Re: Commenst on draft-akiya-bfd-intervals-03****
> Hello Shahram,****
> ** **
> thanks for re-vitalizing this discussion - must admit I was busy with too
> many other things.****
> ** **
> I do agree with including the values you mention in the list of BFD
> supported values, although I question the large values.****
> ** **
> On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD
> implementations out there. So we likely need to support other values as
> well to fit into the existing world.****
> ** **
> ** **
> Regards, Marc****
> ** **
> ** **
> ** **
> ** **
> ** **
> On 2012-12-03, at 20:02 , Shahram Davari wrote:****
>
>
> ****
> Hi,****
> I would like to propose standardizing the same intervals as Y.1731/802.1ag
> for BFD. This would make the total L2, L3 OAM more homogeneous. So the
> proposal is:****
> 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min.****
> Thank you,****
>  Shharam****
> ** **
> --****
> Marc Binderberger           <[email-masked]>****
> ** **

---

From: Binny Jeshan <[email-masked]>
Date: Sun, 16 Dec 2012 20:20:09 +0530

Hello Marc,

You mentioned,

"* **There is the aspect of the multiple poll/final sequences to find the
next common interval. I think it is covered by RFC5880 but this statement
may require more discussion on the BFD list. If not covered then we would
need a standard, I think. *"

Could you please describe more on this, if not in this discussion mail, you
can choose to do it in another mail. This topic interests me :), as i'd
like to know what is missing or needs to be covered.

Regards,
Binny.
Aricent Group - India.

On 16 December 2012 20:14, Binny Jeshan <[email-masked]> wrote:

> I second Sam to his point - "Good to have an informational document and
> do not support the idea of standardizing the intervals"
>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Gregory Mirsky
>> I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and
>> PWE3 WGs have a stake in this discussion.****
>> And I agree with Marc that BFD-based CC is not only for packet or
>> Ethernet transport applications. And more values of transmission interval
>> are useful. That is why I believe that we should not standardize any
>> values, at least not on Standard Track. At most it could be an
>> informational document. Or, which will be great, have a survey among
>> providers on what interval values being used (similar to great survey on
>> PWE VCCV Control Channels).****
>>  ****
>>     Regards,****
>>         Greg****
>> ** **
>> I would like to propose standardizing the same intervals as
>> Y.1731/802.1ag for BFD. This would make the total L2, L3 OAM more
>> homogeneous. So the proposal is:****