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] Sent: Tuesday, November 14, 2017 00:32 To: LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; pce@ietf.org<mailto: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<mailto: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] Sent: Monday, November 13, 2017 16:33 To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org<mailto: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] On Behalf Of stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> Sent: lunedì 13 novembre 2017 16:22 To: pce@ietf.org<mailto: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 [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<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<mailto: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
