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

[Dhruv Dhody <[e-mail]>]

Hi Adrian,

You are right! I can provide text by next week.

Thanks!
Dhruv

On Fri, Jul 22, 2016 at 11:42 AM, Adrian Farrel <[e-mail]> wrote:

> 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 [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.
>
>
>
>
>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
>