Subject: [Lsr] draft-ietf-lsr-flex-algo

From: <[email-masked]>
Date: Thu, 9 Sep 2021 12:43:17 +0000

Hi authors, all,

I have a question related to the two-way connectivity check performed on each link during the FlexAlgo SPF.

Is this point documented in the document? I could not find it so far.
If not, what is the (reverse connectivity) check that need to be performed on the reverse link?

A priori I could see multiple options:
a) link exist
b) link exist with a standard IGP metric  (seem the option defined in the ISO spec §7.2.8.2)
c) link exist with the FlexAlgo metric used by FlexAlgo
d) link exist with the FlexAlgo metric used by FlexAlgo and link complies to FlexAlgo constraints.

I think we'll agree that this point requires uniformity across nodes hence standardization.

Personally, I don't have significant preference, but the algo defined in §13 "Calculation of Flexible Algorithm Paths" could be read as defining option "d" (as links not following the constraints are "pruned from the computation") but I'm not sure that this is intended for the two-way connectivity check.

Thanks,
Regards,
--Bruno

_________________________________________________________________________________________________________________________

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: Peter Psenak <[email-masked]>
Date: Thu, 9 Sep 2021 14:52:17 +0200

Hi Bruno,

> I have a question related to the two-way connectivity check performed on each link during the FlexAlgo SPF.

flex-algo is defined as set of:

(a) calculation-type
(b) metric-type,
(c) a set of constraints

Two way connectivity check for any link in the MT topology is orthogonal 
to flex-algo and is done once only and used for all algorithms.

Flex-algo calculation using (a), (b), and (c) is done on top of MT 
topology using only links for which the 2WCC has already been performed.

> If not, what is the (reverse connectivity) check that need to be performed on the reverse link?

none.

thanks,
Peter

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>

---

From: <[email-masked]>
Date: Thu, 9 Sep 2021 13:27:05 +0000

Hi Peter,

Thanks for your answer.
Please see inline

> -----Original Message-----
> From: Peter Psenak [mailto:[email-masked]]
> Sent: Thursday, September 9, 2021 2:52 PM
> To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]
> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> 
> Hi Bruno,
> 

OK. Excellent.
Could the above be added in the specification, so that we have consistent behaviour across implementations?

Thanks,
Regards,
Bruno
> > Personally, I don't have significant preference, but the algo defined in §13
> "Calculation of Flexible Algorithm Paths" could be read as defining option "d" (as
> links not following the constraints are "pruned from the computation") but I'm not
> sure that this is intended for the two-way connectivity check.
> >
> > Thanks,
> > Regards,
> > --Bruno
> >
> >
> >
> >
> ____________________________________________________________________
> _____________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Peter Psenak <[email-masked]>
Date: Thu, 9 Sep 2021 15:30:09 +0200

Hi Bruno,

> Could the above be added in the specification, so that we have consistent behaviour across implementations?

sure, I will push it with the next revision - after the AD review.

thanks,
Peter

---

From: <[email-masked]>
Date: Thu, 9 Sep 2021 13:36:05 +0000

> sure, I will push it with the next revision - after the AD review.

OK.
Thank you Peter.

--Bruno
> >>> If not, what is the (reverse connectivity) check that need to be performed on
> the
> >> reverse link?
> >>
> >>
> >> none.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>>
> >>> b) link exist with a standard IGP metric  (seem the option defined in the ISO
> spec
> >> §7.2.8.2)

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 9 Sep 2021 16:51:07 +0000

Peter, 

draft-ietf-lsr-flex-algo-17 currently has registered Algorithm Types 128-255 with IANA. 
If we need to add a new Algorithm Type, e.g. using a weighted value of a Stub Link property in calculating the shortest path, do we need to use one of the value within 128-255 or need to ask IANA to assign one of the values within 2-127 (currently shown unassigned on IANA page)?

Linda Dunbar

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Thursday, September 9, 2021 7:52 AM
To: [email-masked]; [email-masked]
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Bruno,

(a) calculation-type
(b) metric-type,
(c) a set of constraints

Two way connectivity check for any link in the MT topology is orthogonal to flex-algo and is done once only and used for all algorithms.

