Subject: [Pce] draft-ietf-pce-stateful-pce : Switching from Passive Stateful to Active Stateful

From: <[email-masked]>
Date: Fri, 14 Oct 2016 07:37:52 +0000

Hi,

One question about the new procedure with introduced couple of weeks ago about delegation.
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.

Brgds,

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

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[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: Dhruv Dhody <[email-masked]>
Date: Fri, 14 Oct 2016 08:17:35 +0000

Fully agree with Stephane on this!

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14 October 2016 13:08
To: [email-masked]
Subject: [Pce] draft-ietf-pce-stateful-pce : Switching from Passive Stateful to Active Stateful

Hi,

Brgds,

Stephane Litkowski
Network Architect

Thank you.

---

From: Olivier Dugeon <[email-masked]>
Date: Fri, 14 Oct 2016 10:52:20 +0200

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

Regards

Olivier

Le 14/10/2016 à 09:37, [email-masked] a écrit :
> “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.
>
> Orange logo <http://www.orange.com/>
>
>  
>
> *Stephane Litkowski *
> Network Architect
> [email-masked] <mailto:[email-masked]>
>
>  
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Fri, 14 Oct 2016 19:32:55 +0000

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 5.8.1<https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16#section-5.8.1> 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 6.1<https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16#section-6.1>.  An implementation MAY allow policies on
   the PCC to determine the configuration parameters to be sent to the
   PCE.

“

Mustapha.

From: Pce [mailto:[email-masked]] On Behalf Of Olivier Dugeon
Sent: Friday, October 14, 2016 4:52 AM
To: [email-masked]; [email-masked]
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : Switching from Passive Stateful to Active Stateful

Hello Stéphane,

Regards

Olivier

Le 14/10/2016 à 09:37, [email-masked]<mailto:[email-masked]> a écrit :
Hi,

Brgds,

Stephane Litkowski
Network Architect

Thank you.

Pce mailing list

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