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 protected] on behalf of [email protected]> wrote: Hi Acee, On 11/09/2021 16:59, Acee Lindem (acee) wrote: > Hi Peter, > > On 9/10/21, 1:46 AM, "Lsr on behalf of Peter Psenak" <[email protected] on behalf of [email protected]> wrote: > > Linda, > > On 09/09/2021 22:17, Linda Dunbar wrote: > > 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)? > > no. > > 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. 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 > > Thanks, > Acee > > > > 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? > > 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 > > > > > > > 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 > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
