Re: [Teas] [RTG-DIR] Routing directorate review of draft-ietf-teas-scheduled-resources-04

["Adrian Farrel" <[e-mail]>]

Hello again, Jon.

Reiterating my thanks for your review.

In line...

> Section 2.5
> 
> I found the following sentence to be misplaced, because it is the first sentence in this section that
> talks about LSP reservation requests, and it appears in the middle of a paragraph that is discussing
> scheduling state.
>
> |   Multiple periods, possibly
> |   of different lengths, may be associated with one reservation request,
> |   and a reservation might repeat on a regular cycle.
>
> LSP reservation requests are then not mentioned again until the final paragraph, where
> it says that you must keep them in a database, too.

OK. That took me a bit to work out, but this might do the job...

OLD
   There are multiple ways to realize this information model and
   different ways to store the data.  The resource state could be
   expressed as a start time and an end time as shown above, or could be
   expressed as a start time and a duration.  Multiple periods, possibly
   of different lengths, may be associated with one reservation request,
   and a reservation might repeat on a regular cycle.  Furthermore, the
   current state of network reservation could be kept separate from the
   scheduled usage, or everything could be merged into a single TS
   database.

   This scheduling state information can be used by applications to book
   resources for future or now, so as to maximize chance of services
   being delivered.  Also, it can avoid contention for resources of
   LSPs.

   Note that it is also necessary to store the information about future
   LSPs.  This information is held to allow the LSPs to be instantiated
   when they are due and using the paths/resources that have been
   computed for them, but also to provide correlation with the TS-TE
   resource reservations so that it is clear why resources were reserved
   allowing pre-emption and handling release of reserved resources in
   the event of cancellation of future LSPs.
NEW
   There are multiple ways to realize this information model and
   different ways to store the data.  The resource state could be
   expressed as a start time and an end time as shown above, or could be
   expressed as a start time and a duration.  Multiple reservation
   periods, possibly of different lengths, may be need to be recorded
   for each resource.  Furthermore, the current state of network
   reservation could be kept separate from the scheduled usage, or
   everything could be merged into a single TS database.

   An application may make a reservation request for immediate resource
   usage, or to book resources for future use so as to maximize the
   chance of services being delivered and to avoid contention for
   resources in the future.  A single reservation request may book
   resources for multiple periods and might request a reservation that
   repeats on a regular cycle.

   A computation engine (that is, a PCE) may use the scheduling state
   information to help optimise the use of resources into the future and
   reduce contention or blocking when the resources are actually needed.

   Note that it is also necessary to store the information about future
   LSPs as distinct from the specific resource scheduling.  This
   information is held to allow the LSPs to be instantiated when they
   are due and using the paths/resources that have been computed for
   them, but also to provide correlation with the TS-TE resource
   reservations so that it is clear why resources were reserved allowing
   pre-emption and handling release of reserved resources in the event
   of cancellation of future LSPs.
END

> Please explain and differentiate more clearly between the database of scheduled
> resources and the database of LSP reservation requests.  You should say what 
> information is contained in each, and how the information in the latter relates to
> the information in the former.  I suggest you delete the above quoted sentence 
>and then expand the final paragraph to give more details on the LSP reservation
> request database.
>
> Actually, now I have read further, section 3.2 already does this very well, so I think it
> would be best to combine 2.5 with it.

Mutters into beard ;-)

There is a fine line. The databases are *a* realisation of how the data may be stored. We don't want to push too far into how an implementation actually stores the information that has to be held.

With the rewrite above, I propose also adding a forward pointer to 3.2.
ADD
           See Section 3.2 for further discussion of the distinction
           between scheduled resource state and scheduled LSP state.
END

> Section 3.1
> 
> In the discussion of the issues of centralizing the scheduling state database, the third 
> bullet appears not to be an issue, but a mitigation of bullet 2.  I think it should be
> merged into bullet 2.

