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

[Huaimo Chen <[e-mail]>]

Hi Robert,

    Thank you very much for your valuable comments.
    They should have been addressed in version 26 uploaded. My explanations are inline below with [HC].

Best Regards,
Huaimo
________________________________
From: Robert Wilton via Datatracker <[e-mail]>
Sent: Wednesday, July 8, 2020 1:10 PM
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: Robert Wilton's No Objection on draft-ietf-pce-stateful-pce-lsp-scheduling-19: (with COMMENT)

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://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%7C18fb9093120a4ebf356508d82361f189%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637298250856502596&amp;sdata=BPjOqAMyEUnqZtwPDjW7vR9rgY4mKgH201Pi642CdnU%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%7C18fb9093120a4ebf356508d82361f189%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637298250856502596&amp;sdata=NSCZpUAOD3XvRMg2WLYd2%2Ft2MDQaV26WgaZH0JxSeLw%3D&amp;reserved=0


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

[HC]: There are some vendors/organizations who are interested in
implementing it but would like to wait after the draft becomes RFC.


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.

[HC]: A client wants to have a scheduled LSP up to carry the traffic
from time T1 for duration D, and has some flexibility on
the starting time T1. The LSP may be up a little bit (such as up to 30 seconds)
earlier or some time (such as up to 60 seconds) later.
Elastic Time LSP Scheduling is suitable for this case.
It will compute a path for the LSP from time T1 for duration D.
When no path is found from time T1 for duration D,
a path may be found for the LSP with the flexibility (i.e.,
a little bit earlier or some time later) and the LSP along the path
may be up to carry the traffic.
When the tunnel has actually been set up, the PCC responsible for the
head of the tunnel would report it to the PCE.
We have added some text to explain (in version 26).


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?

[HC]: During the grace periods, no link bandwidth is reserved for the tunnel.
The tunnel transports the traffic in best effort during these periods.
This seems suitable to some applications such as two parties's meeting
from time T1 to time T2. The QoS needs to be guaranteed from T1 to T2.
A few minutes before T1, poeple may join the meeting.
After T2, people may chat for several minutes, but do not need QoS
guarantee.  Without grace periods, we need to have a tunnel with QoS
from time (T1 - a few minutes) to time (T2 + several minutes).
We have added some text stating the difference (in version 26).


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

[HC]: Generalizing SCHED-PD-LSP-ATTRIBUTE TLV will reduce two TLVs to one.
SCHED-LSP-ATTRIBUTE TLV is a form of SCHED-PD-LSP-ATTRIBUTE TLV with
"no-repeats".
Defining two TLVs (SCHED-PD-LSP-ATTRIBUTE TLV and SCHED-LSP-ATTRIBUTE TLV)
may reduce the size of the message containing these TLVs.
For every scheduled LSP with a time interval, a smaller SCHED-LSP-ATTRIBUTE
TLV is used. It seems that it is more general for a scheduled LSP to have
a time interval.
In addition, there are two LSP schedulings. One is the normal scheduling.
The other is periodical. It seems clearer to use one TLV for the former and
another TLV for the latter.


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.

[HC]: We thought about using NR = 0xFFF as repeat forever before.
But in practice, it seems that there is no unlimited memory/storage
to record the resource reservations for unlimited repeats of time
intervals. We do not adopt "repeat forever".
NR: (12 bits)  The number of repeats. A user can request a scheduled
LSP from time T1 to time T2 to repeat 4095 times at maximum,
which seems big enough.


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.

[HC]: From a user/operator's point of view, it seems natural to have
"repeat every day/week/month/year". It is also desirable to have
"repeat every n weeks/days/hours/minutes/seconds or
some combinations of them (weeks, days, etc)".
All these repeats may be provided through configurations.
Eventually, they are converted to the following three repeats:
repeat every month, repeat every year, and
repeat every repeat-time-length.
repeat every day == repeat every repeat-time-length=86,400 (seconds),
where 86,400 is the number of seconds per day.
repeat every 2 weeks == repeat every repeat-time-length=2*7*86,400.
We have updated the related text accordingly (in version 26).


Hopefully these comment help to improve this document.

[HC]: Your comments improve the quality of the document (version 26 uploaded).

Regards,
Rob