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

Reply via email to