Linda,
On 05/11/2021 16:36, Linda Dunbar wrote:
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)?
yes, each flex-algo number represents a specific combination of (a),
(b), and (c), as defined by the user.
Is the "(c) -constraint" carried in the sub-TLVs of the FAD TLV, such as
the "FAD Flags Sub-TLV" ?
yes (c) is advertised in FAD.
thanks,
Peter
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]
<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
