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) <zhang.x...@huawei.com> 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. > > > > 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:inami...@google.com] > *Sent:* 2014年3月1日 9:05 > *To:* Zhangxian (Xian) > *Cc:* Cyril Margaria; Ramon Casellas; pce@ietf.org > > *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) <zhang.x...@huawei.com> > 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:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria > *Sent:* 2014年2月27日 16:44 > *To:* Ramon Casellas > *Cc:* pce@ietf.org > > > *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 <ramon.casel...@cttc.es> 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 > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
