Subject: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

From: Hariharan Ananthakrishnan <[email-masked]>
Date: Tue, 25 Feb 2014 01:52:55 +0000

Hi Authors,

Couple of comments:

[1] section 5.6.2 - Active Stateful PCE LSP Update
     " For each LSP, it sends an LSP State Report carried on PCRpt message to the PCE, indicating that the LSP's status is 'Pending'. "

[Hari] What is the "Pending" status corresponds to in LSP Object ? Is it LSP Operational bits (0-7) ? Does state 'Pending' corresponds to GOING-DOWN(3) or GOING-UP(4) ?

[2] section 6.2 - The PCUpd Message

"A PCC May respond with multiple LSP State Reports to report LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST be included for the first message, for subsequent messages the reserved value 0x00000000 SHOULD be used".

[Hari] A PCC implementation  may send a PCRpt immediately after receiving a PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt, when it receives updates from RSVP.  Putting this behavior in the above context, could you please clarify the if the below behavior is correct:

PCUpdate (SRP-ID 100) -----> PCC
PCE <----------- PCRpt (SRP-ID 100, LSP Operational = GOING-UP) [ Without waiting for RSVP signaling ]
PCE <----------- PCRpt (SRP-ID 0x0000000, LSP Operational bit = UP ] [After receiving successful RSVP setup ]

[3] section 7.2 (SRP Object)

 "An SRP-ID-number is considered unacknowledged and cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same LSP. A PCRpt with state "Pending" is not considered as an acknowledgement."

[Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID and status as "Pending" since the LSP hasn't been signaled. In this case, does the SRP-ID in PCRpt considered unacknowledged ?  It would be great if the SRP-ID could be explained with an example especially for the PCUpdate cases from PCC perspective.

[4] Section 7.3.1.

[Hari] Shouldn't the IPV4-LSP-IDENTIFIERES-TLV length be 16 ?  Similar changes for IPV6-LSP-IDENTIFIER-TLV.

[5] General Comment. Will the "Type=[TBD]" in 7.xx sections be updated with the proposed values in section 8.x.

Thanks,
Hari

---

From: Ina Minei <[email-masked]>
Date: Tue, 25 Feb 2014 18:21:40 -0800

Hari,

Thank you for the review, please find answers inline, marked [ina]

On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan <
[email-masked]> wrote:

>  Hi Authors,
>
>  Couple of comments:
>
>  [1] section 5.6.2 – Active Stateful PCE LSP Update
>      “ For each LSP, it sends an LSP State Report carried on PCRpt message
> to the PCE, indicating that the LSP’s status is ‘Pending’. “
>
>  [Hari] What is the “Pending” status corresponds to in LSP Object ? Is it
> LSP Operational bits (0-7) ? Does state ‘Pending’ corresponds to
> GOING-DOWN(3) or GOING-UP(4) ?\
>

[ina] Yes, will clean up the text. "Pending" is a leftover from much
earlier incarnations of this draft.

>
>  [2] section 6.2 – The PCUpd Message
>
>  “A PCC May respond with multiple LSP State Reports to report LSP setup
> progress of a single LSP. In that case, the SRP-ID-number MUST be included
> for the first message, for subsequent messages the reserved value
> 0x00000000 SHOULD be used”.
>
>  [Hari] A PCC implementation  may send a PCRpt immediately after
> receiving a PCUpdate (without waiting for RSVP completion). Later it sends
> a PCRpt, when it receives updates from RSVP.  Putting this behavior in the
> above context, could you please clarify the if the below behavior is
> correct:
>
>  PCUpdate (SRP-ID 100) —————> PCC
> PCE <——————————— PCRpt (SRP-ID 100, LSP Operational = GOING-UP) [ Without
> waiting for RSVP signaling ]
> PCE <——————————— PCRpt (SRP-ID 0x0000000, LSP Operational bit = UP ]
> [After receiving successful RSVP setup ]
>
> [ina] Yes

>   “An SRP-ID-number is considered unacknowledged and cannot be reused
> until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for
> the same LSP.* A PCRpt with state "Pending” is not considered as an
> acknowledgement.*”
>

[ina] This text is not applicable, it is left over from earlier discussions
on the SRP, thank you for pointing this out.

>
>  [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID
> and status as “Pending” since the LSP hasn’t been signaled. In this case,
> does the SRP-ID in PCRpt considered unacknowledged ?  It would be great if
> the SRP-ID could be explained with an example especially for the PCUpdate
> cases from PCC perspective.
>
>
>  [4] Section 7.3.1.
>
> [Hari] Shouldn’t the IPV4-LSP-IDENTIFIERES-TLV length be 16 ?  Similar
> changes for IPV6-LSP-IDENTIFIER-TLV.
>

[ina] Yes, thank you for catching, the TLV was changed in version 07 but
the length was not updated at that time :-(

>
>  [5] General Comment. Will the “Type=[TBD]” in 7.xx sections be updated
> with the proposed values in section 8.x.
>

[ina] Yes.

>
>  Thanks,
> Hari
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Hariharan Ananthakrishnan <[email-masked]>
Date: Wed, 26 Feb 2014 03:01:28 +0000

Thanks Ina. Another followup question. Can a PCC use PCReq with an 'active stateful PCE' ? The PCE could respond with a PCUpdate in return or PCErr.  This will be useful for a PCC to trigger a path (re)computation based on 'local event' that a PCE might not be aware of.

- Hari

From: Ina Minei <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2014 at 6:21 PM
To: Hariharan Ananthakrishnan <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

Hari,

On Mon, Feb 24, 2014 at 5:52 PM, Hariharan Ananthakrishnan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Authors,

Couple of comments:

[Hari] What is the "Pending" status corresponds to in LSP Object ? Is it LSP Operational bits (0-7) ? Does state 'Pending' corresponds to GOING-DOWN(3) or GOING-UP(4) ?\

[ina] Yes, will clean up the text. "Pending" is a leftover from much earlier incarnations of this draft.

[ina] Yes

[ina] This text is not applicable, it is left over from earlier discussions on the SRP, thank you for pointing this out.

[4] Section 7.3.1.

[ina] Yes, thank you for catching, the TLV was changed in version 07 but the length was not updated at that time :-(

[ina] Yes.

Thanks,
Hari

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 26 Feb 2014 04:17:05 +0000

Hi Hari,

Apologies for butting in, but...

From: Pce [mailto:[email-masked]] On Behalf Of Hariharan Ananthakrishnan
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

Thanks Ina. Another followup question. Can a PCC use PCReq with an 'active stateful PCE' ? The PCE could respond with a PCUpdate in return or PCErr.  This will be useful for a PCC to trigger a path (re)computation based on 'local event' that a PCE might not be aware of.
[DD] A "local events" can simply be reported to the active stateful PCE via PCRpt for a delegated LSP...
Do you have any specific event in mind that would require PCReq instead?

Dhruv

- Hari

Hari,

Couple of comments:

[ina] Yes

[4] Section 7.3.1.

[ina] Yes.

Thanks,
Hari

---

From: Hariharan Ananthakrishnan <[email-masked]>
Date: Wed, 26 Feb 2014 17:35:47 +0000

Inline..

From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2014 at 8:17 PM
To: Hariharan Ananthakrishnan <[email-masked]<mailto:[email-masked]>>, Ina Minei <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

Hi Hari,

[Hari] The local event could be a timer event say re-optimize timer..

Dhruv

- Hari

Hari,

Couple of comments:

[ina] Yes

[4] Section 7.3.1.

[ina] Yes.

Thanks,
Hari

---

From: Ina Minei <[email-masked]>
Date: Wed, 26 Feb 2014 10:07:13 -0800

Hari,

The short answer is that sending a path computation request as per 5440 is
not precluded in the draft, although this rather breaks the delegation
concept. What is not available today is to send the LSP object in the
PCReq, but for your scenario that is not needed.

However, the model of operation where the PCC sends PCReq should be
carefully considered, because now the control is split between PCC and PCE.
A cleaner solution is for the PCE to be made aware of the local trigger and
take the decision to act on it, or the PCC to revoke the delegation, change
the LSP then delegate again. This is a case-by-case evaluation.

Ina

On Wed, Feb 26, 2014 at 9:35 AM, Hariharan Ananthakrishnan <
[email-masked]> wrote:

>  Inline..
>
>   From: Dhruv Dhody <[email-masked]>
> To: Hariharan Ananthakrishnan <[email-masked]>, Ina Minei <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Apologies for butting in, but…
>
>
>
> *From:* Pce [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Hariharan Ananthakrishnan
> *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt
>
>
>
> Thanks Ina. Another followup question. Can a PCC use PCReq with an ‘active
> stateful PCE’ ? The PCE could respond with a PCUpdate in return or PCErr.
>  This will be useful for a PCC to trigger a path (re)computation based on
> ‘local event’ that a PCE might not be aware of.
>
> *[DD] A ”local events” can simply be reported to the active stateful PCE
> via PCRpt for a delegated LSP… *
>
> *Do you have any specific event in mind that would require PCReq instead?*
>
> *Dhruv*
> *From: *Ina Minei <[email-masked]>
> *Date: *Tuesday, February 25, 2014 at 6:21 PM
> *To: *Hariharan Ananthakrishnan <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt
>
>
>
> Hari,
>
>
>
> [Hari] A PCC implementation  may send a PCRpt immediately after receiving
> a PCUpdate (without waiting for RSVP completion). Later it sends a PCRpt,
> when it receives updates from RSVP.  Putting this behavior in the above
> context, could you please clarify the if the below behavior is correct:
>
>
>
>  “An SRP-ID-number is considered unacknowledged and cannot be reused until
> a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same
> LSP.* A PCRpt with state "Pending” is not considered as an
> acknowledgement.*”
>
>
>
> [ina] This text is not applicable, it is left over from earlier
> discussions on the SRP, thank you for pointing this out.
>
>
>
> [Hari] Per section 6.2, the first message (PCRpt) will have the SRP-ID and
> status as “Pending” since the LSP hasn’t been signaled. In this case, does
> the SRP-ID in PCRpt considered unacknowledged ?  It would be great if the
> SRP-ID could be explained with an example especially for the PCUpdate cases
> from PCC perspective.
>
>
>
>
>
> [4] Section 7.3.1.
>
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 27 Feb 2014 08:13:51 +0530

Hi Ina, Hari,

I agree with Ina that this would break the delegation process, once you
have given control over to the PCE, it should be remain with PCE.

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

This has an added advantage for P2MP LSP (which are much bigger in size and
option to not encode a full P2MP LSP would be good).

Regards,
Dhruv

On Wed, Feb 26, 2014 at 11:37 PM, Ina Minei <[email-masked]> wrote:

>> Thanks Ina. Another followup question. Can a PCC use PCReq with an
>> 'active stateful PCE' ? The PCE could respond with a PCUpdate in return or
>> PCErr.  This will be useful for a PCC to trigger a path (re)computation
>> based on 'local event' that a PCE might not be aware of.
>>
>> *[DD] A "local events" can simply be reported to the active stateful PCE
>> via PCRpt for a delegated LSP... *
>>
>>      " For each LSP, it sends an LSP State Report carried on PCRpt
>> message to the PCE, indicating that the LSP's status is 'Pending'. "
>>
>>
>>
>> [Hari] What is the "Pending" status corresponds to in LSP Object ? Is it
>> LSP Operational bits (0-7) ? Does state 'Pending' corresponds to
>> "A PCC May respond with multiple LSP State Reports to report LSP setup
>> 0x00000000 SHOULD be used".
>>
>>
>>
>> PCUpdate (SRP-ID 100) ----------> PCC
>>
>> PCE <---------------------- PCRpt (SRP-ID 100, LSP Operational = GOING-UP) [ Without
>> PCE <---------------------- PCRpt (SRP-ID 0x0000000, LSP Operational bit = UP ]
>>  "An SRP-ID-number is considered unacknowledged and cannot be reused
>> the same LSP.* A PCRpt with state "Pending" is not considered as an
>> acknowledgement.*"
>>
>>
>>
>> and status as "Pending" since the LSP hasn't been signaled. In this case,

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 27 Feb 2014 07:40:00 +0100

El 27/02/2014 3:43, Dhruv Dhody escribió:
> 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

---

From: Cyril Margaria <[email-masked]>
Date: Thu, 27 Feb 2014 09:43:39 +0100

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 <[email-masked]> wrote:

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

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 28 Feb 2014 06:32:31 +0000

Hi, All,

     I also support adding this function. I remember previous version of this draft (v6) does support this (see: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.4). It would be good to explain why it is removed in the current version if not before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhruv could be addressed if v8 is used. That would help to see if this function is indeed useful.

Regards,
Xian

From: Pce [mailto:[email-masked]] On Behalf Of Cyril Margaria
Sent: 2014年2月27日 16:44
To: Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

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 <[email-masked]<mailto:[email-masked]>> wrote:

> 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

---

From: Ina Minei <[email-masked]>
Date: Fri, 28 Feb 2014 17:05:02 -0800

All,

To Xian's question, as we explained in the wg meeting, the LSP object in
PCReq and PCRep was removed because:
a) there was no further mention anywhere in the document on the use in
those messages, or of the LSP object in those messages, or of the values of
its fields (as can be seen from this thread, different people used them
differently).
b) no use cases were specified in the applicability document for this use.

I think specifying the use cases and the accompanying operation would make
for a very good separate document.

Ina

On Thu, Feb 27, 2014 at 10:32 PM, Zhangxian (Xian) <[email-masked]>wrote:

>  Hi, All,
>
>
>
>      I also support adding this function. I remember previous version of
> this draft (v6) does support this (see:
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.4).
> It would be good to explain why it is removed in the current version if not
> before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhruv
> could be addressed if v8 is used. That would help to see if this function
> is indeed useful.
>
>
>
> Regards,
>
> Xian
>
>
>
> *From:* Pce [mailto:[email-masked]] *On Behalf Of *Cyril Margaria
> *Sent:* 2014年2月27日 16:44
> *To:* Ramon Casellas
> *Cc:* [email-masked]
>
> 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.
>
>
>