Stephane/Dhruv/Mustapha,

>>I’m trying to understand what you really want to achieve here. Or do you want 
>>to have PCE updating LSP parameters/constraints but let the PCC compute path ?

We want to allow changing of other attributes of an LSP (such as BW/metric), 
but leave the path computation to the PCC. With this a PCC now has a choice to 
do a local CSPF or use IGP hop-by-hop. This choice can be enforced on the PCC 
with an empty ERO and local policy. When we want to drive this same behavior 
from the PCE then we could you use a NO-PATH object.

We could define flags in the NO-PATH object to tell the PCC what to do when a 
path is not available. The Nature of Issue is set to 0 (No path) and flags can 
be defined to specify the following

a)       Bring down the LSP

b)       Use local CSPF

c)       Use IGP based hop-by-hop.

Thanks
Redgs
Sudhir C



From: Pce <pce-boun...@ietf.org> on behalf of "stephane.litkow...@orange.com" 
<stephane.litkow...@orange.com>
Date: Monday, October 3, 2016 at 1:27 AM
To: Harish Magganmane <hmagganm...@juniper.net>, "Aissaoui, Mustapha (Nokia - 
CA)" <mustapha.aissa...@nokia.com>, "pce@ietf.org" <pce@ietf.org>, 
"draft-ietf-pce-stateful-...@tools.ietf.org" 
<draft-ietf-pce-stateful-...@tools.ietf.org>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Hi Harish,

Thanks for your feedback.
I do not really understand why you map the empty ERO to a decision to possibly 
fallback computation to local.
As you mentioned, it could be a local PCC policy decision and this local policy 
could be to tear down the LSP instead of deferring ERO selection to the local 
router as you proposed.

The important point is the semantic of this empty ERO, not really the action 
taken. I understand in your email  that you still interpret it from a semantic 
point of view has an indication of no path, so you then can decide to defer ERO 
selection to the router. Because in the case, you want to have the PCE giving 
back path computation role to PCC, the PCE must use the delegate flag for this 
purpose and can revoke the delegation at anytime. I’m trying to understand what 
you really want to achieve here. Or do you want to have PCE updating LSP 
parameters/constraints but let the PCC compute path ?

Best Regards,

Stephane



From: Harish Magganmane [mailto:hmagganm...@juniper.net]
Sent: Saturday, October 01, 2016 00:53
To: LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA); 
pce@ietf.org; draft-ietf-pce-stateful-...@tools.ietf.org
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Hi Stephane,

We are not in favor of using empty ERO as way to signal the tearing of an LSP. 
IMO empty ERO object should be interpreted to mean deferring the ERO selection 
to the router, perhaps through local policy on the PCC. For example PCC could 
choose between a local CSPF or a IGP based hop-by-hop.

In cases where we want PCE to explicitly control the behavior of the PCC when a 
path is not available, NO-PATH object can be used to dictate the behavior. One 
such behavior could be that of tearing down the LSP.

Thanks,
Harish

From: Pce <pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>> on behalf of 
"stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>" 
<stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>>
Date: Friday, September 30, 2016 at 8:33 AM
To: "Aissaoui, Mustapha (Nokia - CA)" 
<mustapha.aissa...@nokia.com<mailto:mustapha.aissa...@nokia.com>>, 
"pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>>, 
"draft-ietf-pce-stateful-...@tools.ietf.org<mailto:draft-ietf-pce-stateful-...@tools.ietf.org>"
 
<draft-ietf-pce-stateful-...@tools.ietf.org<mailto:draft-ietf-pce-stateful-...@tools.ietf.org>>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Hi Mustapha,

Your proposal works from my point of view, but it looks that it causes some 
trouble to another vendor so I would like these people (and others as well) to 
express their concerns regarding usage of empty ERO.

Thanks for pointing again your last proposal.

Best Regards,

Stephane


From: Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissa...@nokia.com]
Sent: Friday, September 30, 2016 17:08
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-stateful-...@tools.ietf.org<mailto:draft-ietf-pce-stateful-...@tools.ietf.org>
Subject: RE: Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC 
about no path

Hi Stephane,
In the last email related to this issue, I made a proposal to Olivier and 
Robert commented on it. Would that be sufficient to address this interop issue?
https://mailarchive.ietf.org/arch/msg/pce/A1ADiw6Uvjn1ETjErqzgjdjXnsE

Mustapha.

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: Friday, September 30, 2016 5:46 AM
To: pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-stateful-...@tools.ietf.org<mailto:draft-ietf-pce-stateful-...@tools.ietf.org>
Subject: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC 
about no path

Hi WG, and draft authors,

We still have an urgent interoperability issue to solve with 
draft-ietf-pce-stateful-pce. We currently have no clear semantic for the PCE to 
advise the PCC that there is no more path available. This point was already 
raised through the list but as we need an URGENT resolution of this issue 
because of implementation timelines, I would like to reactivate the thread.

The situation of no path at PCE side can happen in many situations, and a 
particular situation will require PCC to tear down an existing path : let’s 
think about two strictly SRLG disjoint LSPs with a working path . Now the 
transmission topology is changing (rerouting at WDM layer) leading SRLG 
disjointness not being fitted anymore and PCE cannot find anymore disjoint 
path, it must advise one PCC to tear down the path because it is no more 
disjoint (strict disjointness required).
We do not have any clear semantic today and some implementations are using 
empty ERO for this purpose in PCUpdate but the PCC does not recognize it as a 
valid no path significance.

This subject is critical and I would like that we can achieve a consensus asap 
on the target solution so then vendors can align implementations.
This thread is focusing on the PCE -> PCC way, but having a semantic of 
reporting a no path is also necessary in PCC->PCE way through PCRpt, at least 
to ACK a PCupdate.

One of the previous discussion on the list talked about the possibility to use 
NO-PATH object which already has this semantic for PCReq/PCRep but as already 
mentioned we need to assess impact on existing implementations, so vendor 
feedback (with customer implementations) is highly required. So this is my 
starting proposal to initiate the discussion.


Best Regards,


[ange 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>
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>


_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to