Subject: Re: [Pce] Pce Digest, Vol 123, Issue 6

From: Girish Birajdar <[email-masked]>
Date: Mon, 8 Dec 2014 11:44:36 -0800

Hi Dhruv,

Thanks for the response.
Few questions/comments, please see inline

On Sat, Dec 6, 2014 at 12:00 PM, <[email-masked]> wrote:

>
> Date: Sat, 6 Dec 2014 11:54:22 +0530
> From: Dhruv Dhody <[email-masked]>
> To: "Aissaoui, Mustapha (Mustapha)"
>         <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [Pce] Path Computation Request in Active Stateful PCE
> Message-ID:
>         <
> [email-masked]>
> 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