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
