Re: [Teas] draft-zhuang-teas-scheduled-resources

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

Ciao Dhruv,

> Here is the text for the section on synchronization between PCEs

Thanks!

> as well as a few more comments 

Welcomed.

> (1) Why is the intended status of the document "Standards Track"? 

Why, indeed?!
I don't plan to have that conversation :-)
IMHO, an architecture is normative for solutions work.
But opinions vary and we will be guided by our chairs and the AD.

> (2) In section 2.4, perhaps we should limit to simple example of resources, do
>  you see value in including CPU utilization and buffers?

Well, the example is in the text:

   The resource that is scheduled can be link capacity, physical
   resources on a link, CPU utilization, memory, buffers on an
   interfaces, etc.  The resource might also be the maximal unreserved
   bandwidth of the link over a time intervals.  For any one resource
   there could be multiple pieces of scheduling state, and for any one
   link, the timing windows might overlap.

The intention is to illustrate that a wide range of things could be considered as "resources".

Is there any harm in the text?

> (3) In Section 3.1
>OLD:
>   *  If the scheduling state is held centrally at a PCE, the state
>      must be held and restored after a system restart.  This is
>      relatively easy to achieve on a central server that can have
>      access to non-volatile storage.
>NEW:
>   *  If the scheduling state is held centrally at a PCE, the state
>      must be held and restored after a system restart.  This is
>      relatively easy to achieve on a central server that can have
>      access to non-volatile storage. The PCE could also synchronize 
>       the scheduling state with other PCEs after restart. See section 
>       4.2 for details.            

Yes. Thanks.

> (4) In section 4.1, would it be better to differentiate between the
> case when service requester is App/NMS v/s when it is an LSR.
> Basically to show, when the arrow (a) in the figure is via a management
> interface. 

Hmm. I thought that one of the things that 4655 made clear was that there was no difference between a request from an NMS or from an LSR. 
Indeed, the "service requester" in the figure could be the "LSR" shown in the same figure.  I will make that point clearer, although the paragraph starts with an observation about the requester.

> In case of LSR, do we allow configuration of future LSP at the LSR? If yes when does PCE
> learns about it?

Yes, it's allowed. I guess the PCE learns about it at the time the LSR chooses to tell it. If it leaves it late, however, it runs the risk of resources having been booked for something else.  In this respect there is no difference between this LSP and any other scheduled LSP.

> It would be helpful for PCE to know in advance and thus in this case (a) and (d) are
> sort of merged and we use PCEP for service request too, (perhaps via delegation
> of a future LSP, which will impact the choice of PCEP message in (d))...  

Don't mix up the actors with the actions. (a) is the request for an LSP to be scheduled, and (d) is the "command" to set up the LSP.

> (5)A new section on State synchronization 
> 4.3  Synchronization between the PCEs

[snip]

Thanks for this text.

> (6) Some idnits exist

Yup. Tidiness is next to godliness.

> Thanks and apologies for taking a bit more time! 

No problem. Thank you for the input. You are now a contributor :-)

Adrian