Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

[Huaimo Chen <[e-mail]>]

Hi Alvaro,

    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 22 of the document uploaded

Best Regards,
Huaimo

________________________________
From: Alvaro Retana via Datatracker <[e-mail]>
Sent: Tuesday, July 7, 2020 2:38 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Adrian Farrel <[e-mail]>
Subject: Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-stateful-pce-lsp-scheduling-19: 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%7C434b7ffeba034a05e78408d822a4f7d2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297439231224552&amp;sdata=mCwVobys5l1PWRY5kMWJpEpJkiMERoWN3gEgdh0eNg8%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%7C434b7ffeba034a05e78408d822a4f7d2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297439231224552&amp;sdata=SmHFx7UDDZGg15NdjPtjkGsRQuweyNiH1Xr9X93yvgo%3D&amp;reserved=0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I think that this document still needs work before publication.  I consider the
first 3 points below to be close to DISCUSS-worthy.

(1) In general, it feels like an editorial pass is needed to tighten up the
language used as specification in this document.  There are several places
where the language feels loose -- as an example (from §4.4):

   In PCC-Initiated case, the PCC can send a PCRpt message for the
   scheduled LSP with updated parameters as well as scheduled
   information included in the SCHED-LSP-ATTRIBUTE TLV (see
   Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2)
   carried in the LSP Object.  The PCE would take the updated resources
   and schedule into considerations and update the new path for the
   scheduled LSP to the PCC as well as synchronize to other PCEs in the
   network.  In case path cannot be set based on new requirements, the
   previous LSP will not be impacted and the same should be conveyed by
   the use of empty ERO in the PCEP messages.

"the PCC can send"  Does it have to?  If the information is not sent, then the
PCE will not be able to calculate the path, so something stronger than "can"
seems to be needed.

"PCE would take"  Does this mean that it is optional?  I can imagine how the
PCE may have local policies affecting the action...but I shouldn't have to
imagine anything.

"should be conveyed"  Again, do you have to?  Are there cases when it is ok not
to do it?

Not everything needs rfc2119 key words, but in some cases they would help.  In
this case, I can see a couple of variations possible.

rfc2119>
   ...the PCC MUST send...the PCE SHOULD take...MUST be conveyed...

non-rfc2119>
   ...the PCC sends...the PCE takes...is conveyed...

[HC]: We have updated the document according to rfc2119 as you suggested.


(2) §4.1: "a PCE MUST synchronize to other PCEs within the network...Which way
is used to achieve this is out of scope for this document."   If the
synchronization mechanism is out of scope, how can an implementation be
compliant with this specification?  IOW, if there's nothing to normatively
refer to, then normative language shouldn't be used, or a mechanism should be
mandated.  In either case, because synchronization between the PCEs seems
important for this specification, I would like to also see a discussion about
the specific effects on LSP scheduling instead of the generic pointer to
rfc7399.

[HC]: The description related seems too broad. We have rephrased
the related text to focus on the state of a scheduled LSP
crossing multiple domains from an ingress domain to an egress domain.
There is a PCE responsible for each of these domains.
The PCE for the ingress domain is called ingress PCE.
The PCE for the egress domain is called egress PCE.
The state of the LSP MUST be synchronized among these PCEs.

After a path for the LSP is computed, a PCRpt message with the
scheduled LSP inforamtion MUST be sent to every PCE along the path
from the ingress PCE to the egress PCE.
After receiving the PCRpt message,
the PCE MUST update its SLSP-DB according to the scheduled LSP inforamtion.

The ingress PCE acting as a PCC sends its next hop PCE the PCRpt message.
After receiving the PCRpt message, the next hop PCE acting as a PCC sends
its next hop PCE the PCRpt message. This continues until the egress
PCE receives the PCRpt message.


§4.3 says that the "stateful PCE...shall send a PCRpt message with the
scheduled LSP to other PCEs...to achieve...synchronization."  Even though
normative language is not used, the intent seems to specifically point at using
PCRpt messages for synchronization...

