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

["Zhuangyan (Yan)" <[e-mail]>]

Hi Daniele,

Thank you very much for the review and comments.
Please see some responses inline.

Best Regards,

Yan

·¢¼þÈË: Teas [mailto:[e-mail]] ´ú±í Daniele Ceccarelli
·¢ËÍʱ¼ä: 2016Äê7ÔÂ19ÈÕ 7:10
ÊÕ¼þÈË: [e-mail]
³­ËÍ: TEAS WG ([e-mail])
Ö÷Ìâ: [Teas] draft-zhuang-teas-scheduled-resources

Hi Yan, authors,

I did a review of the draft and I believe it is well written and provides a good overview of the problem statement and the frameworks.
There are some minor issues that can be addressed in further versions, like for example the sentence below which I don¡¯t believe is true:

   TE-LSPs in existing networks are provisioned using RSVP-TE as a
   signaling protocol [RFC3209<https://tools.ietf.org/html/rfc3209>][RFC3473] or by direct control of network
   elements such as in the Software Defined Networking paradigm.

But these are not relevant to the main topic of the draft and can be addressed in the future.
My other comments are:


1.       It is not clear why the LSP-DB time aware is needed for path computation. The only reason that comes to my mind is the same reason that lead to the definition of the LSP-DB for stateful PCE, but I don¡¯t understand why it is needed to have a time aware LSP-DB and a time aware TED is not enough.
The time-based TED is not enough in the time-based system. We still have to trace back to the LSP.
In conventional system, when an LSP is withdrawn, it is torn down and the network released the resources. While in a time-based system, when an LSP that has not yet been set up is withdrawn, we don¡¯t know what resource to release (in the time-based TED) because we don¡¯t know what path the LSP took.


2.       Section 3.2 ¨C Why did you decide to have the time indicated as a discrete number of slots? Wouldn¡¯t it be easier to make it a continuum?
For discrete slots in section 3.2, the bandwidth requirements differs in these slots so the idea is to reserve different bandwidth at respective slots.


3.       Figure in section 4: I don¡¯t understand the need to have d) for LSRs and e) for routers¡­also LSRs can speak BGP-LS. I would just leave LSRs.
The idea here is also include routers which might not be a LSR here.


4.       Section 4.2. ¨C I wouldn¡¯t leave the recovery out of scope as implementation specific. Some options may need dedicated protocol extensions. Moreover if we want a PCE from vendor A to speak with a network from vendor B we need to state how the PCE builds the Time based TED.
Yes, a good point to discuss.

Thank you again and please feel free to share more thoughts.

BR
Daniele