Subject: [Pce] Whither Stateless PCE?

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 Apr 2016 20:00:44 +0100

Once upon a time, in a working group far, far away, PCE was basically stateless.
PCE acted in response to questions asked by PCCs.

These days, everyone is excited by stateful PCEs and there is a lot of
initiation (of LSPs or of control of LSPs).

In the jabber room during today's meeting Ravi noted that not a lot of the new
drafts (maybe none of them) talk about PCReq messages. This raises the question
in our minds as to whether stateless PCE is obsolete.

If (and only if) this mode of PCE usage has gone out of fashion, we *might*
consider cleaning up the protocol and architecture so that we don't need to make
protocol extensions to PCReq and PCRep messages when we make extensions to
PCInit messages. 

Thoughts?

Adrian

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 6 Apr 2016 19:06:42 -0300

Hi Adrian,

Even in the brave new world of Stateful PCE, PCReq and PCRep messages do
play a role in the passive stateful PCE mode. PCReq/PCRep also play a
crucial role in the inter-domain and inter-layer context in the new
proposal like stateful H-PCE.

At the same time mandating that every extension (say SFC) must also be
specified in a stateless manner when no customer deploy in such a way,
might be overkill.

Perhaps we need to look at it case by case!

Dhruv

On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel <[email-masked]> wrote:

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Apr 2016 05:47:37 +0100

I think you are probably right, Dhruv.
 
But referencing the ways in which customers deploy may be a little limiting. 
To say PCE is widely deployed (even after all these years) may be an exaggeration. 
Although we do have some clues about what is currently being pushed for deployment.
 
