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? 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? 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]> Sent: Wednesday, November 3, 2021 7:43 AM To: Linda Dunbar <[email protected]>; [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%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C0a9f151594a34618078208d99ec77062%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637715401744226058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kS4yuH1YUVIYyTOdEH1U5XejgXRZJ3bMZ%2FaJeBGwLYw%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
