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,

--
marc@sniff.de>

= --Apple-Mail-1-444811863-- From gregory.mirsky@ericsson.com Mon Dec 3 11:32:41 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8639A21F884B; Mon, 3 Dec 2012 11:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J81LZoJTPHC4; Mon, 3 Dec 2012 11:32:40 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C347B21F884A; Mon, 3 Dec 2012 11:32:40 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qB3JfNFM020104; Mon, 3 Dec 2012 13:41:45 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 14:32:31 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 14:32:31 -0500 From: Gregory Mirsky To: Marc Binderberger , Shahram Davari Subject: RE: Commenst on draft-akiya-bfd-intervals-03 Thread-Topic: Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAqkOwAAChtFQA== Date: Mon, 3 Dec 2012 19:32:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:32:41 -0000 --_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 C= C/CV and Ether OAM is different time interval. Not by much but different ne= vertheless. 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: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Marc Binderberger Sent: Monday, December 03, 2012 11:08 AM To: Shahram Davari Cc: rtg-bfd@ietf.org Subject: Re: Commenst on draft-akiya-bfd-intervals-03 Hello Shahram, thanks for re-vitalizing this discussion - must admit I was busy with too m= any other things. I do agree with including the values you mention in the list of BFD support= ed values, although I question the large values. On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD i= mplementations 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 prop= osal is: 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min. Thank you, Shharam -- Marc Binderberger > --_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 discussi= on.

I agree that compatibility with i= ntervals standardized for Ether OAM (CFM/Y.1731) makes sense and might be h= elpful 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 neverth= eless.

And I agree with Marc that BFD-ba= sed 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, w= hich will be great, have a survey among providers on what interval values b= eing used (similar to great survey on PWE VCCV Control Channels).

    Regards,

     &nb= sp; Greg

From: rtg-bfd-bounces@ietf.org [mai= lto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger
Sent: Monday, December 03, 2012 11:08 AM
To: Shahram Davari
Cc: rtg-bfd@ietf.org
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 su= pported 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 prop= osal is:

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

Thank you,

Shharam

--<= /div>
Marc Binderberger <marc@sniff.de>

--_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_-- From aldrin.ietf@gmail.com Mon Dec 3 11:53:35 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FF21F87EE; Mon, 3 Dec 2012 11:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAdJPb75mkRw; Mon, 3 Dec 2012 11:53:34 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8B21F8809; Mon, 3 Dec 2012 11:53:33 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1349619dae.31 for ; Mon, 03 Dec 2012 11:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=E/waLi5LQEi/SlyjGrZKCjimRHHrL4aod4PGJALJZhY=; b=CJPFZVZiL3eo0ZrD1SJ8ar5NE1T6hzJdB+b1EBSM46fkPzs99kAazw17j8/AcEuiAF 7QCQhBMTFgQ8iMhdz9DWgLe6M+TsfphB3z/jJqKzr99hP3bYN9g7Es8ym5l2DRwnEAXJ QmW0t96nOWN/WY3+PwbFtwy8BA47u8ybKyel9Byd9VqRBcev/GaGNk0SHGXXVKSm6pul 8XyJ+4V+j/N8oJwAwvyVnjxG5wF5Q4z/X4zzZVY0r3B02n4laQ3Wp8kI4JJ7oUtMEkH3 A9IALb4DA2zl+/qvgCHSAQ/SStGkPivS+0sBsF9C4C7dewIUd+xX+5kmwceBdKFOhrUJ r8jA== Received: by 10.68.131.8 with SMTP id oi8mr32121644pbb.29.1354564412342; Mon, 03 Dec 2012 11:53:32 -0800 (PST) Received: from [192.168.255.135] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id s7sm8538920paz.7.2012.12.03.11.53.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 11:53:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 From: Sam Aldrin In-Reply-To: <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> Date: Mon, 3 Dec 2012 11:53:47 -0800 Message-Id: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> To: "Santiago Alvarez (saalvare)" X-Mailer: Apple Mail (2.1499) Cc: "mpls@ietf.org" , "pwe3@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:53:35 -0000 --Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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)" = wrote: > Applicability of BFD is pretty wide. Mandating a set of intervals = driven by Y.1731 doesn=92t 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. > =20 > SA > -- > =20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Gregory Mirsky > Sent: Monday, December 03, 2012 11:33 AM > To: Marc Binderberger; Shahram Davari > Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 > =20 > 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). > =20 > Regards, > Greg > =20 > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Marc Binderberger > Sent: Monday, December 03, 2012 11:08 AM > To: Shahram Davari > Cc: rtg-bfd@ietf.org > Subject: Re: Commenst on draft-akiya-bfd-intervals-03 >=20 > Hello Shahram, > =20 > thanks for re-vitalizing this discussion - must admit I was busy with = too many other things. > =20 > I do agree with including the values you mention in the list of BFD = supported values, although I question the large values. > =20 > 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. > =20 > =20 > Regards, Marc > =20 > =20 > =20 > =20 > =20 > On 2012-12-03, at 20:02 , Shahram Davari wrote: >=20 >=20 > 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 > =20 > -- > Marc Binderberger > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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)" <saalvare@cisco.com> = wrote:

