Hi Jon, Stephane and I discussed this earlier in the week. And this could be an interesting direction to explore! Will come back to the WG with a proposal soon.
Thanks! Dhruv On Fri, 17 Nov 2017 at 9:03 AM, Jonathan Hardwick < jonathan.hardw...@metaswitch.com> wrote: > Hi Stephane > > > > I’m not necessarily saying that this is the way to go, but I would like to > point out the P flag and the I flag in the PCEP common object header. If a > constraint can be relaxed, the PCC sends the relevant object(s) with P=0. > If the PCE decides to relax a constraint, it includes the relevant > object(s) in the PCRep with I=1. Does that change your opinion of whether > a suitable mechanism for this already exists? > > > > Cheers > > Jon > > > > > > *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of * > stephane.litkow...@orange.com > *Sent:* 14 November 2017 01:18 > *To:* DUGEON Olivier IMT/OLN <olivier.dug...@orange.com>; Daniele > Ceccarelli <daniele.ceccare...@ericsson.com>; pce@ietf.org > > > *Subject:* Re: [Pce] draft-ietf-pce-association-diversity: relaxing > constraint > > > > Hi Olivier, > > > > I do not agree with what you mentioned. > > The metric object is defined (but not limited to) to set a constraint on > the metric: what I should optimize for (IGP metric, TE metric, both…) and > is there a boundary that I should not exceed. > > Nothing says that the constraint can be relaxed by the PCE. If a PCE > receives a computation request or needs to compute a path for an LSP having > for instance a metric object with type=TE and bound=100. If it cannot found > a path, it will return NO-PATH without relaxing the constraint. Relaxing > the constraint means that the PCC allows the PCE to compute a path without > using the requested constraint if the PCE cannot find a path that fills > this constraint. > > So in case of the METRIC object and the boundary case, if the PCC allows > the PCE to relax the constraint, if it does not find a path fitting the > boundary, it will provide a path exceeding this boundary instead of > returning NO-PATH. > > > > Now the METRIC object does not have anything to do with the disjointness. > Except that we can combine both if needed ! > > > > For the disjointness, we have two cases when the PCC allowed the PCE to > relax the constraint: > > - The PCE has successfully computed a disjoint path but with a lower > disjointness type (link instead of node for instance) => this could be seen > as a partially relaxed constraint and I agree that the state could be sent > by adding the association group and filling the “computed state” of the > disjointness in the DISJOINTNESS-INFORMATION TLV (METRIC object has nothing > to do here). > > > - The PCE cannot compute a disjoint path at all and completely relaxed > the constraint. > > > > So we do not have any way yet (AFAIK) to tell the PCE that a particular > constraint can be relaxed (another example is the bandwidth constraint => I > do not think that it is a good example but why not…). > > Then the PCE needs to tell the PCC that it has relaxed a constraint => > this can be deduced from a “computed state” provided by the PCE for each > constraint, but a more clear information may be better (possibly in > addition to the “computed state”). > > > > Brgds, > > > > *From:* Olivier Dugeon [mailto:olivier.dug...@orange.com > <olivier.dug...@orange.com>] > *Sent:* Tuesday, November 14, 2017 00:32 > *To:* LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; pce@ietf.org > *Subject:* Re: [Pce] draft-ietf-pce-association-diversity: relaxing > constraint > > > > Hello Stephane, all > > In fact, these mechanism is already available in RFC 5440. > > First, Metric Object has been defined with a B flag to indicate if this > metric (i.e. constraint) must be bound or not. See > https://tools.ietf.org/html/rfc5440#section-7.8. Terminology is not > exactly the same, but, the goal is similar. It allows a PCC to indicate to > the PCE if the metric must be strictly respected or not. Note, also that it > is possible to indicate many similar Metric object with different value, as > well as different value for the B-flag for more flexibility. For example, > for the Disjointness, we could image a first Metric with SRLG disjoint path > and B-Flag set to one and a second one with SRLG-and-Node disjoint path > with B-Flag clear. This indicate to the PCE that we want at least an SRLG > disjoint path, but if it could compute an SRLG and Node disjoint path we'll > be very happy. > > PCC could also set the C-Flag to indicate to the PCE that it would in turn > the computed Metric. For disjointness, it could indicate which type of > disjointness it successfully used for the computed path. > > If a metric could not be met, PCE will return a No-PATH object with the > default metric to indicate which constraints could not be met. > > Now, to indicate that a metric (constraint) should be relaxed, there is 2 > possibilities: send a new PCEP message with the B-Flag of this Metric > cleared, or a PCEP message without the given Metric. see again RFC 5440 end > of section 7.8 page 38 (https://tools.ietf.org/html/rfc5440#page-38). > > So, I think the generic mechanism is already available and to inherit from > this behaviour, the Disjointeness TLV should be a new Metric Object instead > of a dedicated new TLV. But, I understand that the draft and solution have > not been design with this in mind. So I let authors decided if it is > feasible or not. > > Regards > > Olivier > > > > Le 13/11/2017 à 09:40, stephane.litkow...@orange.com a écrit : > > Hi Daniele, > > > > Thanks for your feedback. > > If we go to a generic mechanism, IMO, this should be addressed in a > separate document. In addition, we need a generic way for a PCC to tell the > PCE that a constraint is relaxable or strict. For diversity, we have a > dedicated flag within the DISJOINTNESS TLV for that purpose. Maybe we > should make it generic as well. > > > > Do you agree ? > > > > Brgds, > > > > > > *From:* Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com > <daniele.ceccare...@ericsson.com>] > *Sent:* Monday, November 13, 2017 16:33 > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *Subject:* RE: draft-ietf-pce-association-diversity: relaxing constraint > > > > Hi Stephane, > > > > definitely needed. > > My opinion is that a way to say that a constraint was relaxed is very > useful. As you said there are different types of constraints that can be > relaxed, e.g. diversity or a TE bound. > > I would make the TLV as generic as possible and maybe define multiple > sub-TLV (or maybe just multiple values) depending on the constraint that > was relaxed. > > > > BR > Daniele > > > > *From:* Pce [mailto:pce-boun...@ietf.org <pce-boun...@ietf.org>] *On > Behalf Of *stephane.litkow...@orange.com > *Sent:* lunedì 13 novembre 2017 16:22 > *To:* pce@ietf.org > *Subject:* [Pce] draft-ietf-pce-association-diversity: relaxing constraint > > > > Hi WG, > > > > In the latest version of draft-ietf-pce-association-diversity we added a > new TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a > PCUpdate message when the PCE relaxes the requested disjointness > constraint. For instance, if a PCC requests an SRLG disjoint path but the > PCE cannot find it, it may relax the constraint (if PCC allows it to do so) > and thus informs the PCC through the RELAXED-CONSTRAINT-TLV. > > > > IMO, this kind of behavior is more generic rather tied to the disjointness > use case. It may be used with other constraints as well. > > > > The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the > association-diversity draft ? or do we drop it ? or do we define a TLV more > specific to the association diversity state ? maybe we can reuse the > association group object in the PCUpdate message including the > DISJOINTNESS-INFORMATION-TLV which reflects the actual disjointness style > used by the PCE. > > > > Opinions ? > > > > > > Brgds, > > > > Stephane > > > > > > [image: Orange logo] <http://www.orange.com/> > > > > *Stephane Litkowski * > Network Architect > Orange/SCE/EQUANT/OINIS/NET > > Orange Expert Future Networks > > phone: +33 2 23 *06* 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> > NEW ! > mobile: +33 6 71 63 27 50 > <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> > NEW ! > 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 > > > > _________________________________________________________________________________________________________________________ > > > > 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
