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>
Sent: Wednesday, November 3, 2021 7:43 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; 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%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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
