Peter,
You said
" The flex-algo is a combination of (a)-Calc-Type, (b)-Metric-Type, and
(c)-constraint"
Does it mean that "Flex-Algorithm" value of the Flex-Algo Definition Sub-TLV is
to indicate the combination of (a), (b), (c)?
Is the "(c) -constraint" carried in the sub-TLVs of the FAD TLV, such as the
"FAD Flags Sub-TLV" ?
Thank you,
Linda
-----Original Message-----
From: Peter Psenak <[email protected]>
Sent: Friday, November 5, 2021 4:43 AM
To: Linda Dunbar <[email protected]>; [email protected]
Subject: Re: Question about how topology is calculated ( was RE: [Lsr] Looking
for feedback of using Flex Algo to advertise the 5G edge computing associated
metrics
Linda,
On 05/11/2021 00:20, Linda Dunbar wrote:
> Peter,
> You said:
> /calculation type refers to how topology is calculated, / I thought
> that the Flexible Algorithm Exclude/Include Admin Group Sub-TLV is to
> indicate if a link belongs to a specific topology. Is my understanding
> correct?
> By indicating "Exclude/Include" bunch of links for a Calc-Type, does
> it practically specify the topology?
that's not how the flex-algorithm is defined.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-18%23section-4&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb88dcb6627dd45adf57a08d9a040a148%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637717021742366778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LUCj3PAiP1EyWSdrHpDyBOelxKNrAvoknr6l2Wjw6Go%3D&reserved=0
"To provide maximum flexibility, we want to provide a mechanism that
allows a router to (a) identify a particular calculation-type, (b)
metric-type, (c) describe a particular set of constraints, and (d)
assign a numeric identifier, referred to as Flex-Algorithm, to the
combination of that calculation-type, metric-type, and those
constraints. We want the mapping between the Flex-Algorithm and its
meaning to be flexible and defined by the user.
The flex-algo is a combination of (a), (b), and (c).
You are trying to define (a) that would have (b) and (c) hardcoded. That does
not follow the defined architecture.
thanks,
Peter
> Thank you, Linda
> -----Original Message-----
> From: Peter Psenak <[email protected]<mailto:[email protected]>>
> Sent: Thursday, November 4, 2021 1:16 PM
> To: Linda Dunbar
> <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[email protected]>
> Subject: Re: Question about the FAD Flags Sub-TLV ( was RE: [Lsr]
> Looking for feedback of using Flex Algo to advertise the 5G edge
> computing associated metrics Linda, please see inline:
> On 04/11/2021 18:17, Linda Dunbar wrote:
>> Peter,
>> Thank you very much for the valuable feedback. We will move the
>> content from Section 1, 2, 3 to an appendix per your suggestion.
>> As for defining a new value in the Flexible Algorithm Definition
>> Flags Sub-TLV, why can't we use the Metric-Type & Calc-Type to
>> represent the information carried by the FAD Flags Sub-TLV?
> because the Metric-Type in flex-algo is referring to link metrics, not
> to prefix metrics. And Calc-Type you still wan to use SPF, don't you?
>> draft-dunbar-lsr-5g-edge-compute-01 suggests to add a new value to
>> the "Metric-Type" to indicate the Aggregated Cost AppMetaData Metrics
>> included in computing the constrained SPF.
>> Is it reasonable to use Calc-Type to indicate the options you mentioned?
> no, calculation type refers to how topology is calculated, not
> how/which prefix metrics is used.
> thanks,
> Peter
>> For example:
>>
>> * Calc-Type-v1: replace the regular prefix metric,
>> * Calc-Type-v2: the newly added metric is added on top,
>> * Calc-Type-v3: only used as tiebreaker,
>> * Calc-Type-v4: use the default prefix metric when the AppMetaData
>> Metrics is not present. When AppMeteData metrics is not present,
>> the prefix is considered normal that doesn't need special
>>constraint
>> SPF computation.
>> * Calc-Type-v5: no transit across areas/domains
>> * Calc-Type-v6: transit across areas/domains.
>>
>> Thank you,
>> Linda
>> -----Original Message-----
>> From: Peter Psenak <[email protected]
>> <mailto:[email protected]<mailto:[email protected]%20<mailto:[email protected]>>>
>> Sent: Wednesday, November 3, 2021 7:43 AM
>> To: Linda Dunbar <[email protected]
>> <mailto:[email protected]>>;
> [email protected]<mailto:[email protected]> <mailto:[email protected]>
>> Subject: Re: [Lsr] Looking for feedback of using Flex Algo to
>> advertise the 5G edge computing associated metrics Hi Linda, I went
>> through your document and here are my comments:
>> 1. the section 1, 2, and 3 can probably be summarized in a single
>> paragraph stating the problem you are trying to solve. The 5G details
>> are redundant, you may just want to add reference to the parent document.
>> 2. FAD is used to advertise how to compute the flex-algo paths, not
>> to advertise metrics. What I believe you need to define for FAD is a
>> new bit in the ISIS/OSPF Flexible Algorithm Definition Flags Sub-TLV
>> to indicate that the calculation should use the new application
>> prefix metric that you define and how exactly that metric will be
>> used during
>> calculation:
>> a) does it replace the regular prefix metric, is added on top, only
>> used as tiebreaker, etc,.
>> b) what happens if the metric is not present with prefix
>> advertisement, is the prefix considered unreachable for the flex-algo
>> or do you fallback to regular prefix metric, etc,.
>> c) how is the propagation of the new metric done between
>> areas/domains 3. The new application metric should be advertised in
>> the IP prefix reachability TLV associated with the (anycast) prefix.
>> 4. How the application metric is calculated, using load, preference,
>> etc, should be hidden from IGPs. I believe the application metric
>> should be calculated at the egress router, associated with the
>> prefix/Server-address and advertised in a form of the resulting value.
>> If you need to consider Network Delay, you can combine the new app.
>> metric (for prefixes) with the existing delay metric support (for
>> links) in the flex-algo, no need to include network delay in the
>> application metric itself. Advertising all the metadata and asking
>> IGP at each node to derive the app metric seems sub-optimal, unless
>> there is an unavoidable reason to do so.
>> 5. I don't see any reason to define a new application in SABM as you
>> do in section 7. The existing flex-algo app is sufficient.
>> thanks,
>> Peter
>> On 14/10/2021 00:50, Linda Dunbar wrote:
>>> LSR experts:
>>>
>>> We have updated the draft to reflect the suggestions from LSR WG to
>>> use Flex Algo to advertise the metrics associated with the
>>> environment where 5G edge computer servers are running.
>>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
>>> tatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&d
>>> ata=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb88dcb6627dd45adf57a08d
>>> 9a040a148%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6377170217423
>>> 66778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
>>> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d8aPiK9HO1hM9pFm9r6C5V
>>> LprerWSVEpJUhVvLvZPPM%3D&reserved=0
>>>
>>> In a nutshell, the draft proposes some new values in the Flex Algo
>>> Definition Sub-TLV
>>>
>>> * A new Metric-Type is introduced to indicate the Aggregated Cost
>>> AppMetaData Metrics included in computing the constrained SPF.
>>> * Additional subsub-TLVs to be included in the Flex Algo
>>>Definition
>>> Sub-TLV to carry the detailed metrics for the constrained SPF.
>>>
>>> We are looking for feedback of our revised approach.
>>>
>>> Thank you.
>>>
>>> Linda Dunbar
>>>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
