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 protected]> Sent: Thursday, September 9, 2021 1:00 PM To: Tony Li <[email protected]>; Linda Dunbar <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Lsr] draft-ietf-lsr-flex-algo 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> On >> Behalf Of Peter Psenak >> Sent: Thursday, September 9, 2021 7:52 AM >> To:[email protected] >> <mailto:[email protected]>;[email protected] <mailto:[email protected]> >> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo >> >> Hi Bruno, >> >> On 09/09/2021 14:43, [email protected] >> <mailto:[email protected]> 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 >>> [email protected] <mailto:[email protected]> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunba >>> r%40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24 >>> 0189c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZ >>> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>> %3D%7C1000&sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2 >>> K0%3D&reserved=0 >>> >>> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] <mailto:[email protected]> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar% >> 40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24018 >> 9c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZsb3d >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 >> C1000&sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2K0%3D& >> amp;reserved=0 >> >> _______________________________________________ >> Lsr mailing list >> [email protected] <mailto:[email protected]> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar% >> 40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24018 >> 9c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZsb3d >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 >> C1000&sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2K0%3D& >> amp;reserved=0 > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
