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.
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
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; firstname.lastname@example.org
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : Switching from Passive
Stateful to Active Stateful
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
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
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.
Pce mailing list
Pce mailing list