[Pce] **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**
Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 16 September 2019 11:18 UTC
Return-Path: <dhruv.ietf@gmail.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 547A4120834; Mon, 16 Sep 2019 04:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9rADYsgGkwAZ; Mon, 16 Sep 2019 04:18:45 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DFA120019; Mon, 16 Sep 2019 04:18:44 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id h144so77608098iof.7; Mon, 16 Sep 2019 04:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=mz7w4BEMvy8p+PNBOGM3jjO7Z9lMrTCbOyyKfBperQQ=; b=AmgE/Q5IesWgChHOKTqFZ00fNGOoxyXm6vRdlDG1L4d3Vm6iehoasBuWP3scLkh20r YzDBKBM5Th0mL9Q9s8Ficz84+6SjCVdC4rI0kxJHcwqhTikLPCmUZOphJmojDFhVP+or tg1T3k2H0pIqvRWijCyefRiv9OOvzxNwanOtLMeMjlsBX0Q5p2W0R3uXCBEGg791W7m3 +e6JKeU6q56NsXIzzql2k1DveS/XP5I/YTkli+3LuapergE1NUKu0di+FPK6/uYuzX52 kChzncOOs6zmF4O+rBXoOv8zr385J5z/7SzMg/3NF/DPhDICKJHq3HhPrtJdxT3td/75 dHAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=mz7w4BEMvy8p+PNBOGM3jjO7Z9lMrTCbOyyKfBperQQ=; b=Vq14yn++Kj3CpEBsHYuTeCoZJXW4moR5TiNQcZKfZ019A9cTyl6jHai8m7aTYoLfcN tlAnkTMcV3xUhHBnZ/+lKiV/dmA6S+/n7Aju/2RcrYnM/aQMS1hOXiyT8h4qhrNBmqef 8zNUrRkmsN2UpoYlry/K9IZ6TpbPmt2U9ym8li3KHKmovQIxkDwepfNoCJ2rPNmXrdUV OjPrf1o7oWa5pN0pN8N927xuFXE25thOGSNx4DN7Dwv+cvceQo6sx1g6BaOwpEMiqAYw jHxgjX/4L4KMIV3YkBv1GdSKlXLMCeoowTs3UFVT6rl+m4dC9vWoMs2tCbOutJqWDTjn 5lUQ==
X-Gm-Message-State: APjAAAXKFPCRZBILrzCYBeOGZAw6Bw2pCZGg0i/4maanX803JLk/YwuN 0CYSwETUQH+nGP70k3Kmh4mQd590oI+7N9+/SoM=
X-Google-Smtp-Source: APXvYqxzJ+KWmPo0S9y5EMEEL1ijr4ZyHqEC5x04kBmBvtQ9C2sWGHUIjYMWJKD9ZCW9/QjSzrz9H0+f6UMiS1ag55w=
X-Received: by 2002:a02:1ac5:: with SMTP id 188mr14535551jai.71.1568632723878; Mon, 16 Sep 2019 04:18:43 -0700 (PDT)
MIME-Version: 1.0
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Mon, 16 Sep 2019 16:48:07 +0530
Message-ID: <CAB75xn5CPpoo=SWGfiDS+jQQ0pr1Z7HeHKjx9prGzb6tH9YxbQ@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>, pce@ietf.org
Cc: The IESG <iesg@ietf.org>, pce-chairs <pce-chairs@ietf.org>, Farrel Adrian <adrian@olddog.co.uk>, draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/YxO8HZTG8xIkK3R4nQJJToVUEZs>
Subject: [Pce] **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 16 Sep 2019 11:18:48 -0000
Hi Barry, WG, I saw the DISCUSS [1] in the datatracker but for some reason the email never landed in my inbox or the list [2]. I am manually posting it here - ==== Discuss (2019-09-16) Thanks for another clear document. There are some "SHOULD" key words in one section that I would like to discuss, and that I think we ought to be able to resolve without much difficulty: — Section 5.7 — There are various “SHOULD”s in this section, and I have the same comment about all of them: BCP 14 says, about “SHOULD”, that “there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.” I see no guidance here to help the reader understand what such circumstances and implications are, so I can’t see how an implementer can evaluate the situation. Can you provide any help here? ==== Comment (2019-09-16) Again, these are purely editorial comments, which need no detailed response; please just consider them. — Section 1 — Over time, based on the varying traffic pattern, an LSP established with a certain bandwidth may require to adjust the bandwidth reserved in the network dynamically. “may require adjustment of the bandwidth” This is similar to the Passive stateful PCE model, while the Passive stateful PCE uses path request/reply mechanism, the Active stateful PCE uses report/update mechanism. NEW This is similar to the Passive stateful PCE model: while the Passive stateful PCE uses a path request/reply mechanism, the Active stateful PCE uses a report/update mechanism. END This document defines the PCEP extensions needed to support Auto- Bandwidth feature in a Active stateful PCE model NEW This document defines the PCEP extensions needed to support an Auto- Bandwidth feature in an Active stateful PCE model END — Section 2.3 — This value indicates how many times consecutively, the percentage or absolute difference Add a comma after “times”. — Section 3 — The PCEP speaker supporting this document must have a mechanism “A PCEP speaker”. o It is required to identify and inform the PCC, which LSPs are enabled with Auto-Bandwidth feature. Not all LSPs in some deployments would like their bandwidth to be dependent on the real-time bandwidth usage but be constant as set by the operator. NEW o It is necessary to identify and inform the PCC which LSPs have the Auto-Bandwidth feature enabled. In some deployments, not all LSPs would like their bandwidth to be dependent on the real-time bandwidth usage, but would rather be constant as set by the operator. END — Section 4.1 — The initial LSP bandwidth can be set to an arbitrary value (including zero), in practice, it can be operator expected value based on design and planning. NEW The initial LSP bandwidth can be set to an arbitrary value (including zero). In practice, it can be set to an expected value based on design and planning. END — Section 4.2 — When the Auto-Bandwidth feature is enabled, the measured traffic rate is periodically sampled at each Sample-Interval (which can be configured by an operator and the default value as 5 minutes) by the PCC, when the PCC is the head-end node of the LSP. The traffic rate samples are accumulated over the Adjustment-Interval period (in the Up or Down direction) (which can be configured by an operator and the default value as 24 hours). NEW When the Auto-Bandwidth feature is enabled, the measured traffic rate is periodically sampled at each Sample-Interval by the PCC, when the PCC is the head-end node of the LSP. The sample interval can be configured by an operator, with a default value of 5 minutes. The traffic rate samples are accumulated over the Adjustment-Interval period (in the Up or Down direction). The period can be configured by an operator, with a default value of 24 hours. END The PCC, in-charge of calculating the bandwidth to be adjusted, can decide to adjust the bandwidth Remove both commas. Only if the difference between the current bandwidth demand (MaxAvgBw) and the current bandwidth reservation is greater than or equal to the Adjustment-Threshold (percentage or absolute value) (which can be configured by an operator and the default as 5 percentage), the LSP bandwidth is adjusted (upsized) to the current bandwidth demand (MaxAvgBw). I’m sorry: I can’t made any sense out of this text and, thus, can’t suggest a fix. Please try rephrasing this. When you do, please make it more than one sentence, and please avoid consecutive parenthesized phrases, which are awkward. However, longer adjustment-interval can result in an undesirable effect “a longer” To avoid this, the Auto-Bandwidth feature may pre-maturely expire the adjustment- interval and adjust the LSP bandwidth “prematurely”, with no hyphen. “adjustment interval”, with no hyphen. — Section 5.1 — o The PCEP speaker that does not recognize the extensions defined in “A PCEP speaker” o If the PCEP speaker that supports the extensions defined in this “If a PCEP speaker supports” — Section 5.2 — Future specification can define additional sub-TLVs. “specifications” If sub-TLVs are not present, the default values as specified in this document are used or otherwise based on the local policy are assumed. I can’t make sense of that sentence; please re-phrase it. — Section 5.2.3.2 — o Reserved: SHOULD be set to zero on transmission and MUST be ignored on receipt. Why is this “SHOULD”, when other reserved values have been “MUST”? (Same comment in 5.2.3.4, 5.2.5.1, 5.2.5.2, 5.2.5.3, and 5.2.5.4.) ==== [1] https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth/ballot/ [2] https://mailarchive.ietf.org/arch/browse/pce/
- [Pce] **Barry Leiba's DISCUSS on draft-ietf-pce-s… Dhruv Dhody
- Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-p… Dhruv Dhody
- Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-p… Adrian Farrel
- Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-p… Rakesh Gandhi
- Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-p… Barry Leiba
- Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-p… Adrian Farrel
- Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-p… Dhruv Dhody
- Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-p… Barry Leiba