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

["Adrian Farrel" <[e-mail]>]

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 <[e-mail]> 
Sent: 16 September 2019 12:21
To: Barry Leiba <[e-mail]>rg>; [e-mail]
Cc: The IESG <[e-mail]>rg>; pce-chairs <[e-mail]>rg>; Farrel Adrian <[e-mail]>uk>; [e-mail]
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 <[e-mail]> 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/