Subject: Re: [Pce] Path Computation Request in Active Stateful PCE

From: Girish Birajdar <[email-masked]>
Date: Mon, 8 Dec 2014 15:17:17 -0800

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-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
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 9 Dec 2014 14:21:24 +0530

Hi Girish,

See inline....

#DD -  Since I am not the author, I will let them or the shepherd respond.

#DD - IMO this boils down to -  does every delegation requires
a response/ack from the PCE. We all seem to be fine with not getting a
response when the LSP was already up. For a down LSP, do we need to change
this procedure? IMO, No, let the PCE decide what should be done... wait for
network change, or log this and do nothing, or PCE can send PCUpd with down
if the implementation chooses to go that way.

PCRpt is
though
and

#DD - As above, by delegating. PCC has given up control and it is
PCE's prerogative to choose the right action (or inaction). PCC can always
revoke delegation and rely on passive PCReq.

>>
>> 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.

#DD - I agree and that is why I am suggesting to not equate the procedures
of PCReq with that of delegation... Both have a different role to play.

Dhruv

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 16 Dec 2014 16:43:41 +0000

Thanks Dhruv for all the insights.

It would be great if the authors of draft-ietf-pce-stateful-pce added a clarification to section 5.6.2 to state that PCC can use the PCReq/PCRep procedures with an Active Stateful PCE to request the initial path of an LSP before delegation to PCE and also subsequently if required by revoking delegation from PCE.

We believe this will remove some ambiguity. As Girish said, we had some feedback from a test equipment vendor that their interpretation was that Active Stateful PCE does not have to support PCReq/PCRep procedures and that the PCRpt is to be used to request a path computation.

Regards,
Mustapha.

From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Tuesday, December 09, 2014 3:51 AM
To: Girish Birajdar
Cc: [email-masked]
Subject: Re: [Pce] Path Computation Request in Active Stateful PCE

Hi Girish,

See inline....

On Dec 9, 2014 4:47 AM, "Girish Birajdar" <[email-masked]<mailto:[email-masked]>> wrote:
>> On Sat, Dec 6, 2014 at 12:00 PM, <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>> From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
>>>         <[email-masked]<mailto:[email-masked]>>
>>> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>>>         <[email-masked]<mailto:[email-masked]>>
>> 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.

>> 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.

#DD - IMO this boils down to -  does every delegation requires a response/ack from the PCE. We all seem to be fine with not getting a response when the LSP was already up. For a down LSP, do we need to change this procedure? IMO, No, let the PCE decide what should be done... wait for network change, or log this and do nothing, or PCE can send PCUpd with down if the implementation chooses to go that way.

>>> > which is in down state, using the PCRpt message. In this case, the PCRpt is
>>> > 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:
>>> >
>>> >
>>>
>> 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?

#DD - As above, by delegating. PCC has given up control and it is PCE's prerogative to choose the right action (or inaction). PCC can always revoke delegation and rely on passive PCReq.

>>
>> 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.

#DD - I agree and that is why I am suggesting to not equate the procedures of PCReq with that of delegation... Both have a different role to play.

Dhruv