Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 3 Mar 2014 02:21:15 +0000

Hi, Ina, and all,

   As for b), I do not think it is entirely true.  In the restoration section(Section 5.4.2), It mentions the existing method provided by RFC5521 and the advantage of a stateful PCE. So, this is a good example of using PLSP-ID instead of providing detailed LSP information (such as ERO etc.), even though It may not be as obvious as you want it.

Another related example, in the last paragraph of Section 5.4 (Recovery), it states as the following:

“ A passive stateful PCE maintains the updated SRLG information of the
   established LSPs in a centralized manner.  Therefore, the PCC can
   specify as constraints to the path computation the SRLG disjointness
   of a set of already established LSPs by only providing the LSP
   identifiers.”

Although Dhruv, Cyril and Ramon mentioned different usage, but the extensions required are the same, putting LSP object into the PCReq/PCRep (Note: This will be OPTIONAL). So it actually proves, from different angles, the need of such an extensions. Cyril and Dhruv’s use cases are recovery/optimization related, they should fall into the scope of applicability draft since we already have these use cases already. I will talk with them to see how what they have in mind can be reflected in the applicability draft to explicitly support such a requirement. As for Ramon’s suggestion, it seems to me, more operational driven. So, I am not sure it should be included in the applicability draft or it should be mentioned in the base draft (as a reason to support such extensions)?  Thoughts?

As for Ina’s suggestion of making a separate document, I am not sure it should be done this way. Recovery/re-optimization is fundamental, thus should be part of the base extensions. If you agree/disagree, can share your thoughts please?

Regards,
Xian

From: Ina Minei [mailto:[email-masked]]
Sent: 2014年3月1日 9:05
To: Zhangxian (Xian)
Cc: Cyril Margaria; Ramon Casellas; [email-masked]
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

All,

To Xian's question, as we explained in the wg meeting, the LSP object in PCReq and PCRep was removed because:
a) there was no further mention anywhere in the document on the use in those messages, or of the LSP object in those messages, or of the values of its fields (as can be seen from this thread, different people used them differently).
b) no use cases were specified in the applicability document for this use.

I think specifying the use cases and the accompanying operation would make for a very good separate document.

Ina

On Thu, Feb 27, 2014 at 10:32 PM, Zhangxian (Xian) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, All,

     I also support adding this function. I remember previous version of this draft (v6) does support this (see: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.4). It would be good to explain why it is removed in the current version if not before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhruv could be addressed if v8 is used. That would help to see if this function is indeed useful.

Regards,
Xian

From: Pce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Cyril Margaria
Sent: 2014年2月27日 16:44
To: Ramon Casellas
Cc: [email-masked]<mailto:[email-masked]>

Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

Hi
I agree with Ramon and Druv.
In addition to those use case, the LSP object in PCReq/PCRep is also applicable for non-delegated LSP in an active stateful PCE case.
One example can be the rerouting after a failure, this may affect delegated and non delegated LSPs, the Stateful PCE would be benefit from knowing which non delegated LSP is to be rerouted.
BR,
Cyril.

On 27 February 2014 07:40, Ramon Casellas <[email-masked]<mailto:[email-masked]>> wrote:
El 27/02/2014 3:43, Dhruv Dhody escribió:

> What is not available today is to send the LSP object in the PCReq,
Ina since you bring this up, IMO LSP object in PCReq for passive stateful PCE can be useful in case of re-optimization, exclusion etc.
Some extensions to PCEP are needed to do that, but the first step would be to identify an LSP in PCReq message.

Dhruv, Ina, all

TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE may delegate a complex (e.g. optical) computation/re-optimization/defragmentation to a "back-end" PCE, and both the TED and LSPDB are shared between the pool of PCEs. In previous versions of the draft, we used the LSP object that was included within a PCEP request. There was the issue about the plspid, our approach was based on using a dummy plspid and refer to the LSP entry in the database by its symbolic name (primary key).

In short, we did find it useful to be able to "refer" to an LSP within the db when requesting computations between collaborating PCEs. Indeed, much like Dhruv's, for this specific use case, the backend is stateful but passive. The alternative is to provide the RRO, but the db contains other relevant information that cannot be conveyed in a "rfc5440" re-optimization

Thanks
Ramon

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 3 Mar 2014 09:41:50 +0100

Hi,

