Subject: [Pce] Robert Wilton's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 08 Jul 2020 10:10:54 -0700

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

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