Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE
draft-ietf-pce-stateful-pce-auto-bandwidth-12

[Ballot comment]
** I support Ben Kaduk’s DISCUSS position on the need for clarity in the definition of Overflow-Count and Overflow-Threshold

** Section 5.2.x.  Error handling:
-- A number of the sub-TLVs define ranges smaller than would be possible given the number of bit (e.g., 1..604800 in a 32-bit field; 1.100), how would an error be signaled for values used outside that range?

-- For values that are [IEEE.754.1985]), how should negative value be processed?

** Nits:
-- Section 1.  Typo. s/a Active stateful/an Active stateful/

-- Section 5.2.2.2.  For consistency with the other sections s/1 to 604800/1 to 604800 (7 days)/

-- Section 6.6.  Typo. s/signalling/signaling/

[Ballot discuss]
This document seems generally useful, and thanks for it.  I think
there's a couple places where it's ambiguous or unclear, and hopefully
we can tighten up the language without needing extensive changes.

There may be an internal inconsistency in Section 2.3's definitions
relating the Overflow-Count and the Overflow-Threshold: the description
of Overflow-Count reads as if it is a reported quantity, but the
description of Overflow-Threshold implies that Overflow-Count is a
configured parameter.  (Similarly for the Underflow- variants.)
Specifically, the sentence "[t]his value indicates how many times
consecutively, the percentage or absolute difference between the current
MaxAvgBw and the current bandwidth reservation of the LSP is greater
than or equal to the Overflow-Threshold value" uses the descriptive
verb "is" as opposed to a conditional such as "needs to be [...] in
order to [...]".

Section 5.2.3.2 says:

  If the percentage difference between the current MaxAvgBw and the
  current bandwidth reservation is greater than or less than or equal
  to the threshold percentage, the LSP bandwidth is adjusted to the
  current bandwidth demand (MaxAvgBw) (as long as the difference in the
  bandwidth is at least or above the Minimum-Threshold).

As written ("greater than or less than or equal to"), this is always
true, which cannot be what was intended.  Probably we should reword to
just "greater than" and talk about the percentage absolute difference,
i.e., 100 * abs(MaxAvgBw - CurrentRes) / CurrentRes .

[Ballot comment]
As a general note, I'm not sure the phrase "calculated bandwidth to be
adjusted" is a great fit for how it's currently being used.
Specifically, the "calculation" in question seems to just be taking the
maximum of a sliding window of per-timeslice average bandwidth values,
and this seems like a sufficiently small amount of computation that I'd
be comfortable describing it as a "measurement", for "measured bandwidth
as input to path calculation".  That is, this doesn't seem like it comes
close to the amount of computation involved in actually computing paths,
so I keep misreading what information is being sent where.

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.  The head-end Label Switch Router (LSR)
  monitors the actual bandwidth demand of the established LSP and
  periodically computes new bandwidth.  The head-end LSR adjusts the
  bandwidth reservation of the LSP based on the computed bandwidth
  automatically.  This feature is commonly referred to as Auto-
  Bandwidth.  The Auto-Bandwidth feature is described in detail in
  Section 4 of this document.

From just this text, I can't tell if this is describing the mechanisms of
this document or an existing Auto-Bandwidth feature that is related to
the mechanisms of this document.

  In the model considered in this document, the PCC (head-end of the
  LSP) collects the traffic rate samples flowing through the LSP and
  calculates the new adjusted bandwidth.  The PCC reports the
  calculated bandwidth to be adjusted to the PCE.  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.  [...]

nit: I think the punctuation in this last sentence needs some tweaking,
as there looks to be a comma splice at present.
(It's also unclear how much we need to talk about Passive stateful PCE,
since just two paragraphs ago we say we focus on Active stateful PCE in
this document.)

  This document defines the PCEP extensions needed to support Auto-
  Bandwidth feature in a Active stateful PCE model where the LSP
  bandwidth to be adjusted is calculated on the PCC (head-end of the
  LSP). The use of PCE to calculate the bandwidth to be adjusted is out
  of scope of this document.

Maybe I'm just confused about active vs. passive in general, but I
thought that active stateful PCE involved the PCE "making the decisions"
with the PCC just providing input data.  But here we're saying that the
PCC is making the bandwidth decision, even though the rest of the LSP
computation remains on the PCE?  Or is "calculate the bandwidth to be
adjusted" referring to "evaluate the expression max_{time periods}(avg.
bandwidth per time period)" (as opposed to "compute the bandwidth
adjustment to make)?

Section 2.3

