Re: [mpls] Commenst on draft-akiya-bfd-intervals-03
Marc Binderberger <marc@sniff.de> Tue, 04 December 2012 23:50 UTC
Return-Path: <marc@sniff.de>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@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)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-16-548157397"
From: Marc Binderberger <marc@sniff.de>
In-Reply-To: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com>
Date: Wed, 05 Dec 2012 00:49:55 +0100
Message-Id: <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de>
References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <CC0AACF6-E747-4C99-9ABD-2AAEC437367F@sniff.de> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com>
To: Shahram Davari <davari@broadcom.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "Santiago Alvarez (saalvare)" <saalvare@cisco.com>, Sam Aldrin <aldrin.ietf@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: mpls@ietf.org, rtg-bfd@ietf.org, pwe3@ietf.org
Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 23:50:03 -0000
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’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: 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). >> >> 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.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 <marc@sniff.de> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > -- Marc Binderberger <marc@sniff.de>
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Gregory Mirsky
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Santiago Alvarez (saalvare)
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Sam Aldrin
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Marc Binderberger
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Binny Jeshan
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Binny Jeshan
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Jeffrey Haas
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Nobo Akiya (nobo)
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Marc Binderberger
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Nobo Akiya (nobo)
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Jeffrey Haas