Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 16 September 2019 11:33 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 C4EBB120838; Mon, 16 Sep 2019 04:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 SzLmTo25n8jP; Mon, 16 Sep 2019 04:33:38 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91355120019; Mon, 16 Sep 2019 04:33:36 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x8GBWe8G025498; Mon, 16 Sep 2019 12:33:31 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C569F22032; Mon, 16 Sep 2019 12:33:30 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id AF30D2203D; Mon, 16 Sep 2019 12:33:30 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.72.158]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x8GBXSfU015860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Sep 2019 12:33:29 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Dhruv Dhody'" <dhruv.ietf@gmail.com>, "'Barry Leiba'" <barryleiba@computer.org>, <pce@ietf.org>
Cc: "'The IESG'" <iesg@ietf.org>, "'pce-chairs'" <pce-chairs@ietf.org>, <draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org>
References: <CAB75xn5CPpoo=SWGfiDS+jQQ0pr1Z7HeHKjx9prGzb6tH9YxbQ@mail.gmail.com> <CAB75xn6jiNGePOAat_ET-JsPsvuouo8d651GrdjswPjC7OYPWQ@mail.gmail.com>
In-Reply-To: <CAB75xn6jiNGePOAat_ET-JsPsvuouo8d651GrdjswPjC7OYPWQ@mail.gmail.com>
Date: Mon, 16 Sep 2019 12:33:28 +0100
Organization: Old Dog Consulting
Message-ID: <016c01d56c82$903a3620$b0aea260$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLaJY984CkYp6/h4if5RMNX+4ERwAL9TlnepQzNGiA=
Content-Language: en-gb
X-Originating-IP: 87.112.72.158
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24914.005
X-TM-AS-Result: No--23.161-10.0-31-10
X-imss-scan-details: No--23.161-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24914.005
X-TMASE-Result: 10--23.161000-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFq9GVQT/CmkaHFPUrVDm6jthlL5/PVMMhIHdnpVZivvnLCb bOwPG3Amh4QrtA0MYnIUJHq3EzYoRx8tmNEYF19BN19PjPJahlJR3sGN+j7mNN+gRbw3K+dvmwO HFxYq8mfV7VjYFubQMFEaFUDrmPqnPWKLA6/g//vx5KZMlKYS/Q73P4/aDCIFG1VFRGOlP68F/2 gAm/rnq+DYvGkwxz0/arhRRWLyWzEhOgSF6241nbqImyaR0axZ4NNiN6MhlPAK5I+5JVbn7jO+P BlvZU7YAOB9g4xdOhlLSashyfR4h1/JJvf1ahcWLCDCajDZWp1aEfFgComdj5DgR3nlxgB6NmGS wj6QJy+tuxo618zL1cPvxoWsx4RiXhIgqyFXxJe9uqvNJ0+KqilayzmQ9QV0jklQr1R1iSf68RI XoGEMjGZANw4i2FngSdlhYkWanzmMQmg2+WN4OzKVTrGMDe/Di8J8z2fwGac3xO2R3boBWH8N94 053/fN9blF8FoSg7i8J639iEjfqHcxza41jj1KECZm53NHwzVUIaneDj+GOz8fBHJpFUzVsyWAN +6yISLICH7stvZ9Dl6X+V0hPL5ko6RGjAPtMXuqDSBu0tUhr7vGYJkNeu61Ocom8XH3/7JoZEsK cpKKle8BsGvUbOXx9mUl/pj0E70CWAJNioDShW6HurDH4PpPowhSWTqHYRigipjx+cBzOc7ixSB r9wsbdpGsTq/ormLZE+mt+xTnl3bXMG2FSiQ12Hlwa3CYC+SPzv8sr7ayo4H7rHelmEu3L+QPwy flusyL+skqd2bd776UFwxM7gqvNtywwIf5ksWeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zUc1+O1X9AzE=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/LAmGnFHVJs8CauzVRim4qmjYPMw>
Subject: Re: [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:33:41 -0000

Top post, historic view.

IIRC the reason for not requiring a Notification in the case of overload was that the process of sending a Notification might contribute to the overload. And, furthermore, that there might be an attack that leverages the need to send a Notification to perpetuate the overload.

I take no position on this: just reporting what is in my memory.

Best,
Adrian

-----Original Message-----
From: Dhruv Dhody <dhruv.ietf@gmail.com> 
Sent: 16 September 2019 12:21
To: Barry Leiba <barryleiba@computer.org>rg>; pce@ietf.org
Cc: The IESG <iesg@ietf.org>rg>; pce-chairs <pce-chairs@ietf.org>rg>; Farrel Adrian <adrian@olddog.co.uk>uk>; draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org
Subject: Re: **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**

Hi again!

On Mon, Sep 16, 2019 at 4:48 PM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>
> 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?
>
> ====
>

I checked the base RFC for PCEP - RFC 5440 where notifications are
first defined. They do not use MUST for sending notification in the
PCE overload case [1].

Leaving that aside, in case of auto-bandwidth feature, this
notification is important for scaling. I am inclined to change it to
MUST as suggested.

Co-authors, WG, please speak up if you disagree!!

I have incorporated all other comments in the working copy.

Diff: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-stateful-pce-auto-bandwidth-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt

Thanks!
Dhruv

[1] https://tools.ietf.org/html/rfc5440#section-7.14

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