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

[Dhruv Dhody <[e-mail]>]

Hi Adrian, 

Please see inline...

> -----Original Message-----
> From: Adrian Farrel [mailto:[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.
> 
[Dhruv] I am happy with chairs/AD taking the call :)

> > (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?
> 
[Dhruv] The only harm (well not really harm, but...) would be that so far none of the RSVP or RSVP-TE documents, as far as I am aware of, explicitly included "CPU utilization, memory, buffers..." as resources that could be reserved; which made me wonder if a document about scheduling should? 

(snip)
> 
> > (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.
> 
[Dhruv] I agree with you. The only issue I had was in the text - 

   When it is time such as at a start time for the LSP to be set up, the
   PCE sends a PCEP Initiate request to the head end LSR (d) providing
   the path to be signaled as well as other parameters such as the
   bandwidth of the LSP.

When a LSR/PCC is configured with a tunnel with scheduling information, it can send a "service request" to PCE via a PCEP message  (PCRpt) and in this case, I am not sure if the use of a PCEP Initiate message from PCE to setup the LSP is right choice. I guess we can debate that in the solution document, a simple resolution would be either to say PCInitiate/PCUpd message or not to mention a message by name.   

(snip)

> > Thanks and apologies for taking a bit more time!
> 
> No problem. Thank you for the input. You are now a contributor :-)
> 


[Dhruv] Thanks! :)

Regards,
Dhruv

> Adrian