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

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

Hi,
 
Good to know you're happy for us to move ahead with adoption and handle this
issue as part of the WG discussion.
 
However, no reason to wait for that before we start the discussion.
 
I just spent some time looking at draft-zhuang-pce-stateful-pce-lsp-scheduling
(which is what I assume you mean by "the solution doc" as mentioned in the
minutes).  Of course, the chronology of architecture and solution is a little
broken, and we need to converge the two things: architecture must meet the needs
that the solution demonstrates; solution needs to conform to the architecture.
 
I'd like to try to pin down exactly what synchronization you are looking for (so
we can add the right text). I presume you are not looking for the network/PCE
synchronization that is just business as usual for a stateful PCE. Your focus
is, I suspect, Appendix A of the solution document, and the challenge is that
when one PCE "commits" to supply a scheduled LSP, it needs to install something
in its peer PCEs so that there is no conflict for future resources. The choice
is whether to synch the scheduled-LSP-DB or the scheduled TED (or both).
 
This issue is certainly discussed in draft-zhuang-teas-scheduled-resources-02,
but possibly not sufficiently for your pleasure. I see:
- Section 3.1 bottom bullet of page 6
- Section 4.2
 
Bottom line, we agree that DB synch is important, we believe it builds on synch
for pre-scheduling PCE work, we are happy to add text.
Would you or Dhruv like to suggest text, or at least pin down a little more
clearly what you'd like to see?
 
Thanks
Adrian
 
From: Daniele Ceccarelli [mailto:[e-mail]] 
Sent: 21 July 2016 11:27
To: [e-mail]; 'Zhuangyan (Yan)';
[e-mail]
Cc: 'TEAS WG'
Subject: RE: [Teas] draft-zhuang-teas-scheduled-resources
 
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 [ <https://tools.ietf.org/html/rfc3209> 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.