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

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 16 September 2019 16:16 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 D19E912004F; Mon, 16 Sep 2019 09:16:21 -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 qXUsHLOwaLYh; Mon, 16 Sep 2019 09:16:19 -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 D5B6C120026; Mon, 16 Sep 2019 09:16:18 -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 x8GGGEin014223; Mon, 16 Sep 2019 17:16:15 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 169FA22032; Mon, 16 Sep 2019 17:16:15 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id F258622042; Mon, 16 Sep 2019 17:16:14 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.72.158]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x8GGGBF9013296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Sep 2019 17:16:13 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Barry Leiba'" <barryleiba@computer.org>, "'Dhruv Dhody'" <dhruv.ietf@gmail.com>
Cc: <pce@ietf.org>, "'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> <CALaySJJ2dkCLm9zdfRFYzU5QRve41UhoX9RYPxvkvpeZJnByZg@mail.gmail.com>
In-Reply-To: <CALaySJJ2dkCLm9zdfRFYzU5QRve41UhoX9RYPxvkvpeZJnByZg@mail.gmail.com>
Date: Mon, 16 Sep 2019 17:16:10 +0100
Organization: Old Dog Consulting
Message-ID: <024101d56caa$0f14f710$2d3ee530$@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+4ERwAL9TlneAh10iSKk/DHiMA==
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-24916.000
X-TM-AS-Result: No--31.369-10.0-31-10
X-imss-scan-details: No--31.369-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24916.000
X-TMASE-Result: 10--31.369300-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFq9GVQT/CmkaHFPUrVDm6jtjHhXj1NLbjBayaoU89Fh9s9H W53QBL0AVs85UhK71rjB/g189dtqj5BKcAbnxjMCqjZ865FPtprBnL3AaGm9o5l6cEz4nsnl8gv cSKVCSkIkR3pgFbBMgIfv9hpetzms7K35r0y1/571WO1NzV/CYKrhQu91zwNn5DJ1FS+XdBPWNt V1ifHVhsBhyl4WRusrbDlVQvRsKTtoWWTS0CIqzjdfT4zyWoZSlJ6XrUTdEpEoWk+HrvUAIE5VH uLzyf0qF3uQYtPkNr5zluLdPk1n7T1iiwOv4P/78eSmTJSmEv1+Mk6ACsw4JhtVRURjpT+vqM7v 6KBNGANq6b3UW5godg96yZo+kNGOOXyRIvc0XEMiMpIfyuUBOyIk3dpe5X+hmEmkgQDHT/xe/RS +vWeoFzjpLDVWoC1BH5ED9mQDsMjPIXC61GJeS6roPbyANljgPJb7oABYhT9J/DW2nb8DkZbPBs aBVobl/nw40ETKsm1OK+rVow/DPtF+3yx4SzgcfjUCBXbhed99iuvWn3J8KrytS1u1Z7z6l9Mup 5cLtswduR3Zh+ac91wpiL8fYl2ZayXayD84kueFTLRMAFrHXG+BW75YgTMbEd+K6O5Nt53E4EXr t01+HcA01iXVdUbitvifC4MzRj2/C8Xh7eU7wyTc3NdTt+Z6TJYvCNRUoW6E2ut4EHvMmYE/vIN hyffjQTiBk5oGzQos4iOZjuRh1nKQyUwGFiMJ7LuOEAY9BqSCF6GkB9h+D5GhAvBSa2i/C2AcMd uALVImLrQLVUxjyhn1Zh5h4gk/HnGJ65Z1kWSeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 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/BmueiiE6xWcC53R96LBoCi-TIjM>
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 16:16:22 -0000

Yes, that's a reasonable request.

Should send a Notification.
If congested or would only serve to increase overload, May choose to not send a Notification.
Not sending a Notification could result in foo
A PCC experiencing foo should to bar.
Note that when a PCE serves very many PCCs, congestion may arise without any one PCC becoming aware of multiple unserved messages, in which case something.

Adrian

-----Original Message-----
From: Barry Leiba <barryleiba@computer.org> 
Sent: 16 September 2019 17:00
To: Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: pce@ietf.org; 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**

Thanks for the reply, Dhruv.

To be clear, I am NOT suggesting changing it to MUST (though that
could be a perfectly good outcome of the discussion).  I am suggesting
that if it remains as SHOULD, there has to be some explanation of what
the constraints are and what interoperability or security issues could
arise if an implementation doesn't do it that way.

Barry

On Mon, Sep 16, 2019 at 4:21 AM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>
> 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/