Re: [mpls] Commenst on draft-akiya-bfd-intervals-03
Binny Jeshan <binnyjeshan@gmail.com> Sun, 16 December 2012 14:50 UTC
Return-Path: <binnyjeshan@gmail.com>
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 807A921F87BC; Sun, 16 Dec 2012 06:50:14 -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 4NVBo+WFFqpq; Sun, 16 Dec 2012 06:50:10 -0800 (PST)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6D58A21F87B6; Sun, 16 Dec 2012 06:50:10 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id k19so3411191qcs.27 for <multiple recipients>; Sun, 16 Dec 2012 06:50:09 -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=cUJiGws3f/eBo6Lb9eqE7MeNFIWFJt4TbKCXVbpYdrM=; b=mR3ROrgOjrBHc5mlo2JDFlAWwdnDb63ZT7A2woprgJzxjALXS/ODSU/DKa8XvrHYjD SUaBy7k14lz9DDizYJnOHBJW2iPGHIMRJ3Rd4ChhENp9KofR1yupEs6NhTXqQwpfdUps P1n6afk2jtqP6GwxfVHrKV6zvr5IS4qN7VwdF0B5RiJHvC6YF8kOUpoZocZpFX9LzlOn gISoAoGlwD8jETVHMoz7oyJX8uWVT/0ISv1NjbpuAPySrNLYSGI8WouTn7koUtlW5LyI VFyqE/5TIwq5qwMbvW2O0shZomo8gnCopoChIcB0TaN5sssQf/jmazRxurUnLTeyiwNk 7z4g==
MIME-Version: 1.0
Received: by 10.49.131.67 with SMTP id ok3mr5798307qeb.42.1355669409572; Sun, 16 Dec 2012 06:50:09 -0800 (PST)
Received: by 10.49.106.169 with HTTP; Sun, 16 Dec 2012 06:50:09 -0800 (PST)
In-Reply-To: <CAHcPYOz0SZZGFyK_SoVz-QyQ7qxA9UarzTebdi_Y-e952PwcjQ@mail.gmail.com>
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> <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> <CAHcPYOz0SZZGFyK_SoVz-QyQ7qxA9UarzTebdi_Y-e952PwcjQ@mail.gmail.com>
Date: Sun, 16 Dec 2012 20:20:09 +0530
Message-ID: <CAHcPYOzk5qpKxveutZCx8nMrWeiQbG2up3y47yP9=wB4+ehU6Q@mail.gmail.com>
From: Binny Jeshan <binnyjeshan@gmail.com>
To: Marc Binderberger <marc@sniff.de>
Content-Type: multipart/alternative; boundary="047d7bdc06f09727da04d0f9614e"
Cc: mpls@ietf.org, "Santiago Alvarez (saalvare)" <saalvare@cisco.com>, pwe3@ietf.org, rtg-bfd@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: Sun, 16 Dec 2012 14:50:14 -0000
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 <binnyjeshan@gmail.com> wrote: > 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 <marc@sniff.de> 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 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<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