Are we assuming any relationship between the Up-Adjustment-Threshold and
the Overflow-Threshold?

      traffic demand.  If the percentage or absolute difference between
      the current MaxAvgBw and the current bandwidth reservation of the
      LSP is greater than or equal to the threshold value, the overflow
      condition is set to be met.  The LSP bandwidth is adjusted to the

nit: I think s/set to be met/said to be met/ ?  (this appears twice)

  Minimum-Threshold:  The increase or decrease of the LSP bandwidth
      should be at least or above the minimum-threshold represented as
      an absolute bandwidth value before the bandwidth adjustment for
      the LSP is made.  This threshold can be seen as a suppression
      threshold that is used along with a percentage threshold to avoid
      unnecessary auto-bandwidth adjustments and re-signaling of the LSP
      at low bandwidth values.

I can't tell from this text if this threshold is a (LSP) bandwidth
value/measurement or a bandwidth offset between configured and measured
values.  (The subsequent protocol element definitions are more clear
that it's the latter.)

Section 3

The column headings in Table 1 refer to who initiates the LSP in
question, right?

  The PCEP speaker supporting this document must have a mechanism to
  advertise the automatic bandwidth adjustment capability for both PCC-
  Initiated and PCE-Initiated LSPs.

Just checking on "must" vs. "MUST" here.

  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.

nit: I suggest NEW:

%  o  It is required to identify and inform the PCC which LSPs have
%    enabled the Auto-Bandwidth feature.  Not all LSPs in some
%    deployments would like their bandwidth to be dependent on the
%    real-time bandwidth usage; for some LSPs leaving the bandwidth
%    constant as set by the operator is preferred.

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

Do we cover what happens in the case when the PCC is not the head-end
node of the LSP?

Section 5.1

  o  The PCEP speaker that does not recognize the extensions defined in
      this document sends the PCErr message with error-type 2
      (capability not supported) as per Section 6.9 in [RFC5440].

This refers to when the actual new messages (e.g.,
AUTO-BANDWIDTH-ATTRIBUTES TLV) are being used, not merely advertising
the Auto-Bandwidth Capability TLV in the OPEN object, right?  That is,
this is descriptive language of what the core protocol spec mandates as
error handling in the presence of unrecognized input?

Section 5.1.1

nit: in the previous section we captialized this as "Auto-Bandwidth
Capability", but here (including the section heading) it is
"AUTO-BANDWIDTH-CAPABILITY".  Should they be consistent?

Section 5.2

  Future specification can define additional sub-TLVs.

I see that we see later that unrecognized sub-TLVs are ignored, but
would there be a case where we want to use a bit in the
AUTO-BANDWIDTH-CAPABILITY flags to negotiate support for a sub-TLV
(i.e., to confirm that the peer will understand it, instead of just
sending it and not knowing if it is understood)?

Section 5.2.1

It sounds like we should ignore values larger than 7 days as well
(rather than erroring out)?

Section 5.2.2, 5.2.3

I'd like to see a little bit more detail specified of the interaction
between (regular) Adjustment-{Interval,Threshold} and
Down-Adjustment-{Interval,Threshold}.  We do have this text about (e.g.)
"[t]he Adjustment-Interval sub-TLV specifies the time interval for both
upward and downward trend", which conveys the general intent, but I'm
not sure I have all the details about there being one default value,
that applies to both, and changes to the (regular) parameter continue to
apply to both, until an explicit Down- variant is seen, at which point
the control of the two parameters diverge permanently and they must
always be separately controlled.

Section 5.2.3.1

  o  Adjustment-Threshold: The absolute Adjustment-Threshold bandwidth
      value, encoded in IEEE floating point format (see

nit: I'd suggest that this is a bandwidth *difference* value (or offset),
pedantically speaking.  (The following paragraph is quite clear on the
actual usage, though, so this is nit-level.)  This comment applies to
basically all the threshold fields in the document, but I'll just make
it once, here.

Section 5.2.3.2

  o  Reserved: SHOULD be set to zero on transmission and MUST be
      ignored on receipt.

I think the formulation of "MUST be set to zero on transmission and
SHOULD be ignored on receipt" is more common.

  o  Percentage: The Adjustment-Threshold value (7 bits), encoded in
      percentage (an integer from 1 to 100).  The value 0 is considered
      to be invalid.  The default value is 5 percent.

I assume that the question of whether to allow sub-percentage
granularity came up, and don't want to revisit the WG's decision.  But
please confirm that it was discussed.

Also, are values over 100 also "invalid"?  What should the recipient do
upon receipt of an invalid value?

  If the percentage difference between the current MaxAvgBw and the
  current bandwidth reservation is greater than or less than or equal
  to the threshold percentage, the LSP bandwidth is adjusted to the
  current bandwidth demand (MaxAvgBw) (as long as the difference in the
  bandwidth is at least or above the Minimum-Threshold).

I'd suggest rewording to make the two criteria equal peers (e.g., "If X
and Y") rather than relegating the minimum-threshold to a parenthetical
that's easy to ignore.

Section 5.2.3.3

It would probably be good to reiterate here (and at other similar
locations) that this "is used to decide" only when there's a need for
different behavior in the upward and downard directions.

Also, nit-level, I think "overrides" is more appropriate than
"overwrites", since the non-Down- variant remains active for its
separate role.

Section 5.2.4.2

      per second.  The default maximum-bandwidth value is not set.

I guess effectively the default is FLOAT_MAX, inherited from RFC 5440.

Section 5.2.5.1

  o  Overflow-Threshold: The absolute Overflow-Threshold bandwidth
      value, encoded in IEEE floating point format (see
      [IEEE.754.1985]), expressed in bytes per second.  Refer to Section
      3.1.2 of [RFC3471] for a table of commonly used values.  If the
      increase of the current MaxAvgBw from the current bandwidth
      reservation is greater than or equal to the threshold value, the
      overflow condition is met.

nit: I'd suggest to s/increase/difference/, since (IIUC) the operation
here is "observed bandwidth remains above the (reservation plus)
threshold for  times", not "observed bandwidth increases in
successive reporting intervals".  This assumes that the
Adjustment-Interval is larger than  times the reporting interval,
of course.

Section 5.2.5.3

  o  Underflow-Threshold: The absolute Underflow-Threshold bandwidth
      value, encoded in IEEE floating point format (see
      [IEEE.754.1985]), expressed in bytes per second.  Refer to Section
      3.1.2 of [RFC3471] for a table of commonly used values.  If the
      decrease of the current MaxAvgBw from the current bandwidth
      reservation is greater than or equal to the threshold value, the
      underflow condition is met.

As above, I suggest s/decrease/difference/ (perhaps with an additional
indication that the magnitude of the difference is to be used, not the
signed difference).

Section 5.7

I'm not sure I understand why there's a need for an
auto-bandwidth-specific "overload" notification, as opposed to having
such messages suppressed as part of a more general overload condition.
But that doesn't mean there's not a need, of course, as I'm not very
familiar with this area!

Section 6.6

  An implementation MAY allow a limit to be placed on the rate of auto-
  bandwidth related messages sent by a PCEP speaker and received by a
  peer.  An implementation MAY also allow sending a notification when a
  PCEP speaker is overwhelmed or the rate of messages reach a
  threshold.

I don't want to revisit a WG consensus outcome, but I could see "SHOULD"
for "allow sending a notification", noting that it is "SHOULD allow
sending" and not "SHOULD send".

Section 7

  This document defines AUTO-BANDWIDTH-CAPABILITY TLV and AUTO-
  BANDWIDTH-ATTRIBUTES sub-TLVs which do not add any new security
  concerns beyond those already discussed in [RFC8231] and [RFC8281]

I'd suggest to qualify this as "do not add any substantial new security
concerns".  We did just in the previous section talk about how this
functionality could increase computational and operational load, which,
taken to an extreme, can affect availability and could be considered a
security consideration.

We could also perhaps give guidance about setting the min and max
bandwidth sub-TLVs to constrain automatic adjustment to be within a
known range and thus bound the extent of second-order effects on the
rest of the MPLS-TE domain.

Section 8.2

It might be good to say within what registry the sub-registry being
created is to be located.

Also, the last paragraph could perhaps be rephrased as "the initial
contents of the registry are empty, with all bits unassigned".

Section 9.2

I think that the RFC 7525 and 8253 references fall under the RECOMMENDED
guidance in Section 7, in which case per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
they should be classified as Normative references.  (It's probably also
good to cite RFC 7525 as BCP 195 and not just RFC 7525.)

The IEEE.754 reference is also normative since we use its wire encoding
(but it could practically be considered "well-known" at this point,
given its ubiquity).

[Ballot comment]
[Updates have been made; thanks, everyone, for the discussion and for considering my comments.]

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?

And these below 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.)

[Ballot discuss]
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?

[Ballot comment]
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.)

