Skip to main content

Framework for Scheduled Use of Resources
draft-ietf-teas-scheduled-resources-07

Yes

(Deborah Brungard)

No Objection

(Adam Roach)
(Alissa Cooper)
(Alvaro Retana)
(Ben Campbell)
(Ignas Bagdonas)
(Martin Vigoureux)
(Spencer Dawkins)
(Suresh Krishnan)

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

Deborah Brungard Former IESG member
Yes
Yes (for -06) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2018-04-04 for -06) Unknown
It might be nice to have some idea of a typical/expected timescale for length of reservation and distance in the future
being reserved, though I concede there is risk that any such suggestion could become stale.

In Section 3.2

   [...] When the LSP or the
   request for the LSP with a number of time intervals is cancelled, the
   PCE must release the resources that were reserved on each of the
   links along the path of the LSP in every time intervals from the TED.
   If the bandwidth reserved on a link for the LSP is B from time T2 to
   T3 and the unreserved bandwidth on the link is B2 from T2 to T3, B is
   added to the link for the time interval from T2 to T3 and the
   unreserved bandwidth on the link from T2 to T3 will be B2 + B

Is this supposed to describe what happens when the request for an
LSP from T2 to T3 is cancelled?  If so, the text does not do a good
job of indicating it -- the "If the bandwidth reserved..." reads like it's
starting a new conditional expression, not necessarily connected to the
previous coverage of cancellation.


Thank you for the clear security considerations section!
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-04-04 for -06) Unknown
One question: I think I don't understand how the proposed framework would interact with non-Time-Scheduled reservations or reservations that support TS but don't know their end-time. If you have such reservations, you basically already need to block the resources of all future scheduled reservations because you don't know how long the requested unbounded reservation is needed, which could also lead to an non-optimal resource  scheduling. Could you please clarify this in the document or further elaborate/acknowledge this problem in the doc?
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -06) Unknown