Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 23 February 2017 10:34 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7BA1296AE; Thu, 23 Feb 2017 02:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7cDSceHjM55; Thu, 23 Feb 2017 02:34:03 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC701296A1; Thu, 23 Feb 2017 02:34:02 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1NAXshj020877; Thu, 23 Feb 2017 10:33:54 GMT
Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1NAXotX020861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 10:33:53 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dhruv Dhody' <dhruv.dhody@huawei.com>, 'Jonathan Hardwick' <Jonathan.Hardwick@metaswitch.com>, pce@ietf.org
References: <BY2PR0201MB191078869D7F31052330053284600@BY2PR0201MB1910.namprd02.prod.outlook.com> <04d801d271c7$75a51770$60ef4650$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8CA6247C@blreml501-mbb> <082c01d27988$9c30e950$d492bbf0$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8CA62780@blreml501-mbb> <23CE718903A838468A8B325B80962F9B8CA7500F@blreml501-mbb>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CA7500F@blreml501-mbb>
Date: Thu, 23 Feb 2017 10:33:52 -0000
Message-ID: <067401d28dc0$55ad6570$01083050$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIr/eg1Q9mZk8qgpXnDhlnKP/1QeALisXMGAYJ7SLYBvd0TpQHdfopcAhb5lAOgcsi64A==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22902.006
X-TM-AS-Result: No--15.171-10.0-31-10
X-imss-scan-details: No--15.171-10.0-31-10
X-TMASE-MatchedRID: oHOSwQSJZWinykMun0J1wvHkpkyUphL9Ud7Bjfo+5jTM9X6l99fFT3eR +gIsfN9AOY5vwWpeQsBiPmy8WTo67mob6A84c/fI2MMmxTWvrZu5JJEy92I4jCRwmEMDEuwZTVe /MsxLuMAsm08AFnP7irIukFeJn/9AcNf8KQA4w7xor4yxPAz7WUNphebivZBYCTaA+uwR5t8q1n Wfko5RGYxiQgtW5pQ9VBcMAm2b6Q06q0cNvkl2ilaOpp/sV5nVhV0srjoqtx+na6U74e0+qALyt DvV39h+FqzzhFk7BYZf8868kEpnmStg+qZmq1X/QpxiLlDD9FUxmbT6wQT2aznKpbGL4ChVHACU cDvcWyAcl4Vrs6KMmHJkCGHrg33EMNaqmAxHBiRswYo64ufkVSMSJEhzxGu9kapCDmBfYkly3yC VHtn3QIX5qeuCEtpocAjp+XhH9sndWSaa0iXMMJ4CIKY/Hg3AY2fxc+IAshv6APa9i04WGCq2rl 3dzGQ1zAYCMArxFLAzwt80PodM3UEtchC63boUkQiFGO5KmKZuJImNnvU7nmunJiG40iC4
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/LuGMPuuAfJDKLcYTBLBSH8Us0uE>
Cc: draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org, pce-chairs@ietf.org
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 10:34:05 -0000
Thanks. Wfm. A > -----Original Message----- > From: Dhruv Dhody [mailto:dhruv.dhody@huawei.com] > Sent: 23 February 2017 06:58 > To: 'adrian@olddog.co.uk'; 'Jonathan Hardwick'; 'pce@ietf.org' > Cc: 'pce-chairs@ietf.org'; 'draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org' > Subject: RE: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto- > bandwidth-09 > > Hi Adrian, WG, > > This is an update for the two open issues - > > [snip] > > > > >> --- > > > >> Did you consider allowing a different Adjustment-Interval for > > > >> adjustment up and adjustment down (with them defaulting to the same > > value)? > > > > > > > > [Dhruv] No, it is not supported by most of the vendors. > > > > > > ROFL > > > It's not even a WG draft yet. > > > > > > > [Dhruv] :) I meant, for the existing implementation of auto-bandwidth > > feature with local CSPF. Anyways... > > > > > > They keep the same interval but allow setting of different values > > > > for the overflow and underflow threshold/count. Do you feel that > > > > this should be added? > > > > > > Not sure. If I was writing the code, I would certainly have used two > > > different timers because that is cheap and easy and flexible. Whether > > > I would have exposed both as configurable in the first release is > > debatable. > > > > > > If I was deploying I think I would want to experiment with making > > > changes more sticky in one direction than in the other direction. How > > > important that is might depend on how expensive it is to increase b/w > > > once it has been reduced, and how likely it is that an increase might > > fail. > > > > > > > [Dhruv] Understood. I will keep this point open in the current version and > > gather feedback from my co-authors as well as operators, before updating. > > > > [[Dhruv Dhody]] Authors discussed this point and concluded that this flexibility > could be quite useful. And thus have added separate interval and threshold for > up and down - > > - Up-Adjustment-Interval > - Down-Adjustment-Interval > - Up-Adjustment-Threshold > - Down-Adjustment-Threshold > > > > > >>--- > > > >> 4.2 has > > > >> > > > >> All thresholds in this document could be represented in both > > > >> absolute value and percentage, and could be used together. > > > >> > > > >> I looked but couldn't find. If absolute and percentage are both > > > >> supplied and imply different thresholds, which one is used? Could > > > >> be as simple as "the first threshold hit", but this could lead to > > > >> some flaps that are not obvious to someone staring at either the > > > >> up/down percentage thresholds or at the up/down absolute values. > > > > > > > > [Dhruv] In section 5.2.3 (and similarly 5.2.5) states - > > > > > > > > An implementation MAY include both > > > > sub-TLVs for the absolute value and the percentage, in which case > > > >the bandwidth is adjusted when either of the adjustment threshold > > > > conditions are met. > > > > > > > > Which is similar to what you state. > > > > Do you suggest we add some guidelines to provide information on > > > > which threshold is met by logging? > > > > Or do you feel strongly about this and we should use only one format? > > > > > > I think that this may be flexibility too far. I can't see a way that > > > this would break anything, but might lead to "unexpected" results. For > > example... > > > > > > Up % = 1% > > > Down % = 10% > > > Up absolute = 1 GB > > > Down absolute = 1 MB > > > > > > This would cause wibbles, but maybe that is what the operator has asked > > for. > > > > > > But maybe nothing more to say. > > > > > > > > > > [Dhruv] Personally I am fine either way. I will update once I get a > > confirmation from my co-authors. > > > > [[Dhruv Dhody]] We would like to keep this flexibility as it useful when the LSP > bandwidth becomes large or small, and optionally providing threshold in both > absolute and %age is useful. > Consider we set overflow threshold as either 20% or 500M. > When tunnel gets large (say 10G), the 20% is 2G, which is too large a threshold > and thus 500M as an absolute value helps, but when the same tunnel is small I > would like 20% threshold to be applied, even when it is less than 500M. > > We have clarified this in the latest version. > > The diff is attached, it also includes some editorial changes. > > Thanks again for your detailed review comments. > > Regards, > Dhruv (on behalf of co-authors)
- [Pce] Poll for adoption: draft-dhody-pce-stateful… Jonathan Hardwick
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Dhruv Dhody
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Udayasree palle
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Rakesh Gandhi
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Ravi Singh
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Sureshbr
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Shah, Himanshu
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Phil Bedard
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Leeyoung
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Jeff Tantsura
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Daniele Ceccarelli
- [Pce] 答复: Poll for adoption: draft-dhody-pce-stat… Zhenghaomian
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Adrian Farrel
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Jonathan Hardwick
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Dhruv Dhody
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Adrian Farrel
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Dhruv Dhody
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Dhruv Dhody
- Re: [Pce] Poll for adoption: draft-dhody-pce-stat… Adrian Farrel