[Ballot comment]
Thanks for quickly addressing the TSV-ART review (and thanks to David for this very clear and well explained review)! I would have preferred to actually see a normative requirement as original proposed by David ("sample interval SHOULD NOT be less than 1 minute") in section 5.2.1. Also I would have expected the proposed new text to show up somewhere in section 4 (maybe even as a new subsection).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-stateful-pce-auto-bandwidth-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

two, new indicators are to be registered as follows:

Value: [ TBD-at-Registration ]
Description: AUTO-BANDWIDTH-CAPABILITY
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: AUTO-BANDWIDTH-ATTRIBUTES
Reference: [ RFC-to-be ]

Second, a new subregistry of the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

is to be created called the AUTO-BANDWIDTH-CAPABILITY TLV Flag Field registry. New registrations in the registry are to be managed via Standards Action as defined in RFC 8126. There are three fields in the registry as follows:

Bit number
Capability description
Reference

There are no initial registrations in the new registry.

Third, a new subregistry is to be created called the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types registry. The new registry will be created on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

The registry has values between 0-65535. The registration procedure for this registry is as follows:

0-65503 IETF Review
65504-65535 Experimental Use

There are initial registrations in the new registry as follows:

Type Name Reference
---------------------------------------------------------------
0 Reserved [ RFC-to-be ]
1 Sample-Interval sub-TLV [ RFC-to-be ]
2 Adjustment-Interval sub-TLV [ RFC-to-be ]
3 Down-Adjustment-Interval sub-TLV [ RFC-to-be ]
4 Adjustment-Threshold sub-TLV [ RFC-to-be ]
5 Adjustment-Threshold-Percentage sub-TLV [ RFC-to-be ]
6 Down-Adjustment-Threshold sub-TLV [ RFC-to-be ]
7 Down-Adjustment-Threshold-Percentage sub-TLV [ RFC-to-be ]
8 Minimum-Bandwidth sub-TLV [ RFC-to-be ]
9 Maximum-Bandwidth sub-TLV [ RFC-to-be ]
10 Overflow-Threshold sub-TLV [ RFC-to-be ]
11 Overflow-Threshold-Percentage sub-TLV [ RFC-to-be ]
12 Underflow-Threshold sub-TLV [ RFC-to-be ]
13 Underflow-Threshold-Percentage sub-TLV [ RFC-to-be ]
14- Unassigned [ RFC-to-be ]
65535