I think you have mainly grasped my point, however. We need to understand which extensions are definitely only needed in one mode or another, and which should be done in all modes (either because they are needed or because we don't know).
 
OTOH, I suppose TLVs are just TLVs. Once you specified the TLV it is not rocket science to include it in a message. In fact, it is probably one line of text to include it and only a short paragraph to describe additional processing in other modes once you have described how it is used in one mode.
 
Where does that leave us?
 
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?
 
Hi Adrian, 
 
Even in the brave new world of Stateful PCE, PCReq and PCRep messages do play a role in the passive stateful PCE mode. PCReq/PCRep also play a crucial role in the inter-domain and inter-layer context in the new proposal like stateful H-PCE. 
 
At the same time mandating that every extension (say SFC) must also be specified in a stateless manner when no customer deploy in such a way, might be overkill. 

Dhruv 

Thoughts?

Adrian

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Thu, 7 Apr 2016 21:22:13 +0000

Hi Adrian,
I raised in December 2014 the technical issue in draft-ietf-pce-stateful-pce that a PCC must be able to convey the original parameters (constraints) of the LSP path (Bandwidth, Metric, and LSPA objects) using a PCReq message to a PCE and subsequently delegate the LSP to PCE using the PCRpt message. Otherwise, when the LSP is delegated to PCE only the operational values of these parameters can be included in the PCRpt message. The latter means that the PCE will update the path without knowing exactly the original parameters.

For me, PCReq/PCRep are an integral part of operating an LSP in stateful mode.

Here is the link to the archived thread:
https://mailarchive.ietf.org/arch/search/?email_list=pce&so=-date&q=%22+Path+Computation+Request+in+Active+Stateful+PCE%22

Regards,
Mustapha.

From: Pce [mailto:[email-masked]] On Behalf Of EXT Adrian Farrel
Sent: Thursday, April 07, 2016 12:48 AM
To: 'Dhruv Dhody'
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Adrian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Hi Adrian,

Dhruv

On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Once upon a time, in a working group far, far away, PCE was basically stateless.
PCE acted in response to questions asked by PCCs.

Thoughts?

Adrian

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

---

From: <[email-masked]>
Date: Fri, 8 Apr 2016 18:29:24 +0200

Hello all,

IMHO the discussion must be split into is 2 different subjects:

1/ PCInit message could be seen as an independent message compared to 
other PCReq/PCRep, PCRpt and PCUp. Indeed, the PCE uses the PCInit 
message after a request that comes from another interface (e.g. a 
RestConf API) instead of PCReq that comes from the router itself through 
PCEP. In fact, when you configure a tunnel on the router, only the path 
computation part is requested to the PCE. Complements of tunnel 
configuration still remain in the router configuration. In case of 
PCInit, all information must be provided to the router. This could be 
for example the traffic steering. So, IMHO, it is normal that the PCInit 
message evolves through extensions different from the other PCEP 
messages, and in particular PCReq, as it is not triggered by the same 
entity, i.e. an external component instead the PCC router itself.

2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 will 
continue to be mandatory for stateful both passive and active mode even 
if it needs clarification in the draft. Let me explain. In passive 
stateful, a PCReq/PCRep sequence is drawn in Figure 7 of the pce 
stateful draft prior to the PCRpt message Now, the ambiguity comes from 
the active stateful mode and figure 8. Why is the PCReq/PCRep sequence 
not mentioned? Of course the tunnel is delegated in this mode, but, the 
delegation object has been added as an extension to the PCReq message in 
the same draft. So, IMHO, at the creation of the tunnel, the draft must 
precise that a PCReq/PCRep exchange with delegation=1 must be used prior 
to the PCRpt to be coherent with RFC 5440 and passive stateful mode.

The problem occured during our evaluation of commercial products on 
which we made interoperability tests. Indeed we observed different 
behaviours that are due to the draft ambiguity and conduct to some 
interoperability issues. The different cases are as follow:
  - a/ - PCReq/PCRep exchange to obtain a valid ERO before the PCRpt message
  - b/ - PCReq message to obtain a valid ERO but with no reaction from 
the PCE which is not conform to RFC5440
  - c/ - PCRpt with empty ERO (looks strange. What is the meaning of an 
Empty ERO ? a loose path ? no path ? )/PCupd to get a valid path which 
overlaps with standard RFC5440 PCReq/PCRep.
  - d/ - PCRpt with empty ERO and no PCUpd leaving the tunnel down.

Thus, PCC/PCE that used PCRpt/PCupd messages for active stateful mode 
are incompatible with PCC/PCE that used standard PCReq/PCrep exchange. 
We could not mix both behaviours (PCC that use PCReq message with PCE 
that react to PCRpt with empty ERO and reciprocally). The problem occurs 
only at the creation of the tunnel. Once created and up the tunnel is 
reported and updated by means of PCRpt / PCupd messages correctly in all 
cases.

To summarize: PCInit message could leave independently from other 
messages. PCReq is the basis of PCE and is mandatory in all use cases 
included the active stateful mode, but this need to be clarify in the 
pce stateful draft.

Regards

Olivier

Le 07/04/2016 23:22, Aissaoui, Mustapha (Nokia - CA) a écrit :
>
> Hi Adrian,
>
> I raised in December 2014 the technical issue in 
> draft-ietf-pce-stateful-pce that a PCC must be able to convey the 
> original parameters (constraints) of the LSP path (Bandwidth, Metric, 
> and LSPA objects) using a PCReq message to a PCE and subsequently 
> delegate the LSP to PCE using the PCRpt message. Otherwise, when the 
> LSP is delegated to PCE only the operational values of these 
> parameters can be included in the PCRpt message. The latter means that 
> the PCE will update the path without knowing exactly the original 
> parameters.
>
> *From:*Pce [mailto:[email-masked]] *On Behalf Of *EXT Adrian Farrel
> *Sent:* Thursday, April 07, 2016 12:48 AM
> *To:* 'Dhruv Dhody'
> *Cc:* [email-masked]
> *Subject:* Re: [Pce] Whither Stateless PCE?
>
> I think you have mainly grasped my point, however. We need to 
> understand which extensions are definitely only needed in one mode or 
> another, and which should be done in all modes (either because they 
> are needed or because we don't know).
>
> OTOH, I suppose TLVs are just TLVs. Once you specified the TLV it is 
> not rocket science to include it in a message. In fact, it is probably 
> one line of text to include it and only a short paragraph to describe 
> additional processing in other modes once you have described how it is 
> used in one mode.
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Dhruv Dhody
> *Sent:* 06 April 2016 23:07
> *To:* Farrel Adrian
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Pce] Whither Stateless PCE?
>
> Hi Adrian,
>
> Even in the brave new world of Stateful PCE, PCReq and PCRep messages 
> do play a role in the passive stateful PCE mode. PCReq/PCRep also play 
> a crucial role in the inter-domain and inter-layer context in the new 
> [email-masked] <mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Fri, 8 Apr 2016 17:04:14 +0000

Hi,

I fully agree that stateful PCE draft needs to be more clear about how a PCC retrieves a path when the delegation starts and the LSP has just been configured (does it need to compute locally first and then delegate, or do PCReq as Olivier proposed …).
I want to add my voice to what Olivier said about the inconsistent behaviors we see today in implementations leading to lack of interoperability.
The most important point is that we need to find a solution as soon as possible as some people wants to deploy it in multivendor environment and find workaround (btw vendor1 and vendor 2) to fix it interop is not the right way to go …
This is a question that the WG must work on and close asap.

Best Regards,

Stephane

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, April 08, 2016 18:29
To: Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Hello all,

1/ PCInit message could be seen as an independent message compared to other PCReq/PCRep, PCRpt and PCUp. Indeed, the PCE uses the PCInit message after a request that comes from another interface (e.g. a RestConf API) instead of PCReq that comes from the router itself through PCEP. In fact, when you configure a tunnel on the router, only the path computation part is requested to the PCE. Complements of tunnel configuration still remain in the router configuration. In case of PCInit, all information must be provided to the router. This could be for example the traffic steering. So, IMHO, it is normal that the PCInit message evolves through extensions different from the other PCEP messages, and in particular PCReq, as it is not triggered by the same entity, i.e. an external component instead the PCC router itself.

2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 will continue to be mandatory for stateful both passive and active mode even if it needs clarification in the draft. Let me explain. In passive stateful, a PCReq/PCRep sequence is drawn in Figure 7 of the pce stateful draft prior to the PCRpt message Now, the ambiguity comes from the active stateful mode and figure 8. Why is the PCReq/PCRep sequence not mentioned? Of course the tunnel is delegated in this mode, but, the delegation object has been added as an extension to the PCReq message in the same draft. So, IMHO, at the creation of the tunnel, the draft must precise that a PCReq/PCRep exchange with delegation=1 must be used prior to the PCRpt to be coherent with RFC 5440 and passive stateful mode.

The problem occured during our evaluation of commercial products on which we made interoperability tests. Indeed we observed different behaviours that are due to the draft ambiguity and conduct to some interoperability issues. The different cases are as follow:
 - a/ - PCReq/PCRep exchange to obtain a valid ERO before the PCRpt message
 - b/ - PCReq message to obtain a valid ERO but with no reaction from the PCE which is not conform to RFC5440
 - c/ - PCRpt with empty ERO (looks strange. What is the meaning of an Empty ERO ? a loose path ? no path ? )/PCupd to get a valid path which overlaps with standard RFC5440 PCReq/PCRep.
 - d/ - PCRpt with empty ERO and no PCUpd leaving the tunnel down.

Thus, PCC/PCE that used PCRpt/PCupd messages for active stateful mode are incompatible with PCC/PCE that used standard PCReq/PCrep exchange. We could not mix both behaviours (PCC that use PCReq message with PCE that react to PCRpt with empty ERO and reciprocally). The problem occurs only at the creation of the tunnel. Once created and up the tunnel is reported and updated by means of PCRpt / PCupd messages correctly in all cases.

To summarize: PCInit message could leave independently from other messages. PCReq is the basis of PCE and is mandatory in all use cases included the active stateful mode, but this need to be clarify in the pce stateful draft.

Regards

Olivier

Regards,
Mustapha.

Adrian

Hi Adrian,

Dhruv

Thoughts?

Adrian

Pce mailing list

Thank you.

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Fri, 8 Apr 2016 17:26:07 +0000

Hi Olivier,
Good summary indeed. I was worried about interop testing when I sent the original email to the list in December 2014.

I just wanted to comment on a couple of things:

1.     You are correct that the LSP object which has the D-delegate flag is allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I however think it is more appropriate to do the delegation in the subsequent PCRpt message once the LSP path is programmed by PCC following the PCRep message from PCE. This is because it is at that time that the LSP is being synchronized with the PCE LSP database.

2.     The PCRpt message does not carry the original constraints of the LSP (Bandwidth, Metric, and LSPA objects). It can carry the operational values of the Bandwidth and Metric objects used by the last computed path in the router. So, even if you have a PCE which reacted to the PCRpt message and computed a new path, it will not get the appropriate constraints included. That is why the PCReq/PCRep sequence before delegating the LSP is needed.

Regards,
Mustapha.

From: EXT [email-masked] [mailto:[email-masked]]
Sent: Friday, April 08, 2016 12:29 PM
To: Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Hello all,

Regards

Olivier

Regards,
Mustapha.

Adrian

Hi Adrian,

Dhruv

Thoughts?

Adrian

Pce mailing list

Thank you.

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 14 Apr 2016 07:39:03 +0000

Hi Stephane,

Could you clarify what is interoperability issue in multivendor environment (multivendor in one administrative domain?)?

Do you mean there is interoperability issue when vendor 1 supports stateless PCE and vendor 2 supports stateful PCE?

Thanks

Fatai

发件人: Pce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2016年4月9日 1:04
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
抄送: [email-masked]
主题: Re: [Pce] Whither Stateless PCE?

Hi,

Best Regards,

Stephane

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, April 08, 2016 18:29
To: Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Hello all,

Regards

Olivier

Regards,
Mustapha.

Adrian

Hi Adrian,

Dhruv

Thoughts?

Adrian

Pce mailing list

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 15 Apr 2016 08:35:39 +0000

Hi,

It’s multivendor in a single domain between two stateful active implementations.
In a delegation scenario, we have some issue with triggers of Path computation and update sent on PCE side.
The draft is not really clear on when this path computation and update must be triggered, especially when PCC does not use PCReq but only PCRpt.

From an operational perspective, we expect PCE to takeover the LSP computation when LSP is delegated and it’s not always the case.

Example :
Case#1 : PCC has no path, it reports empty ERO in PCRpt (case Olivier was mentioning), PCE vendor does not compute path and does not send update

ð  Using PCReq could make sense here as Mustapha proposed or clearly mentioning that PCRpt with empty ERO needs to trigger path computation and sending PCUpd.

Case#2 : PCC has a path, it reports ERO, PCE has different constraints configured, we expect PCE to update the path

Case#3 : PCC has a path, it reports ERO, PCE has a different optimization algorithm leading to a different ERO with the same constraint, we expect PCE to update the path

Case#2 and Case#3 requires the PCE to know the existing constraint configured on PCC for the LSP , by using only PCRpt we cannot have such constraint information, we need a PCReq also to describe the configuration (PCRpt only describes operation state => Mustapha’s point again).

Best Regards,

Stephane

From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, April 14, 2016 09:39
To: LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
Cc: [email-masked]
Subject: 答复: [Pce] Whither Stateless PCE?

Hi Stephane,

Thanks

Fatai

发件人: Pce [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2016年4月9日 1:04
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Pce] Whither Stateless PCE?

Hi,

Best Regards,

Stephane

Hello all,

Regards

Olivier

Regards,
Mustapha.

Adrian

Hi Adrian,

Dhruv

Thoughts?

Adrian

Pce mailing list

Thank you.

Thank you.

---

From: Olivier Dugeon <[email-masked]>
Date: Mon, 18 Apr 2016 14:58:01 +0200

Dear Mustapha,

You catch a good point regarding the original constraints that are not 
carry by the PCRpt message. Thus, if we used a standard PCReq message 
without the D-delegate flag set, there is a risk that the PCE considers 
this request as a stateless one and don't keep track of the original 
request, and consequently, original constraints.

So, is it preferable to set de D-delegate flag in the PCReq message to 
tell the PCE to keep in memory the original constraints for further 
usage, or, is the 'STATEFUL-PCE-CAPABILITY' TLV in Open message is 
sufficient for the PCE to know that it must keep track of any requests? 
I prefer the first option as it allows a per request configuration while 
the second enables the memorization globally for all requests.

Regards,

Olivier

Le 08/04/2016 19:26, Aissaoui, Mustapha (Nokia - CA) a écrit :
>
> Hi Olivier,
>
> Good summary indeed. I was worried about interop testing when I sent 
> the original email to the list in December 2014.
>
> 1.You are correct that the LSP object which has the D-delegate flag is 
> allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I 
> however think it is more appropriate to do the delegation in the 
> subsequent PCRpt message once the LSP path is programmed by PCC 
> following the PCRep message from PCE. This is because it is at that 
> time that the LSP is being synchronized with the PCE LSP database.
>
> 2.The PCRpt message does not carry the original constraints of the LSP 
> (Bandwidth, Metric, and LSPA objects). It can carry the operational 
> values of the Bandwidth and Metric objects used by the last computed 
> path in the router. So, even if you have a PCE which reacted to the 
> PCRpt message and computed a new path, it will not get the appropriate 
> constraints included. That is why the PCReq/PCRep sequence before 
> delegating the LSP is needed.
>
> Regards,
>
> Mustapha.
>
> *From:*EXT [email-masked] [mailto:[email-masked]]
> *Sent:* Friday, April 08, 2016 12:29 PM
> *To:* Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
> *Cc:* [email-masked]
> RestConf API) instead of PCReq that comes from the router itself 
> through PCEP. In fact, when you configure a tunnel on the router, only 
> the path computation part is requested to the PCE. Complements of 
> tunnel configuration still remain in the router configuration. In case 
> of PCInit, all information must be provided to the router. This could 
> be for example the traffic steering. So, IMHO, it is normal that the 
> PCInit message evolves through extensions different from the other 
> PCEP messages, and in particular PCReq, as it is not triggered by the 
> same entity, i.e. an external component instead the PCC router itself.
>
> 2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 
> will continue to be mandatory for stateful both passive and active 
> mode even if it needs clarification in the draft. Let me explain. In 
> passive stateful, a PCReq/PCRep sequence is drawn in Figure 7 of the 
> pce stateful draft prior to the PCRpt message Now, the ambiguity comes 
> from the active stateful mode and figure 8. Why is the PCReq/PCRep 
> sequence not mentioned? Of course the tunnel is delegated in this 
> mode, but, the delegation object has been added as an extension to the 
> PCReq message in the same draft. So, IMHO, at the creation of the 
> tunnel, the draft must precise that a PCReq/PCRep exchange with 
> delegation=1 must be used prior to the PCRpt to be coherent with RFC 
> 5440 and passive stateful mode.
>
> that react to PCRpt with empty ERO and reciprocally). The problem 
> occurs only at the creation of the tunnel. Once created and up the 
> tunnel is reported and updated by means of PCRpt / PCupd messages 
> correctly in all cases.
>
>     original parameters (constraints) of the LSP path (Bandwidth,
>     Metric, and LSPA objects) using a PCReq message to a PCE and
>     subsequently delegate the LSP to PCE using the PCRpt message.
>     Otherwise, when the LSP is delegated to PCE only the operational
>     values of these parameters can be included in the PCRpt message.
>     The latter means that the PCE will update the path without knowing
>     exactly the original parameters.
>
>     understand which extensions are definitely only needed in one mode
>     or another, and which should be done in all modes (either because
>     they are needed or because we don't know).
>
>     OTOH, I suppose TLVs are just TLVs. Once you specified the TLV it
>     is not rocket science to include it in a message. In fact, it is
>     probably one line of text to include it and only a short paragraph
>     to describe additional processing in other modes once you have
>     described how it is used in one mode.
>
>     Even in the brave new world of Stateful PCE, PCReq and PCRep
>     messages do play a role in the passive stateful PCE mode.
>     PCReq/PCRep also play a crucial role in the inter-domain and
>     inter-layer context in the new proposal like stateful H-PCE.
>
>     At the same time mandating that every extension (say SFC) must
>     also be specified in a stateless manner when no customer deploy in
>     such a way, might be overkill.
>

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Mon, 18 Apr 2016 20:00:27 +0000

Hi Olivier,
It is one option for sure. In general, implementations of stateful PCE should be able of caching the constraints received in the PCReq message for some period of time to give a chance for a potential follow-up PCRpt message. Even if you set the D-flag in the PCReq message, there is no guarantee that a PCRpt will follow and as such a PCE implementation will have to flush that information from its cache at some point in time.

In addition, I think it is worth considering sending the constraints in a PCRpt message in duplicate Metric/LSPA objects with the P-flag set. This is in addition to the same objects containing the operational values. This can be useful in the case where the initial path was computed by the router and it is active and the user is delegating it. The PCE at that point in time will not compute a path immediately but will save the original constraints in the PCRpt message for the next time it needs to update the path.

Regards,
Mustapha.

From: EXT Olivier Dugeon [mailto:[email-masked]]
Sent: Monday, April 18, 2016 8:58 AM
To: Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Dear Mustapha,

You catch a good point regarding the original constraints that are not carry by the PCRpt message. Thus, if we used a standard PCReq message without the D-delegate flag set, there is a risk that the PCE considers this request as a stateless one and don't keep track of the original request, and consequently, original constraints.

So, is it preferable to set de D-delegate flag in the PCReq message to tell the PCE to keep in memory the original constraints for further usage, or, is the 'STATEFUL-PCE-CAPABILITY' TLV in Open message is sufficient for the PCE to know that it must keep track of any requests? I prefer the first option as it allows a per request configuration while the second enables the memorization globally for all requests.

Regards,

Olivier

Regards,
Mustapha.

From: EXT [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Hello all,

Regards

Olivier

Regards,
Mustapha.

Adrian

Hi Adrian,

Dhruv

Thoughts?

Adrian

Pce mailing list

Thank you.