Applicability of BFD is = pretty wide. Mandating a set of intervals driven by Y.1731 doesn=92t= 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.

--

mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory = Mirsky
Sent: Monday, December 03, 2012 = 11:33 AM
To: Marc Binderberger; Shahram = Davari
Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org
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).
        = Greg
rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc = Binderberger
Sent: Monday, December 03, 2012 = 11:08 AM
To: Shahram = Davari
Cc:  Re: Commenst on = draft-akiya-bfd-intervals-03
Hello Shahram,

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:
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:
Thank you, Shharam
Marc Binderberger = <mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls

= --Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B-- From marc@sniff.de Tue Dec 4 15:50:03 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637B521F8BB2; Tue, 4 Dec 2012 15:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STxlYa-rzE8Q; Tue, 4 Dec 2012 15:50:02 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F8421F8BB0; Tue, 4 Dec 2012 15:50:01 -0800 (PST) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 0F4F62AA0F; Tue, 4 Dec 2012 23:49:56 +0000 (GMT) Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16-548157397 From: Marc Binderberger In-Reply-To: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> Date: Wed, 5 Dec 2012 00:49:55 +0100 Message-Id: <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> To: Shahram Davari , Gregory Mirsky , "Santiago Alvarez (saalvare)" , Sam Aldrin X-Mailer: Apple Mail (2.1084) Cc: mpls@ietf.org, rtg-bfd@ietf.org, pwe3@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 23:50:03 -0000 --Apple-Mail-16-548157397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 On 2012-12-03, at 20:53 , Sam Aldrin wrote: > 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. >=20 > -sam > On Dec 3, 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" = wrote: >=20 >> Applicability of BFD is pretty wide. Mandating a set of intervals = driven by Y.1731 doesn=92t 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. >> =20 >> SA >> -- >> =20 >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Gregory Mirsky >> Sent: Monday, December 03, 2012 11:33 AM >> To: Marc Binderberger; Shahram Davari >> Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org >> Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >> =20 >> 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). >> =20 >> Regards, >> Greg >> =20 >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Marc Binderberger >> Sent: Monday, December 03, 2012 11:08 AM >> To: Shahram Davari >> Cc: rtg-bfd@ietf.org >> Subject: Re: Commenst on draft-akiya-bfd-intervals-03 >>=20 >> Hello Shahram, >> =20 >> thanks for re-vitalizing this discussion - must admit I was busy with = too many other things. >> =20 >> I do agree with including the values you mention in the list of BFD = supported values, although I question the large values. >> =20 >> 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. >> =20 >> =20 >> Regards, Marc >> =20 >> =20 >> =20 >> =20 >> =20 >> On 2012-12-03, at 20:02 , Shahram Davari wrote: >>=20 >>=20 >> 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 >> =20 >> -- >> Marc Binderberger >> =20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 -- Marc Binderberger --Apple-Mail-16-548157397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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

=

On 2012-12-03, at 20:53 , Sam Aldrin wrote:

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)" <saalvare@cisco.com> = wrote:

Applicability of BFD is = pretty wide. Mandating a set of intervals driven by Y.1731 doesn=92t= 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.

--

mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory = Mirsky
Sent: Monday, December 03, 2012 = 11:33 AM
To: Marc Binderberger; Shahram = Davari
Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org
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).
        = Greg
rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc = Binderberger
Sent: Monday, December 03, 2012 = 11:08 AM
To: Shahram = Davari
Cc:  Re: Commenst on = draft-akiya-bfd-intervals-03
Hello Shahram,

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:
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:
Thank you, Shharam
Marc Binderberger = <mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

--
Marc Binderberger = <marc@sniff.de>

