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.
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
