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

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 18 Jul 2016 23:10:25 +0000

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.

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?

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.

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.

BR
Daniele

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Tue, 19 Jul 2016 09:22:24 +0000

Hi Daniele,

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

Best Regards,

Yan

发件人: Teas [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2016年7月19日 7:10
收件人: [email-masked]
抄送: TEAS WG ([email-masked])
主题: [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:

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Jul 2016 17:06:44 +0100

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?

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 21 Jul 2016 10:27:09 +0000

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:[email-masked]]
Sent: martedì 19 luglio 2016 18:07
To: 'Zhuangyan (Yan)' <[email-masked]>; Daniele Ceccarelli <[email-masked]>; [email-masked]
Cc: 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] draft-zhuang-teas-scheduled-resources

Hi,

See [AF].

Adrian

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

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.

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

[DC] like for example?

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

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 22 Jul 2016 10:42:29 +0100

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:[email-masked]] 
Sent: 21 July 2016 11:27
To: [email-masked]; 'Zhuangyan (Yan)';
[email-masked]
Cc: 'TEAS WG'
Subject: RE: [Teas] draft-zhuang-teas-scheduled-resources
 
Hi Adrian, Yan,

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:[email-masked]] 
Sent: martedì 19 luglio 2016 18:07
To: 'Zhuangyan (Yan)' <[email-masked]>; Daniele Ceccarelli
<[email-masked]>;
[email-masked]
Cc: 'TEAS WG' <[email-masked]>
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:

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

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

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 22 Jul 2016 12:07:22 +0200

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 <[email-masked]> 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.
>
>
>
> 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:
>
> 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:[email-masked]]
> *Sent:* 21 July 2016 11:27
> *To:* [email-masked]; 'Zhuangyan (Yan)';
> *Cc:* 'TEAS WG'
> *Subject:* RE: [Teas] draft-zhuang-teas-scheduled-resources
>
>
>
> Hi Adrian, Yan,
>
>
>
> 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:[email-masked]]
> *Sent:* martedì 19 luglio 2016 18:07
> *To:* 'Zhuangyan (Yan)' <[email-masked]>; Daniele Ceccarelli
> *Cc:* 'TEAS WG' <[email-masked]>
> *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:
>
>
>
>    signaling protocol [RFC3209 <https://tools.ietf.org/html/rfc3209>][RFC3473]
> [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.
>
>
>
> 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.
>
> 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 :-)
>
> [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.
>
>
>
> 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.
>
> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>