= --Apple-Mail-16-548157397-- From binnyjeshan@gmail.com Sun Dec 16 06:44:43 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063DD21F8715; Sun, 16 Dec 2012 06:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+dCXX1FkPZ2; Sun, 16 Dec 2012 06:44:41 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E011E21F84EB; Sun, 16 Dec 2012 06:44:36 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so1818379qan.10 for ; Sun, 16 Dec 2012 06:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aSX4HIkwJMuIdAFsuDHgNX+SykTHKvZR1DE79DYCFfc=; b=h+xDDOYtQ/GB2G1C4dHHQ9XQAwMA6Z1mCzfoFF/DaFEYh+PzTRJFoFBXKvmcWZ3YW9 Ihz+VmiLttJLidumSBxNd7FaoE6es1NZH+y6AzxJ64/RO3WxsM8sA/odXUsUC/SKyNvC J1o0RWYEITZ3EsB172EKYMZGhSdQssV86ows4toIRf9tSM9yxXljFxoc+spQNU7oaiKN gTxdTizTMwX035ZqwebL3VdJQKdh21JD8guOqbVzEjHaWQD7TnbWeIic8F+ix+NsmHh7 +YvaDW8gjlahJpRoI64PnqbefungSF/BDaYJXpLIXTX3qIgiAH605Gc6LGqk3We38No4 vMhA== MIME-Version: 1.0 Received: by 10.229.195.211 with SMTP id ed19mr1076553qcb.78.1355669075006; Sun, 16 Dec 2012 06:44:35 -0800 (PST) Received: by 10.49.106.169 with HTTP; Sun, 16 Dec 2012 06:44:34 -0800 (PST) In-Reply-To: <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> Date: Sun, 16 Dec 2012 20:14:34 +0530 Message-ID: Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 From: Binny Jeshan To: Marc Binderberger Content-Type: multipart/alternative; boundary=005045016f07a6163604d0f94dd5 Cc: mpls@ietf.org, "Santiago Alvarez \(saalvare\)" , pwe3@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 14:44:43 -0000 --005045016f07a6163604d0f94dd5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 wrote: > 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 nee= d > 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 > > > > > On 2012-12-03, at 20:53 , Sam Aldrin wrote: > > 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)" < > saalvare@cisco.com> wrote: > > Applicability of BFD is pretty wide. Mandating a set of intervals driven > by Y.1731 doesn=92t sound like a good idea to me. Having lived through m= ost > 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:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Gregory Mirsky > *Sent:* Monday, December 03, 2012 11:33 AM > *To:* Marc Binderberger; Shahram Davari > *Cc:* mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org > *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 PWE= 3 > 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 Etherne= t > 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 documen= t. > 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:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Marc Binderberger > *Sent:* Monday, December 03, 2012 11:08 AM > *To:* Shahram Davari > *Cc:* rtg-bfd@ietf.org > *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.1a= g > 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 **** > ** ** > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > -- > Marc Binderberger > > --005045016f07a6163604d0f94dd5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello,

Looks like i missed this discussion.
I second Sam to his point - "Good to have an informational document and do not support the id= ea of standardizing the intervals"=A0

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

Regards,
=
Binny.
=
Aricent Group - India.

On 5 December 2012 05:19, Marc Binder= berger <marc@sniff.de> wrote:

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

thanks for the feedback. Input from the MPLS and P= WE3 list is welcome regarding important timer values for which we would lik= e to have a common support.

Few comments from my side:

I c= an live with an informal document, at least with respect to the "stand= ard intervals". The document shall help to improve interoperability an= d even an informal document can become de-facto standard when customers req= uest it ;-)

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

We will not make any reference to Y.1731 in the text bu= t 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 draf= t -03 version

=A0 =A0o =A03.3msec: required b= y MPLS-TP

=A0 =A0o =A010msec and 20msec: both valu= es allow to detect faster than 50msec,

=A0 =A0 =A0 when used with a multiplier of 2 or 3 (for 10msec). =A0A c= ompromise
=A0 =A0 =A0 could be a single interval of 15msec.
=

=A0 =A0o =A050msec: this seems an interval often suppor= ted by software

=A0 =A0 =A0 implementations, so the assumption here is that for conven= ience
=A0 =A0 =A0 this value should be supported.

<= /div>
=A0 =A0o =A0300msec: this would support large scale of 3 x 300mse= c setups used

=A0 =A0 =A0 by customers to have a detection time slightly below 1sec = for VoIP
=A0 =A0 =A0 setups.

=A0 =A0o = =A01sec: as mentioned in RFC5880

<= div>We also discussed some time ago that the 300msec could be replaced by 1= 00msec intervals but this still needs more discussion. And the lower interv= al range 10-50msec, especially 10-20msec, I personally tend to have more &q= uot;standard values" than less, providing more common intervals betwee= n hardware based BFD and software based BFD; it is at least my impression t= hat in this range most software-based implementations have their lower limi= t 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, 100ms= ec is obviously too slow).

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

Thanks & Regards,
Marc

<= div>
On 2012-12-03, at 20:53 , Sam Aldrin wrote:

I echo what Santiago had said in his em= ail. 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)" <saalvare@cisco.com> wro= te:

Applicability of BFD is pretty wide.=A0= Mandating a set of intervals driven by Y.1731 doesn=92t sound like a good = idea to me.=A0 Having lived through most of the BFD CC interop testing in t= he context of MPLS-TP, I can see some value in having an informational doc = that would discuss interval configuration and interoperability.

Cheers.
=A0
SA

--
=A0
<= div style=3D"border-style:solid none none;border-top-width:1pt;border-top-c= olor:rgb(181,196,223);padding:3pt 0in 0in">
From:=A0mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=A0On Behalf Of=A0Gregory Mirsky
Sent:=A0Monday, December 03, 2012 11:33 AM
To:=A0Marc Binderberger; Shahram Davari
Cc:=A0mpls@ietf.org; = rtg-bfd@ietf.org;= pwe3@ietf.org
Subject:=A0Re: [mpls] Commenst on draft-akiya-bfd-inter= vals-03
=A0

Dear Shahram, Marc, et al.,
I th= ink that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3 WGs = have a stake in this discussion.
I ag= ree that compatibility with intervals standardized for Ether OAM (CFM/Y.173= 1) makes sense and might be helpful in interworking. But I'll note that= even with the same transmission intervals failure detection in BFD-based C= C/CV and Ether OAM is different time interval. Not by much but different ne= vertheless.

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 a= ny values, at least not on Standard Track. At most it could be an informati= onal document. Or, which will be great, have a survey among providers on wh= at interval values being used (similar to great survey on PWE VCCV Control = Channels).

=A0
=A0=A0=A0 = Regards,

=A0=A0=A0=A0=A0=A0=A0 Greg
=A0
From:=A0= rtg-bfd-bounces@ietf.org=A0[mailto:rtg-bfd-bounces@iet= f.org]=A0On Behalf Of=A0Marc Binderber= ger
Sent:=A0Monday, December 03, 2012 11:08 AM
To:=A0Shahram Davari
Cc:=A0rtg-bfd@ietf.org
Subject:=A0Re: Commenst on draft-akiya-bfd-intervals-03=
Hello Shahram,

=A0
thanks for re-vitalizing this discussion - must admit I was busy with too m= any other things.
<= /u>=A0

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

=A0
On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD i= mplementations out there. So we likely need to support other values as well= to fit into the existing world.
=A0
=A0<= /div>
Regards, Marc
= =A0
=A0
=A0<= /div>
=A0
=A0<= /div>
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,

=A0Shharam

=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif"> --= =
Mar= c Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.= de>

=A0
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>

Regards,<= /div>

Binny.<= /div>

Aricent Group=A0- India.

On 16 December 2012 20:14, Binny Jesh= an <binnyjeshan@gmail.com> wrote:

Hello,

Looks like i misse= d this discussion.

I second Sam to his point - &qu= ot;Good to have an informational document and do not support the idea = of standardizing the intervals"=A0

And IMHO, i think BFD as it currently supports wide range of adjust= able 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 <marc@sniff.de> wrote:

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

thanks for the feedback. Input from the MPLS and P= WE3 list is welcome regarding important timer values for which we would lik= e to have a common support.

Few comments from my side:

I c= an live with an informal document, at least with respect to the "stand= ard intervals". The document shall help to improve interoperability an= d even an informal document can become de-facto standard when customers req= uest it ;-)

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

We will not make any reference to Y.1731 in the text bu= t 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 draf= t -03 version

=A0 =A0o =A03.3msec: required b= y MPLS-TP

=A0 =A0o =A010msec and 20msec: both valu= es allow to detect faster than 50msec,

=A0 =A0 =A0 when used with a multiplier of 2 or 3 (for 10msec). =A0A c= ompromise

=A0 =A0 =A0 could be a single interval of 15msec.

=A0 =A0o =A050msec: this seems an interval often suppor= ted by software

=A0 =A0 =A0 implementations, so the assumption here is that for conven= ience

=A0 =A0 =A0 this value should be supported.