Hmmm. It was intended to set up an issue (starting in a similar way to bullet 2), but somehow the issue never got written, and that is probably because there isn't an issue.

I propose to strike bullet 3.

> In the final bullet, you say that the central server must have full control of
> reservations, but I think you should take the extra step and justify this 
> statement.  If a node sets up its own RSVP-TE LSP without contacting the 
> server, then it may invalidate some plans that the server has already made.
> The server will eventually find out about the new reservation, but (a) it might
> take too long to find out and (b) the server will have no idea how long the
> reservation is going to persist for.  I think you are saying that, for reasons
> (a) and (b), all reservations must be scheduled by the server without exception.
>  Correct?

Well, not quite.  The problems you identify as (a) and (b) are real, but could be reconciled provided the central server can collect the information from the network. So, when the text says...
      but the problem of collecting the information
      from the network is only solved if the central server has full
      control of the booking of resources and the establishment of new
      LSPs.
The intention was to highlight the challenge of collecting the information. But the text didn't do that :-(

So...
OLD
   o  Of course, a centralized system must store information about all
      of the resources in the network.  In a busy network with a high
      arrival rate of new LSPs and a low hold time for each LSP, this
      could be a lot of state.  This is multiplied by the size of the
      network measured both by the number of links and nodes, and by the
      number of trackable resources on each link or at each node.  The
      challenge may be mitigated by the centralized server being
      dedicated hardware, but the problem of collecting the information
      from the network is only solved if the central server has full
      control of the booking of resources and the establishment of new
      LSPs.
NEW
   o  Of course, a centralized system must store information about all
      of the resources in the network.  In a busy network with a high
      arrival rate of new LSPs and a low hold time for each LSP, this
      could be a lot of state.  This is multiplied by the size of the
      network measured both by the number of links and nodes, and by the
      number of trackable resources on each link or at each node.  This
      challenge may be mitigated by the centralized server being
      dedicated hardware, but there remains the problem of collecting
      the information from the network in a timely way when there is
      potentially a very large amount of information to be collected and
      when the rate of change of that information is high.  This latter
      challenge is only solved if the central server has full control of
      the booking of resources and the establishment of new LSPs so that
      the information from the network only serves to confirm what the
      central server expected.
END

> Section 3.2
>
> This treads much of the same ground as section 2.5 and does it much better.  I
> suggest merging the two, or making 2.5 very brief and giving a forward reference
> to 3.2.

See above.

> Section 4.1
>
> I think it would be useful to note in paragraph 2 that the update to the TEDB may trigger
> a re-optimization of the TEDB, potentially changing a previously computed reservation for
> existing LSP requests, either by pre-empting them or by moving their planned paths. 
> And this might involve some sort of update sent back over interface (a).
>
> Similarly, in the final paragraph, if an LSP request is cancelled then it may trigger a 
> re-optimization of the TEDB such that previously requested LSPs are re-planned or
> become viable.

Yes (modulo s/re-optimization of the TEDB/re-optimization of the LSPs/)

But I don't want to interrupt the flow of 4.1. How about...

ADD
4.1.1.  Reoptimization After TED Updates
   
   When the TED is updated as indicated in Section 4.1, the PCE may
   perform reoptimization of the LSPs for which it has computed paths.
   These LSPs may be already provisioned in which case the PCE issues
   PCEP Update request messages for the LSPs that should be adjusted.
   Additionally, the LSPs being reoptimized may be scheduled LSPs that
   have not yet been provisioned, in which case reoptimization involves
   updating the store of scheduled LSPs and resources.

   In all cases, the purpose of reoptimization is to take account of the
   resource usage and availability in the network and to compute paths 
   for the current and future LSPs that best satisfy the objectives of
   those LSPs while keeping the network as clear as possible to support
   further LSPs.
END

> References
> Please update:
> draft-ietf-pce-pceps -> RFC 8253
> draft-ietf-pce-stateful-pce -> RFC 8231

Tempus fugit!

Yes.

Cheers,
Adrian