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

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 Sep 2019 16:48:07 +0530

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/

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 Sep 2019 16:50:46 +0530

Hi again!

> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Sep 2019 12:33:28 +0100

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 <[email-masked]> 
Sent: 16 September 2019 12:21
To: Barry Leiba <[email-masked]>; [email-masked]
Cc: The IESG <[email-masked]>; pce-chairs <[email-masked]>; Farrel Adrian <[email-masked]>; [email-masked]
Subject: Re: **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**

Hi again!

Thanks!
Dhruv

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 16 Sep 2019 11:29:57 -0400

Hi Dhruv,
If the node is overloaded, it may not be able to send the notification, may
be too busy completing the work. "SHOULD" seems reasonable for this
notification as well.

Thanks Adrian for your view.

Thanks,
Rakesh

On Mon, Sep 16, 2019 at 7:33 AM Adrian Farrel <[email-masked]> wrote:

> 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.
>
> Cc: The IESG <[email-masked]>; pce-chairs <[email-masked]>; Farrel
> Adrian <[email-masked]>;
> [email-masked]
> Subject: Re: **Barry Leiba's DISCUSS on
> draft-ietf-pce-stateful-pce-auto-bandwidth**
>
> Hi again!
>
> 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://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth/ballot/
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 16 Sep 2019 09:00:05 -0700

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Sep 2019 17:16:10 +0100

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 <[email-masked]> 
Sent: 16 September 2019 17:00
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked]; The IESG <[email-masked]>; pce-chairs <[email-masked]>; Farrel Adrian <[email-masked]>; [email-masked]
Subject: Re: **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**

Barry

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 17 Sep 2019 10:59:17 +0530

Hi All,

Thanks for the discussion. I have updated text based on Adrian's suggestion.

See 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

Skip to Section 5.7 to see related changes.

Let me know if any further changes are needed.

Thanks!
Dhruv

---

From: Barry Leiba <[email-masked]>
Date: Mon, 16 Sep 2019 23:00:48 -0700

> See 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…

This looks good to me, and seems a clear explanation.  I'll go clear
my DISCUSS.  Thanks for making the changes, and thanks, Adrian and
Rakesh, for weighing in on the discussion.

Barry