Re: [Teas] AD review: draft-ietf-teas-scheduled-resources

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

Hi Deborah,

Thanks for the thoughtful review.

> I’ve done my AD review of your draft. This draft is on a complex problem
space.
> In reviewing it, it reminded me of the discussion around the MLN work
(RFC5212,
> RFC5339) which discussed scheduling of resources (virtual). 

You're right. And not much has changed over the (very nearly) ten years. That
is, there is an assumption that there is some management element responsible for
handling the "booking" of network resources. Of course, 5212 and 5338
(importantly supplemented by 5623 that defined VNTM) considered multi-layered
networks, where we are focused on booking in a single layer.

> Most significantly, I missed discussion related to operator policy.

There is a slightly different nuance to this important issue. In a multi-layer
network we are concerned (one might say worried!) about how a client network
requests resources from a server network. Operator policy is, of course,
fundamental in that scenario.

But in our case, we are looking at how an operator manages their own network. Of
course, there is policy there, but (one assumes) an operator does not manage
their own network outside of their own policy. That is to say, it is the
operator's PCE that is doing the work. (No unicorns were harmed in the
production of this document!)

Nevertheless, I think we could usefully add a new section 3.3 called
"Enforcement of operator policy."  See below.

> Here’s several critical items which were discussed in the MLN work:
> • Amount of capacity available for scheduling needs to be under
>    operator policy.
> • The use of scheduled resources if needed during a sudden change
>  in traffic demand event or a complex (multiple nodes/links) failure
>  event needs to be based on operator policy so as to protect against
>  network destabilization.

There are two cases:

- If the repair is handled by the network then the fact that the resources
  are reserved is unknown by the network and that PCE will react in the
  same way that it would to a link failure and will try to recompute the
  path of the booked LSP.

- If the repair is handled by the PCE then it is aware of the booked resources
  and can apply "operator policy" to determine whether the booked LSP is
  more or less important than repair of the failed LSP.

> • The choice of reserving immediately resources for future use or to
>  book without reserving network capacity must be under the control
>   of an operator. And both should be supported by the database
>  (need to be able to distinguish).

Resources that are reserved "now" are indistinguishable from provisioned LSPs
(because they are provisioned LSPs). So, yes, an operator could service a
request for an LSP to be available next year by setting it up today (or
responding "No, come back later"). You may be suggesting that such LSPs
provisioned ahead of their actual need could be more pre-emptable than LSPs that
are in use. But I think that is crazy-talk :-) If you want to be more
pre-emptable, then don't provision the LSP - that's why you have a stateful PCE.

> • Section 2.5 “allows pre-emption”. This was the first mention of pre-emption
>  of current reservations to handle a scheduled reservation. There is no
additional
>  discussion e.g. priority, etc. Pre-emption is a complex subject and if it is
allowed,
>  more description is needed and it needs to be added that it is based on
operator
>  policy.

You're right that 2.1 and 2.2 should talk about pre-emption.
Personally, I don't think it is a particularly complex concept. But recall, the
decision is under the control of the stateful PCE.

> • Need to include network performance factors (maximum link utilization
>  and residual capacity of the network) with respect to supporting scheduling
>  and subject to operator policy.

Yes, we could make more of Objective Functions. I guess we're just too used to
seeing that as a normal, everyday factor of PCE.

> • When you discuss re-optimization, you need to add this needs to be under
>  control of operator policy as the stability of the network will be impacted.

Now you must remember whose PCE this is. Re-optimization out of the control of a
PCE is no more than a service re-provisioning request, but since the application
is unlikely to be able to see much of the TED, it is meaningless for it to make
such a request. Re-optimization under the control of the PCE is exactly
according to the operator's policy by definition.

> • The OAM status of the reserved resources (alarms) must be available. Control
of
>  recalculations for the scheduled resources and notifications of the alarms
needs to
>  be subject to policy.

It either is or it isn't!
This is no different to any other TED computation except (of course?) computing
an LSP's path for an LSP due in three years' time might be more likely to ignore
today's alarms.
 
> In the abstract, you say “This document provides a framework..discusses the
> architecture..”. As this document is more than an architecture, I think the
title
> should reflect it is a “Framework..”.

This choice of semantics is way above my pay-grade.

 > You listed CPU utilization, memory, buffers of interfaces as resources that
can be
> scheduled. As this draft is on TE LSPs, I didn’t see the relation to these
parameters
> (for RSVP-TE signaling or PCE use)?

Yup. RSVP-TE is not used to provision compute and storage resources - for which
we are suitably grateful. But some people observe that an orchestrator is a type
of PCE and that an SDN system uses a PCE at its core. 

> In the acknowledgements, you list chen-teas-frmwk-tts and also list it
>  in the references. As this earlier document was dated March 2016, it 
> would be sufficient to list the authors as you have done, saying
>  contributed to earlier version, but don’t list the no longer existing
> document.
 
The text as written is very precise. Is there a problem with an informative
reference to an expired draft?

> There are multiple instances where the English lacks in clarity and
> impacts the understanding. I’ve suggested improvements for
> multiple sentences, though the document needs a more careful review. 

Red Rag, please meet Mr. Bull.

I'll look through your comments with interest :-)
 
> As I said, this is a complex problem space so don’t take my comments
> negatively. I’ll send a marked up document to the authors with my
> suggestions for appropriate sections to add text and improving clarity.

Thanks again.

And now, proposed text...

====

3.3 Enforcement of Operator Policy

Computation requests for LSPs are serviced according to operator policy. For
example, a PCE may refuse a computation request because the application making
the request does not have sufficient permissions, or because servicing the
request might take specific resource usage over a given threshold.

Furthermore, the pre-emption and holding priorities of any particular
computation request may be subject to the operator's policies. The request could
be rejected if it does not conform to the operator's policies, or (possibly more
likely) the priorities could be set/overwritten according to the operator's
policies.

Additionally, the objective functions (OFs) of computation request (such as
maximizing residual bandwidth) are also subject to operator policies. It is
highly likely that the choice of OFs is not available to an application and is
selected by the PCE or management system subject to operator policies and
knowledge of the application.

None of these statements is new to scheduled resources. They apply to stateless,
stateful, passive, and active PCEs, and they continue to apply to scheduling of
resources.

An operator may choose to configure special behavior for a PCE that handles
resource scheduling. For example, an operator might want only a certain
percentage of any resource to be bookable. And an operator might want the
pre-emption of booked resources to be an inverse function of how far in the
future the resources are needed for the first time.

It Is a general assumption about the architecture described in Section 4 that a
PCE is under the operational control of the operator that owns the resources
that the PCE manipulates. Thus the operator may configure any amount of
(potentially complex) policy at the PCE. This configuration would also include
policy points surrounding re-optimization of existing and planned LSPs in the
event of changes in the current and future (planned) resource availability.

====

Best,
Adrian (passing through Newark and so able to throw rocks ;-)