Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
Dhruv Dhody <dhruv.dhody@huawei.com> Sat, 28 January 2017 07:55 UTC
Return-Path: <dhruv.dhody@huawei.com>
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 0DCE7129444; Fri, 27 Jan 2017 23:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.017
X-Spam-Level:
X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, T_HTML_ATTACH=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 4-QFESN7MU-6; Fri, 27 Jan 2017 23:54:55 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7421293FB; Fri, 27 Jan 2017 23:54:53 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFJ29756; Sat, 28 Jan 2017 07:54:50 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 28 Jan 2017 07:54:47 +0000
Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Sat, 28 Jan 2017 13:24:37 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Jonathan Hardwick' <Jonathan.Hardwick@metaswitch.com>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09
Thread-Index: AdJnZ5Q70JvzTR/tS1eyDhyWcO0DJQKMcZOAAeGIHYA=
Date: Sat, 28 Jan 2017 07:54:36 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8CA6247C@blreml501-mbb>
References: <BY2PR0201MB191078869D7F31052330053284600@BY2PR0201MB1910.namprd02.prod.outlook.com> <04d801d271c7$75a51770$60ef4650$@olddog.co.uk>
In-Reply-To: <04d801d271c7$75a51770$60ef4650$@olddog.co.uk>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.77.201]
Content-Type: multipart/mixed; boundary="_005_23CE718903A838468A8B325B80962F9B8CA6247Cblreml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.588C4E4B.017C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 23306873fab4aca67084db16cd5f7edb
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/L4XZ8Hx0Jc30IiAFkK90TvmzxrQ>
Cc: "draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org" <draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org>, "pce-chairs@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
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: Sat, 28 Jan 2017 07:55:04 -0000
Hi Adrian, Thanks for your support and comments. Apologies for the delay in the reply. See inline... From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 19 January 2017 01:44 To: 'Jonathan Hardwick' <Jonathan.Hardwick@metaswitch.com>; pce@ietf.org Cc: draft-dhody-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 Hi Jon, chairs, I think this is something we should be working on and I think that this draft will be a reasonable starting point although I do have some issues for discussion. I think we can handle the issues at any time (including after adoption). Thanks, Adrian - - - - - - It might be nice if the Abstract gave a very simple explanation of "automatic bandwidth adjustment". You have text in the Introduction you could use. [Dhruv] Done! Automatic bandwidth adjustment allows automatic and dynamic adjustment of the reserved bandwidth allocation of an TE LSP based on the volume of traffic flowing through it. --- There are three bullets at the end of Section 1, but I lack the context to understand whether this is a list of possible approaches, a list of steps, or something else. [Dhruv] I reworded the text and converted into a paragraph. The PCC (head-end of the LSP) monitors the traffic flowing through the LSP and calculates the new adjusted bandwidth. The PCC reports the calculated bandwidth to be adjusted to the PCE. This is similar to a passive stateful PCE model, while the passive stateful PCE uses path request/reply mechanism, the active stateful PCE uses report/update mechanism to adjust the LSP bandwidth. In case of PCE- initiated LSP, the PCC is requested during the LSP initiation to monitor and calculate the new adjusted bandwidth. --- I note that this revision seems to have dropped the ability for a PCC to report samples to the PCE and have the PCE do all of the work of determining whether auth-bandwidth adjustments are needed/desirable before performing the various path computations. There is a clear benefit in pushing the responsibility for deciding when adjustments are needed to the PCC. This distributes the load of monitoring the LSPs down to the PCCs and frees up the PCE as well as reducing the load on PCEP communications. However, ... Exactly when to adjust an LSP (and the scaling consequences discussed in 4.3) could be better left to a PCE. That is, a PCE could be flexible in its interpretation of thresholds enabling it to trigger adjustment early if it believes there is a good reason (for example, doing a set of parallel recomputations) or late (for example, when it knows that an adjustment would be disruptive to the network and can see the changes that lead to an adjustment request). When this is delegated to the PCC, the PCC cannot see the impact on other LSPs, and the PCE cannot tell whether the request for adjust the LSP is critical or moderate. Clearly there are options and trade-offs, and different pain points. Was there a logic to this edit? [Dhruv] You are right, we have not dropped the model, only decided to pursue the second model in a different draft "draft-gandhi-pce-pm-04" which deals with reporting parameters to the PCE including bandwidth Utilizations, as well as delay, jitter etc. This would be in-line with other RFCs in OSPF, IS-IS and PCE which deals with these parameters together. (BTW - Having a way for the PCC to report measurements to the PCE does not necessarily imply using a PCRpt for that purpose.) [Dhruv] That is true. In this draft we are focusing on changes in PCEP. If PCE is using some other mechanism to learn, it can still use the existing PCUpd mechanism to update the bandwidth. Note that in 4.2 you have The PCEP peer which is in-charge of calculating the bandwidth to be adjusted, will adjust the bandwidth of the LSP to the highest sampled traffic rate (MaxAvgBw) amongst the set of bandwidth samples collected over the adjustment-interval. I think that *in*your*current*revision* "The PCEP peer" means "the PCC" and that "the PCC" is congruent to the "LSP head end". [Dhruv] Ack and Updated. Similarly, when you took text out in this revision, I think you missed updating 4.3 where you have... If a PCE gets overwhelmed, it can notify the PCC to temporarily suspend its auto-bandwidth reporting (see Section 5.6). ...yet the PCC does not (now) do auto-bandwidth reporting. [Dhruv] It is updated to "reporting of the new bandwidth to be adjusted" to be clear. --- I think the table in Section 3 slightly misses the point. The statement "No new extensions are needed" is currently applied to "PCC Initiated", but I think there may be confusion in the delegated case. That is, once delegated, a PCC *could* send a request for adjustment, but neither the PCC nor the PCE may really be expecting that. They may expect something more similar to the PCE-initiated case. Thus, at the time of delegation, the PCE needs to be able to say "yes, delegated, but I want you to monitor the LSP with these parameters." Maybe, also, at the time of delegation the PCC should be letting the PCE know what monitoring it is planning on doing. [Dhruv] Agree and updated. --- 4.1 has... Auto-Bandwidth feature allows an LSP to automatically and dynamically adjust its reserved bandwidth over time, i.e. without network operator intervention. Well, of course, the LSP does no such thing. Probably the head-end LSR does that. [Dhruv] Ack. Updated to - Auto-Bandwidth feature allows automatic and dynamic adjustment of the reserved bandwidth of an LSP over time, i.e. without network operator intervention. --- 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. 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? --- 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? --- 5.2 has For PCE-Initiated LSP ([I-D.ietf-pce-pce-initiated-lsp]), this TLV is included in the LSPA Object with PCInitiate message. For delegated LSPs, this TLV is carried in PCRpt message in LSPA Object. I *think* that a PCUpd can also carry these to allow a PCE to direct the PCC to use different parameters with the LSP. [Dhruv] Yes that should be clarified. I have added text. This was earlier mentioned further down in the same section. --- 5.2 The TLV is encoded in all PCEP messages for the LSP till the auto bandwidth adjustment feature is enabled, the absence of the TLV indicate the PCEP speaker wish to disable the feature. Does this mean The TLV is encoded in all PCEP messages for the LSP while the auto bandwidth adjustment feature is enabled, the absence of the TLV indicate the PCEP speaker wish to disable the feature. ?? [Dhruv] Yes, updated. --- 5.2 Length: Variable How true! But what does it encode? [Dhruv] Ack and Updated. --- Do you need section 5.7 for PCUpd? [Dhruv] Added. --- You have... This document defines AUTO-BANDWIDTH-CAPABILITY TLV, AUTO-BANDWIDTH-ATTRIBUTE TLV which do not add any new security concerns beyond those discussed in [RFC5440] and [I-D.ietf-pce-stateful-pce]. Some deployments may find the reporting of the auto-bandwidth information as extra sensitive and thus SHOULD employ suitable PCEP security mechanisms like TCP-AO or [I-D.ietf-pce-pceps]. Are you sure there are no additional security concerns as stated in your first paragraph. Doesn't your second paragraph say that there *are* additional concerns: in particular that things be deduced from the fact of, the timing of, and the amount of adjustments? So even if the messages are protected from spoofing or modification, that wouldn't be enough. [Dhruv] You are right, updated. This document defines AUTO-BANDWIDTH-CAPABILITY TLV, AUTO-BANDWIDTH-ATTRIBUTE TLV which does not add any new security concerns beyond those discussed in [RFC5440] and [I-D.ietf-pce-stateful-pce] in itself. Some deployments may find the auto-bandwidth information as extra sensitive and could be used to influence path computation and setup with adverse effect. Additionally snooping of PCEP messages with such data or using PCEP messages for network reconnaissance, may give an attacker sensitive information about the operations of the network. Thus, such deployment should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or [I-D.ietf-pce-pceps]. --- 7.2. Information and Data Models [RFC7420] describes the PCEP MIB, there are no new MIB Objects defined in this document. What you say is true. But do you think there is a need for an augmentation for the new features? What about YANG? [Dhruv] Updated. A Management Information Base (MIB) module for modeling PCEP is described in [RFC7420]. However, the preferred mechanism for configuration is through a YANG model [I-D.ietf-pce-pcep-yang]. This SHOULD be enhanced to provide controls and indicators for support of auto-bandwidth feature. Support for various configuration knobs as well as counters of messages sent/received containing the TLVs (defined in this document) should be added. --- 7.6. Impact On Network Operations Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440]. Really? Haven't you described a mechanism specifically designed to change the way that the network is operated? Haven't you also described problems (and mitigations) that could cause PCC and PCE to be swamped? [Dhruv] Updated. In order to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit to be placed on the number of LSPs that can be enabled with auto-bandwidth feature, and MAY allow a limit to be placed on the rate of messages sent by a PCEP speaker and received from a peer related to auto-bandwidth. It MAY also allow sending a notification when the PCEP speaker is overwhelmed or a rate threshold is reached. --- 8.2 "IETF Consensus" is now called "IETF Review". You also need a reference to RFC 5226. [Dhruv] Ack. --- 8.3. AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV You need to define the allocation policy for this new registry. [Dhruv] Added --- The absence of TBD2 and TBD3 is not critical, but cause IANA and the RFC editor to ask you a question. [Dhruv] Ack. Thanks again for your detailed review. I am attaching a diff. Regards, Dhruv From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 05 January 2017 15:24 To: pce@ietf.org<mailto:pce@ietf.org> Cc: draft-dhody-pce-stateful-pce-auto-bandwidth@ietf.org<mailto:draft-dhody-pce-stateful-pce-auto-bandwidth@ietf.org>; pce-chairs@ietf.org<mailto:pce-chairs@ietf.org> Subject: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09 All, This is start of a two week poll on making draft-dhody-pce-stateful-pce-auto-bandwidth-09 a PCE working group document. https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth/ Please review the draft and send an email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reasons. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends on Thursday January 19. Thanks, Jon, JP and Julien
- [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