<= /div>

=A0 =A0o =A0300msec: this would support large scale of 3 x 300mse= c setups used

=A0 =A0 =A0 by customers to have a detection time slightly below 1sec = for VoIP

=A0 =A0 =A0 setups.

=A0 =A0o = =A01sec: as mentioned in RFC5880

<= div>We also discussed some time ago that the 300msec could be replaced by 1= 00msec intervals but this still needs more discussion. And the lower interv= al range 10-50msec, especially 10-20msec, I personally tend to have more &q= uot;standard values" than less, providing more common intervals betwee= n hardware based BFD and software based BFD; it is at least my impression t= hat in this range most software-based implementations have their lower limi= t 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, 100ms= ec is obviously too slow).

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

Thanks & Regards,

Marc

On 2= 012-12-03, at 20:53 , Sam Aldrin wrote:

I echo what Santiago had said in his em= ail. 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)" <saalvare@cisco.com> wro= te:

Applicability of BFD is pretty wide.=A0= Mandating a set of intervals driven by Y.1731 doesn=92t sound like a good = idea to me.=A0 Having lived through most of the BFD CC interop testing in t= he context of MPLS-TP, I can see some value in having an informational doc = that would discuss interval configuration and interoperability.

Cheers.
=A0
SA

--
=A0
<= div style=3D"border-style:solid none none;border-top-width:1pt;border-top-c= olor:rgb(181,196,223);padding:3pt 0in 0in">
From:=A0mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=A0On Behalf Of=A0Gregory Mirsky
Sent:=A0Monday, December 03, 2012 11:33 AM
To:=A0Marc Binderberger; Shahram Davari
Cc:=A0mpls@ietf.org; = rtg-bfd@ietf.org;= pwe3@ietf.org
Subject:=A0Re: [mpls] Commenst on draft-akiya-bfd-inter= vals-03
=A0

Dear Shahram, Marc, et al.,
I th= ink that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3 WGs = have a stake in this discussion.
I ag= ree that compatibility with intervals standardized for Ether OAM (CFM/Y.173= 1) makes sense and might be helpful in interworking. But I'll note that= even with the same transmission intervals failure detection in BFD-based C= C/CV and Ether OAM is different time interval. Not by much but different ne= vertheless.

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 a= ny values, at least not on Standard Track. At most it could be an informati= onal document. Or, which will be great, have a survey among providers on wh= at interval values being used (similar to great survey on PWE VCCV Control = Channels).

=A0
=A0=A0=A0 = Regards,

=A0=A0=A0=A0=A0=A0=A0 Greg
=A0
From:=A0= rtg-bfd-bounces@ietf.org=A0[mailto:rtg-bfd-bounces@iet= f.org]=A0On Behalf Of=A0Marc Binderber= ger
Sent:=A0Monday, December 03, 2012 11:08 AM
To:=A0Shahram Davari
Cc:=A0rtg-bfd@ietf.org
Subject:=A0Re: Commenst on draft-akiya-bfd-intervals-03=
Hello Shahram,

=A0
thanks for re-vitalizing this discussion - must admit I was busy with too m= any other things.
<= /u>=A0

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

=A0
On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD i= mplementations out there. So we likely need to support other values as well= to fit into the existing world.
=A0
=A0<= /div>
Regards, Marc
= =A0
=A0
=A0<= /div>
=A0
=A0<= /div>
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,

=A0Shharam

=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif"> --= =
Mar= c Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.= de>

=A0
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>

--047d7bdc06f09727da04d0f9614e-- From internet-drafts@ietf.org Mon Dec 17 14:44:38 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3A321F8946; Mon, 17 Dec 2012 14:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctGBO1W2zFOp; Mon, 17 Dec 2012 14:44:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B12021F892A; Mon, 17 Dec 2012 14:44:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217224437.2882.94018.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 14:44:37 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:44:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-12.txt Pages : 38 Date : 2012-12-17 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 26 12:14:54 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917921F8CE0; Wed, 26 Dec 2012 12:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72MPWHHB7qyI; Wed, 26 Dec 2012 12:14:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170321F8CDE; Wed, 26 Dec 2012 12:14:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mpls-mib-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121226201453.27822.29805.idtracker@ietfa.amsl.com> Date: Wed, 26 Dec 2012 12:14:53 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 20:14:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base (MIB) extensions for MPL= S and MPLS-TP Networks Author(s) : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-bfd-mpls-mib-01.txt Pages : 20 Date : 2012-12-26 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mpls-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/