Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

From: <[email-masked]>
Date: Mon, 13 Nov 2017 08:22:18 +0000

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-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 13 Nov 2017 08:33:24 +0000

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-masked]] On Behalf Of [email-masked]
Sent: lunedì 13 novembre 2017 16:22
To: [email-masked]
Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hi WG,

Opinions ?

Brgds,

Stephane

Stephane Litkowski
Network Architect

Thank you.

---

From: <[email-masked]>
Date: Mon, 13 Nov 2017 08:40:41 +0000

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-masked]]
Sent: Monday, November 13, 2017 16:33
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: draft-ietf-pce-association-diversity: relaxing constraint

Hi Stephane,

definitely needed.

BR
Daniele

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: lunedì 13 novembre 2017 16:22
To: [email-masked]<mailto:[email-masked]>
Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hi WG,

Opinions ?

Brgds,

Stephane

Stephane Litkowski
Network Architect

Thank you.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 13 Nov 2017 08:42:34 +0000

On everything 😊

From: [email-masked] [mailto:[email-masked]]
Sent: lunedì 13 novembre 2017 16:41
To: Daniele Ceccarelli <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-pce-association-diversity: relaxing constraint

Hi Daniele,

Do you agree ?

Brgds,

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Monday, November 13, 2017 16:33
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-pce-association-diversity: relaxing constraint

Hi Stephane,

definitely needed.

BR
Daniele

Hi WG,

Opinions ?

Brgds,

Stephane

Stephane Litkowski
Network Architect

Thank you.

Thank you.

---

From: Olivier Dugeon <[email-masked]>
Date: Mon, 13 Nov 2017 17:32:02 +0100

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-masked] a écrit :
> *From:*Daniele Ceccarelli [mailto:[email-masked]]
> *Sent:* Monday, November 13, 2017 16:33
> *To:* LITKOWSKI Stephane OBS/OINIS; [email-masked]
> *Subject:* RE: draft-ietf-pce-association-diversity: relaxing constraint
>
>  
>
> Hi Stephane,
>
>  
>
> definitely needed.
>
> *From:* Pce [mailto:[email-masked]] *On Behalf Of [email-masked] <mailto:[email-masked]>
> *Sent:* lunedì 13 novembre 2017 16:22
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Pce] draft-ietf-pce-association-diversity: relaxing constraint
>
>  
>
> Hi WG,
>
>  
>
> Orange logo <http://www.orange.com/>
>
>  
>
> *Stephane Litkowski *
> Network Architect
> 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 !
> [email-masked] <mailto:[email-masked]>
>
>  
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: <[email-masked]>
Date: Mon, 13 Nov 2017 17:18:28 +0000

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:[email-masked]]
Sent: Tuesday, November 14, 2017 00:32
To: LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; [email-masked]
Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hello Stephane, all

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.

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).

Regards

Olivier

Le 13/11/2017 à 09:40, [email-masked]<mailto:[email-masked]> a écrit :
Hi Daniele,

Do you agree ?

Brgds,

Hi Stephane,

definitely needed.

BR
Daniele

Hi WG,

Opinions ?

Brgds,

Stephane

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Pce mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 17 Nov 2017 01:02:51 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: 14 November 2017 01:18
To: DUGEON Olivier IMT/OLN <[email-masked]>; Daniele Ceccarelli <[email-masked]>; [email-masked]
Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hi Olivier,

  *   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.

Brgds,

From: Olivier Dugeon [mailto:[email-masked]]
Sent: Tuesday, November 14, 2017 00:32
To: LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hello Stephane, all

Regards

Olivier

Do you agree ?

Brgds,

Hi Stephane,

definitely needed.

BR
Daniele

Hi WG,

Opinions ?

Brgds,

Stephane

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Pce mailing list

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 17 Nov 2017 01:06:52 +0000

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 <
[email-masked]> 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:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* 14 November 2017 01:18
> *To:* DUGEON Olivier IMT/OLN <[email-masked]>; Daniele
> Ceccarelli <[email-masked]>; [email-masked]
>
>
> *Subject:* Re: [Pce] draft-ietf-pce-association-diversity: relaxing
> constraint
>
>
>
> Hi Olivier,
>
>
>
> 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 !
>
>
>
>    - 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).
>
>
> 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:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, November 14, 2017 00:32
> *To:* LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; [email-masked]
> *Subject:* Re: [Pce] draft-ietf-pce-association-diversity: relaxing
> constraint
>
>
>
> Hello Stephane, all
>
> 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
>
>
>
> 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-masked]
> <[email-masked]>]
> 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-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *To:* [email-masked]
> 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
>
>
>
>
>
>  <http://www.orange.com/>
>
>
>
> *Stephane Litkowski *
> Network Architect
> 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-masked]
>
>
>