Flex-algo calculation using (a), (b), and (c) is done on top of MT topology using only links for which the 2WCC has already been performed.

none.

thanks,
Peter

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3D&amp;reserved=0
> 
> 

_______________________________________________
Lsr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3D&amp;reserved=0

---

From: Tony Li <[email-masked]>
Date: Thu, 9 Sep 2021 10:37:12 -0700

Hi Linda,

Algorithm types 128-255 are intended to be used with the constraints that are advertised inside of a FlexAlgo definition.

I think what you’re proposing is not captured there, so you would need to have a defined algorithm from 2–127.

Tony

> On Sep 9, 2021, at 9:51 AM, Linda Dunbar <[email-masked]> wrote:
> 
> Peter, 
> 
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf Of Peter Psenak
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3D&amp;reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3D&amp;reserved=0>
>> 
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3D&amp;reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3D&amp;reserved=0>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 9 Sep 2021 19:59:56 +0200

Hi Linda, Tony,

On 09/09/2021 19:37, Tony Li wrote:
> 
> 
> Hi Linda,
> 
> Algorithm types 128-255 are intended to be used with the constraints 
> that are advertised inside of a FlexAlgo definition.
> 

eventually, the usage of the "weighted value of a Stub Link property" 
can be added to the FAD and be used with flex-algo.

thanks,
Peter

> 
> Tony
> 
> 
>> On Sep 9, 2021, at 9:51 AM, Linda Dunbar <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Peter,
>>
>> If we need to add a new Algorithm Type, e.g. using a weighted value of 
>> a Stub Link property in calculating the shortest path, do we need to 
>> use one of the value within 128-255 or need to ask IANA to assign one 
>> of the values within 2-127 (currently shown unassigned on IANA page)?
>>
>> Linda Dunbar
>>
>> To:[email-masked] 
>> <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
>> On 09/09/2021 14:43, [email-masked] 
>> <mailto:[email-masked]> wrote:
>>> Hi authors, all,
>>>
>> Two way connectivity check for any link in the MT topology is 
>> orthogonal to flex-algo and is done once only and used for all algorithms.
>>
>>> Personally, I don't have significant preference, but the algo defined 
>>> in §13 "Calculation of Flexible Algorithm Paths" could be read as 
>>> defining option "d" (as links not following the constraints are 
>>> "pruned from the computation") but I'm not sure that this is intended 
>>> for the two-way connectivity check.
>>>
>>> Thanks,
>>> Regards,
>>> --Bruno
>>>
>>>
>>>
>>> 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,
>>> This message and its attachments may contain confidential or 
>>> privileged information that may be protected by law;
>>> If you have received this email in error, please notify the sender 
>>> and delete this message and its attachments.

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 9 Sep 2021 20:17:21 +0000

Peter and Tony, 

Thank you very much for the explanation.

Is it necessary to register with IANA on individual Flex-Algo value (a value between 128-255)?
Say there are 5 properties associated with the Stub link, one Flex algo uses weighted values of 4 properties, another Flex Algo uses Weighted values of 5 properties. Can operator use any value they want? As long as the value is consistent among all nodes in one IGP domain? 

How is Calc-Type used, especially combined with Flex-Algo? 

Does the Flex-Algo type already indicate how  Metric are to be included in the algorithm? Why need to explicit indicate the "Metric-Type" in the FAD Sub-TLV? 

Linda

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Thursday, September 9, 2021 1:00 PM
To: Tony Li <[email-masked]>; Linda Dunbar <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

On 09/09/2021 19:37, Tony Li wrote:
> I think what you're proposing is not captured there, so you would need 
> to have a defined algorithm from 2-127.

thanks,
Peter

