--- Begin Message ---
Linda,
On 09/11/2021 18:09, Linda Dunbar wrote:
> Peter,
> You suggested creating a new sub-TLV for E-Intra-Area-Prefix-LSA,
> E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and E-Type-7-LSA [RFC8362].
> But if we use the original Intra/Inter-area-prefix LSA [RFC5340], we can
> use the “Metric” field to carry the aggregated cost. Is it simpler?
well, that would mean that such metric would be used for algo 0 and all
flex-algos. Is that the intention?
If yes, we don't need any IETF draft, we just locally, on the egress
node, fill the existing prefix metric field with the value calculated
based on the load, etc. Any traffic to that site would be affected by
such metric.
My understanding was that you want some extra prefix metric that would
only be used for specific traffic for which you can use a specific
flex-algo.
thanks,
Peter
> Thanks, Linda
> _____________________________________________
> *From:* Linda Dunbar
> *Sent:* Tuesday, November 9, 2021 9:24 AM
> *To:* Peter Psenak <[email protected]>
> *Cc:* Huaimo Chen <[email protected]>; Aijun Wang
> <[email protected]>
> *Subject:* RE: Do you want to be co-author of using Flex Algo to
> advertise the 5G edge computing associated metrics?
> Peter,
> Thanks for the comments. Attached 03 version addressed your comments.
> Resolution to your comments are inserted below:
> Thank you. << File: draft-dunbar-lsr-5g-edge-compute-03.docx >>
> -----Original Message-----
> From: Peter Psenak <[email protected]>
> Sent: Tuesday, November 9, 2021 4:32 AM
> To: Linda Dunbar <[email protected]>
> Cc: Huaimo Chen <[email protected]>; Aijun Wang
> <[email protected]>
> Subject: Re: Do you want to be co-author of using Flex Algo to advertise
> the 5G edge computing associated metrics?
> Linda,
> On 08/11/2021 17:48, Linda Dunbar wrote:
>> Peter,
>>
>> We have updated the draft per your suggestion.
> not quite yet, here are my comments.
> Section 4:
> 4. FAD sub-TLV for Constrained SPF with Site Cost
> We do not need any of that.
> [Linda] As of now three types of Metric-Types can be used: 0 (IGP
> Metric); 1 (min Unidirectional Link Delay); and 2 (TE). For a ANYCAST
> prefix that needs to incorporate Capacity
> Index/LoadIndex/PreferenceIndex into the constrained SPF computation,
> which one should be used if not adding a new "Metric-Type"?
> ----
> 4.1. New Flags added to FAD Flags Sub-TLV
> why do we need two behaviors? I would think one would be sufficient. We
> also need more details about how these flags are used. I can help with
> that once we agree on the rest.
> [Linda] Only one behavior is used for a given prefix. If a prefix A
> uses the “Site-Cost” as tiebreaker, then the T-flag needs to be set. If
> another prefix B uses “Site-Cost” metrics as additional metric for the
> Calc-Type indicated, another flag needs to be set. Since FAD Flag value
> is a bit map, how to express this scenario if not having multiple flags?
> --------
> 5.1. OSPFv3 LSA to Carry the Aggregated Cost
> we do not need any new LSA. All we need is a new sub-TLV for:
> E-Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and
> E-Type-7-LSA
> [Linda] There is no extension needed to carry the aggregated cost. This
> section is to illustrate how to carry the aggregated cost using the
> existing Sub-TLVs. I remove the illustration figure as it can make
> people feel a new sub-TLV is added.
> Q: is E-Intra-Area-Prefix-LSA same as the Inter-Area-Prefix-LSAs
> specified in the 4.4.3.4. of RFC5340?
> ----
> 5.2. OSPFv2 LSA to Carry the Aggregated Cost
> we do not need any new LSA. All we need is a new sub-TLV of the OSPF
> Extended Prefix TLV described in [RFC7684]
> [Linda] There is no extension needed. I add a sentence to emphasize this.
> /There is no extension needed to advertise the aggregated cost for EC
> servers using IPv4. The aggregated cost can be encoded in the “Metric”
> field of the Stub Link LSA [Link type =3] specified by Section 12.4 of
> the [RFC2328]./
> ----
> 5.3. AppMetaData Sub-TLV in OSPF
> I don't see why we need it. This data should be used at the egress
> router and does not need to be flooded.
> [Linda] As stated in the Solution Overview, there are two types of the
> “site-cost”: a) detailed (LoadIndex/CapacityIndex/PreferenceIndex)
> metrics might be needed by some deployments where the some routers in
> the IGP domain, such as the routers adjacent to the 5G UFP, need to do
> more analysis; or the computing of the aggregated cost needs historic
> data as reference. For example, Load Index is computed as current load
> in comparing with the last 7 day average.
> ----
> 6.1. Aggregated Cost Advertisement in IS-IS
> we just need a simple TLV that carries the extra metric:
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [Linda] I see you use 32 bits to carry the Value, my 02 version only
> used 16 bits. Yours is better. Changed to your version.
> ----
> 6.2. AppMetaData Advertisement in IS-IS
> same comment as for OSPF, why do we need this to be flooded?
> [Linda] Same comment.
> ------------
> 7. IP Layer App-Metrics (AppMetaData) SubSub-TLVs
> same here, why do we need to flood this?
> [Linda] Same reason as explained for 5.3 above.
>> Since the revised draft is primarily structured based on your suggestion,
>> can we list you as co-author?
> maybe once the content is what I believe it should be.
> thanks,
> Peter
>> See the attached draft and the presentation to LSR on Thurs.
>>
>> Thank you very much,
>>
>> Linda
>>
>> -----Original Message-----
>> From: Peter Psenak <[email protected] <mailto:[email protected]>>
>> Sent: Monday, November 8, 2021 4:03 AM
>> To: Linda Dunbar <[email protected]
>> <mailto:[email protected]>>;
> [email protected] <mailto:[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 08/11/2021 03:19, Linda Dunbar wrote:
>>> Peter,
>>> Is the following the correct summary of what you said?
>>> /- //the egress edge router (A-ER) with the EC Servers directly
>>> attached //can//advertise the "Site-Cost" via IP prefix reachability
>>> TLV associated with the (anycast) prefix/
>>> /- //using Flexible algorithms to advertise the desired constrained
>>> SPF computation methods, so that constrained IGP path can be computed
>>> as desired./
>>
>> yes, that's the idea.
>>
>> You need to add a bit in the FADF Sub-TLV to enforce the usage of the new
>> "Site-Cost" and define the behavior for it.
>>
>> thanks,
>> Peter
>>
>>
>>
>>
>>
>>> Thank you,
>>> Linda
>>> -----Original Message-----
>>> From: Peter Psenak <[email protected] <mailto:[email protected]>>
>>> Sent: Friday, November 5, 2021 10:49 AM
>>> To: Linda Dunbar <[email protected]
>>> <mailto:[email protected]>>;
> [email protected] <mailto:[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 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] <mailto:[email protected]
>>>> <mailto:[email protected]
> <mailto:[email protected]>>>
>>>> Sent: Friday, November 5, 2021 4:43 AM
>>>> To: Linda Dunbar <[email protected]
>>>> <mailto:[email protected]>>;
>>> [email protected] <mailto:[email protected]> <mailto:[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%2Fdata
>>>>
>>>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-18%23section-
>>>>
>>>> 4&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cc14fae9bf42e4fc2a1
>>>>
>>>> 6408d9a073bf22%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6377172412
>>>>
>>>> 70768557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>>
>>>> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=naTIhgLANNDBD5BEgnjWQhG
>>>> o8NcXDV8MISqoq99igFE%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]
>>>>> <mailto:[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]> <mailto:[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]>
> <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%2F
>>>>>>> d
>>>>>>> a
>>>>>>> tatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&
>>>>>>> ;
>>>>>>> d
>>>>>>> ata=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb88dcb6627dd45adf57a0
>>>>>>> 8
>>>>>>> d
>>>>>>> 9a040a148%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63771702174
>>>>>>> 2
>>>>>>> 3
>>>>>>> 66778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
>>>>>>> L
>>>>>>> C
>>>>>>> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d8aPiK9HO1hM9pFm9r6C
>>>>>>> 5
>>>>>>> V
>>>>>>> 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
>>>>>>>
>>
>>
--- End Message ---
