Subject: [Pce] Erik Kline's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-18: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Sun, 05 Jul 2020 23:45:42 -0700

Erik Kline has entered the following ballot position for
draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[ section 1 ]

* "the service really being used" -> "the service is really being used"?

[ section 4.1 ]

* "SHALL check ... and computes" -> "... and compute"

* "on the scheduling usage expires" -> "on scheduled usage expiration"?

[ section 4.2.2 ]

* If there is no possible path do you want some text, maybe even just a
  lowercase should, about "should report to an administrator" or something?

[ section 4.3 ]

* In the first of the 4 bullet points at the end of this section, should the
  "required" and "shall" be capitalized?

[ section 4.5 ]

* "In other case," -> "In all other cases," or just "Otherwise,"?

[ section 5.1 ]

* Perhaps there's a way to strengthen the "PD requires B" text by saying what
  an endpoint should do if it sees PD without B?

[ section 5.2.1 & 5.2.2 ]

* R bit.  WRT to R=0 and the wraparound, it would seem to me that in this
  case the receiver really needs to check if start-time is less than the
  current time, and if so treat that as wrap-around (2106) + start-time number
  of seconds.

  Otherwise, I think you'll need to be more precise about what it means to be
  "near" the wrap-around.  Even still, if times are not sync'd carefully and
  the start-time is not a moderate amount of time in the future there remains
  a chance that an endpoint could receive a start-time it perceives as
  "in the past". What should an endpoint in this circumstance?

  Yet another alternative is to take a flag bit to indicate that start-time is
  after the wrap-around, and say that by 2242 CE some other solution should be
  found.  :-)

* Duration: Is a value of 1 just as nonsensical as 0?  What about a value of
  0 if grace-before and grace-after are non-zero?

  I may not understand the grace and elastic uses properly, but it seems to
  me that the thing to forbid is an "effective duration" of 0 (i.e. factoring
  in grace or elastic values).

* Grace and Elastic fields:  If it cannot provide both simultaneously why have
  both fields?  What just have a "lower" and "upper" pair of fields and choose
  a new flag value to indicate whether the fields are grace values or elastic
  values?

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 12 Jul 2020 18:44:17 +0000

Hi Erik,

    Thank you very much for your valuable comments, which improve the quality of the document.
    My explanations/answers are inline below with prefix [HC].
    The comments have been addressed in version 20 of the document uploaded.

Best Regards,
Huaimo

________________________________
From: Erik Kline via Datatracker <[email-masked]>
Sent: Monday, July 6, 2020 2:45 AM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked] <[email-masked]>
Subject: Erik Kline's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-18: (with COMMENT)

Please refer to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2dab594ee3e44c0e8a7008d82178352b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296147471756053&amp;sdata=1PioVZz%2FQB%2FDpaOFqyDjFZbFg8DQNxTNHPD0%2B7NRd8w%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2dab594ee3e44c0e8a7008d82178352b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637296147471756053&amp;sdata=Tt1CWH9WxW%2BmOO1Yi8t%2FyVw6vfJkyc1kRj4hPDH7fZQ%3D&amp;reserved=0

[ section 1 ]

[HC]: We have changed it as you suggested.

[ section 4.1 ]

[HC]: We have changed it as you suggested.

[HC]: We have changed it as you suggested.

[ section 4.2.2 ]

[HC]: Yes. We have added some text to report
"Constraints could not be met for some intervals".

[ section 4.3 ]

[HC]: We have capitalized them.

[ section 4.5 ]

[HC]: We have changed it to "Otherwise," as you suggested.

[ section 5.1 ]

[HC]: We have added some text accordingly.

[HC]: We have added some more details.

[HC]: We have added some text to state that the value of Duration SHOULD
be greater than a constant MINIMUM-DURATION seconds, where MINIMUM-DURATION
is 5.
Even though the grace-before and grace-after are non-zero, the value of
Duration SHOULD be greater than a constant MINIMUM-DURATION seconds.
Elastic will not change the duration of an LSP, it just gives some
relaxation for computing a path for the LSP with a time interval
(say [Ta, Tb], which means from time Ta to time Tb). The duration,
which is Tb - Ta, is fixed. With elastic, the interval [Ta, Tb] may
be shifted to left or right to satisfy the constraints of the path
for the LSP if a path could not be found in the interval [Ta, Tb].
Grace extends the lifetime of the LSP to include the grace period.
For an LSP with interval [Ta, Tb], and grace-before GB and grace-after GA,
the lifetime of the LSP is from (Ta-GB) to (Tb+GA).
During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the
LSP is up to carry traffic (maybe in best effort).
In the time period from Ta to Tb, QoS is guaranteed since
a path is computed such that the path satisfies the constraints for the
LSP in the time period from Ta to Tb.

[HC]: We have updated the document according to your suggestion.