Hi Olivier,
Since the actions a PCC may take following a PCRep with the NO_PATH object are 
similar (but not exactly the same) as when it receives a PCUpd with an empty 
ERO, perhaps we can reuse the below text proposed by Stephane by adding the 
option of PCC to request a path from another PCE and adjust it for the case of 
a PCRep message. We then add each text to the corresponding section: 6.2 for 
the PCUpd and 5.8.2 for the PCRep.

Here is a proposal. The change to Section 5.8.2 means that we are relaxing the 
original text which required that the PCReq message to be used prior to 
delegation in the case a NO_PATH object is received in the reply to the first 
PCReq. Let me know what you think.

Section 6.2 (updated original text from Stephane):
The ERO may be empty if the PCE cannot find a valid path for a delegated LSP. 
One typical situation resulting in this empty ERO carried in the PCUpd message 
is that a PCE can no longer find a strict SRLG-disjoint path for a delegated 
LSP after a link failure.  The PCC SHOULD implement a local policy to decide 
the appropriate action to be taken: tear down LSP, revoke delegation and use a 
locally computed path, revoke delegation and request path from another PCE, 
keep existing LSP state.

Section 5.8.2:
This section deals with the scenario of an LSP transitioning from a
   passive stateful to an active stateful mode of operation.  When the
   LSP has no working path, prior to delegating the LSP, the PCC MUST
   first use the procedure defined in Section 
to request the
   initial path from the PCE.  This is required because the action of
   delegating the LSP to a PCE using a PCRpt message is not an explicit
   request to the PCE to compute a path for the LSP.  The only explicit
   way for a PCC to request a path from PCE is to send a PCReq message.
   The PCRpt message MUST NOT be used by the PCC to attempt to request a
   path from the PCE.

If PCE replied with a PCRep message containing the NO_PATH object, PCC SHOULD 
use a local policy to decide the appropriate action to be taken: retry the 
PCReq message to the same PCE, delegate the LSP in DOWN state to the same PCE 
for a subsequent path update, make a path request to another PCE, use a locally 
computed path.

When the LSP is delegated after its setup, it may be useful for the
   PCC to communicate to the PCE the locally configured intended
   configuration parameters, so that the PCE may reuse them in its
   computations.  Such parameters MAY be acquired through an out of band
   channel, or MAY be communicated in the PCRpt message delegating the
   LSPs, by including them as part of the intented-attribute-list as
   explained in Section 
An implementation MAY allow policies on
   the PCC to determine the configuration parameters to be sent to the



From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Olivier Dugeon
Sent: Friday, October 14, 2016 4:52 AM
To: stephane.litkow...@orange.com; pce@ietf.org
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : Switching from Passive 
Stateful to Active Stateful

Hello Stéphane,

I agree with you. But, we should also let the PCC able to request a path to 
another PCE (if configured) or perform a local CSPF computation before 
delegating the LSP. Again, it is a policy matter on the PCC to decide what to 
do when a PCE reply with a NO-PATH like when a PCE send an empty ERO in a 



Le 14/10/2016 à 09:37, 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> a écrit :

One question about the new procedure with introduced couple of weeks ago about 
We are stating that the PCReq/PCRep is required  before delegation which is 
fine, but what happens if PCE is answering NO-PATH in the PCReq, does it 
prevent delegation ?
There is an ambiguous sentence :
“When the LSP is delegated after its setup,…”

Which could make thing that a valid path and a signaled LSP is required before 
delegation can occur, but I’m not sure that this is really necessary.
If PCE has no path at the moment of the request, PCC can still delegate the 
path and PCE will provide a valid path through PCUpdate as soon as the topology 
allows to find a suitable path. This would be faster than retrying PCReq in a 
polling fashion.


[Orange                  logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange Expert Future Networks
phone: +33 2 23 28 49 83 
mobile: +33 6 37 86 97 52 


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.


Pce mailing list



Pce mailing list

Reply via email to