>> If we need to add a new Algorithm Type, e.g. using a weighted value 
>> of a Stub Link property in calculating the shortest path, do we need 
>> to use one of the value within 128-255 or need to ask IANA to assign 
>> one of the values within 2-127 (currently shown unassigned on IANA page)?
>>
>> Linda Dunbar
>>
>>> I have a question related to the two-way connectivity check 
>>> performed on each link during the FlexAlgo SPF.
>>
>>> Personally, I don't have significant preference, but the algo 
>>> defined in §13 "Calculation of Flexible Algorithm Paths" could be 
>>> read as defining option "d" (as links not following the constraints 
>>> are "pruned from the computation") but I'm not sure that this is 
>>> intended for the two-way connectivity check.
>>>
>>> Thanks,
>>> Regards,
>>> --Bruno
>>>
>>>
>>>
>>> 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.
>>>
>>> privileged information that may be protected by law; they should not 
>>> be distributed, used or copied without authorisation.
>>> As emails may be altered, Orange is not liable for messages that 
>>> have been modified, changed or falsified.
>>> Thank you.
>>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>> w.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunba
>>> r%40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24
>>> 0189c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZ
>>> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>> %3D%7C1000&amp;sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2
>>> K0%3D&amp;reserved=0
>>>
>>>
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%
>> 40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24018
>> 9c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZsb3d
>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>> C1000&amp;sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2K0%3D&
>> amp;reserved=0
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%
>> 40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24018
>> 9c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZsb3d
>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>> C1000&amp;sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2K0%3D&
>> amp;reserved=0
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 10 Sep 2021 07:45:33 +0200

Linda,

> Is it necessary to register with IANA on individual Flex-Algo value (a value between 128-255)?

no.

> Say there are 5 properties associated with the Stub link, one Flex algo uses weighted values of 4 properties, another Flex Algo uses Weighted values of 5 properties. Can operator use any value they…

that is right.

> How is Calc-Type used, especially combined with Flex-Algo?

we only have a single calculation type for now which is SPF. We added it 
for future if anyone wants to use a different one.

> Does the Flex-Algo type already indicate how  Metric are to be included in the algorithm? Why need to explicit indicate the "Metric-Type" in the FAD Sub-TLV?

It's the Calc-Type which indicates how metric is used. Metric-Type 
indicates which metric is used.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 11 Sep 2021 14:59:28 +0000

Hi Peter, 

On 9/10/21, 1:46 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Linda,

    no.

But if the corresponding algorithm is in another standards track document, it would need to be registered and part of the standard range.  

Thanks,
Acee

    that is right.

    thanks,
    Peter

---

From: Peter Psenak <[email-masked]>
Date: Sun, 12 Sep 2021 20:14:56 +0200

Hi Acee,

> But if the corresponding algorithm is in another standards track document, it would need to be registered and part of the standard range.

sure, the question was if "individual Flex-Algo value" needs to be 
registered and the answer to that is no. We have reserved the range of 
algos from 128 to 255 to flex-algos and there is no further IANA 
registration needed for those.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 15 Sep 2021 18:09:58 +0000

Hi Peter, 

I had too long of a context switch on flex algo.... See inline. 

On 9/12/21, 2:15 PM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Hi Acee,

