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

[Dhruv Dhody <[e-mail]>]

Hi Adrian,

Here is the text for the section on synchronization between PCEs, as well as a few more comments –


(1) Why is the intended status of the document "Standards Track"?



(2) In section 2.4, perhaps we should limit to simple example of resources, do you see value in including CPU utilization and buffers?



(3) In Section 3.1

OLD:

      *  If the scheduling state is held centrally at a PCE, the state

         must be held and restored after a system restart.  This is

         relatively easy to achieve on a central server that can have

         access to non-volatile storage.

NEW:

      *  If the scheduling state is held centrally at a PCE, the state

         must be held and restored after a system restart.  This is

         relatively easy to achieve on a central server that can have

         access to non-volatile storage. The PCE could also synchronize

         the scheduling state with other PCEs after restart. See section

         4.2 for details.



(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.

In case of LSR, do we allow configuration of future LSP at the LSR? If yes when does PCE learns about it? It would be helpful for PCE to know in advance and thus in this case (a) and (d) are sort of merged and we use PCEP for service request too, (perhaps via delegation of a future LSP, which will impact the choice of PCEP message in (d))...



(5)A new section on State synchronization

4.3  Synchronization between the PCEs



   If there is more than one PCE active in the network which supports

   scheduling, it is important to achieve some consistency between the

   scheduled TED and  scheduled LSP-DB between the PCEs.



   [RFC7399] answers various questions around synchronization between

   the PCEs. It should be noted that the time-based "scheduled"

   information adds another dimension to it. It should be noted that the

   deployment may use a primary PCE and the other PCEs as backup, where

   the backup PCE can take over only in the event of a failure of the

   primary PCE. Or the PCEs may share the load at all times. The choice

   of the synchronization technique is largely dependent on the

   deployment of PCEs in the network.



   One option for ensuring that multiple PCEs use the same scheduled

   information is simply to have the PCEs driven from the same shared

   database, but it is likely to be inefficient and inter-operation

   between multiple implementation harder.



   Or the PCEs might be responsible for its own scheduled database and

   utilize some distributed database synchronization mechanism to have a

   consistent database. Based on the implementation, this could be

   efficient but the inter-operation between heterogeneous

   implementation is still hard.



   Another approach would be to utilize PCEP messages to synchronize the

   scheduled state between PCEs. This approach would work well if the

   number of PCEs which support scheduling are less, but as the number

   increases considerable message exchange needs to happen to keep the

   scheduled database in sync. Future solution could also utilize some

   synchronization optimization techniques for efficiency. Another

   variation would be to request information from other PCEs for a

   particular time slice but this might have impact on the optimization

   algorithm.





(6) Some idnits exist - https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-zhuang-teas-scheduled-resources-02.txt

Thanks and apologies for taking a bit more time!

Regards,
Dhruv

From: Teas [mailto:[e-mail]] On Behalf Of Dhruv Dhody
Sent: 22 July 2016 15:37
To: Farrel Adrian <[e-mail]>
Cc: Zhuangyan (Yan) <[e-mail]>; [e-mail]; Daniele Ceccarelli <[e-mail]>; TEAS WG <[e-mail]>
Subject: Re: [Teas] draft-zhuang-teas-scheduled-resources

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]<mailto:[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]<mailto:[e-mail]>]
Sent: 21 July 2016 11:27
To: [e-mail]<mailto:[e-mail]>; 'Zhuangyan (Yan)'; [e-mail]<mailto:[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]<mailto:[e-mail]>]
Sent: martedì 19 luglio 2016 18:07
To: 'Zhuangyan (Yan)' <[e-mail]<mailto:[e-mail]>>; Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'TEAS WG' <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas