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.

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

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 <linda.dun...@futurewei.com <mailto:linda.dun...@futurewei.com>> wrote:

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 <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> On Behalf Of Peter Psenak
Sent: Thursday, September 9, 2021 7:52 AM
To:bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>;lsr@ietf.org <mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Bruno,

On 09/09/2021 14:43, bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> wrote:
Hi authors, all,

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.



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?


none.

thanks,
Peter



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.

_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
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
Lsr@ietf.org <mailto:Lsr@ietf.org>
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
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to