So, if someone wants to define new constraints (e.g., Linda's server/application metrics), they would need to define the semantics and encodings similar to what is being done for bandwidth metrics in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ . Then the flex algos could be defined using these metrics. Correct? 

Thanks,
Acee

    thanks,
    Peter

---

From: Peter Psenak <[email-masked]>
Date: Wed, 15 Sep 2021 20:17:25 +0200

Hi Acee,

> So, if someone wants to define new constraints (e.g., Linda's server/application metrics), they would need to define the semantics and encodings similar to what is being done for bandwidth metrics…

yes, they would need to define a new FAD constraint and/or metric only.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Wed, 15 Sep 2021 11:26:05 -0700

> On Sep 15, 2021, at 11:17 AM, Peter Psenak <[email-masked]> wrote:
> 
>> So, if someone wants to define new constraints (e.g., Linda's server/application metrics), they would need to define the semantics and encodings similar to what is being done for bandwidth metrics in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ <https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/> . Then the flex algos could be defined using these metrics. Correct?
> 

I agree that if the goal is a new metric, then that’s sufficient.  [Plug for generic metrics.]

It sounded a bit like Linda was wanting a fundamental change to the SPF algorithm.  If, so, I believe that would require a new Calc-Type. Linda, could you please clarify?

Tony

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Sep 2021 19:45:05 +0000

Tony,

Answers are inserted below:

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, September 15, 2021 1:26 PM
To: Peter Psenak <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; Acee Lindem (acee) <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

On Sep 15, 2021, at 11:17 AM, Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:

So, if someone wants to define new constraints (e.g., Linda's server/application metrics), they would need to define the semantics and encodings similar to what is being done for bandwidth metrics in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-flex-algo-bw-con%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca8b0297f156e4079414008d978764920%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637673271737823035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=fm4E8mhhCeYA4ab7gvSDqBX9ZG6QjBJA62Br86l%2F1q0%3D&reserved=0> . Then the flex algos could be defined using these metrics. Correct?

I agree that if the goal is a new metric, then that's sufficient.  [Plug for generic metrics.]

It sounded a bit like Linda was wanting a fundamental change to the SPF algorithm.  If, so, I believe that would require a new Calc-Type. Linda, could you please clarify?
[Linda] I don't think so. We want a constrained SPF algorithm that take into additional metrics. Just like TE being added into the SPF.

Linda Dunbar

Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 15 Sep 2021 21:30:10 +0000

Hi Linda, Tony,

From: Linda Dunbar <[email-masked]>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>
Cc: "Acee Lindem (acee)" <acee=[email-masked]>, Acee Lindem <[email-masked]>, Bruno Decraene <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] draft-ietf-lsr-flex-algo

Tony,

It sounded a bit like Linda was wanting a fundamental change to the SPF algorithm.  If, so, I believe that would require a new Calc-Type. Linda, could you please clarify?
[Linda] I don’t think so. We want a constrained SPF algorithm that take into additional metrics. Just like TE being added into the SPF.

I was thinking that as well. These metrics would be defined to have precedence over the path cost – sort of like OSPF Type 2 external metrics do for OSPF AS External routes.

Thanks,
Acee

Linda Dunbar

Tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 16 Sep 2021 09:19:50 +0200

Hi Linda,

On 15/09/2021 21:45, Linda Dunbar wrote:
> *From:* Tony Li <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Wednesday, September 15, 2021 1:26 PM
> *To:* Peter Psenak <[email-masked]>
> *Cc:* Acee Lindem (acee) <acee=[email-masked]>; Acee Lindem 
> (acee) <[email-masked]>; Linda Dunbar <[email-masked]>; 
> [email-masked]; [email-masked]
> *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo
> 
> 
> 
>         So, if someone wants to define new constraints (e.g., Linda's
>         server/application metrics), they would need to define the
>         semantics and encodings similar to what is being done for
>         bandwidth metrics
>         inhttps://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
>         <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-flex-algo-bw-con%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca8b0297f156e4079414008d978764920%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637673271737823035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=fm4E8mhhCeYA4ab7gvSDqBX9ZG6QjBJA62Br86l%2F1q0%3D&reserved=0>.
>         Then the flex algos could be defined using these metrics. Correct?
> 
> 
> It sounded a bit like Linda was wanting a fundamental change to the SPF 
> algorithm.  If, so, I believe that would require a new Calc-Type. Linda, 
> could you please clarify?
> 
> [Linda] I don’t think so. We want a constrained SPF algorithm that take 
> into additional metrics. Just like TE being added into the SPF.

I believe flex-algo with additional constraints would be sufficient.

For example, we've already defined M-flag and FAMP metric that can be 
used during flex-algo computation as an additional metric for prefixes.

Something similar can be defined for your use case I believe.

thank,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Sep 2021 11:35:12 +0200

> I believe flex-algo with additional constraints would be sufficient.

Aren't we putting too much operational complexity to the operators ?

How can anyone practically assure that such constraints will be understood
across a zoo of software versions and various implementations ?

For well known metrics it could be ok - but for new metrics and selective
use in FAD I am afraid this is going to be a pandora box.

Best,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 16 Sep 2021 20:16:16 +0000

Hi Robert,

From: Robert Raszuk <[email-masked]>
Date: Thursday, September 16, 2021 at 5:34 AM
To: Peter Psenak <ppsenak=[email-masked]>
Cc: Linda Dunbar <[email-masked]>, Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>, Acee Lindem <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

The architecture supports it additional constraints. Nobody says they have to be used. This is an interesting comment coming from the originator of https://www.ietf.org/archive/id/draft-ietf-idr-wide-bgp-communities-05.txt   😉

How can anyone practically assure that such constraints will be understood across a zoo of software versions and various implementations ?

IIRC, only routers supporting the FAD will participate in the flex algorithm computation. I’ll defer to the authors for elaboration as I’m busy with something else right now.

Thanks,
Acee

For well known metrics it could be ok - but for new metrics and selective use in FAD I am afraid this is going to be a pandora box.

Best,
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 16 Sep 2021 22:21:33 +0200

Robert, Acee,

On 16/09/2021 22:16, Acee Lindem (acee) wrote:
> Hi Robert,
> 
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Thursday, September 16, 2021 at 5:34 AM
> *To: *Peter Psenak <ppsenak=[email-masked]>
> *Cc: *Linda Dunbar <[email-masked]>, Tony Li 
> <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene 
> <[email-masked]>, Acee Lindem <[email-masked]>, "Acee Lindem 
> (acee)" <acee=[email-masked]>
> *Subject: *Re: [Lsr] draft-ietf-lsr-flex-algo
> 
> The architecture supports it additional constraints. Nobody says they 
> have to be used. This is an interesting comment coming from the 
> originator of 
> https://www.ietf.org/archive/id/draft-ietf-idr-wide-bgp-communities-05.txt 
> 😉
> 
> How can anyone practically assure that such constraints will be 
> understood across a zoo of software versions and various implementations ?
> 
> IIRC, only routers supporting the FAD will participate in the flex 
> algorithm computation. I’ll defer to the authors for elaboration as I’m 
> busy with something else right now.

that's right, consistency check is one of the basic building blocks of
the flex-algo technology.

thanks,
Peter

> 
> Thanks,
> Acee
> 
> For well known metrics it could be ok - but for new metrics and 
> selective use in FAD I am afraid this is going to be a pandora box.
> 
> Best,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Sep 2021 22:23:42 +0200

Acee,

Wide communities actually are designed to help operators in their tasks. I
am not sure why you brought it here.

Besides please observe that communities are optional attributes. Lack of
support on any BGP speaker will not break things or cause a permanent loop
by design.

Thx
R.

On Thu, Sep 16, 2021 at 10:16 PM Acee Lindem (acee) <[email-masked]> wrote:

> *Cc: *Linda Dunbar <[email-masked]>, Tony Li <[email-masked]>,
> "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>,
> Acee Lindem <[email-masked]>, "Acee Lindem (acee)" <acee=
> [email-masked]>
> The architecture supports it additional constraints. Nobody says they have
> to be used. This is an interesting comment coming from the originator of

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 16 Sep 2021 21:15:28 +0000

Hi Robert,

From: Robert Raszuk <[email-masked]>
Date: Thursday, September 16, 2021 at 4:23 PM
To: Acee Lindem <[email-masked]>
Cc: Peter Psenak <ppsenak=[email-masked]>, Linda Dunbar <[email-masked]>, Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Acee,

Wide communities actually are designed to help operators in their tasks. I am not sure why you brought it here.

I only mentioned wide communities in context of them being, IMO, a mechanism that could potentially be used to create an order of magnitude more complexity than flex algo… But you are right, we don’t want to discuss it here.

Besides please observe that communities are optional attributes. Lack of support on any BGP speaker will not break things or cause a permanent loop by design.

Lack of support for flex algorithm or a particular flex algorithm will not break things either.

Thanks,
Acee

Thx
R.

On Thu, Sep 16, 2021 at 10:16 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 16, 2021 at 5:34 AM
To: Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>>
Cc: Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Tony Li <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bruno Decraene <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, "Acee Lindem (acee)" <acee=[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Thanks,
Acee

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Sep 2021 23:24:58 +0200

> Lack of support for flex algorithm or a particular flex algorithm will not

I was not really talking about breaking.

I was more expressing an option about cross vendor support of various
metrics and constraints as part of a given flexible algorithm. I think
putting a hard line that perhaps very useful set of constraints and metrics
- documented as IETF informational doc - even if still using Dijkstra for
SPT can not have a unique IANA assigned type is a bit too coarse, That's
all.

Many thx,
R.

---

From: Tony Li <[email-masked]>
Date: Thu, 16 Sep 2021 14:32:14 -0700

Dear Gentlebeings,

> I was more expressing an option about cross vendor support of various metrics and constraints as part of a given flexible algorithm. I think putting a hard line that perhaps very useful set of constraints and metrics - documented as IETF informational doc - even if still using Dijkstra for SPT can not have a unique IANA assigned type is a bit too coarse, That's all. 

We are all painfully aware of the true challenges of interoperability.  Is there really some point to beating on this decades-dead horse?

Assigning some type (from what namespace?) to some subset of the features doesn’t seem helpful in this regard. There will always need to be site-specific details about the constraints for a specific algorithm and topology. And there will always be implementation issues and restrictions.

If you really want to regress to the point where we had unanimous interoperability, I’m afraid that you’ll have to go back to running RIP on the FDDI.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Sep 2021 23:39:33 +0200

Tony,

> We are all painfully aware of the true challenges of interoperability.
Is there really some point to beating on this decades-dead horse?

IMHO the magnitude of those will exponentially increase with flex-algo if
it really takes off. Will it be manageable in some networks - perhaps.

But the question is - Can we do a bit better and help to standardize most
useful flex-algos to make their deployment easier cross vendor ?

That's all.

Best,
R

On Thu, Sep 16, 2021 at 11:32 PM Tony Li <[email-masked]> wrote:

> We are all painfully aware of the true challenges of interoperability.  Is
> there really some point to beating on this decades-dead horse?
>
> Assigning some type (from what namespace?) to some subset of the features
> doesn’t seem helpful in this regard. There will always need to be
> site-specific details about the constraints for a specific algorithm and
> topology. And there will always be implementation issues and restrictions.
>
> If you really want to regress to the point where we had unanimous
> interoperability, I’m afraid that you’ll have to go back to running RIP on
> the FDDI.
>
> Regards,
> Tony
>
>

---

From: Tony Li <[email-masked]>
Date: Thu, 16 Sep 2021 15:02:06 -0700

Robert,

> IMHO the magnitude of those will exponentially increase with flex-algo if it really takes off. Will it be manageable in some networks - perhaps. 

Well, you’re welcome to your opinion. :-)

The basic set of constraints seem very straightforward and, as always, operators are likely to lab test their configurations before a production deployment.  If FlexAlgo really takes off, it would imply that the vendors have good interoperability of those basic constraints.

> But the question is - Can we do a bit better and help to standardize most useful flex-algos to make their deployment easier cross vendor ? 

Short of creating a worldwide authoritarian government with you as its benevolent dictator, what would you propose? :-)

There have been many prior attempts to ensure compliance and interoperability.  There have been test suites and compliance statements. All of it has proven to be of dubious value. What has worked? Actual interoperability testing where developers sit down and test.  Today, that role seems to be primarily fulfilled by EANTC and FlexAlgo is already tested there.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Sep 2021 00:26:47 +0200

Hi Tony,

> Actual interoperability testing where developers sit down and test.

To the best of my knowledge the objective of those testing is to detect
bugs or make sure that developers of different vendors read the spec they
were implementing the same way.

> what would you propose? :-)

Top define what is useful in IANA.

What harm would it make if someone writes a draft, defines a useful flex
algo on which (the usefulness the LSR WG agrees) say using max propagation
delay across hops as as a metric and allocates IANA type 135 for it ?

That is what I have a hard time to understand the objections for.

Many thx,
R.

On Fri, Sep 17, 2021 at 12:02 AM Tony Li <[email-masked]> wrote:

>
> Robert,
>
>
> > IMHO the magnitude of those will exponentially increase with flex-algo
> if it really takes off. Will it be manageable in some networks - perhaps.
>
>
> The basic set of constraints seem very straightforward and, as always,
> operators are likely to lab test their configurations before a production
> deployment.  If FlexAlgo really takes off, it would imply that the vendors
> have good interoperability of those basic constraints.
>
>
> > But the question is - Can we do a bit better and help to standardize
> most useful flex-algos to make their deployment easier cross vendor ?
>
>
> Short of creating a worldwide authoritarian government with you as its
> benevolent dictator, what would you propose? :-)
>
> There have been many prior attempts to ensure compliance and
> interoperability.  There have been test suites and compliance statements.
> All of it has proven to be of dubious value. What has worked? Actual
> interoperability testing where developers sit down and test.  Today, that
> role seems to be primarily fulfilled by EANTC and FlexAlgo is already
> tested there.
>
> Tony
>
>

