Hi, I think the text from Stephane solve well the no-path case, if a PCE would like to force a tear-down of the LSP, the admin-status bit seems appropriate. In the case you mention, a PCE may sets a loose hop towards egress, but its up to the PCC to expand or not the ERO.
BR Cyril On 11 October 2016 at 19:16, Sudhir Cheruathur <scheruat...@juniper.net> wrote: > Stephane/Dhruv/Xian, > > > > I am concerned with the need to revoke the delegation when there is no > path. Today, we can change three attributes of a delegated LSP - Path > (ERO), Bandwidth and Metric. > > > > Are we suggesting that when BW and/or Metric is changed it must always be > accompanied with a path? How would you handle cases where only BW and/or > Metric is changed for a delegated LSPs from controller that has no > computation engine or would prefer the PCC to do the computation? Yes, > keep the existing path could be an option but since it is not always > guaranteed we will need appropriate error handling. > > > > Thanks > > Regds > Sudhir C > > > > > > *From: *Pce <pce-boun...@ietf.org> on behalf of " > stephane.litkow...@orange.com" <stephane.litkow...@orange.com> > *Date: *Tuesday, October 11, 2016 at 4:14 AM > *To: *Dhruv Dhody <dhruv.i...@gmail.com>, "Zhangxian (Xian)" < > zhang.x...@huawei.com> > *Cc: *"pce@ietf.org" <pce@ietf.org> > *Subject: *Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi, > > > > I would rather prefer to have a more generic statement for the PCC local > policy : > > > > 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, keep existing LSP state … > > > > Brgds, > > > > > > *From:* dhruvdh...@gmail.com [mailto:dhruvdh...@gmail.com] *On Behalf Of > *Dhruv > Dhody > *Sent:* Monday, October 10, 2016 06:45 > *To:* Zhangxian (Xian) > *Cc:* LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui, > Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; pce@ietf.org > *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Xian, > > > > I would avoid saying set of *paths* for delegated LSP, instead I would > modify your text slightly as - > > > > 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. If the PCC's local policy allows it, > it SHOULD signal the tear down of the LSP. Alternatively, PCC MAY revoke > delegation and use a locally computed path instead. > > > > Regards, > > Dhruv > > > > On Mon, Oct 10, 2016 at 8:15 AM, Zhangxian (Xian) <zhang.x...@huawei.com> > wrote: > > Hi, Stephane, Olivier, All, > > > > I support the option 1 Dhruv proposed (see below), which has least > impact on existing implementations. > > > > >(1) Allow Empty ERO to mean no path. > > >Let it be valid in all messages to mean that no intended path exists for > this LSP. > > >As per -16, > > >- empty ERO is added in the end of synchronization marker (PCRpt). > > >- The ERO may be empty if the PCE does not have a path for a delegated > LSP. > > > > >We can add text in section 6.2 to say something like – > > > > >The ERO may be empty if the PCE does not have an intended path for the > delegated LSP. > > >If the local policy allows it, the PCC SHOULD signal the tear down of > the LSP. At > > >this time, PCC MAY also revoke delegation and use a locally computed > path instead. > > > > >To me this is more logical and in spirit with the rest of the document, > also would require least amount of changes in existing implementations. > > > > If we have rough consensus, we should start to work on the changes needed > in draft-ietf-pce-stateful-pce-16 to clarify, I would propose to add the > following sentences in somewhere in Section 6.2 (edited on top of what > Dhruv has suggested above): > > > > The ERO may be empty if the PCE cannot find one or a set of valid paths > for a delegated LSP. One typical situation resulting in this empty ERO > carried in the PCUpd message is that PCE can no longer find two strictly > SRLG-disjoint paths for a delegation LSP after link failure. If its local > policy allows it, the PCC SHOULD signal the tear down of the LSP. > Alternatively, PCC MAY revoke delegation and use a locally computed path > instead. > > > > Does the text look good to address the ambiguity issue you raised? > > > > Regards, > > Xian > > > > *发件人**:* Pce [mailto:pce-boun...@ietf.org] *代表 * > stephane.litkow...@orange.com > *发送时间:* 2016年10月6日 15:19 > *收件人:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC > Julien IMT/OLN; pce@ietf.org > *主题:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > Hi Olivier, > > > > I think we almost have a consensus on using the current ERO object with > the semantic “I have no intended path”, so adding a new sibling object is > not necessary. > > It would then be up to the PCC to have a local policy to control the > associated behavior => tear down, revoking delegation, keep existing path > or whatever… > > > > Optionally, we still need to agree if we consider NO-PATH object as a > complement and optional object. > > > > Brgds, > > > > > > *From:* Pce [mailto:pce-boun...@ietf.org <pce-boun...@ietf.org>] *On > Behalf Of *Olivier Dugeon > *Sent:* Wednesday, October 05, 2016 18:11 > *To:* Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; pce@ietf.org > *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE > advising PCC about no path > > > > 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:pce-boun...@ietf.org <pce-boun...@ietf.org>] *On > Behalf Of *Julien Meuric > *Sent:* Wednesday, October 05, 2016 8:04 AM > *To:* pce@ietf.org > *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:dhruv.dh...@huawei.com > <dhruv.dh...@huawei.com>] > *Sent:* Wednesday, October 05, 2016 06:09 > *To:* Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; > Aissaoui, Mustapha (Nokia - CA); pce@ietf.org; > draft-ietf-pce-stateful-...@tools.ietf.org > *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:pce-boun...@ietf.org <pce-boun...@ietf.org>] *On > Behalf Of *Sudhir Cheruathur > *Sent:* 04 October 2016 23:16 > *To:* stephane.litkow...@orange.com; Harish Magganmane < > hmagganm...@juniper.net>; Aissaoui, Mustapha (Nokia - CA) < > mustapha.aissa...@nokia.com>; pce@ietf.org; draft-ietf-pce-stateful-pce@ > tools.ietf.org > *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 <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-pce@ > 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 > <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> on behalf of " > stephane.litkow...@orange.com" <stephane.litkow...@orange.com> > *Date: *Friday, September 30, 2016 at 8:33 AM > *To: *"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 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.aissaoui@ > nokia.com <mustapha.aissa...@nokia.com>] > *Sent:* Friday, September 30, 2016 17:08 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org; > 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 <pce-boun...@ietf.org>] *On > Behalf Of *stephane.litkow...@orange.com > *Sent:* Friday, September 30, 2016 5:46 AM > *To:* pce@ietf.org; 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, > > > > > > [image: nge 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 > > > > _________________________________________________________________________________________________________________________ > > > > 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 > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > > _________________________________________________________________________________________________________________________ > > > > 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 > > > > _________________________________________________________________________________________________________________________ > > > > 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 > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce