re-sending with correct email subject. Earlier email was reply to digest format
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
