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?
Thank you, Linda
-----Original Message-----
From: Peter Psenak <ppse...@cisco.com>
Sent: Thursday, November 4, 2021 1:16 PM
To: Linda Dunbar <linda.dun...@futurewei.com>; lsr@ietf.org
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 <ppse...@cisco.com<mailto:ppse...@cisco.com>>
> Sent: Wednesday, November 3, 2021 7:43 AM
> To: Linda Dunbar
> <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>;
> lsr@ietf.org<mailto:lsr@ietf.org>
> 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%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C7775d35a409c43c09e2b08d99fbf2f9f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637716465769821490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FfJIFYMNCvLwCm%2FnLlV9MRGFgQsbwV3yDNy6mQwk4%2B0%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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