Besides the confusing use of language, rfc8231 defines PCRpt as a "message sent
by a PCC to a PCE to report the current state of an LSP", but I didn't see
where the use if defined between PCEs -- maybe I missed it.  §6.1 does
reinforce that the "Path Computation State Report (PCRpt) is a PCEP message
sent by a PCC to a PCE to report the status of one or more LSPs as per
[RFC8231]....This message is also used to synchronize the scheduled LSPs to
other PCE as described in [RFC8231]".  But this last point is what I can't find
in rfc8231.

[HC]: We have updated/cleaned the text related.
The Path Computation State Report (PCRpt) is a PCEP message sent by
a PCC to a PCE as per [RFC8231]. A PCE can act as a PCC to send a PCRpt
message to another PCE.


(3) This whole document is about scheduling LSPs, which would seem to require
time synchronization.  However, I found only one mention: "It is necessary to
synchronize the clocks of the PCEs and PCCs when relative time is used."
Should this sentence use normative language?  Is there a recommended way to
achieve time synchronization?  This seems to be an important manageability
consideration that impacts network operations.

[HC]: Yes. We have changed it to use normative language, and
recommended Network Time Protocol [RFC5905] for time synchronization.


(4) rfc8413 should be a Normative reference because it "provides a framework
that describes and discusses the problem, and defines an appropriate
architecture for the scheduled reservation of TE resources", which is the basis
for the extensions defined in this document.

[HC]: We have moved it to Normative reference section.


(5) §2.1: Some of the terminology terms have 2 references -- that caught my
attention.  For example, the definition of TED points at both rfc5440 and
rfc8231.  rfc5440 has a definition, but rfc8231 points at rfc4655.  Luckily,
the definitions in rfc5440 and rfc4655 are the same...but the added indirection
through rfc8231 is unnecessary.  Please revalidate the references and include
only one.

[HC]: We have revalidated them and removed the unnecessary ones.


(6) §2.1: "Duration:  This value indicates the time duration..."   Please don't
use "duration" to define "duration".  Maybe s/time duration/length of time

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


(7) §4.1: "A PCC MUST delegate a scheduled LSP with information of its
scheduling parameters, including the starting time and the duration using PCRpt
message."  This sentence seems to refer to the use of the new TLVs defined
later in the test.  Please include a forward reference to make it easier for
the reader to figure out how this action would be done.

[HC]: We have added a forward reference to the TLV.


(8) §4.3: "The PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and
update its scheduled TED."  When is it ok for the PCE not to add this
information?  IOW, why is MUST not used?  If the information is not added, what
is the effect on the required synchronization?

[HC]: We have changed SHOULD to MUST.


Later in this section: "The stateful PCE is required to update its local
scheduled LSP-DB and scheduled TED with the scheduled LSP."  Even though
normative language is not used here, the intent of requiring an update to the
databases seems different than above and results in confusion.

[HC]: We have changed "is required to" to MUST


(9) §4.3: "the PCC knows that it is a scheduled path"  How?  I'm sure that it
is through the contents of the messages.  Please be specific.

[HC]: We have indicated the specific TLV in the message.


(10) §5.1: "After a PCEP session has been established, a PCC and a PCE
indicates its ability to support LSP scheduling during the PCEP session
establishment phase."  Is it after or during?

[HC]: During. We have changed it to During.


(11) §5.1: "...the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231].  Note that
the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]..."  Redundant.

[HC]: We have removed the first "defined in [RFC8231]".


(12) §5.1: "we define a new flag bit B (SCHED-LSP-CAPABLITY) flag...B
(LSP-SCHEDULING-CAPABILITY..."  The names don't match.

[HC]: We have updated the text.


(13) §5.1: "Setting PD bit requires setting B bit as specified in 5.2.2."  That
is not specified in §5.2.2.  However, it brings up the question about the
interpretation of only receiving the PD bit set -- I'm assuming that it should
be ignored unless the B but is also set, right?  If so, please specify it!

[HC]: You are right. We have added the text to state that it MUST be ignored.


(14) §5.2: "this LSP is requesting scheduled parameters"  The request is by the
PCC, not the LSP...

[HC]: It SHOULD be "this LSP has scheduled parameters".
We have changed it accordingly.


(15) §5.2: "scheduled LSP attribute TLV"  Even though it may be obvious, the
SCHED-LSP-ATTRIBUTE TLV is not called "scheduled LSP attribute TLV" anywhere in
the document.

[HC]: We have changed it to "SCHED-LSP-ATTRIBUTE TLV".


(16) §5.2: "For periodical LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in
LSP Object for each periodic scheduled LSP carried in the PCEP messages."
Don't you *have* to use it?  Otherwise, how would the periodic nature be known?

[HC]: We have changed can to MUST.


(17) §5.2: "Only one of these TLV SHOULD be present in the LSP object.  In case
more than one scheduling TLV is found, the first instance is processed and
others ignored."  This section talks about both the SCHED-LSP-ATTRIBUTE and the
SCHED-PD-LSP-ATTRIBUTE TLVs -- the sentence sounds as if only one of them
(either one) should be present.  Please rephrase -- it may be better to define
this behavior for each TLV independently (in §5.2.*).

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


(18) §5.2.1: "This TLV MUST NOT be included unless both PCEP peers have set the
B..."  What should the receiver do if the TLV is received when both peers
didn't set the B bit?

[HC]: The receiver ignores the TLV. We have added the text about this.



(19) §5.2.1: "Just before the wraparound, if the time at which the LSP is to be
activated is after the wraparound..."   I don't know how that is possible.

[HC]: We have added details in version 20.


(20) §5.2.1: "...non-zero grace period or elastic range, but it MUST NOT
provide both for an LSP."  What should a receiver do if both sets are non-zero?

[HC]: We have addressed this in version 20.
The same space (32 bits) is used for grace period or elastic range.
A flag G-bit is defined to indicate which one is stored in the space.
G=1: the space stores the Grace period.
G=0: the space stores elastic range.


(21) §5.2.2: "This TLV MUST NOT be included unless both PCEP peers have set the
B...and PD..."  What should the receiver do if the TLV is received but both
bits were not set?

[HC]: The receiver ignores the TLV. We have added the text about this.


(22) §5.2.2: "A new registry "Opt" under SCHED-PD-LSP-ATTRIBUTE is created."
The registry is not part of the definition of the field...this sentence is not
needed here.

[HC]: We have removed it.


(23) §5.2.2: "Opt value not defined"   I think you may mean an unknown value
(or maybe unsupported).

[HC]: We have changed it to "unknown Opt value".


(24) Nits:

s/following terminologies are re-used/following terminology is re-used

s/computes a path/compute a path/g

s/by PCE itself/by a|the PCE itself

s/setup of LSP/setup of an LSP

s/ask PCC/ask the PCC

s/In PCC-Initiated case/In the PCC-Initiated case/g

s/In PCE-Initiated case/In the PCE-Initiated case/g

s/establish PCEP session/establish a PCEP session

s/Setting PD bit requires setting B bit/Setting the PD bit requires setting the
B bit

s/presence of SCHED-LSP-ATTRIBUTE/presence of the SCHED-LSP-ATTRIBUTE

s/in LSP Object/in the LSP Object/g

s/one of these TLV/one of these TLVs

s/B (LSP-SCHEDULING-CAPABILITY bit)/B (LSP-SCHEDULING-CAPABILITY) bit/g

s/Following flags/The following flags

s/remains same as/remain the same as in the

s/Options =/Opt =

s/In each of repeats, /During each repetition

§6.1: s/described in [RFC8231]/described in [RFC8231].

[HC]: We have changed all the related text accordingly.