Fourth, in the PCEP-ERROR Object Error Types and Values registry, also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

a single, new registration will be made as follows:

For error-type 19:

19 Invalid Operations

Error-Value = [ TBD-at-Registration ]: [ RFC-to-be ]
Auto-Bandwidth Capability
was not Advertised

Fifth, in the Notification Object registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

a single, new registration will be made as follows:

Type Meaning Reference
-------------------------------------------------------------
[ TBD-at-Registration ]
Auto-Bandwidth Overwhelm State [ RFC-to-be ]
Notification-value=1: Entering Auto-Bandwidth
overwhelm state
Notification-value=2: Clearing Auto-Bandwidth
overwhelm state

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-28):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, Adrian Farrel , pce@ietf.org, pce-chairs@ietf.org, adrian@olddog.co.uk, draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'PCEP Extensions for MPLS-TE LSP Automatic
Bandwidth Adjustment with
  Stateful PCE'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Path Computation Element Communication Protocol (PCEP) provides
  mechanisms for Path Computation Elements (PCEs) to perform path
  computations in response to Path Computation Clients (PCCs) requests.
  The Stateful PCE extensions allow stateful control of Multi-Protocol
  Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
  LSPs) using PCEP.

  The automatic bandwidth feature allows automatic and dynamic
  adjustment of the TE LSP bandwidth reservation based on the volume of
  traffic flowing through the LSP.  This document describes PCEP
  extensions for automatic bandwidth adjustment when employing an
  Active Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2996/

The PCE working group request publication of draft-ietf-pce-stateful-pce-auto-bandwidth as an IETF Stream RFC.

> (1) What type of RFC is being requested?

Publication is requested as a Proposed Standard.
The document title page indicates "Standards Track" as is conventional for Proposed Standard.
This is the appropriate classification for this document because it includes protocol extensions to a previous IETF Proposed Standard.

> (2) The IESG approval announcement includes a Document Announcement Write-Up.
>
> Technical Summary

The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multi-Protocol
Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
LSPs) using PCEP.

The automatic bandwidth feature allows automatic and dynamic
adjustment of the TE LSP bandwidth reservation based on the volume of
traffic flowing through the LSP.  This document describes PCEP
extensions for automatic bandwidth adjustment when employing an
Active Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs.

> Working Group Summary

There was nothing unusual in the working group processing of this document.