I agree with Xian the  applicability consider those use case and the
passive statefull in general.
In order to support the passive stateful use case it seems to be a bit
overkill to create a separate document to revert an optional object from 2
revision ago.

Best Regards.

On 3 March 2014 03:21, Zhangxian (Xian) <[email-masked]> wrote:

>  Hi, Ina, and all,
>
>
>
>    As for b), I do not think it is entirely true.  In the restoration
> section(Section 5.4.2), It mentions the existing method provided by RFC5521
> and the advantage of a stateful PCE. So, this is a good example of using
> PLSP-ID instead of providing detailed LSP information (such as ERO etc.),
> even though It may not be as obvious as you want it.
>
>
>
> Although Dhruv, Cyril and Ramon mentioned different usage, but the
> extensions required are the same, putting LSP object into the PCReq/PCRep
> (Note: This will be OPTIONAL). So it actually proves, from different
> angles, the need of such an extensions. Cyril and Dhruv’s use cases are
> recovery/optimization related, they should fall into the scope of
> applicability draft since we already have these use cases already. I will
> talk with them to see how what they have in mind can be reflected in the
> applicability draft to explicitly support such a requirement. As for
> Ramon’s suggestion, it seems to me, more operational driven. So, I am not
> sure it should be included in the applicability draft or it should be
> mentioned in the base draft (as a reason to support such extensions)?
>  Thoughts?
>
>
>
> As for Ina’s suggestion of making a separate document, I am not sure it
> should be done this way. Recovery/re-optimization is fundamental, thus
> should be part of the base extensions. If you agree/disagree, can share
> your thoughts please?
>
>
>
> Regards,
>
> Xian
>
>
>
> *From:* Ina Minei [mailto:[email-masked]]
> *Sent:* 2014年3月1日 9:05
> *To:* Zhangxian (Xian)
> *Cc:* Cyril Margaria; Ramon Casellas; [email-masked]
>
> *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt
>
>
>
> All,
>
>
>
> a) there was no further mention anywhere in the document on the use in
> those messages, or of the LSP object in those messages, or of the values of
> its fields (as can be seen from this thread, different people used them
> differently).
>
> On Thu, Feb 27, 2014 at 10:32 PM, Zhangxian (Xian) <[email-masked]>
> wrote:
>
> Hi, All,
>
>
>
>      I also support adding this function. I remember previous version of
> this draft (v6) does support this (see:
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.4).
> It would be good to explain why it is removed in the current version if not
> before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhruv
> could be addressed if v8 is used. That would help to see if this function
> is indeed useful.
>
>
>
> Regards,
>
> Xian
>
>
>
> *From:* Pce [mailto:[email-masked]] *On Behalf Of *Cyril Margaria
> *Sent:* 2014年2月27日 16:44
> *To:* Ramon Casellas
> *Cc:* [email-masked]
>
>
> *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt
>
>
>
> Hi
>
> In addition to those use case, the LSP object in PCReq/PCRep is also
> applicable for non-delegated LSP in an active stateful PCE case.
>
> One example can be the rerouting after a failure, this may affect
> delegated and non delegated LSPs, the Stateful PCE would be benefit from
> knowing which non delegated LSP is to be rerouted.
>
> BR,
>
> Cyril.
>
>
>
> On 27 February 2014 07:40, Ramon Casellas <[email-masked]> wrote:
>
> Ina since you bring this up, IMO LSP object in PCReq for passive stateful
> PCE can be useful in case of re-optimization, exclusion etc.
>
> TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE
> may delegate a complex (e.g. optical)
> computation/re-optimization/defragmentation to a "back-end" PCE, and both
> the TED and LSPDB are shared between the pool of PCEs. In previous versions
> of the draft, we used the LSP object that was included within a PCEP
> request. There was the issue about the plspid, our approach was based on
> using a dummy plspid and refer to the LSP entry in the database by its
> symbolic name (primary key).
>
> In short, we did find it useful to be able to "refer" to an LSP within the
> db when requesting computations between collaborating PCEs. Indeed, much
> like Dhruv's, for this specific use case, the backend is stateful but
> passive. The alternative is to provide the RRO, but the db contains other
> relevant information that cannot be conveyed in a "rfc5440" re-optimization
>
> Thanks
> Ramon
>
>
> [email-masked]
> [email-masked]