PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE
draft-ietf-pce-stateful-pce-lsp-scheduling-27

Note: This ballot was opened for revision 17 and is now closed.

Deborah Brungard Yes

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2020-07-08 for -19)
I concur with Alvaro Retana’s point (2) and (3), that since time synchronization is key to functionality clarified normative guidance is needed.

I support Ben Kaduk's DISCUSS position.

** Section 2.1.  Thank you for providing a mapping of terms to references.

** Consider using normative language in the following places:
-- Section 5.2.1.  Per “The Start-Time indicates a time at or before which the schedule LSP must be set up”, should this be a normative MUST?

-- Section 8.  Per “Thus, such deployment should employ suitable PCEP security mechanisms …”, why not a normative SHOULD?

** Editorial Nits:
-- Section 1.  Typo. s/can not/cannot/

-- Section 5.2.1.  Typo. s/an non zero/a non zero/g

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-08-07 for -24)
No email
send info
Thank you for addressing my Discuss points!

Erik Kline No Objection

Comment (2020-07-05 for -18)
[ 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?

Murray Kucherawy No Objection

Comment (2020-07-06 for -19)
Section 2.1:

* "Passive Stateful PCE" is listed in the imported terminology, but not used elsewhere in the document.

Sections 5.2.1 & 5.2.2:

* I had the same questions Erik did about the R-bit.

Section 7:

The text here is unchanged since version -09 of this document, which recorded no known implementations, and was posted almost a year ago.  Is that still the case now?

Section 10.1.1:

This section defines a new registry but doesn't explicitly describe the fields of that registry like Section 10.1.2 does.  It's nice to be explicit about these things, in my opinion.

Barry Leiba No Objection

Alvaro Retana No Objection

Comment (2020-07-07 for -19)
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...
   


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

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



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



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



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



(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



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



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

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.



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



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



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



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



(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!



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


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



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



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



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



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



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



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



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



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



(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].

Éric Vyncke No Objection

Comment (2020-07-06 for -18)
Thank you for the work put into this document. 

Please find below one non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 4.2.2.1 --
May be am I failing to understand this part of the sentence "|X| is the minimum value from 0 to max(P, Q)" as it is not the same as "where -P <= X <= Q" or does the "|X|" not represent the absolute value of X ? 

== NITS ==

-- Section 4.2.2.1 --
Please use "are" rather than "is" in "Note that both Ta and Tb is shifted by the same 'X'"

Magnus Westerlund No Objection

Robert Wilton No Objection

Comment (2020-07-08 for -19)
I found that document somewhat hard to read and support Alvaro's comment that this document would benefit from an editorial pass.  However, it is worth noting that I don't have much knowledge/experience of PCE.

A few comments:

Top level comment - should this draft be marked as "Experimental" if it unclear whether it will be implemented?

4.2.2.1.  Elastic Time LSP Scheduling

It wasn't quite clear to me how an end client would make use of elastic time scheduling.  Is there some signalling mechanism to inform the client at the point in time that the tunnel has actually been set up, or otherwise how do they know when to make use of it?  This might be worth clarifying in this section unless it is covered elsewhere.

4.2.2.2.  Grace Periods

I'm not really convinced that grace periods are worth it.  I.e. the PCC client could trivially do the calculation and request the exact duration that they wanted which would slightly simplify the protocol messages.  Is there any further justification as to why grace periods are requried?

5.2.  LSP Object

I'm not entirely convinced that it is that useful/necessary to have both messages.  I would have probably just defined SCHED-PD-LSP-ATTRIBUTE TLV and treated the non repeating case as degenerate case (i.e. opt = "no-repeats", repeat-time-length = 0).

5.2.2.  SCHED-PD-LSP-ATTRIBUTE TLV

It isn't clear to me whether a client can make a request for it to repeat forever (until cancelled), and if so, how that would be indicated.

Did you consider other encodings of the "Opt" and "Repeat-time-length" fields:
 - I would have added "seconds", "minute", "hours" to the "Opt" field and removed "Options = 5: repeat every Repeat-time-length".
 - I would then always combine the "Opt" field with the "Repeat-time-length" field, e.g. so that you could express repeat every 12 hours as: (opt="hours", repeat-time-length=12), or every 30 minutes as (opt="minutes", repeat-time-length=30), etc.
 
Hopefully these comment help to improve this document.

Regards,
Rob