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

[Daniele Ceccarelli <[e-mail]>]

Hi Adrian, Yan,

Congratulations for the wide support! :D

I concur with Dhruv's comment on synchronization, that needs to be addressed IMO and I agree to have it done after WG adoption.

Please see inline.

BR
Daniele

From: Adrian Farrel [mailto:[e-mail]]
Sent: martedì 19 luglio 2016 18:07
To: 'Zhuangyan (Yan)' <[e-mail]>; Daniele Ceccarelli <[e-mail]>; [e-mail]
Cc: 'TEAS WG' <[e-mail]>
Subject: RE: [Teas] draft-zhuang-teas-scheduled-resources

Hi,

See [AF].

Adrian

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.

[AF] I am a little worried about what is not true in this sentence. Can you clarify? Are you suggesting that one of these techniques is not used, or are you suggesting that there are other ways to set up TE-LSPs?
[DC] the text as is seems to say that SDN == direct control of network elements. Just removing "such as in the SDN paradigm" should be fine.

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.

[AF] Perfect answer :-)
You could call this "time-stateful" if you want.
[DC] ok and agree with that. My point (maybe misinterpreted) is that you needed that info for path computation. I'd say you might need it for path computation is you plan for a future LSP and later on you decide to build a totally disjoint LSP...but I'm not sure it is a case worth being covered.


2.       Section 3.2 - 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.

[AF] Yeah. even when we have a continuum we really describe it in slots (e.g., units of seconds). The question to address is the amount of data needed to store the state, and the level of granularity that is needed. If, for example, you allowed a granularity of one second then you could have an LSP every odd second, but not every even second, and that would take quite a lot of storage.
[DC] I see the continuum easy to manage as you store the info that you need to store is that the LSP will be in place from T1 to T2 and not at T1, T1+1slot, T1+2slots, T1+3slots...maybe I'm missing something.


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.
[DC] like for example?


4.       Section 4.2. - 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.

[AF] I hoped that the text of 4.2 did not put it out of scope. But it does say...

   Next, the PCE must construct a time-based TED to show scheduled
   resource usage.  How it does this is implementation specific: it may
   recover a time-based TED previously saved to non-volatile storage, or
   it may reconstruct the time-based TED from information retrieved from
the LSP-DB previously saved to non-volatile storage.

What we intended is that the *mechanism* for constructing the time-based TED is implementation specific. That is, how you create this form the information retrieved from the network and from the time-based LSP-DB is up to the implementer.

If protocol extensions are needed, then for what? They would be to suck data from somewhere. But the network nodes don't have this information.