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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