Before the document was adopted there were concerns regarding scaling and scope of the work. The version of this I-D that was adopted handled these and had broad support from the WG at the time of adoption and later during WGLC. There is consensus in the WG to publish this work.

> Document Quality

The authors report "a few" implementations supporting this feature. Some, they say, are more complete than others.

A few people in the working group performed substantial reviews, but most of the working group was quiet. During working group last call a good number of people reported that they had read the document and supported publication.

> Personnel

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd.
Deborah Brungard is the Responsible Area Director.

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I conducted a late review when I took over as document shepherd and the authors fixed a number of nits for me.
In my opinion, the document is ready for pubication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective?

No special reviews are needed, but the usual Directorate reviews will be welcome if they come.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of?

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed.

All authors and contributors made an explicit declaration to the working grop list.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

There is an IPR disclosure at https://datatracker.ietf.org/ipr/2996/
This was announced to the working group on 2019-05-04
One WG participant raised a concern that the IPR was very old and had been disclosed very late. The author who worked for the IPR-owning company answered that he had disclosed as soon as he became aware of the IPR. The concerned participant accepted this answer.

> (9) How solid is the WG consensus behind this document?

The document triggered various discussions and it has been carefully reviewed by a few interested individuals. Overall it can be considered as a consensus of the WG as a whole.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

idnits runs clean.

> (12) Describe how the document meets any required formal review
> criteria.

No such criteria.
The document uses RBNF (RFC 5511) to describe a PCEP message, but it adopts that unchanged from RFC 8281, so no special care is needed.
A reference to RFC 5511 might usefully be added.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

None.

>(15) Are there downward normative references references (see RFC 3967)?

None.

> (16) Will publication of this document change the status of any
> existing RFCs?

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The IANA Considerations section is substantial, but well written and consistent with the existing registries. All the necessary informaiton has been provided.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

Not Applicable.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

Not Applicable.

The PCE working group request publication of draft-ietf-pce-stateful-pce-auto-bandwidth as an IETF Stream RFC.

> (1) What type of RFC is being requested?

Publication is requested as a Proposed Standard.
The document title page indicates "Standards Track" as is conventional for Proposed Standard.
This is the appropriate classification for this document because it includes protocol extensions to a previous IETF Proposed Standard.

> (2) The IESG approval announcement includes a Document Announcement Write-Up.
>
> Technical Summary

The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multi-Protocol
Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
LSPs) using PCEP.

The automatic bandwidth feature allows automatic and dynamic
adjustment of the TE LSP bandwidth reservation based on the volume of
traffic flowing through the LSP.  This document describes PCEP
extensions for automatic bandwidth adjustment when employing an
Active Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs.

> Working Group Summary

There was nothing unusual in the working group processing of this document.

Before the document was adopted there were concerns regarding scaling and scope of the work. The version of this I-D that was adopted handled these and had broad support from the WG at the time of adoption and later during WGLC. There is consensus in the WG to publish this work.

> Document Quality

The authors report "a few" implementations supporting this feature. Some, they say, are more complete than others.

A few people in the working group performed substantial reviews, but most of the working group was quiet. During working group last call a good number of people reported that they had read the document and supported publication.

> Personnel

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd.
Deborah Brungard is the Responsible Area Director.

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I conducted a late review when I took over as document shepherd and the authors fixed a number of nits for me.
In my opinion, the document is ready for pubication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective?

No special reviews are needed, but the usual Directorate reviews will be welcome if they come.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of?

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed.

All authors and contributors made an explicit declaration to the working grop list.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

There is an IPR disclosure at https://datatracker.ietf.org/ipr/2996/
This was announced to the working group on 2019-05-04
One WG participant raised a concern that the IPR was very old and had been disclosed very late. The author who worked for the IPR-owning company answered that he had disclosed as soon as he became aware of the IPR. The concerned participant accepted this answer.

> (9) How solid is the WG consensus behind this document?

The document triggered various discussions and it has been carefully reviewed by a few interested individuals. Overall it can be considered as a consensus of the WG as a whole.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

idnits runs clean.

> (12) Describe how the document meets any required formal review
> criteria.

No such criteria.
The document uses RBNF (RFC 5511) to describe a PCEP message, but it adopts that unchanged from RFC 8281, so no special care is needed.
A reference to RFC 5511 might usefully be added.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

None.

>(15) Are there downward normative references references (see RFC 3967)?

None.

> (16) Will publication of this document change the status of any
> existing RFCs?

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The IANA Considerations section is substantial, but well written and consistent with the existing registries. All the necessary informaiton has been provided.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

Not Applicable.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

Not Applicable.