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

[Huaimo Chen <[e-mail]>]

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 <[e-mail]>
Sent: Monday, July 6, 2020 2:45 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Adrian Farrel <[e-mail]>; [e-mail] <[e-mail]>
Subject: Erik Kline's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-18: (with COMMENT)

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://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



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

[ section 1 ]

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

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

[ section 4.1 ]

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

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

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

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

[ 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?

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


[ section 4.3 ]

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

[HC]: We have capitalized them.

[ section 4.5 ]

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

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

[ 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?

[HC]: We have added some text accordingly.

[ 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.  :-)

[HC]: We have added some more details.


* 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).

[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.


* 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?

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