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, [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> 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.
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
