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>
>>
>>
>