Hi Dhruv, Thanks for the response. Few questions/comments, please see inline
On Sat, Dec 6, 2014 at 12:00 PM, <[email protected]> wrote: > > Date: Sat, 6 Dec 2014 11:54:22 +0530 > From: Dhruv Dhody <[email protected]> > To: "Aissaoui, Mustapha (Mustapha)" > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [Pce] Path Computation Request in Active Stateful PCE > Message-ID: > < > cab75xn5iv5oks02sd2ufvudrzhggpr2iszqgrxkbonfqyx8...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Mustapha, > > Since delegation is applied per LSP and not all LSPs are delegated it > is perfectly fine for an active stateful PCE to receive PCReq/PCRep. > In your mail you apply a passive / active property to whole PCC/PCE > which is not correct. > > I see this as - > > Stateless PCE > Stateless PCE + PCRpt (LSPBD) = Passive Stateful PCE > Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) = Active Stateful PCE > The draft too mentions this as definitions. Active stateful PCE is extension to functionality supported by passive stateful PCE. However the interaction shown in section 5.6.1 and 5.6.2 gives impression that PCRequest is handled by PCE acting as "passive stateful" and not "active stateful". Verbatim interpretation of these section contradict the definitions given in beginning of the draft. Would it be possible for the authors to address this issue in next draft, unless the the description in section 5.6.1 is not meant for "active stateful" PCE. > At the same time, someone may choose to implement (as per some SDN > like deployment) to only support delegation. But that is their choice. > In case one implements a PCE only with "PCRpt (LSPBD) + PCUpd (delegation)", is it expected to respond to a PCRpt with down path in case the path was not computed at PCE? The draft is clear about use of PCUpd - mainly to handle topology events that affect existing paths or to allow operator to optimize network. > > > > > > 2. The PCC starts in the active stateful mode and delegates the LSP, > > which is in down state, using the PCRpt message. In this case, the PCRpt > is > > used to synchronize the state of the LSP with the PCE but also as an > > implicit way to request the initial LSP path computation. The issue > though > > is that the PCRpt message is not an explicit path computation request and > > lacks the following: > > > > > > It is completely fine for PCC to delegate an unsignalled LSP to PCE. > But I think we should not equate a path computation request with > delegation completely. With delegation your aim is to give up some > control and let PCE run the show, one should not expect the behavior > of this action to be exactly same as a path computation > request/response. > > Is it reasonable for PCC to expect PCUpd (with path)? or the PCE returns error for path that was never computed either by PCE or locally by PCC? We recently had interaction with vendor implementing PCEP test tools, they seem to interpret "active stateful PCE" need not support the RFC5440 functionality and a PCC could get path computed by sending PCRpt!!! I hope this is not a widely conceived opinion in order to circumvent PCRequest/PCReply. Thanks, Girish
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
