Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[Olivier Dugeon <[e-mail]>]

Hello all,

If I try to summarize, in one hand we have some implementations that use an empty ERO which lead in interoperability issues due to ambiguous interpretation, and in the other hand a clear non-ambiguous object i.e. NO-PATH which break implementation or at least impose strong modifications in existing code.

So, in order to advance on the subject, I would propose to add new code points to explicitly mention that the ERO is empty, and why is empty:  This solves the ambiguity while imposing smooth modification in today implementations as they just have to check a particular ERO code point (in replacement to check that the ERO is empty) instead processing a new object (i.e. NO-PATH).

There is two options for this new ERO code points:

a) At the ERO registry level. ERO is Class Type 20 and Class Num 1. The idea is to add a new Class Num = 2 i.e. Empty ERO with possibility to add different values to specify why it is empty e.g. 1 = NO-PATH, 2 = LOOSE-PATH ...

b) At the sub-object level. Within ERO Class Type 20 and Class Num 1, add new code points. eg. 38 = Empty-ERO NO-PATH, 39 = Empty-ERO Loose-Path ...

Option a) require to request a new registry and code points while option b) just require new code points in existing registry to IANA. Option a) allows to add a dedicated registry for Empty ERO with possibility to precisely describe why it is empty, while option b) mix the notion of Empty ERO and the reason why it is empty. Looking to implementation, option a) impose to look at Class Num when processing the ERO while option b) just need to look at sub-object.

Draft stateful could introduce this new ERO code points (whatever option a or b) and other drafts (initiated, synchronisation ...) could add there own needs regarding this empty ERO.

Comments are welcome.

Regards

Olivier

Le 05/10/2016 à 16:01, Aissaoui, Mustapha (Nokia - CA) a écrit :
>
> I am of the same opinion too. Let us keep empty ERO in both the PCUpd and PCRpt messages to mean there is no valid path for the LSP. A PCC implementation receiving a PCUpd with an empty ERO for a non-zero PLSP-ID can decide if the outcome of this means to tear down the path or keep the existing working path. If the PCC wants to use the local CSPF or an IGP driven path, then it must first revoke the delegation as per existing procedures.
>
>  
>
> Regards,
>
> Mustapha.
>
>  
>
> *From:*Pce [mailto:[e-mail]] *On Behalf Of *Julien Meuric
> *Sent:* Wednesday, October 05, 2016 8:04 AM
> *To:* [e-mail]
> *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>  
>
> Hi all,
>
> Chair hat on, I concur with the proposed plan: we need to stick to the current scope of the base stateful I-D and fix pending issues in there, new proposals like "partial delegation" do require a new document.
>
> Thank you Dhruv and Stéphane for being proactive on that,
>
> Julien
>
>  
>
> Oct. 05, 2016 - :
>
>     Hi Dhruv, Sudhir
>
>      
>
>     I agree that what is achieved here is a partial delegation which is not inline with delegation in stateful pce draft which gives full control to PCE.
>
>      
>
>     The use case described is interesting but I’m afraid that empty ERO was used for this purpose while there was no discussion at WG level to achieve consensus for this partial delegation solution. I would prefer that Juniper used a vendor specific flag for this behavior rather than using existing objects.
>
>     I would prefer to close the base stateful PCE draft before adding new features …
>
>      
>
>     Partial delegation may be complex to handle as some people may want ERO to be controlled by PCC while constraints by PCE and some other may want the opposite (constraints by PCC and ERO by PCE) so this requires more discussion.
>
>      
>
>     Brgds,
>
>      
>
>     Stephane
>
>      
>
>     *From:*Dhruv Dhody [mailto:[e-mail]]
>     *Sent:* Wednesday, October 05, 2016 06:09
>     *To:* Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; Aissaoui, Mustapha (Nokia - CA); [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *Cc:* 'Dhruv Dhody'
>     *Subject:* RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     Hi Sudhir/Harish,
>
>      
>
>     Thanks for explaining your motivation but it is not as per the definition of “delegation”.
>
>     What you are suggesting is a new feature lets call it “partial delegation”. I hope we can discuss the merit and the procedures of this in a small separate document away from this base document. IMHO this document should explain why partial delegation is needed and especially why PCE would still like to control how the path is computed at PCC?
>
>      
>
>     How do you/WG feel about taking this approach?
>
>      
>
>     Regards,
>
>     Dhruv
>
>      
>
>      
>
>     *From:* Pce [mailto:[e-mail]] *On Behalf Of *Sudhir Cheruathur
>     *Sent:* 04 October 2016 23:16
>     *To:* [e-mail] <mailto:[e-mail]>; Harish Magganmane <[e-mail] <mailto:[e-mail]>>; Aissaoui, Mustapha (Nokia - CA) <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     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 <[e-mail] <mailto:[e-mail]>> on behalf of "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>     *Date: *Monday, October 3, 2016 at 1:27 AM
>     *To: *Harish Magganmane <[e-mail] <mailto:[e-mail]>>, "Aissaoui, Mustapha (Nokia - CA)" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>     *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:[e-mail]]
>     *Sent:* Saturday, October 01, 2016 00:53
>     *To:* LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA); [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *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 <[e-mail] <mailto:[e-mail]>> on behalf of "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>     *Date: *Friday, September 30, 2016 at 8:33 AM
>     *To: *"Aissaoui, Mustapha (Nokia - CA)" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>     *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:[e-mail]]
>     *Sent:* Friday, September 30, 2016 17:08
>     *To:* LITKOWSKI Stephane OBS/OINIS; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *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:[e-mail]] *On Behalf Of *[e-mail] <mailto:[e-mail]>
>     *Sent:* Friday, September 30, 2016 5:46 AM
>     *To:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *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: [phone] <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: [phone] <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>
>     [e-mail] <mailto:[e-mail]>
>
>      
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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.
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/pce
>
>  
>
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce