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-flagfor 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, [email protected] 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:[email protected]] > *Sent:* Monday, November 13, 2017 16:33 > *To:* LITKOWSKI Stephane OBS/OINIS; [email protected] > *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:[email protected]] *On Behalf Of > *[email protected] <mailto:[email protected]> > *Sent:* lunedì 13 novembre 2017 16:22 > *To:* [email protected] <mailto:[email protected]> > *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 ! > [email protected] <mailto:[email protected]> > > > > _________________________________________________________________________________________________________________________ > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