---

From: Tony Li <[email-masked]>
Date: Thu, 16 Sep 2021 15:48:17 -0700

Robert,

> What harm would it make if someone writes a draft, defines a useful flex algo on which (the usefulness the LSR WG agrees) say using max propagation delay across hops as as a metric and allocates IANA type 135 for it ? 

I’m inferring that you are suggesting that we take a code point from the IANA IGP Algorithm Types registry.  There are only 256 of those, so they are quite precious.  135 has already been allocated to FlexAlgo for local use.  Values 2-127 are currently unassigned.

The exact same semantics could be achieved by using a local algorithm value and then specifying the Min Unidirectional Link Delay as the Metric Type in the FlexAlgo Definition.

> That is what I have a hard time to understand the objections for. 

You burn a precious code point and have made the problem worse.  Now, you need to ensure that not only do all of your implementations support min delay, but now they also must know about the statically defined code point.  That lowers interoperability, not improves it.

And once we head down this slippery slope, everyone and their uncle will ask for a code point for their favorite particular combinations of FAD parameters.  125 values will not go very far in encoding a rich constraint space.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Sep 2021 01:14:22 +0200

Tony,

Yes - spot on.

It is like either selecting ingredients to "make your own pizza" vs
ordering a fixed one (Pepperoni, Margarita, 4 cheese, style #135 etc...)

All I am saying is that both options are useful. And it seems defining few
most useful flex-algos may be helpful. Call it well known flex-algos. I am
questioning enforcement saying you must always select all pieces yourself.

If most useful ones are going to be done under IETF umbrella or outside of
it time will tell.

And btw I do agree on the limited number of those code points ... Well -
maybe one octet is not enough ?

Kind regards,
Robert.

On Fri, Sep 17, 2021 at 12:48 AM Tony Li <[email-masked]> wrote:

> I’m inferring that you are suggesting that we take a code point from the
> IANA IGP Algorithm Types registry.  There are only 256 of those, so they
> are quite precious.  135 has already been allocated to FlexAlgo for local
> use.  Values 2-127 are currently unassigned.
>
> The exact same semantics could be achieved by using a local algorithm
> value and then specifying the Min Unidirectional Link Delay as the Metric
> Type in the FlexAlgo Definition.
>
>
> You burn a precious code point and have made the problem worse.  Now, you
> need to ensure that not only do all of your implementations support min
> delay, but now they also must know about the statically defined code
> point.  That lowers interoperability, not improves it.
>
> And once we head down this slippery slope, everyone and their uncle will
> ask for a code point for their favorite particular combinations of FAD
> parameters.  125 values will not go very far in encoding a rich constraint
> space.
>
> Regards,
> Tony
>
>

---

From: John Scudder <[email-masked]>
Date: Thu, 23 Sep 2021 18:00:14 +0000

Hi Peter,

Unless you have some special reason for waiting until after AD review (in which case please let me know), I’d prefer if you didn’t hold off incorporating planned changes.

Thanks,

—John

> On Sep 9, 2021, at 9:30 AM, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Bruno,
> 
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QDbnMxgvs-3Nw1duHw-Lo0ToK8aZSyFCYlBRQu-2yr1WReve4IDOKCdjc0OWSA$
>>>> 
>>>> 
>> 
>> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QDbnMxgvs-3Nw1duHw-Lo0ToK8aZSyFCYlBRQu-2yr1WReve4IDOKCdjc0OWSA$