Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

From: Linda Dunbar <[email-masked]>
Date: Fri, 7 Jan 2022 19:29:22 +0000

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In a nutshell, the proposed solution

  *   advertises the "Site-Cost" via IP prefix reachability TLV associated with the (anycast) prefix
The  Site-Cost is the aggregated cost associated with an Edge Compute (EC) server (i.e., ANYCAST prefix), computed based on the IP layer related metrics for the prefix, such as Load Measurement, the Capacity Index, the Preference Index, and other constraints by a consistent algorithm across all egress routers to which the EC servers are attached.

  *   Uses a Flag in the Flexible Algorithm TLV to indicate that  "site-cost" needs to be included for the constrained SPF to reach the Prefix

Any feedbacks? Or suggestions?

Thank you very much
Linda

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 15:48:19 +0000

Linda –

I believe the most valuable feedback you received during your presentation at IETF 112 is that using IGPs likely will not meet the deployment requirements.
In particular, persistence of a given client session with a given application server is likely a requirement which will not be achieved using an IGP based solution.
Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows.

I suggest you start with a clean slate – focus on defining what all the requirements are without regard to what mechanism/protocol might be used – and then think about defining a solution which meets these requirements.
I think you will end up NOT using routing protocols at all.

On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6 ) is – to put it bluntly – a mess! 😊
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV.

   Les

From: Lsr <[email-masked]> On Behalf Of Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: [email-masked]
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

LSR experts,

  *   advertises the “Site-Cost” via IP prefix reachability TLV associated with the (anycast) prefix
The  Site-Cost is the aggregated cost associated with an Edge Compute (EC) server (i.e., ANYCAST prefix), computed based on the IP layer related metrics for the prefix, such as Load Measurement, the Capacity Index, the Preference Index, and other constraints by a consistent algorithm across all egress routers to which the EC servers are attached.

  *   Uses a Flag in the Flexible Algorithm TLV to indicate that  “site-cost” needs to be included for the constrained SPF to reach the Prefix

Thank you very much
Linda

---

From: Aijun Wang <[email-masked]>
Date: Tue, 11 Jan 2022 01:05:24 +0800

Hi, Les:

Aijun Wang
China Telecom

> On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> 
> Linda –
>  
[WAJ] The main aim of draft is to how assist the router to select the most appropriate application servers, with regards to the metrics that is not limited to the link cost.
> Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows.

[WAJ] These metrics are associated with the links that doesn’t participate in the IGP, that is, they are the characteristics of the “Stub-Link”, then only the application that utilize such information will be influenced, or optimized.

> I think you will end up NOT using routing protocols at all

[WAJ] Selecting the most appropriate/optimized application server should base on the topology information which is routing protocol related.
> And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV.

[WAJ] Actually, the most appropriate place to convey such information is via the Stub-Link TLV/Sub-TLV that defined in https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02

> advertises the “Site-Cost” via IP prefix reachability TLV associated with the (anycast) prefix
> Uses a Flag in the Flexible Algorithm TLV to indicate that  “site-cost” needs to be included for the constrained SPF to reach the Prefix
>  
>  
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 12:19:48 -0800

> On Jan 10, 2022, at 9:05 AM, Aijun Wang <[email-masked]> wrote:
> 

Just because some mechanism wants to use toplogy information does NOT imply that it should be part of the routing protocol.

In this case, load balancing should be an independent mechanism.  If it wants to peek into the LSDB, that would be perfectly acceptable, IMHO.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 20:55:11 +0000

Aijun –

Top posting here.

I think what is desired is load balancing at the application layer – coupled with persistence of a given flow (AKA client-server connection). You aren’t going to achieve that by dynamically adjusting IGP costs.
And you are likely to get oscillation – which is undesirable.

As regards the relationship between draft-dunbar-lsr-5g-edge-compute and draft-wang-lsr-stub-link-attributes, I noted that in my reading but chose not to discuss it as my concerns with each draft are more fundamental and I did not want to distract.
But since you mention this, draft-dunbar-lsr-5g-edge-compute is proposing to advertise new prefix related information.
draft-wang-lsr-stub-link-attributes is proposing to advertise new link related information.
This difference matters to me – though it seems it does not to you.
One reason why we will never agree about this. 😊

As regards the IS-IS encoding, please look at the equivalent proposed OSPF encoding in the previous section and ask yourself why they are different. 😊

   Les

From: Lsr <[email-masked]> On Behalf Of Aijun Wang
Sent: Monday, January 10, 2022 9:05 AM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi, Les:
Aijun Wang
China Telecom

On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>> wrote:

Linda –

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

LSR experts,

Thank you very much
Linda
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 11 Jan 2022 14:39:18 +0800

Hi, Les:

From: Les Ginsberg (ginsberg) <[email-masked]> 
Sent: Tuesday, January 11, 2022 4:55 AM
To: Aijun Wang <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Aijun –

Top posting here.

[WAJ] The IGP costs that related to the application layer is at the stub end of the link. It is not the transit link that other pairs of services will also use. \

Then adjust such costs on demand doesn’t influence any transit traffic, the oscillation that you are worrying will not happen.

[WAJ] Actually, I prefer to advertise such information with the link, not the prefixes.  The application prefixes should also be the attributes of the link(specially, stub link). This is the consistent way.

[WAJ] I think you can refer to https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7.  
In this section, we have illustrate that “It would be better if the aggregated cost could be advertised (in) the same way, regardless of OSPFv2, OSPFv3, or ISIS.“

   Les

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Aijun Wang
Sent: Monday, January 10, 2022 9:05 AM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked] <mailto:ginsberg=[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Linda Dunbar <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi, Les:

Aijun Wang

China Telecom

On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) <ginsberg=[email-masked] <mailto:ginsberg=[email-masked]> > wrote:

Linda –

 

 

   Les

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

LSR experts, 

-          advertises the “Site-Cost” via IP prefix reachability TLV associated with the (anycast) prefix

-          Uses a Flag in the Flexible Algorithm TLV to indicate that  “site-cost” needs to be included for the constrained SPF to reach the Prefix

Thank you very much

Linda

_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 11 Jan 2022 14:45:30 +0800

Hi, Tony:

From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 4:20 AM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; lsr
<[email-masked]>; Linda Dunbar <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised
draft-dunbar-lsr-5g-edge-compute

On Jan 10, 2022, at 9:05 AM, Aijun Wang <[email-masked]
<mailto:[email-masked]> > wrote:

[WAJ] Selecting the most appropriate/optimized application server should
base on the topology information which is routing protocol related.

Just because some mechanism wants to use toplogy information does NOT imply
that it should be part of the routing protocol.

In this case, load balancing should be an independent mechanism.  If it
wants to peek into the LSDB, that would be perfectly acceptable, IMHO.

[WAJ] Current LSDB doesn't include the aggregated cost that can be used to
select the optimal application server.

If they are separated, the router should do the SPF calculation twice. Using
the constrained SPF/flexalgo to achieve such optimal goal is certainly
better than calculate twice.

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 22:49:36 -0800

Hi Aijun,

> [WAJ] Current LSDB doesn’t include the aggregated cost that can be used to select the optimal application server.

So please feel free to add whatever costs you want to circulate to whatever other load balancing protocol you come up with.

> If they are separated, the router should do the SPF calculation twice. Using the constrained SPF/flexalgo to achieve such optimal goal is certainly better than calculate twice.

I don’t understand or believe this.  We have been running multiple SPFs since the early days of TE. This is Not A Big Deal.

Tony

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jan 2022 03:46:45 +0000

Les,

Starting with a clean slate:

Problem:
Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS.

From Underlay IP network perspective, connecting applications with instances instantiated at multiple locations is like having multiple Egress routers towards the same destination (ANYCAST).
For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost.

Suggested solution:
Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the Egress router) is suggested by Peter Psenak (through the offline discussion prior to the IETF 112, see the attached email thread)

There is only one sentence in the Section 6, which is per Peter’s suggestion:
“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”

Why do you say it is a “mess”?   I felt your words are more like personal attack than giving a constructive suggestion.

Linda

From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar <[email-masked]>; [email-masked]
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda –

On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265066903950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZJY0ugnVuhUmc6o%2Bje2FDhnAcSo2tvhxYn4c3YFxcFM%3D&reserved=0> ) is – to put it bluntly – a mess! 😊
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV.

   Les

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<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%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265067060188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GXrGqw4CNac27y1cIY9dC68j3%2FKx1x5kCzPtoPMCUUs%3D&reserved=0>

Thank you very much
Linda

Subject: Re: comparing using E-intra/inter-area-prefix LSA [RFC8362] with the original Intra/Inter-area-prefix LSA [RFC5340]
From: Peter Psenak <[email-masked]>
To: Linda Dunbar <[email-masked]>
Cc: Huaimo Chen <[email-masked]>, Aijun Wang <[email-masked]>
Date: Wed, 10 Nov 2021 14:12:20 +0000

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-masked]>
> *Cc:* Huaimo Chen <[email-masked]>; Aijun Wang 
> <[email-masked]>
> *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-masked]>
> Sent: Tuesday, November 9, 2021 4:32 AM
> To: Linda Dunbar <[email-masked]>
> Cc: Huaimo Chen <[email-masked]>; Aijun Wang 
> <[email-masked]>
> 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-masked] <mailto:[email-masked]>>
>> Sent: Monday, November 8, 2021 4:03 AM
>> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
>> 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-masked] <mailto:[email-masked]>>
>>> Sent: Friday, November 5, 2021 10:49 AM
>>> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
>>> 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-masked] <mailto:[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>>>> Sent: Friday, November 5, 2021 4:43 AM
>>>> To: Linda Dunbar <[email-masked]
>>>> <mailto:[email-masked]>>;
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>> 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&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cc14fae9bf42e4fc2a1
>>>>
>>>> 6408d9a073bf22%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6377172412
>>>>
>>>> 70768557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>>
>>>> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=naTIhgLANNDBD5BEgnjWQhG
>>>> o8NcXDV8MISqoq99igFE%3D&amp;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-masked] <mailto:[email-masked]
>>>>> <mailto:[email-masked]
>>> <mailto:[email-masked]>>>
>>>>> Sent: Thursday, November 4, 2021 1:16 PM
>>>>> To: Linda Dunbar <[email-masked]
>>>>> <mailto:[email-masked]>>;
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 
> <mailto:[email-masked]>
>>>>> 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-masked] <mailto:[email-masked]
>>>>>> <mailto:[email-masked]
>>>> <mailto:[email-masked]>>>
>>>>>> Sent: Wednesday, November 3, 2021 7:43 AM
>>>>>> To: Linda Dunbar <[email-masked]
>>>>>> <mailto:[email-masked]>>;
>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 
> <mailto:[email-masked]>
>>> <mailto:[email-masked]>
>>>>>> 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&amp
>>>>>>> ;
>>>>>>> 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&amp;sdata=d8aPiK9HO1hM9pFm9r6C
>>>>>>> 5
>>>>>>> V
>>>>>>> LprerWSVEpJUhVvLvZPPM%3D&amp;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
>>>>>>>
>> 
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 12 Jan 2022 05:14:29 +0000

Linda -

From: Linda Dunbar <[email-masked]>
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

Problem:

[LES:] What I am saying is that you need to do load balancing at the Application Layer – not at Layer 3.
IGPs can provide you with paths to the set of Application servers that share the same anycast address – but dynamically manipulating the IGP metrics (even this new metric you propose) – will give you oscillation – not application server load balancing.

Suggested solution:

[LES:] Apologies if you were offended – I did put a smiley in to try give it a light touch – but I should know better than to be so flippant in this context.
My point is that in what is indeed a very small section there are multiple errors:

  *   The TLVs mentioned are not correct
  *   The diagram with the proposed sub-TLV encoding incorrectly includes the prefix. The prefix is already present in the parent TLV – it should not be present in the sub-TLV. You have this correct in Section 5 for OSPF.

But these points can be ignored because I believe using the IGPs isn’t the right solution and so we won’t need these new sub-TLVs anyway.

I don’t know what comment from Peter you are referring to – but if he mentioned TLVs 128/130 I will take that up with him – he knows better. 😊
I do recall that in an earlier version of the draft you were proposing to advertise the new metric as part of a link advertisement (TLV 22) – and he was quite correct in directing you to use Prefix Reachability advertisements (like TLV 135).

But please focus on looking at a non-IGP solution – that is what you need to do IMO.

   Les

Linda

From: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda –

   Les

LSR experts,

Thank you very much
Linda

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 12 Jan 2022 15:44:01 +0800

Hi, Les:

IGP is now considering the dynamic metric(for example, the delay metric within flexalgo), not only the static metic.

The proposed “AggCost” is also one kind of dynamic metric. It can assist the new clients to avoid the already heavy-burden application server. 

With the “Flow Affinity to an ANYCAST server” capabilities that mentioned in https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-13, the oscillation phenomena can be mitigated for the existing client/server flow.

Or else, all the dynamic cost can’t be used within the IGP.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, January 12, 2022 1:14 PM
To: Linda Dunbar <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda -

From: Linda Dunbar <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les, 

Problem: 

 

Suggested solution:

·       The TLVs mentioned are not correct

·       The diagram with the proposed sub-TLV encoding incorrectly includes the prefix. The prefix is already present in the parent TLV – it should not be present in the sub-TLV. You have this correct in Section 5 for OSPF.

   Les

 

Linda

From: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda –

On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265066903950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZJY0ugnVuhUmc6o%2Bje2FDhnAcSo2tvhxYn4c3YFxcFM%3D&reserved=0>  ) is – to put it bluntly – a mess! 😊

   Les

LSR experts, 

https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ <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%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265067060188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GXrGqw4CNac27y1cIY9dC68j3%2FKx1x5kCzPtoPMCUUs%3D&reserved=0> 

 

Thank you very much

Linda

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Jan 2022 12:06:56 +0100

Hi Aijun & Linda,

I think based on your below comment you are putting an equal sign between
flexible network transport topologies vs flexible application driven
transport topologies.

To the best of my understanding the intention of flexalgo is the former and
never was intended to take on the latter.

I would be personally very hesitant to load any user application data onto
IGPs for lots of scale and stability reasons. It seems much wiser to keep
application distribution as an overlay and never inject any state into
transport. As we all know encapsulation at the application layer
effectively and in line rate helps with such clean hierarchy.

Kind regards,
Robert

On Wed, Jan 12, 2022 at 8:44 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Les:
>
>
>
> IGP is now considering the dynamic metric(for example, the delay metric
> within flexalgo), not only the static metic.
>
> The proposed “AggCost” is also one kind of dynamic metric. It can assist
> the new clients to avoid the already heavy-burden application server.
>
> With the “Flow Affinity to an ANYCAST server” capabilities that mentioned
> in
> https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-13,
> the oscillation phenomena can be mitigated for the existing client/server
> flow.
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Wednesday, January 12, 2022 1:14 PM
> *To:* Linda Dunbar <[email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] Seeking feedback to the revised
> *From:* Linda Dunbar <[email-masked]>
> *Sent:* Tuesday, January 11, 2022 7:47 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
> *Subject:* RE: Seeking feedback to the revised
> *Problem: *
> Most applications are instantiated at multiple locations to achieve
> optimal performance. Traditional shortest path to reach one single
> destination is making load balancers the bottleneck, or pushing the traffic
> management responsibility to DNS.
>
>
>
> From Underlay IP network perspective, connecting applications with
> instances instantiated at multiple locations is like having multiple Egress
> routers towards the same destination (ANYCAST).
>
> For example, to reach an application B instantiated at B1, B2, B3, which
> corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path
> Computation need to include both routing distance and the resources
> attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple
> Path) should include both the routing distances and the resource cost.
>
>
>
> *[LES:] What I am saying is that you need to do load balancing at the
> Application Layer – not at Layer 3.*
>
> *IGPs can provide you with paths to the set of Application servers that
> share the same anycast address – but dynamically manipulating the IGP
> metrics (even this new metric you propose) – will give you oscillation –
> not application server load balancing.*
>
>
>
>
>
> *Suggested solution:*
>
> Using TLV 128 and 130 to carry the “aggregated site cost” (associated t
> the Egress router) is suggested by Peter Psenak (through the offline
> discussion prior to the IETF 112, see the attached email thread)
>
>
>
> *“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”*
>
>
>
> Why do you say it is a “mess”?   I felt your words are more like personal
> attack than giving a constructive suggestion.
>
>
>
> *[LES:] Apologies if you were offended – I did put a smiley in to try give
> it a light touch – but I should know better than to be so flippant in this
> context.*
>
> *My point is that in what is indeed a very small section there are
> multiple errors:*
>
>
>
> ·       *The TLVs mentioned are not correct*
>
> ·       *The diagram with the proposed sub-TLV encoding incorrectly
> includes the prefix. The prefix is already present in the parent TLV – it
> should not be present in the sub-TLV. You have this correct in Section 5
> for OSPF.*
>
>
>
> *But these points can be ignored because I believe using the IGPs isn’t
> the right solution and so we won’t need these new sub-TLVs anyway.*
>
>
>
> *I don’t know what comment from Peter you are referring to – but if he
> mentioned TLVs 128/130 I will take that up with him – he knows better. *
> *😊*
>
> *I do recall that in an earlier version of the draft you were proposing to
> advertise the new metric as part of a link advertisement (TLV 22) – and he
> was quite correct in directing you to use Prefix Reachability
> advertisements (like TLV 135).*
>
>
>
> *But please focus on looking at a non-IGP solution – that is what you need
> to do IMO.*
>
>
>
> *   Les*
>
>
>
>
>
>
>
>
>
> Linda
>
>
>
>
>
>
>
> *From:* Les Ginsberg (ginsberg) <[email-masked]>
> *Sent:* Monday, January 10, 2022 9:48 AM
> *To:* Linda Dunbar <[email-masked]>; [email-masked]
> *Subject:* RE: Seeking feedback to the revised
> I believe the most valuable feedback you received during your presentation
> at IETF 112 is that using IGPs likely will not meet the deployment
> requirements.
>
> In particular, persistence of a given client session with a given
> application server is likely a requirement which will not be achieved using
> an IGP based solution.
>
> I suggest you start with a clean slate – focus on defining what all the
> requirements are without regard to what mechanism/protocol might be used –
> and then think about defining a solution which meets these requirements.
>
> On a more mundane note, the section describing the new IS-IS advertisement
> (
> https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265066903950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZJY0ugnVuhUmc6o%2Bje2FDhnAcSo2tvhxYn4c3YFxcFM%3D&reserved=0>
> ) is – to put it bluntly – a mess! 😊
>
> And the encoding diagram shows a “prefix” being advertised in the new
> sub-TLV when it should not. The prefix has already been advertised in the
> parent TLV.
>
>
>
>    Les
>
>
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Linda Dunbar
> *Sent:* Friday, January 7, 2022 11:29 AM
> *To:* [email-masked]
> *Subject:* [Lsr] Seeking feedback to the revised
> <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%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265067060188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GXrGqw4CNac27y1cIY9dC68j3%2FKx1x5kCzPtoPMCUUs%3D&reserved=0>
>
>
>
> The  Site-Cost is the aggregated cost associated with an Edge Compute (EC)
> server (i.e., ANYCAST prefix), computed based on the IP layer related
> metrics for the prefix, such as Load Measurement, the Capacity Index, the
> Preference Index, and other constraints by a consistent algorithm across
> all egress routers to which the EC servers are attached.
>
>
>
> -          Uses a Flag in the Flexible Algorithm TLV to indicate that
> “site-cost” needs to be included for the constrained SPF to reach the Prefix
>
>
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 Jan 2022 12:25:29 +0000

Speaking as WG member:

From a 10,000 foot view, flex algorithm is the right place to introduce new metrics as it assures uniform treatment of these metrics within the IGP domain (only routers understanding the metrics are included in the SPT).

What is being debated here is the issue of whether 5G application load should be used by IGPs for route computation.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Wednesday, January 12, 2022 at 6:07 AM
To: Aijun Wang <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>, lsr <[email-masked]>, Linda Dunbar <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Aijun & Linda,

I think based on your below comment you are putting an equal sign between flexible network transport topologies vs flexible application driven transport topologies.

To the best of my understanding the intention of flexalgo is the former and never was intended to take on the latter.

I would be personally very hesitant to load any user application data onto IGPs for lots of scale and stability reasons. It seems much wiser to keep application distribution as an overlay and never inject any state into transport. As we all know encapsulation at the application layer effectively and in line rate helps with such clean hierarchy.

Kind regards,
Robert

On Wed, Jan 12, 2022 at 8:44 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Les:

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, January 12, 2022 1:14 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda -

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

Problem:

Suggested solution:

•       The TLVs mentioned are not correct
•       The diagram with the proposed sub-TLV encoding incorrectly includes the prefix. The prefix is already present in the parent TLV – it should not be present in the sub-TLV. You have this correct in Section 5 for OSPF.

   Les

Linda

Linda –

   Les

LSR experts,

Thank you very much
Linda

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Jan 2022 13:32:01 +0100

Good luck keeping the IGP stable at scale once you allow any external
compute node to inject metrics into it.

And if you do I do not see why one should be allowed and the other not. At
least that is not for LSR WG to judge that IMHO.

Cheers,
R.

On Wed, Jan 12, 2022 at 1:25 PM Acee Lindem (acee) <[email-masked]> wrote:

> Speaking as WG member:
>
>
>
> From a 10,000 foot view, flex algorithm is the right place to introduce
> new metrics as it assures uniform treatment of these metrics within the IGP
> domain (only routers understanding the metrics are included in the SPT).
>
>
>
> What is being debated here is the issue of whether 5G application load
> should be used by IGPs for route computation.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Wednesday, January 12, 2022 at 6:07 AM
> *To: *Aijun Wang <[email-masked]>
> *Cc: *"Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>,
> lsr <[email-masked]>, Linda Dunbar <[email-masked]>
> *Subject: *Re: [Lsr] Seeking feedback to the revised
> To the best of my understanding the intention of flexalgo is the former
> and never was intended to take on the latter.
>
>
>
> *“**Aggregated Cost appended to the IP Reachability TLV: 128, 130, or
> 135.”*
>
>
>
> -          Uses a Flag in the Flexible Algorithm TLV to indicate that  “
> site-cost” needs to be included for the constrained SPF to reach the
> Prefix
>
>
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jan 2022 16:40:38 +0000

Les,

With regard to what You said about “needing to do load balancing at the Application Layer – not at Layer 3”:

Answer: Most deployments could have 10s, 100s, or even thousands of Application Layer load balancers. The proposed solution is to utilize network layer and resource capability information to balance the distribution of traffic among the Application Load balancers. The documents stated that the distribution behind the load balancers are out of the scope.

With regard to what you said about “oscillation”:

Answer: The rate of capability index changes is in terms of hours or days, more like the link failure that IGP is intended to distribute. Therefore, the oscillation is not the issue.

With regard to what you said about “incorrect TLV”

Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; and TLV 135 is for Extended IP reachability.
Do you mean another TLV should be used instead of TLV 128/130/135?

For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to be consistent with OSPF:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCostSubTLV  | Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              AggCost to the App Server                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 2: Aggregated cost Advertisement in IS-IS

Any other issues?

Linda

From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Tuesday, January 11, 2022 11:14 PM
To: Linda Dunbar <[email-masked]>; [email-masked]
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda -

Les,

Problem:

Suggested solution:

   Les

Linda

Linda –

On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4e790860cb7e40ff9cac08d9d58a7534%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637775612935452545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W9%2FRpPfP4JXon%2F5kAftUxpjZjQzjgHkephRs5StyCqE%3D&reserved=0> ) is – to put it bluntly – a mess! 😊
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV.

   Les

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<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%7C4e790860cb7e40ff9cac08d9d58a7534%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637775612935452545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C02rBS0oFyNztREkN2lMaCKTL%2BUfOJIZ2zHJl%2FFA2Cw%3D&reserved=0>

Thank you very much
Linda

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 12 Jan 2022 17:20:48 +0000

Linda –

Please see inline.

From: Linda Dunbar <[email-masked]>
Sent: Wednesday, January 12, 2022 8:41 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

[LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis.

I also don’t understand why you mention “link failure” when the discussion here is about load balancing across multiple Application Servers even when the underlying network is stable.

Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; and TLV 135 is for Extended IP reachability.
Do you mean another TLV should be used instead of TLV 128/130/135?
[LES:] You cannot put sub-TLVs into TLVs 128/130. These TLVs are “old style” TLVs which do not support sub-TLVs of any kind.
The following TLVs would be relevant:
Extended IP reachability (135)
MT IP Reach (235)
IPv6 IP Reach (236)
MT IPv6 IP Reach (237)

Please see https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability

[LES:] Great – thanx.

   Les

Any other issues?

Linda

Linda -

Les,

Problem:

Suggested solution:

   Les

Linda

Linda –

   Les

LSR experts,

Thank you very much
Linda

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jan 2022 18:48:15 +0000

Les,

Please see my questions to your suggestions inserted below:

Linda

From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Wednesday, January 12, 2022 11:21 AM
To: Linda Dunbar <[email-masked]>; [email-masked]
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda –

Please see inline.

Les,

[Linda] Most vendors do support flow based ECMP, with Shortest Path computed by attributes advertised by IGP.

[Linda] I meant to say topology changes caused by “Link failure” or others.

[Linda] Thank you for the suggestion. Are Extended IP reachability (135) and MT IP Reachability (235) equally good?

Thank you.

Linda

[LES:] Great – thanx.

   Les

Any other issues?

Linda

Linda -

Les,

Problem:

Suggested solution:

   Les

Linda

Linda –

On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C545c905210d244329d3408d9d5efe32f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776048578938040%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Vz82mTcdqlfor2G8GASWf8c%2F%2B0S0YD8AjtKow3tJGFE%3D&reserved=0> ) is – to put it bluntly – a mess! 😊
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV.

   Les

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<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%7C545c905210d244329d3408d9d5efe32f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776048578938040%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fj5FPoA%2BI%2Brcx2gEvfRMvZoInUrOpM8EVGLmluCktGo%3D&reserved=0>

Thank you very much
Linda

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Jan 2022 19:59:34 +0100

Hi Linda,

*[LES:] It is my opinion that what you propose will not achieve your goals
> – in part because IGPs only influence forwarding on a per packet basis –
> not a per flow/connection basis.*
>
> *[Linda] Most vendors do support flow based ECMP, with Shortest Path
> computed by attributes advertised by IGP.*
>

I am with Les here. ECMP has nothing to do with his point.

Draft says:

*When those multiple server instances share one IP address (ANYCAST), the
transient network and load conditions can be incorporated in selecting an
optimal path among server instances for UEs.*

So if we apply any new metric to indicate load of a single anycast address
how is this going to help anything ?

You would need a mechanism where the network is smart and say per src-dst
tuple or more spreads the traffic. IGP does not play that game today I am
afraid.

Thx a lot,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jan 2022 19:18:56 +0000

Robert,

Please see inline in green:

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, January 12, 2022 1:00 PM
To: Linda Dunbar <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda,

[Linda] Les said that “IGP only influence forwarding on a per packet basis”.  I am saying that vendors supporting “forwarding per flow” with equal cost computed by IGP implies  that forwarding on modern routers are no longer purely per packet basis.

Draft says:

When those multiple server instances share one IP address (ANYCAST), the transient network and load conditions can be incorporated in selecting an optimal path among server instances for UEs.

So if we apply any new metric to indicate load of a single anycast address how is this going to help anything ?

[Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths with the same routing distance.

You would need a mechanism where the network is smart and say per src-dst tuple or more spreads the traffic. IGP does not play that game today I am afraid.
[Linda] There is one SRC and multiple paths to one DST. IGP has been used for the Multi-path computation for a long time.

Thank you, Linda

Thx a lot,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Jan 2022 20:23:04 +0100

Linda,

> IGP has been used for the Multi-path computation for a long time

IGP can and does ECMP well. Moreover, injecting metric of anycast server
destination plays no role in it as all paths would inherit that external to
the IGP cost.

Unequal cost load balancing or intelligent traffic spread has always been
done at the application layer *for example MPLS*

Thx a lot,
R.

On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <[email-masked]>
wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, January 12, 2022 1:00 PM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
> [Linda] Les said that “IGP only influence forwarding on a per packet
> basis”.  I am saying that vendors supporting “forwarding per flow” with
> equal cost computed by IGP implies  that forwarding on modern routers are
> no longer purely per packet basis.
>
>
>
>
>
> Draft says:
>
>
>
> [Linda] There is one SRC and multiple paths to one DST. IGP has been used
> for the Multi-path computation for a long time.
>
>
>
> Thank you, Linda
>
>
>
> Thx a lot,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 12 Jan 2022 20:11:08 +0000

Linda –

Inline. Look for LES2:

From: Linda Dunbar <[email-masked]>
Sent: Wednesday, January 12, 2022 10:48 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

Linda

Linda –

Please see inline.

Les,

[LES2:] Robert has already made the relevant points.

Yes – routers today support maintaining flows, but it is done by applying policy to select from a set of nexthops provided by the routing protocol. This allows you to maintain flows and to load balance.

You want to build the policy into the IGP metric, but this provides no way to maintain a flow.

[LES2:] I am only saying the behavior you want has nothing to do with topology changes. Of course, if an Application Server goes down/becomes unreachable forwarding state will change – but that isn’t relevant to the new behavior (load balancing based on Application server load) that you want.

[LES2:]  TLVs 135 and 236 work for MTID #0.
TLVs 235 and 237 work for non-zero MTIDs.

Generally, any sub-TLV which is defined can be used in either TLV. Which TLV you actually use depends on the MTID used in your deployment.

   Les

Thank you.

Linda

[LES:] Great – thanx.

   Les

Any other issues?

Linda

Linda -

Les,

Problem:

Suggested solution:

   Les

Linda

Linda –

   Les

LSR experts,

Thank you very much
Linda

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jan 2022 20:35:58 +0000

Robert,

IGP cost typically is determined by comparing the preference, then the weight, then the metric, and finally the metric2 of the two resolving routes.
The draft is to add another site-cost metric to the IGP computation.
Using MPLS is too heavy.

Linda

Sent: Wednesday, January 12, 2022 1:23 PM

Linda,

> IGP has been used for the Multi-path computation for a long time

IGP can and does ECMP well. Moreover, injecting metric of anycast server destination plays no role in it as all paths would inherit that external to the IGP cost.

Unequal cost load balancing or intelligent traffic spread has always been done at the application layer *for example MPLS*

Thx a lot,
R.

On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 12, 2022 1:00 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Jan 2022 21:39:19 +0100

> IGP cost typically is determined by comparing the preference, then the
weight,
> then the metric, and finally the metric2 of the two resolving routes.

Are we sure we are on the same page here ?

Are you describing some new yet to be defined algorithm or Dijkstra ?

Thx,
R.

On Wed, Jan 12, 2022 at 9:36 PM Linda Dunbar <[email-masked]>
wrote:

> Robert,
>
>
>
> IGP cost typically is determined by comparing the preference, then the
> weight, then the metric, and finally the metric2 of the two resolving
> routes.
>
> *Sent:* Wednesday, January 12, 2022 1:23 PM

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jan 2022 21:05:42 +0000

Still use the Dijkstra shortest path algorithm. Just the cost to the destination includes more than the routing hops.

Linda

Sent: Wednesday, January 12, 2022 2:39 PM

> IGP cost typically is determined by comparing the preference, then the weight,

Thx,
R.

On Wed, Jan 12, 2022 at 9:36 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda

Linda,

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 12 Jan 2022 20:26:06 -0500

Robert

Here are a few examples of UCMP drafts below used in core and data center
use cases.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz

There are many use cases in routing for unequal cost load balancing
capabilities.

Kind Regards

Gyan

On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk <[email-masked]> wrote:

>> *[LES:] It is my opinion that what you propose will not achieve your
>> goals – in part because IGPs only influence forwarding on a per packet
>> basis – not a per flow/connection basis.*
>>
>> So if we apply any new metric to indicate load of a single anycast
>> address how is this going to help anything ?
>>
>>
>>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 Jan 2022 03:16:51 +0000

Gyan –

The difference between ECMP and UCMP is not significant in this discussion.
I don’t want to speak for Robert, but for me his point was that IGPs can do “multipath” well – but this does not translate into managing flows.
Please see my other responses on this thread.

Thanx.

    Les

From: Gyan Mishra <[email-masked]>
Sent: Wednesday, January 12, 2022 5:26 PM
To: Robert Raszuk <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Robert

Here are a few examples of UCMP drafts below used in core and data center use cases.

There are many use cases in routing for unequal cost load balancing capabilities.

Kind Regards

Gyan

On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Linda,

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Jan 2022 01:04:55 -0500

Hi Les

Agreed.

My thoughts are that the context of the draft is based on an Anycast VIP
address of a server which is proximity based load balancing and not
necessarily ECMP/UCMP and only if the proximity is the same for multiple
paths to the Anycast VIP would there be a ECMP/UCMP possibility.

Let’s say if it’s proximity based and one path is preferred, the flow will
take that path.  So now the server you are on gets overloaded and a site
cost gets advertised in the IGP at which point the connection receives a
TCP reset and flow re-establishes on the alternate path based on the site
cost and remains there until the server goes down or  gets overloaded or a
better path comes along.

For ECMP case, ECMP has flow affinity so the flow will stay on the same
path long lived until the connection terminates.

So now in ECMP case the flow hashed to a path and maintains its affinity to
that path.  Now all of sudden the server gets overloaded and we get a
better site cost advertised.  So now the session terminates on current path
and establishes again on the Anycast VIP new path based on the site cost
advertised.

The failover I believe results in the user refreshing their browser which
is better than hanging.

As the VIP prefix is the only one that experiences reconvergence on new
path based on site cost if there is any instability with the servers that
will be reflected to the IGP Anycast prefix as well.

Is that a good or bad thing.  I think if you had to pick your poison as
here the issue Linda is trying to solve is a server issue but leveraging
the IGP to force re-convergence when the server is in a half baked state
meaning it’s busy and connections are being dropped or very slow QOE for
end user.  If you did nothing and let it ride the the user would be stuck
on a bad connection.

So this solution dynamically fixed the issue.

As far as oscillation that is not a big deal as you are in a much worse off
state connected to a dying server on its last leg as far as memory and CPU.

This solution I can see can apply to any client / server connection and not
just 5G and can be used by enterprises as well as SP for their customers to
have an drastically improved QOE.

I saw some feedback on the TLV and I think once that is all worked out I am
in favor of advancing this draft.

Kind Regards

Gyan

On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> I don’t want to speak for Robert, but for me his point was that IGPs can
> do “multipath” well – but this does not translate into managing flows.
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Wednesday, January 12, 2022 5:26 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Linda Dunbar <
> [email-masked]>; [email-masked]
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 11:45:26 +0100

Gyan,

Your below email nicely proves my point. Unequal cost load sharing is done
at the app level not IGP transport.

Thank you,
R.

On Thu, Jan 13, 2022 at 2:26 AM Gyan Mishra <[email-masked]> wrote:

>>> *When those multiple server instances share one IP address (ANYCAST),
>>> the transient network and load conditions can be incorporated in selecting
>>> an optimal path among server instances for UEs.*
>>>
>>>
>>>
>>> [Linda] The “Load” or “Aggregated Site Cost” is to differentiate
>>> multiple paths with the same routing distance.
>>>
>>>
>>>
>>>
>>>
>>> You would need a mechanism where the network is smart and say per
>>> src-dst tuple or more spreads the traffic. IGP does not play that game
>>> today I am afraid.
>>>
>>> [Linda] There is one SRC and multiple paths to one DST. IGP has been
>>> used for the Multi-path computation for a long time.
>>>
>>>
>>>
>>> Thank you, Linda
>>>
>>>
>>>
>>> Thx a lot,
>>> R.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 11:56:00 +0100

Gyan,

I see what the draft is trying to do now. /* I did not even consider this
for the reason described below. */

But what you wrote requires little correction:

"So now the server you are on gets overloaded and a site cost gets
advertised in the IGP at which point the connection receives a TCP reset"

if you *s/connection/all connections/* then you quickly realize that what
is proposed here is a disaster.

Breaking all existing flows going to one LB to suddenly timeout and all go
to the other LB(s) is never a technique any one would seriously deploy in a
production network.

Leave alone that doing that has potential to immediately overload the other
LB(s)/server(s) too.

For me the conclusion is that IGP transport level is not the proper layer
to address the requirement.

Cheers,
Robert.

On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra <[email-masked]> wrote:

> So now in ECMP case the flow hashed to a path and maintains its affinity
> to that path.  Now all of sudden the server gets overloaded and we get a
> As far as oscillation that is not a big deal as you are in a much worse
> off state connected to a dying server on its last leg as far as memory and
> CPU.
>
> This solution I can see can apply to any client / server connection and
> not just 5G and can be used by enterprises as well as SP for their
> customers to have an drastically improved QOE.
>
> I saw some feedback on the TLV and I think once that is all worked out I
> am in favor of advancing this draft.
>
> Kind Regards
>
> Gyan
>
>
> On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
>> Gyan –
>>
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 11:59:41 +0100

And just to provide a sound alternative to the objective of this work.

Please consider using Traefik - https://traefik.io/

Thx,
R.

On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk <[email-masked]> wrote:

> Leave alone that doing that has potential to immediately overload the
> other LB(s)/server(s) too.
>
>> Let’s say if it’s proximity based and one path is preferred, the flow
>> will take that path.  So now the server you are on gets overloaded and a
>> site cost gets advertised in the IGP at which point the connection receives
>> a TCP reset and flow re-establishes on the alternate path based on the site
>>> Unequal cost load balancing or intelligent traffic spread has always
>>> been done at the application layer *for example MPLS*
>>>
>>>
>>>
>>> Thx a lot,
>>>
>>> R.
>>>
>>>
>>>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 13 Jan 2022 15:23:02 +0000

Robert,

Your link to Traefik  adds more reasons why "Site index and preference" should be distributed by IGP:

  *   Site index and preferences for a cluster of micro-service instances are rarely dynamically changed. Most of those values are configured. Therefore, the oscillation is minimal.
  *   Flows among micro-services are very short. Put less requirements to flow affinity.
  *

Linda

From: Robert Raszuk <[email-masked]>
Sent: Thursday, January 13, 2022 5:00 AM
To: Gyan Mishra <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DTSgF4GOdBXmJmF18s%2BhPYpod1g2wul6z%2BY6Gi6a%2F14%3D&reserved=0>

Thx,
R.

On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */

"So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset"

if you s/connection/all connections/ then you quickly realize that what is proposed here is a disaster.

Breaking all existing flows going to one LB to suddenly timeout and all go to the other LB(s) is never a technique any one would seriously deploy in a production network.

Leave alone that doing that has potential to immediately overload the other LB(s)/server(s) too.

For me the conclusion is that IGP transport level is not the proper layer to address the requirement.

Cheers,
Robert.

On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Les

Agreed.

My thoughts are that the context of the draft is based on an Anycast VIP address of a server which is proximity based load balancing and not necessarily ECMP/UCMP and only if the proximity is the same for multiple paths to the Anycast VIP would there be a ECMP/UCMP possibility.

Let's say if it's proximity based and one path is preferred, the flow will take that path.  So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset and flow re-establishes on the alternate path based on the site cost and remains there until the server goes down or  gets overloaded or a better path comes along.

For ECMP case, ECMP has flow affinity so the flow will stay on the same path long lived until the connection terminates.

So now in ECMP case the flow hashed to a path and maintains its affinity to that path.  Now all of sudden the server gets overloaded and we get a better site cost advertised.  So now the session terminates on current path and establishes again on the Anycast VIP new path based on the site cost advertised.

The failover I believe results in the user refreshing their browser which is better than hanging.

As the VIP prefix is the only one that experiences reconvergence on new path based on site cost if there is any instability with the servers that will be reflected to the IGP Anycast prefix as well.

Is that a good or bad thing.  I think if you had to pick your poison as here the issue Linda is trying to solve is a server issue but leveraging the IGP to force re-convergence when the server is in a half baked state meaning it's busy and connections are being dropped or very slow QOE for end user.  If you did nothing and let it ride the the user would be stuck on a bad connection.

As far as oscillation that is not a big deal as you are in a much worse off state connected to a dying server on its last leg as far as memory and CPU.

This solution I can see can apply to any client / server connection and not just 5G and can be used by enterprises as well as SP for their customers to have an drastically improved QOE.

I saw some feedback on the TLV and I think once that is all worked out I am in favor of advancing this draft.

Kind Regards

Gyan

On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Gyan -

The difference between ECMP and UCMP is not significant in this discussion.
I don't want to speak for Robert, but for me his point was that IGPs can do "multipath" well - but this does not translate into managing flows.
Please see my other responses on this thread.

Thanx.

    Les

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 12, 2022 5:26 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Robert

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4UNvQ%2BYX070LVrBejcmpx86pXIzfLLnHVyPYde16Nc0%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Miu9gbzoB9tHmhoNLlO9HnlgPa%2BePOAgyDShwVzCY%2Fw%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GMZE2%2Fv0HjRkMQhwbEk9m4CwYnXFCJ9PyU%2BmuNGMEmE%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=or%2Bp8uMaRm0a2v7GcCANIy1TijsxaGArdDB3rhLplwM%3D&reserved=0>

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

[LES:] It is my opinion that what you propose will not achieve your goals - in part because IGPs only influence forwarding on a per packet basis - not a per flow/connection basis.

[Linda] Les said that "IGP only influence forwarding on a per packet basis".  I am saying that vendors supporting "forwarding per flow" with equal cost computed by IGP implies  that forwarding on modern routers are no longer purely per packet basis.

Draft says:

[Linda] The "Load" or "Aggregated Site Cost" is to differentiate multiple paths with the same routing distance.

Thank you, Linda

Thx a lot,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hu%2BxfAxyCu5YRFoKFZ9UHjDipkc79mTILkg25NnJo0g%3D&reserved=0>
--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5fxHmSsuBcJzRu6Qr9VjQA18pK0OmRfFWdtqBDQL9y0%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5fxHmSsuBcJzRu6Qr9VjQA18pK0OmRfFWdtqBDQL9y0%3D&reserved=0>

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 16:36:50 +0100

> Flows among micro-services are very short.

While that can be true - there is nowhere in the document a restriction or
even a warning that this solution is aiming for short lived flows only and
that users should be well aware about drastic nature of proposed
mechanism to their established flows.

In one of the companies I worked for average  TCP flow duration was
anywhere from 8-18 hours and it was a very drastic event for the user to
loose it in the middle of the day.  Various means where taken and applied
to protect such sessions from any form of disconnects.

I think we are shooting here with the wrong weapon to the target.

Thx,
R.

On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar <[email-masked]>
wrote:

> Robert,
>
>
>
> Your link to Traefik  adds more reasons why “Site index and preference”
> should be distributed by IGP:
>
>    - Site index and preferences for a cluster of micro-service instances
>    are rarely dynamically changed. Most of those values are configured.
>    Therefore, the oscillation is minimal.
>    - Flows among micro-services are very short. Put less requirements to
>    flow affinity.
>    -
>
>
>
> Linda
>
>
>
>
>
> *Sent:* Thursday, January 13, 2022 5:00 AM
> *To:* Gyan Mishra <[email-masked]>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DTSgF4GOdBXmJmF18s%2BhPYpod1g2wul6z%2BY6Gi6a%2F14%3D&reserved=0>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4UNvQ%2BYX070LVrBejcmpx86pXIzfLLnHVyPYde16Nc0%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Miu9gbzoB9tHmhoNLlO9HnlgPa%2BePOAgyDShwVzCY%2Fw%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GMZE2%2Fv0HjRkMQhwbEk9m4CwYnXFCJ9PyU%2BmuNGMEmE%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=or%2Bp8uMaRm0a2v7GcCANIy1TijsxaGArdDB3rhLplwM%3D&reserved=0>
>
>
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hu%2BxfAxyCu5YRFoKFZ9UHjDipkc79mTILkg25NnJo0g%3D&reserved=0>
>
> --
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5fxHmSsuBcJzRu6Qr9VjQA18pK0OmRfFWdtqBDQL9y0%3D&reserved=0>
>
> *Gyan Mishra*
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827390551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5fxHmSsuBcJzRu6Qr9VjQA18pK0OmRfFWdtqBDQL9y0%3D&reserved=0>
>
> *Gyan Mishra*
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 13 Jan 2022 15:57:32 +0000

Robert,

For your scenario of TCP flows lasting more than 8~18 hours,  multiple server instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address).  Each of those instances should have one distinct IP address.

The draft is for different scenario where application are instantiated at multiple locations behind multiple App Layer Load Balancers. They have relative short flows that can go to any App Layer Load Balancers. Multiple Load Balancers  for those applications are assigned with the same IP address. In Kubernetes, multiple load balancers for one type of microservices are assigned with one single Virtual IP address, so that the network can forward as one single destination.

Linda
From: Robert Raszuk <[email-masked]>
Sent: Thursday, January 13, 2022 9:37 AM
To: Linda Dunbar <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

> Flows among micro-services are very short.

While that can be true - there is nowhere in the document a restriction or even a warning that this solution is aiming for short lived flows only and that users should be well aware about drastic nature of proposed mechanism to their established flows.

In one of the companies I worked for average  TCP flow duration was anywhere from 8-18 hours and it was a very drastic event for the user to loose it in the middle of the day.  Various means where taken and applied to protect such sessions from any form of disconnects.

Thx,
R.

On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda

To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>

Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P%2BItvofz3%2Bgg0KEMdfxe9MluMPkQ2v1jL8a1Q50rddo%3D&reserved=0>

Thx,
R.

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=G8h11WpirgxNmk2wzr6QN9DsnYBNGQ42ft7Cz9E8pAk%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zcwF%2F%2FKh77N6jyXDOXuftPALvaUb%2B2Kvj2G2tedfvL0%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nJcXT7NffiSt7CJh%2F2bnqaa7ClnxMSCf%2BVproPb34s0%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AbVKlR%2FrX1vhMzdzHL7J8VgiU2oxaqxSu9oMx9onJRo%3D&reserved=0>

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4VvMlYIqiEyjlRQHQkRLXocNchpxnDGqBSfKG96GCaY%3D&reserved=0>
--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RBLTHUJUf6MujlMd%2FIpMJH36fjYXm3diFx6nS9I28E0%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RBLTHUJUf6MujlMd%2FIpMJH36fjYXm3diFx6nS9I28E0%3D&reserved=0>

Gyan Mishra

M 301 502-1347

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 Jan 2022 16:36:54 +0000

Linda -

Are you saying that the scenario you are trying to address is to have a given "transaction" go to the currently closest/most lightly loaded Application Server?
And there is no intent to support for long lived connections?

If so, then this isn't really a load balancing issue and I agree that using the IGP/Flex Algo as you are proposing is a viable solution.
The concern then becomes the rate of updates to the new Prefix Metric. If this changes too rapidly this will heavily consume network resources by triggering flooding, SPF, forwarding plane updates at a high rate.
Can you put some language in the draft that indicates the expected rate of updates to the metric and some guidelines on limiting the frequency?

Thanx.

   Les

Sent: Thursday, January 13, 2022 7:58 AM

Robert,

Linda

Thx,
R.

Linda

Thx,
R.

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 17:51:51 +0100

> and I agree that using the IGP/Flex Algo as you are proposing is a viable
solution.

Except that IGP usually does not run between application server and load
balancer ...

On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Linda –
>
>
>
> Are you saying that the scenario you are trying to address is to have a
> given “transaction” go to the currently closest/most lightly loaded
> Application Server?
>
> If so, then this isn’t really a load balancing issue and I agree that
> using the IGP/Flex Algo as you are proposing is a viable solution.
>
> The concern then becomes the rate of updates to the new Prefix Metric. If
> this changes too rapidly this will heavily consume network resources by
> triggering flooding, SPF, forwarding plane updates at a high rate.
>
> Can you put some language in the draft that indicates the expected rate of
> updates to the metric and some guidelines on limiting the frequency?
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
>
>
> *Sent:* Thursday, January 13, 2022 7:58 AM
> *Cc:* Gyan Mishra <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; [email-masked]
> *Subject:* RE: [Lsr] Seeking feedback to the revised
> For your scenario of TCP flows lasting more than 8~18 hours,  multiple
> server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST
> address).  Each of those instances should have one distinct IP address.
>
>
>
> The draft is for different scenario where application are instantiated at
> multiple locations behind multiple App Layer Load Balancers. They have
> relative short flows that can go to any App Layer Load Balancers. Multiple
> Load Balancers  for those applications are assigned with the same IP
> address. In Kubernetes, multiple load balancers for one type of
> microservices are assigned with one single Virtual IP address, so that the
> network can forward as one single destination.
>
>
>
> Linda
>
> *Sent:* Thursday, January 13, 2022 9:37 AM
> *Cc:* Gyan Mishra <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; [email-masked]
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P%2BItvofz3%2Bgg0KEMdfxe9MluMPkQ2v1jL8a1Q50rddo%3D&reserved=0>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=G8h11WpirgxNmk2wzr6QN9DsnYBNGQ42ft7Cz9E8pAk%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zcwF%2F%2FKh77N6jyXDOXuftPALvaUb%2B2Kvj2G2tedfvL0%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nJcXT7NffiSt7CJh%2F2bnqaa7ClnxMSCf%2BVproPb34s0%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AbVKlR%2FrX1vhMzdzHL7J8VgiU2oxaqxSu9oMx9onJRo%3D&reserved=0>
>
>
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4VvMlYIqiEyjlRQHQkRLXocNchpxnDGqBSfKG96GCaY%3D&reserved=0>
>
> --
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RBLTHUJUf6MujlMd%2FIpMJH36fjYXm3diFx6nS9I28E0%3D&reserved=0>
>
> *Gyan Mishra*
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RBLTHUJUf6MujlMd%2FIpMJH36fjYXm3diFx6nS9I28E0%3D&reserved=0>
>
> *Gyan Mishra*
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 13 Jan 2022 17:18:34 +0000

Robert,

The draft is about distributing the Site Index and preferences of the Egress routers to which the application load balancers (or instances) are attached.

Thanks, Linda

From: Robert Raszuk <[email-masked]>
Sent: Thursday, January 13, 2022 10:52 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Linda Dunbar <[email-masked]>; Gyan Mishra <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

> and I agree that using the IGP/Flex Algo as you are proposing is a viable solution.

Except that IGP usually does not run between application server and load balancer ...

On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Linda -

Thanx.

   Les

Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Robert,

Linda
Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Thx,
R.

Linda

Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=M0zh%2FGcSbGbsMSTtLumrJwqHpaLEeN2BNrAC5Vzfc1k%3D&reserved=0>

Thx,
R.

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=I%2FV11f3RHBqxf7hsSv2WoTqvuAKd1m1I%2FKjazfdcKW8%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BIbu6t8949iZ1XTQxH1DqKnmWdDS12oFHeswXVetj6I%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C8rfWoZqKqU96otmvHNK1VzCdjch8Z2l57b75QFUtZI%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275677079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QDdZtfjYAwMxpYg7i2%2FVEI2ZuOAMNTbtASK8v6RzImw%3D&reserved=0>

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275687025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XHWDGZiGZbkJApYhfj7zKApfMmPfRlQf5IoGQ9t4yWM%3D&reserved=0>
--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275687025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PMh5sg8qdhonud0abjJFIXbwAZdvr4ixW242qVDyfz8%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275696990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oC1vEW%2B3HfEqKiVvC3CoGWZ3xrDGitMiCXeCOIIfE2U%3D&reserved=0>

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 18:27:06 +0100

Linda,

Let me ask again ... How does ISIS process on the egress router learns the
load of the "attached" load balancer ?

As far as your comment on using or not using anycast addresses I disagree,
but we will not be spamming LSR WG list to discuss this further.

Thx a lot,
R.

On Thu, Jan 13, 2022 at 6:18 PM Linda Dunbar <[email-masked]>
wrote:

> Robert,
>
>
>
> The draft is about distributing the Site Index and preferences of the
> Egress routers to which the application load balancers (or instances) are
> attached.
>
>
>
> Thanks, Linda
>
>
>
> *Sent:* Thursday, January 13, 2022 10:52 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Linda Dunbar <[email-masked]>; Gyan Mishra <
> [email-masked]>; [email-masked]
> On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) <
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=M0zh%2FGcSbGbsMSTtLumrJwqHpaLEeN2BNrAC5Vzfc1k%3D&reserved=0>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=I%2FV11f3RHBqxf7hsSv2WoTqvuAKd1m1I%2FKjazfdcKW8%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BIbu6t8949iZ1XTQxH1DqKnmWdDS12oFHeswXVetj6I%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C8rfWoZqKqU96otmvHNK1VzCdjch8Z2l57b75QFUtZI%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275677079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QDdZtfjYAwMxpYg7i2%2FVEI2ZuOAMNTbtASK8v6RzImw%3D&reserved=0>
>
>
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275687025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XHWDGZiGZbkJApYhfj7zKApfMmPfRlQf5IoGQ9t4yWM%3D&reserved=0>
>
> --
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275687025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PMh5sg8qdhonud0abjJFIXbwAZdvr4ixW242qVDyfz8%3D&reserved=0>
>
> *Gyan Mishra*
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275696990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oC1vEW%2B3HfEqKiVvC3CoGWZ3xrDGitMiCXeCOIIfE2U%3D&reserved=0>
>
> *Gyan Mishra*
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 13 Jan 2022 17:29:15 +0000

Robert,

Egress routers can be assigned with a site preference index for a specific set of prefixes attached.

Linda

From: Robert Raszuk <[email-masked]>
Sent: Thursday, January 13, 2022 11:27 AM
To: Linda Dunbar <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda,

Let me ask again ... How does ISIS process on the egress router learns the load of the "attached" load balancer ?

As far as your comment on using or not using anycast addresses I disagree, but we will not be spamming LSR WG list to discuss this further.

Thx a lot,
R.

On Thu, Jan 13, 2022 at 6:18 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Thanks, Linda

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 13, 2022 10:52 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Thanx.

   Les

Robert,

Linda

Thx,
R.

Linda

Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pQDpf5Bl4odcr2ZowdxW9lmkJDnbvdX4YY3%2BnDU1ZCU%3D&reserved=0>

Thx,
R.

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0Cb8RsTgPhCmPuM%2FlI5p96qOI1xOv04539VnBm4pDCU%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=202YnLqpE835cdqWTeir%2BH5AYr9phcn4rnX9hmbpRno%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pdDptGH2ZZiAp18e%2FojL9jt3tZmWLHsN64RK0u%2BSCuQ%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=08lqKu6kbqeC6HVePOnI9aUc0VPPUM%2B4mPQmg93UwZ0%3D&reserved=0>

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AwBn%2Bqz1xsRrnbxfDLQQEEsnnb%2Bq7ama2xRGwmlvDIg%3D&reserved=0>
--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427342360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yfD5DEan2qhnN8REWk75DjWJmmXIErDXXj8pzn9E1BQ%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427342360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yfD5DEan2qhnN8REWk75DjWJmmXIErDXXj8pzn9E1BQ%3D&reserved=0>

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 18:35:26 +0100

I am asking not for static assigned values by cfg. I am asking for dynamic
values being as part of site cost your draft is describing here:

   The "Site-Cost", which is derived from "site-capacity + load
   measurement + Preference + xxx", can be raw measurements
   collected by the egress routers based on the instructions
   from a controller or can be informed by the App Controller
   periodically.

Draft says "collected" - I am asking how is it collected ?

Thx

On Thu, Jan 13, 2022 at 6:29 PM Linda Dunbar <[email-masked]>
wrote:

> *Sent:* Thursday, January 13, 2022 11:27 AM
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pQDpf5Bl4odcr2ZowdxW9lmkJDnbvdX4YY3%2BnDU1ZCU%3D&reserved=0>
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0Cb8RsTgPhCmPuM%2FlI5p96qOI1xOv04539VnBm4pDCU%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=202YnLqpE835cdqWTeir%2BH5AYr9phcn4rnX9hmbpRno%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pdDptGH2ZZiAp18e%2FojL9jt3tZmWLHsN64RK0u%2BSCuQ%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=08lqKu6kbqeC6HVePOnI9aUc0VPPUM%2B4mPQmg93UwZ0%3D&reserved=0>
>
>
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AwBn%2Bqz1xsRrnbxfDLQQEEsnnb%2Bq7ama2xRGwmlvDIg%3D&reserved=0>
>
> --
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427342360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yfD5DEan2qhnN8REWk75DjWJmmXIErDXXj8pzn9E1BQ%3D&reserved=0>
>
> *Gyan Mishra*
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427342360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yfD5DEan2qhnN8REWk75DjWJmmXIErDXXj8pzn9E1BQ%3D&reserved=0>
>
> *Gyan Mishra*
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 Jan 2022 18:12:38 +0000

Robert –

I agree there is still a concern here – which has to do with how the new metric is calculated.

Imagine  that I have a million users in a metro area and they are all WFH (gee – when would that ever happen?? 😊 ) So they aren’t really mobile.
Are we going to have all users initially directed to Server #1 – and then after some period move all users to Server #2 just because Server #1 is busier than Server #2? (I hope not)
It seems to me that how the metric is calculated has cross-site implications.
This is out of scope for the IGP – we simply use what we are given.
But whatever entity is calculating the metric to be used has to be able to do so in a way that doesn’t cause spurious rerouting.

Seems to me you are asking Linda this question in one of your other posts.

My agreement on the use of the IGP assumes that the entity calculating the metric to be provided to the IGP has the correct intelligence.

   Les

Sent: Thursday, January 13, 2022 8:52 AM

Are you saying that the scenario you are trying to address is to have a given “transaction” go to the currently closest/most lightly loaded Application Server?
And there is no intent to support for long lived connections?

If so, then this isn’t really a load balancing issue and I agree that using the IGP/Flex Algo as you are proposing is a viable solution.
The concern then becomes the rate of updates to the new Prefix Metric. If this changes too rapidly this will heavily consume network resources by triggering flooding, SPF, forwarding plane updates at a high rate.
Can you put some language in the draft that indicates the expected rate of updates to the metric and some guidelines on limiting the frequency?

Thanx.

   Les

Robert,

For your scenario of TCP flows lasting more than 8~18 hours,  multiple server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST address).  Each of those instances should have one distinct IP address.

Linda

Thx,
R.

Your link to Traefik  adds more reasons why “Site index and preference” should be distributed by IGP:

Linda

Thx,
R.

Cheers,
Robert.

Hi Les

Agreed.

Let’s say if it’s proximity based and one path is preferred, the flow will take that path.  So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset and flow re-establishes on the alternate path based on the site cost and remains there until the server goes down or  gets overloaded or a better path comes along.

Is that a good or bad thing.  I think if you had to pick your poison as here the issue Linda is trying to solve is a server issue but leveraging the IGP to force re-convergence when the server is in a half baked state meaning it’s busy and connections are being dropped or very slow QOE for end user.  If you did nothing and let it ride the the user would be stuck on a bad connection.

Kind Regards

Gyan

Thanx.

    Les

Robert

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 19:19:42 +0100

> My agreement on the use of the IGP assumes that the entity calculating
the metric
> to be provided to the IGP has the correct intelligence.

I would not count on that

We have seen intelligent entities claiming to optimize routing having bugs
and missing corner cases which in turn when injected into routing protocols
results in massive (often global if we think BGP) unreachability.

Point here is that if we are to take dynamic data of any smart oracle to
use for making routing decisions (this is not really TE IMO) we better have
day one build in fuses and auto breakers to detect and suppress the
potential damage.

Thx,
R.

On Thu, Jan 13, 2022 at 7:12 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Imagine  that I have a million users in a metro area and they are all WFH
> (gee – when would that ever happen?? 😊 ) So they aren’t really mobile.
>
> Are we going to have all users initially directed to Server #1 – and then
> after some period move all users to Server #2 just because Server #1 is
> busier than Server #2? (I hope not)
>
> But whatever entity is calculating the metric to be used has to be able to
> do so in a way that doesn’t cause spurious rerouting.
>
>
>
> My agreement on the use of the IGP assumes that the entity calculating the
> metric to be provided to the IGP has the correct intelligence.
>
>
>
>    Les
>
>
>
>
>
> *Sent:* Thursday, January 13, 2022 8:52 AM

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Jan 2022 22:52:54 -0500

Robert

Responses in-line

> is proposed here is a disaster.

   Gyan>  Remember this is Anycast proximity based routing along with ECMP
/ UCMP flow based load balancing and most vendors modern routers support
some sort of  x-tuple ECMP/UCMP hash so the flows would be evenly
distributed, so if you have 10s of 100s of paths, the flows would be evenly
distributed across all the paths.  Since it’s Anycast proximity each path
leads to a different Application LB VIP and backend server.  So all the TCP
connections would be uniformly distributed across all the paths.

Only the connections hashed to the path with overloaded server would get
reset and it would be no different then if the server went down as the
connections would get reset anyway in that case.

 In this case instead of being pinned to a bad connection you are now reset
to a good connection resulting in better QOE for the end user and a Happy
customer.

To me thats a positive not a negative.

 A good analogy would be let’s say you are on WIFI and on the same channel
that your neighbors are on and have horrible bandwidth.  Do you stay on
that bad channel and limp along all day or to you flip to an unused channel.

Another example is if you have a server that has run out of resources.  Do
you fail production traffic off the server taking it out of rotation or let
it stay as is and pray things get better.  This draft is a good example of
how IGP can save the day with site metric.

> to the other LB(s) is never a technique any one would seriously deploy in a

Gyan> Application load balancing can be done with DNS based GEO load
balancing based on client and server IP database where you have more
discrete control however the failover is much slower.

> other LB(s)/server(s) too.

Gyan> The idea with Anycast load balancing is that you may have 10 or even
100s of paths, so if one server fails the load can be evenly distributed
based on statistical multiplexing algorithm calculated by the server teams
engineering the sizing of the server clusters to ensure what you described
won’t happen.

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Jan 2022 10:19:39 +0100

Gyan,

This is not a network discussion. There are well proven techniques to
direct user sessions or user requests to a pool of servers deployed and
operational. All provide robust services. Network plays very little to no
role in that.

There are also lot's of factors involved in making that decision (CPU load,
RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now
make IGP to carry it and make routing decisions (even if separate topology)
based on that information.

I do not see this like a move into the right direction. That is my input.

Kind regards,
Robert.

On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra <[email-masked]> wrote:

>> if you *s/connection/all connections/* then you quickly realize that
>> what is proposed here is a disaster.
>>
>
>  In this case instead of being pinned to a bad connection you are now
> reset to a good connection resulting in better QOE for the end user and a
> Happy customer.
>
>> Breaking all existing flows going to one LB to suddenly timeout and all
>> go to the other LB(s) is never a technique any one would seriously deploy
>> in a production network.
>>
>
>>>> I don’t want to speak for Robert, but for me his point was that IGPs
>>>> can do “multipath” well – but this does not translate into managing flows.
>>>>
>>>> IGP can and does ECMP well. Moreover, injecting metric of anycast
>>>> server destination plays no role in it as all paths would inherit that
>>>> external to the IGP cost.
>>>>
>>>>
>>>>
>>>> On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <
>>>> [email-masked]> wrote:
>>>>
>>>> Robert,
>>>>
>>>>
>>>>

---

From: John E Drake <[email-masked]>
Date: Fri, 14 Jan 2022 15:48:28 +0000

Robert is correct on all points.

Yours Irrespectively,

John

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, January 14, 2022 4:20 AM
To: Gyan Mishra <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[External Email. Be cautious of content]

Gyan,

This is not a network discussion. There are well proven techniques to direct user sessions or user requests to a pool of servers deployed and operational. All provide robust services. Network plays very little to no role in that.

There are also lot's of factors involved in making that decision (CPU load, RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make IGP to carry it and make routing decisions (even if separate topology) based on that information.

Kind regards,
Robert.

On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Robert

Responses in-line

On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

   Gyan>  Remember this is Anycast proximity based routing along with ECMP / UCMP flow based load balancing and most vendors modern routers support some sort of  x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so if you have 10s of 100s of paths, the flows would be evenly distributed across all the paths.  Since it's Anycast proximity each path leads to a different Application LB VIP and backend server.  So all the TCP connections would be uniformly distributed across all the paths.

Only the connections hashed to the path with overloaded server would get reset and it would be no different then if the server went down as the connections would get reset anyway in that case.

 In this case instead of being pinned to a bad connection you are now reset to a good connection resulting in better QOE for the end user and a Happy customer.

 A good analogy would be let's say you are on WIFI and on the same channel that your neighbors are on and have horrible bandwidth.  Do you stay on that bad channel and limp along all day or to you flip to an unused channel.

Another example is if you have a server that has run out of resources.  Do you fail production traffic off the server taking it out of rotation or let it stay as is and pray things get better.  This draft is a good example of how IGP can save the day with site metric.

Gyan> Application load balancing can be done with DNS based GEO load balancing based on client and server IP database where you have more discrete control however the failover is much slower.

Gyan> The idea with Anycast load balancing is that you may have 10 or even 100s of paths, so if one server fails the load can be evenly distributed based on statistical multiplexing algorithm calculated by the server teams engineering the sizing of the server clusters to ensure what you described won't happen.

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul_v4FfHY$>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul6f5yYBY$>

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul5Iqp-4w$>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIuljUtRa8M$>

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulvnuCJa8$>
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$>

Gyan Mishra

M 301 502-1347

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 07:58:05 +0800

Hi, John:
Here I would also like to hear your own opinions. If not, please see my responses for both you and Robert:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01 has introduced the “delay metric” into the IGP. Such metric may be variant in every link within the IGP.
The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link’s/prefixes characteristics, it is the aggregate cost to the server that measured from the router.

All the factors that mentioned by Robert maybe the parameters that influences the performance of the server, which will be reflected in the aggregate cost.

Then, the conclusion is that IGP has now the capabilities to deal with the dynamics value(the change frequencies can certainly be controlled, thinking how we control the flapping interface)within the network , the aggregate cost or other quasi-static factor to the server at the edge of the network can also be considered together.
Such approaches can certainly let the IGP give more optimal behavior to forward the traffic to the appropriate destination, or follow an optimal path.

Aijun Wang
China Telecom

> On Jan 14, 2022, at 23:49, John E Drake <jdrake=[email-masked]> wrote:
> 
> 
>    Gyan>  Remember this is Anycast proximity based routing along with ECMP / UCMP flow based load balancing and most vendors modern routers support some sort of  x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so if you have 10s of 100s of paths, the flows would be evenly distributed across all the paths.  Since it’s Anycast proximity each path leads to a different Application LB VIP and backend server.  So all the TCP connections would be uniformly distributed across all the paths.  
>  
>  A good analogy would be let’s say you are on WIFI and on the same channel that your neighbors are on and have horrible bandwidth.  Do you stay on that bad channel and limp along all day or to you flip to an unused channel.
>  
> Gyan> The idea with Anycast load balancing is that you may have 10 or even 100s of paths, so if one server fails the load can be evenly distributed based on statistical multiplexing algorithm calculated by the server teams engineering the sizing of the server clusters to ensure what you described won’t happen.
>  
> On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) <[email-masked]> wrote:
> Gyan –
>  
> On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <[email-masked]> wrote:
> Robert,
>  
> Email [email-masked]
> M 301 502-1347
> 
>  
> --
> 
> 
> Gyan Mishra
> Email [email-masked]
> M 301 502-1347
> 
>  
> --
> 
> 
> Gyan Mishra
> Email [email-masked]
> M 301 502-1347
> 
>

---

From: John E Drake <[email-masked]>
Date: Sat, 15 Jan 2022 00:36:52 +0000

This is similar to the issue with the Down/Up proposal.  A single metric tells an ingress node nothing about the performance of or load on the individual applications at a given site.

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]>
Sent: Friday, January 14, 2022 6:58 PM
To: John E Drake <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Gyan Mishra <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi, John:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc$> has introduced the “delay metric” into the IGP. Such metric may be variant in every link within the IGP.
The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link’s/prefixes characteristics, it is the aggregate cost to the server that measured from the router.

On Jan 14, 2022, at 23:49, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

Yours Irrespectively,

John

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk

Gyan,

Kind regards,
Robert.

Responses in-line

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 11:37:23 +0800

This draft is now proposing one aggregate cost of the application server.  

The detailed factors can also be included if necessary. But the principle for advertising them should be controllable, as required by other dynamic metrics in IGP.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:37, John E Drake <jdrake=[email-masked]> wrote:
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Jan 2022 01:52:15 -0500

Hi Robert

Many Thanks for your feedback on the draft.

I understand your POV and views as agreed that server load balancing can be
solved at the application layer and maybe with other possible solutions.

Understood.

The thoughts behind Linda draft is an alternative to solving at the
application layer using IGP based solution.   I know there is a lot
involved that gets factored into the server pool resources provisioning and
monitoring and even in this solution the server health checks are closely
monitored by the load balancers and trigger of a HRI-host route injection
withdrawal as soon as the LBV VIP monitor fails.

Also it maybe possible but Linda can speak further on it that GEO DNS based
application based load balancing hybrid Model with IGP site cost
interleaved could possibly apply to this as well so it’s not all IGP based
as well as other application layer appliance or virtual based load
balancing concepts.

Kind Regards

Gyan
On Fri, Jan 14, 2022 at 4:19 AM Robert Raszuk <[email-masked]> wrote:

> There are also lot's of factors involved in making that decision (CPU
> load, RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to
> now make IGP to carry it and make routing decisions (even if separate
> topology) based on that information.
>
>>    Gyan>  Remember this is Anycast proximity based routing along with
>> ECMP / UCMP flow based load balancing and most vendors modern routers
>> support some sort of  x-tuple ECMP/UCMP hash so the flows would be evenly
>>  A good analogy would be let’s say you are on WIFI and on the same
>> channel that your neighbors are on and have horrible bandwidth.  Do you
>> stay on that bad channel and limp along all day or to you flip to an unused
>> channel.
>>
>> Another example is if you have a server that has run out of resources.
>> Do you fail production traffic off the server taking it out of rotation or
>> let it stay as is and pray things get better.  This draft is a good example
>> of how IGP can save the day with site metric.
>>
>>>
>> Gyan> The idea with Anycast load balancing is that you may have 10 or
>> even 100s of paths, so if one server fails the load can be evenly
>> distributed based on statistical multiplexing algorithm calculated by the
>> server teams engineering the sizing of the server clusters to ensure what
>> you described won’t happen.
>>
>>>
>>>> My thoughts are that the context of the draft is based on an Anycast
>>>> VIP address of a server which is proximity based load balancing and not
>>>> So now in ECMP case the flow hashed to a path and maintains its
>>>> affinity to that path.  Now all of sudden the server gets overloaded and we
>>>> get a better site cost advertised.  So now the session terminates on
>>>> current path and establishes again on the Anycast VIP new path based on the
>>>> site cost advertised.
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Jan 2022 01:53:17 -0500

Many Thanks for the feedback!

Gyan

On Fri, Jan 14, 2022 at 10:48 AM John E Drake <[email-masked]> wrote:

> *From:* Lsr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Friday, January 14, 2022 4:20 AM
> *[External Email. Be cautious of content]*
>
>
>
> Gyan,
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul_v4FfHY$>
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul6f5yYBY$>
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul5Iqp-4w$>
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIuljUtRa8M$>
>
>
>
>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulvnuCJa8$>
>
> --
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$>
>
> *Gyan Mishra*
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$>
>
> *Gyan Mishra*
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ$>
>
> *Gyan Mishra*
>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 15 Jan 2022 11:30:00 +0000

Hi Aijun, Linda,
Independent of the ongoing debate on whether advertising the server metrics in the IGPs…

Now that the draft is simplified to use a single aggregated metric, why not make the draft informational and use the base IGP metrics? This avoid the burden of adding a new flex algorithm.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Aijun Wang <[email-masked]>
Date: Friday, January 14, 2022 at 10:38 PM
To: John E Drake <jdrake=[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, Linda Dunbar <[email-masked]>, Gyan Mishra <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Yours Irrespectively,

John

Hi, John:

Yours Irrespectively,

John

Gyan,

Kind regards,
Robert.

Responses in-line

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 16 Jan 2022 01:02:26 +0000

Acee, John, Robert, and LSR experts:

We have updated the draft to reflect the comments and suggestions on the LSR mailing list.  https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In particular:

  *   This draft describes using additional site costs to influence the shortest path computation for a specific set of prefixes. As there are a small number of egress routers having those prefixes (or destinations) that need to incorporate site costs in SPF computation, Flexible Algorithms [LSR-FlexAlgo] is used to indicate the need for the site costs to be considered for the specific topologies.

Need a Flag in the Flexible Algorithm TLV to indicate that "site-cost" needs to be included for the constrained SPF to reach the Prefix.
Therefore, it is not informational draft.

The "Site Cost" associated with a prefix (i.e., ANYCAST prefix) can be a value configured on the router to which the prefix is attached. The actual mechanism of assigning "Site Cost" or the detailed algorithm is out of the scope of document
The "site cost" change rate is comparable with the rate that the application controller adds or removes the application instances at locations to adjust the workload distribution. Typically, the rate of change could be in days. On rare occasions, there might need rate changes in hours.

We have added a section to emphasize that  It is important that the "site cost" metric doesn't change too frequently to avoid route oscillation within the network.

Thank you.

Linda

From: Acee Lindem (acee) <[email-masked]>
Sent: Saturday, January 15, 2022 5:30 AM
To: Aijun Wang <[email-masked]>; John E Drake <jdrake=[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Linda Dunbar <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Aijun, Linda,

Independent of the ongoing debate on whether advertising the server metrics in the IGPs...

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Aijun Wang <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 14, 2022 at 10:38 PM
To: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Gyan Mishra <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

On Jan 15, 2022, at 08:37, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:
This is similar to the issue with the Down/Up proposal.  A single metric tells an ingress node nothing about the performance of or load on the individual applications at a given site.

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 14, 2022 6:58 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi, John:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-bw-con-01__%3B!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TVa27j%2Br9AIn3eD6puZdGPnTSDSqmlEOQ0NQUO0%2FGfc%3D&reserved=0> has introduced the "delay metric" into the IGP. Such metric may be variant in every link within the IGP.
The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link's/prefixes characteristics, it is the aggregate cost to the server that measured from the router.

Yours Irrespectively,

John

Gyan,

Kind regards,
Robert.

Responses in-line

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul_v4FfHY%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FBSqEL6aHR1qX%2FTe7t00ixOAPrcOIs2xOhMlg4ujUwQ%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul6f5yYBY%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vstVAd1HKNbxYF5k0Uqhbh62rSSscJ7IR6m0NPAwyJw%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIul5Iqp-4w%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wNdySf5VwInS1cB1iNVjuCAUScPGNggOlAEwaKNjQ2s%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIuljUtRa8M%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pwxmwsHJD1rCKTVDVCMgwhAHbaArCh6IBsfCkc%2BBw2c%3D&reserved=0>

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulvnuCJa8%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5nHTrHOvixdThanqkmUu1Zb9HzKEpvRLDj2U6wbyAWc%3D&reserved=0>
--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.verizon.com%2F__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OCVpMSHB2uJIKsp%2Bwvf4NolGS7mOYJNUh3N0%2BUBY%2BfY%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.verizon.com%2F__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OCVpMSHB2uJIKsp%2Bwvf4NolGS7mOYJNUh3N0%2BUBY%2BfY%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.verizon.com%2F__%3B!!NEt6yMaO-gk!Q_dNhM4zkmVLzk7kt8jFZyeqmHv6UQsKS6Rh3LIVyyGjsTVubuh7HIulfHhV7yQ%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OCVpMSHB2uJIKsp%2Bwvf4NolGS7mOYJNUh3N0%2BUBY%2BfY%3D&reserved=0>

Gyan Mishra

M 301 502-1347

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=l4ap2Ws%2F8oorV8CCX2avTQwtvmhWLJpqjigDGd2nNa8%3D&reserved=0>
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 16 Jan 2022 14:41:38 +0000

Hi Linda,

I guess you misunderstood me. Since the only advertises a single aggregated metric, you don’t need a new aggregated cost TLV or to use flex algorithm. Just set the base IGP metric for the prefix to the aggregated metric and IGPs will route based on that metric.

Thanks,
Acee

From: Linda Dunbar <[email-masked]>
Date: Saturday, January 15, 2022 at 8:03 PM
To: Acee Lindem <[email-masked]>, Aijun Wang <[email-masked]>, John E Drake <jdrake=[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, Gyan Mishra <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

In particular:

-          This draft describes using additional site costs to influence the shortest path computation for a specific set of prefixes. As there are a small number of egress routers having those prefixes (or destinations) that need to incorporate site costs in SPF computation, Flexible Algorithms [LSR-FlexAlgo] is used to indicate the need for the site costs to be considered for the specific topologies.

Need a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs to be included for the constrained SPF to reach the Prefix.
Therefore, it is not informational draft.

The “Site Cost” associated with a prefix (i.e., ANYCAST prefix) can be a value configured on the router to which the prefix is attached. The actual mechanism of assigning “Site Cost” or the detailed algorithm is out of the scope of document
The “site cost” change rate is comparable with the rate that the application controller adds or removes the application instances at locations to adjust the workload distribution. Typically, the rate of change could be in days. On rare occasions, there might need rate changes in hours.

We have added a section to emphasize that  It is important that the “site cost” metric doesn’t change too frequently to avoid route oscillation within the network.

Thank you.

Linda

Hi Aijun, Linda,

Thanks,
Acee

Yours Irrespectively,

John

Hi, John:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-bw-con-01__%3B!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TVa27j%2Br9AIn3eD6puZdGPnTSDSqmlEOQ0NQUO0%2FGfc%3D&reserved=0> has introduced the “delay metric” into the IGP. Such metric may be variant in every link within the IGP.
The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link’s/prefixes characteristics, it is the aggregate cost to the server that measured from the router.

Yours Irrespectively,

John

Gyan,

Kind regards,
Robert.

Responses in-line

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 17 Jan 2022 10:47:19 +0800

Hi, Acee:

My thought is that the traditional IGP metric is the cost from ingress routers(Ra/Rb) to egress routers(R1/R2/R3) which is illustrated in https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-04#appendix-A.

Such metric will be same(because of the ANYCAST address be advertised simultaneously via R1/R2/R3 at the same time for one application server, for example, S1/aa08::4450).

But, In the above mentioned scenario, there are other factors to be considered, or other factors may be more signification for the selection of ANYCAST server, for example, the Capacity Index, the Preference Index and other constraints.

The egress router(A-ER) now calculate the aggregated metric based on these factors. The derived cost should be considered or added at the IGP SPF calculation to the ANYCAST prefix.

There are two way to advertise such additional information:

1)     To define another type prefix cost, and also the new Flexalgo algorithm, to indicate that both the traditional prefix metric and this additional aggregated metric should be considered together to select the right egress router

2)     To put the additional cost information within the Stub-Link TLV that defined in https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-03,  

Both can results in the EPE(Egress Peering Engineering)-like effect.

But I am prefer to the second option, because in such scenario, the stub link bandwidth, stub link delay etc factors should also be considered when to select the best egress, they are not the attribute of prefixes.

We should also know that for these “no inter-as boundary link”, or ‘stub link’, the associated prefix will not be advertised into the IGP automatically, only the local interface address of the stub link on the egress router will be advertised.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Sunday, January 16, 2022 10:42 PM
To: Linda Dunbar <[email-masked]>; Aijun Wang <[email-masked]>; John E Drake <jdrake=[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda, 

Thanks,

Acee

From: Linda Dunbar <[email-masked] <mailto:[email-masked]> >
Date: Saturday, January 15, 2022 at 8:03 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, Aijun Wang <[email-masked] <mailto:[email-masked]> >, John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >
Cc: "Les Ginsberg (ginsberg)" <[email-masked] <mailto:[email-masked]> >, Gyan Mishra <[email-masked] <mailto:[email-masked]> >, Robert Raszuk <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

In particular:

Thank you. 

Linda

From: Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > 
Sent: Saturday, January 15, 2022 5:30 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >; John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >
Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; Linda Dunbar <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Robert Raszuk <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Aijun, Linda,

Thanks,

Acee

From: Lsr <[email-masked] <mailto:[email-masked]> > on behalf of Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Friday, January 14, 2022 at 10:38 PM
To: John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >
Cc: "Les Ginsberg (ginsberg)" <[email-masked] <mailto:[email-masked]> >, Linda Dunbar <[email-masked] <mailto:[email-masked]> >, Gyan Mishra <[email-masked] <mailto:[email-masked]> >, Robert Raszuk <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Aijun Wang

China Telecom

On Jan 15, 2022, at 08:37, John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> > wrote:

Yours Irrespectively,

John

From: Aijun Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, January 14, 2022 6:58 PM
To: John E Drake <[email-masked] <mailto:[email-masked]> >
Cc: Robert Raszuk <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; Linda Dunbar <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi, John: 

Aijun Wang 

China Telecom

On Jan 14, 2022, at 23:49, John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> > wrote:

Yours Irrespectively,

John

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Robert Raszuk
Sent: Friday, January 14, 2022 4:20 AM
To: Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; Linda Dunbar <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Gyan, 

Kind regards,

Robert.

 

 

On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Robert 

Responses in-line 

On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

Gyan, 

Cheers,

Robert.

On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Hi Les 

Agreed.

Kind Regards 

Gyan

On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> > wrote:

Gyan –

Thanx.

    Les

From: Gyan Mishra <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, January 12, 2022 5:26 PM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; Linda Dunbar <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Robert 

 

Kind Regards 

Gyan

On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

Linda,

Thx a lot,

R.

On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <[email-masked] <mailto:[email-masked]> > wrote:

Robert, 

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, January 12, 2022 1:00 PM
To: Linda Dunbar <[email-masked] <mailto:[email-masked]> >
Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda,

 

Draft says: 

 

Thank you, Linda 

Thx a lot,
R.

 

-- 

Gyan Mishra

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

-- 

Gyan Mishra

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

-- 

Gyan Mishra

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=l4ap2Ws%2F8oorV8CCX2avTQwtvmhWLJpqjigDGd2nNa8%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 17 Jan 2022 12:29:08 +0100

Aijun,

Such metric will be same(because of the ANYCAST address be advertised
> simultaneously via R1/R2/R3 at the same time for one application server,
> for example, S1/aa08::4450).
>

That is not really correct.

On each router R1 or R2 or R3 when you for example redistribute or
originate in any other way host route for example S1/aa08::4450 you can
apply a different metric to it.

That is why I keep asking what is the mechanism in which routers will be
informed what host routes to advertise and what metric to use for each IP
address of the server or application on the server. The most precise answer
received so far was "it is out of scope". And that is important
irrespective if we are talking about using passive interfaces, stub
interfaces or simply static routes.

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Mon, 17 Jan 2022 20:11:38 +0800

Hi, Robert:

I think redistribute the route with the additional cost is possible but we should consider the aggregated cost may changed upon the server status, although not very frequently or in one controllable manner.
The aggregated cost is measured and calculated at the egress router. It’s behavior is similar with the link delay attributes.

Aijun Wang
China Telecom

> On Jan 17, 2022, at 19:29, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> On each router R1 or R2 or R3 when you for example redistribute or originate in any other way host route for example S1/aa08::4450 you can apply a different metric to it. 
> 
> That is why I keep asking what is the mechanism in which routers will be informed what host routes to advertise and what metric to use for each IP address of the server or application on the server. The most precise answer received so far was "it is out of scope". And that is important irrespective if we are talking about using passive interfaces, stub interfaces or simply static routes. 
> 
> Thx,
> R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 17 Jan 2022 13:15:09 +0000

Hi Aijung,
So I guess you’re saying the current draft with a single aggregated cost is incorrect and will be updated?
Thanks,
Acee

From: Aijun Wang <[email-masked]>
Date: Sunday, January 16, 2022 at 9:47 PM
To: Acee Lindem <[email-masked]>, 'Linda Dunbar' <[email-masked]>, John E Drake <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, 'Gyan Mishra' <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi, Acee:

Best Regards

Aijun Wang
China Telecom

Hi Linda,

Thanks,
Acee

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Saturday, January 15, 2022 at 8:03 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Aijun Wang <[email-masked]<mailto:[email-masked]>>, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Gyan Mishra <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

In particular:

Thank you.

Linda

From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, January 15, 2022 5:30 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Aijun, Linda,

Thanks,
Acee

Yours Irrespectively,

John

Hi, John:

Yours Irrespectively,

John

Gyan,

Kind regards,
Robert.

Responses in-line

Cheers,
Robert.

Hi Les

Agreed.

Kind Regards

Gyan

Thanx.

    Les

Robert

Kind Regards

Gyan

Thx a lot,
R.

Hi Linda,

Draft says:

Thank you, Linda

Thx a lot,
R.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Aijun Wang <[email-masked]>
Date: Mon, 17 Jan 2022 22:00:10 +0800

Hi, Acee:

Actually I think so. We would like to hear more comments for the two approaches.

It’s better to update the draft based on the consensus or through discussion.

Aijun Wang
China Telecom

> On Jan 17, 2022, at 21:15, Acee Lindem (acee) <acee=[email-masked]> wrote:
> 
> 
> Hi Aijung,

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jan 2022 03:52:18 +0000

Robert,

In the new version of the draft, we have:
“The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) can be a value configured on the router to which the prefix is attached. The aggregated site cost can be computed based on an algorithm configured on router for specific prefixes. The detailed algorithm of computing the aggregated site cost is out of the scope of document.
As the cost change can impact the path computation, there is a Minimum Interval for Metrics Change Advertisement which is configured on the routers to avoid route oscillations. Default is 30s.
The aggregated site cost change rate is comparable with the rate of adding or removing application instances at locations to adapt to the workload distribution changes. The rate of change could be in weeks or days. On rare occasions, there might need rate changes in hours..”

Your comments and suggestions are greatly appreciated.

Linda

From: Robert Raszuk <[email-masked]>
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; Linda Dunbar <[email-masked]>; John E Drake <jdrake=[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Aijun,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Jan 2022 11:18:12 +0100

Hi Linda,

*The aggregated site cost change rate is comparable with the rate of adding
or removing application instances at locations to adapt to the workload
distribution changes.*

[RR] What Les and myself have been trying to highlight here is that the
above model does not effectively work well in the underlay layer.

The moment you adjust such cost will not really spread workload
distribution, but shift it between servers - members of given anycast
address. The forwarding decision will happen at the first common P core
underlay node from the server side and not the ingress to the network -
where is what you would really want.

Only in very specific topologies you may see some more control, but I would
say that this is rather an exception then a rule.

Thx,
R.

On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar <[email-masked]>
wrote:

> *“The aggregated site cost associated with a prefix (i.e., ANYCAST prefix)
> can be a value configured on the router to which the prefix is attached.
> The aggregated site cost can be computed based on an algorithm configured
> on router for specific prefixes. The detailed algorithm of computing the
> aggregated site cost is out of the scope of document. *
>
> *As the cost change can impact the path computation, there is a Minimum
> Interval for Metrics Change Advertisement which is configured on the
> routers to avoid route oscillations. Default is 30s. *
>
> *The aggregated site cost change rate is comparable with the rate of
> adding or removing application instances at locations to adapt to the
> workload distribution changes. The rate of change could be in weeks or
> days. On rare occasions, there might need rate changes in hours..”*
>
>
>
> *Sent:* Monday, January 17, 2022 5:29 AM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* Acee Lindem (acee) <acee=[email-masked]>; Linda Dunbar <
> [email-masked]>; John E Drake <jdrake=
> [email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>;
> Gyan Mishra <[email-masked]>; lsr <[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Jan 2022 13:17:36 +0000

Hi Linda,

You seem to be either missing or avoiding my question as to why the base IGP metric can’t be used now that the draft has a single aggregated cost?

Aijun replied with two alternatives for changing it to allow for complex selection algorithm based on multiple metrics. What is the actual requirement here?

Acee

From: Linda Dunbar <[email-masked]>
Date: Tuesday, January 18, 2022 at 10:52 PM
To: Robert Raszuk <[email-masked]>, Aijun Wang <[email-masked]>
Cc: Acee Lindem <[email-masked]>, John E Drake <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, Gyan Mishra <[email-masked]>, lsr <[email-masked]>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Robert,

Linda

Aijun,

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Wed, 19 Jan 2022 22:06:04 +0800

Hi, Robert:

As described in the draft, “all those locations can be close in proximity. There might be a tiny difference in the routing distance to reach an application instance attached to a different edge router”
So, the “aggregated cost” or other factors that associated with the stub link may be more important for selecting the right server.
I think it is not important for P router responses or Ingress router responses first. In Figure 10, you will notice the client’s traffic is first distributed via the DNS to different “ANYCAST” address. Then for the same “ANYCAST” address, the client will prefer one of the three server, if these server has different “aggregated cost”
We can now adjust the “aggregated cost” to influence the traffic distribution among these three servers for the same “ANYCAST” address.
For example, if we set all the”aggregated cost” same for one “ANYCAST” address(for example, aa08:4450), then the traffic to this address will be distributed equally among the three locations. No traffic oscillation will occur.

The key point here is that the attributes associated with these stub links/prefixes should be considered or emphasized.

Aijun Wang
China Telecom

> On Jan 19, 2022, at 18:19, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Linda,
> 
> The aggregated site cost change rate is comparable with the rate of adding or removing application instances at locations to adapt to the workload distribution changes.
> 
> [RR] What Les and myself have been trying to highlight here is that the above model does not effectively work well in the underlay layer. 
> 
> The moment you adjust such cost will not really spread workload distribution, but shift it between servers - members of given anycast address. The forwarding decision will happen at the first common P core underlay node from the server side and not the ingress to the network - where is what you would really want. 
> 
> Only in very specific topologies you may see some more control, but I would say that this is rather an exception then a rule. 
> 
> Thx,
> R.
> 
> 
> 
>> On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar <[email-masked]> wrote:
>> Robert,
>> 
>>  
>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Jan 2022 15:28:11 +0100

All,

There is a fundamental question in respect to your and Linda drafts - how
much service awareness should be carried by link state protocols.

Historically till today IGPs provide stable underlay reachability within
the IGP coverage area (including hierarchy). Yes they were extended to
carry underlay TE or SR information, but still that was within the core
transport.

All external or service information where not carried by neither OSPF nor
ISIS. Neither was node liveness as an extra indicator.

Various services were loaded onto BGP and BGP was and still continues to be
the victim of those who think that it is cool to make network service rich
and smart.

I understand now its IGP turn to overload it with lots of external and in
fact opaque to native IGP function stuff. And once we open that gate we
will be walking on the cliff where the edge is not rock, but clay or sand.

Very honestly I do think that information about services do not belong to
link state protocols. They are much better handled at the application layer
and in the end to end fashion between actual application endpoints. We
should aim to decrease state carried and handled by IGPs not spending time
on the absolute reverse.

See take your stub link draft ... say an area may have 100 intra-area links
and 1000s of external logical links (example VLANs) which you proposed to
model as link. Moreover, information advertised with those stub links may
be dynamic which multiplied by scale has clear potential to overwhelm (in
processing or distribution) by orders of magnitude important data coming
with real transport links.

Kind regards,
Robert

On Wed, Jan 19, 2022 at 3:06 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Robert:
>
> As described in the draft, “all those locations can be close in proximity.
> There might be a tiny difference in the routing distance to reach an
> application instance attached to a different edge router”
> So, the “aggregated cost” or other factors that associated with the stub
> link may be more important for selecting the right server.
> I think it is not important for P router responses or Ingress router
> responses first. In Figure 10, you will notice the client’s traffic is
> first distributed via the DNS to different “ANYCAST” address. Then for the
> same “ANYCAST” address, the client will prefer one of the three server, if
> these server has different “aggregated cost”
> We can now adjust the “aggregated cost” to influence the traffic
> distribution among these three servers for the same “ANYCAST” address.
> For example, if we set all the”aggregated cost” same for one “ANYCAST”
> address(for example, aa08:4450), then the traffic to this address will be
> distributed equally among the three locations. No traffic oscillation will
> occur.
>
> The key point here is that the attributes associated with these stub
> links/prefixes should be considered or emphasized.
>
> Aijun Wang
> China Telecom
>
> workload distribution changes.*
>
> Only in very specific topologies you may see some more control, but I
> would say that this is rather an exception then a rule.
>
> Thx,
> R.
>
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 19 Jan 2022 20:25:53 +0530

Hi,

Just curious, keeping the 5G use case and applications aside, is it fair to
consider the new metric analogous to TE metric for a prefix that CSPF can
use? The metric can be split into 'n' parts all internal to the specific
application?

Regards,
Muthu

On Wed, Jan 19, 2022 at 7:36 PM Aijun Wang <[email-masked]>
wrote:

>> *“The aggregated site cost associated with a prefix (i.e., ANYCAST
>> prefix) can be a value configured on the router to which the prefix is
>> attached. The aggregated site cost can be computed based on an algorithm
>> configured on router for specific prefixes. The detailed algorithm of
>> computing the aggregated site cost is out of the scope of document. *
>>
>> *Cc:* Acee Lindem (acee) <acee=[email-masked]>; Linda Dunbar
>> <[email-masked]>; John E Drake <jdrake=
>> [email-masked]>; Les Ginsberg (ginsberg) <
>> [email-masked]>; Gyan Mishra <[email-masked]>; lsr <
>> [email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jan 2022 15:36:52 +0000

Acee,

I am sorry for missing answering your question.

Aggregated site cost for a specific prefix is different than the base IGP cost for the following reasons:

  *   The aggregated site cost only applies to a specific topology. The policy is configured to the relevant nodes to take the aggregated site cost into consideration in computing the shortest path.
  *   As Muthu’s email stated that “The metric can be split into 'n' parts all internal to the specific application”. The aggregated site cost can be one value or a set of values.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCostSubTLV                  | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        AggCost Attribute-1 to the Prefix                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|        AggCost Attribute-i to the Prefix                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Aggregated cost Advertisement in OSPF

Your suggestions and comments are greatly appreciated.

Linda Dunbar

From: Acee Lindem (acee) <[email-masked]>
Sent: Wednesday, January 19, 2022 7:18 AM
To: Linda Dunbar <[email-masked]>; Robert Raszuk <[email-masked]>; Aijun Wang <[email-masked]>
Cc: John E Drake <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda,

Acee

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 18, 2022 at 10:52 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Gyan Mishra <[email-masked]<mailto:[email-masked]>>, lsr <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Robert,

Linda

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Aijun,

Thx,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jan 2022 15:59:12 +0000

Robert,

Reply to your comments are inserted below:

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, January 19, 2022 4:18 AM
To: Linda Dunbar <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; John E Drake <jdrake=[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda,

The moment you adjust such cost will not really spread workload distribution, but shift it between servers - members of given anycast address.

[Linda] that is exactly what the draft is proposing to do: shifting traffic among members of one ANYCAST address. For example, one prefix A has 4 instances attached to 4 different routers (R1/R2/R3/R4). The distance to each of the routers is D1/D2/D3/D4. Routers in 5G Local Data Networks have preconfigured ECMP or (weighted ECMP) to distribute traffic towards A via 4 available paths through R1/R2/R3/R4.

When  R3 reduces the aggregated site cost for the prefix A to a specific topology (e.g. the specific Local Data Network around Cell tower Cluster X),  the shortest path from routers in the Cell Tower Cluster X for the prefix A will be shorter via R3. There are other factors influencing the shortest path computation and ECMP among all paths towards the prefix A.

The forwarding decision will happen at the first common P core underlay node from the server side and not the ingress to the network - where is what you would really want.

[Linda] The draft is for the scenario where there are multiple common routers towards multiple instances of the same prefix.

Linda

On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda

Cc: Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>

Aijun,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Jan 2022 17:08:16 +0100

Linda,

> When  R3 reduces the aggregated site cost for the prefix A to a specific
topology
+
> The aggregated site cost only applies to a specific topology.

As it has been confirmed with flex-algo authors for a given prefix you can
not have different cost per topology. Each locator or prefix can only be
associated only with a single topology. That restriction does not apply to
SR-MPLS, but I don't think this is what we are discussing here.

So with that what Acee is asking seems very reasonable - to simply use base
topology and compute the reachability using combined cost (base + external)
to your anycast prefixes.

Thx,
R.

On Wed, Jan 19, 2022 at 4:59 PM Linda Dunbar <[email-masked]>
wrote:

> *Sent:* Wednesday, January 19, 2022 4:18 AM
> *Cc:* Aijun Wang <[email-masked]>; Acee Lindem (acee) <acee=
> [email-masked]>; John E Drake <jdrake=
> address.
> [Linda] that is exactly what the draft is proposing to do: shifting
> traffic among members of one ANYCAST address. For example, one prefix A has
> 4 instances attached to 4 different routers (R1/R2/R3/R4). The distance to
> each of the routers is D1/D2/D3/D4. Routers in 5G Local Data Networks have
> preconfigured ECMP or (weighted ECMP) to distribute traffic towards A via 4
> available paths through R1/R2/R3/R4.
>
>
>
> When  R3 reduces the aggregated site cost for the prefix A to a specific
> topology (e.g. the specific Local Data Network around Cell tower Cluster
> X),  the shortest path from routers in the Cell Tower Cluster X for the
> prefix A will be shorter via R3. There are other factors influencing the
> shortest path computation and ECMP among all paths towards the prefix A.
>
>
>
> The forwarding decision will happen at the first common P core underlay
> node from the server side and not the ingress to the network - where is
> what you would really want.
>
>
>
> [Linda] The draft is for the scenario where there are multiple common
> routers towards multiple instances of the same prefix.
>
>
>
>
>
> Linda
>
>
>
>
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Jan 2022 16:09:20 +0000

Hi Linda,

Thanks for explaining that “aggregated” doesn’t mean that all the previously described application metrics are aggregated but that components each of these metric in the path are aggregated. If the algorithm isn’t specified and not all routers in the IGP domain use the same algorithm, then you have the possibility of loops.

Thanks,
Acee

From: Linda Dunbar <[email-masked]>
Date: Wednesday, January 19, 2022 at 10:37 AM
To: Acee Lindem <[email-masked]>, Robert Raszuk <[email-masked]>, Aijun Wang <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: John E Drake <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, Gyan Mishra <[email-masked]>, lsr <[email-masked]>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Acee,

-          The aggregated site cost only applies to a specific topology. The policy is configured to the relevant nodes to take the aggregated site cost into consideration in computing the shortest path.

-          As Muthu’s email stated that “The metric can be split into 'n' parts all internal to the specific application”. The aggregated site cost can be one value or a set of values.

Linda Dunbar

Hi Linda,

Acee

Robert,

Linda

Aijun,

Thx,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jan 2022 16:28:41 +0000

Robert,

Replies inserted below:

Sent: Wednesday, January 19, 2022 10:08 AM

Linda,

> When  R3 reduces the aggregated site cost for the prefix A to a specific topology
+
> The aggregated site cost only applies to a specific topology.

As it has been confirmed with flex-algo authors for a given prefix you can not have different cost per topology. Each locator or prefix can only be associated only with a single topology. That restriction does not apply to SR-MPLS, but I don't think this is what we are discussing here.

[Linda] That is why Peter Psenak suggested to use a new Flag in the Flag Algo to indicate the specific topology that needs to consider the Aggregated Site Cost.

A New flag (P-flag) is added to indicate that the aggregated site cost needs to be considered for the SPF to the prefix for a specific topology.
Flags:
0 1 2 3 4 5 6 7...
+-+-+-+-+-+-+-+-+...
|M|P| | ...
+-+-+-+-+-+-+-+-+...

Linda

On Wed, Jan 19, 2022 at 4:59 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>

Hi Linda,

Linda

Linda

Aijun,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Jan 2022 17:31:00 +0100

Linda,

But the point is that you can only have a single topology for a prefix - so
why not to do it in base ?

Thx

On Wed, Jan 19, 2022 at 5:28 PM Linda Dunbar <[email-masked]>
wrote:

> *Sent:* Wednesday, January 19, 2022 10:08 AM
> [Linda] That is why Peter Psenak suggested to use a new Flag in the Flag
> Algo to indicate the specific topology that needs to consider the
> Aggregated Site Cost.
>
>
>
> A New flag (P-flag) is added to indicate that the aggregated site cost
> needs to be considered for the SPF to the prefix for a specific topology.
>
> Flags:
>
> 0 1 2 3 4 5 6 7...
>
> +-+-+-+-+-+-+-+-+...
>
> |M|P| | ...
>
> +-+-+-+-+-+-+-+-+...
>
>
>
> Linda
>
>
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jan 2022 17:04:33 +0000

Acee,

Thank you for the valid point.
The aggregated site cost is supposed to impact a specific topology with a small number of routers, e.g. routers near a cluster of cell towers X.

We will add some description to the draft to address your points.

Thank you.
Linda

From: Acee Lindem (acee) <[email-masked]>
Sent: Wednesday, January 19, 2022 10:09 AM
To: Linda Dunbar <[email-masked]>; Robert Raszuk <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]
Cc: John E Drake <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda,

Thanks,
Acee

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 19, 2022 at 10:37 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Aijun Wang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Gyan Mishra <[email-masked]<mailto:[email-masked]>>, lsr <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Acee,

Linda Dunbar

From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 19, 2022 7:18 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Hi Linda,

Acee

Robert,

Linda

Aijun,

Thx,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Jan 2022 17:07:55 +0000

Hi Linda,

Date: Wednesday, January 19, 2022 at 12:05 PM

Acee,

How do you guarantee all the routers in the “topology” use the same algorithm and how does the “topology” relate to an IGP domain. Is it separate?

Thanks,
Acee

Thank you.
Linda

Hi Linda,

Thanks,
Acee

Acee,

Linda Dunbar

Hi Linda,

Acee

Robert,

Linda

Aijun,

Thx,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jan 2022 17:17:22 +0000

Acee,

You said:

Answers:

  *   The algorithm is preconfigured on the relevant routers. The aggregated site cost is most likely one single value, but not excluding scenario of a set of values.
  *   The topology can be different from IGP domain. For example, in the figure below, one specific topology could be the Red #2&#3; another specific topology could be the Orange #1&#2&#3.

  *   

Thanks,
Linda

Thank you.
Linda

To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Linda,

Thanks,
Acee

Acee,

Linda Dunbar

Hi Linda,

Acee

Robert,

Linda

Aijun,

Thx,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Jan 2022 20:39:41 +0000

Robert,

What you said is all correct for general purpose underlay networks.

In the traditional networks where traditional IGP has been deployed,  different addresses are for different end points. But  for the 5G edge computing environment, one entity can have multiple addresses and one prefix “A” can be attached to multiple routers.

E.g. in the picture below, the entity EAS-1 can have 3 addresses (E1/E2/E3). By adjusting the site cost for E1 on Router 1 for the Red Topology, traffic destined towards E1 from the routers in the Red Topology can be led to (or away from) to Router 1. And the traffic destined towards E2/E3 stay the same.

.

Linda

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, January 19, 2022 8:28 AM
To: lsr <[email-masked]>; Aijun Wang <[email-masked]>; Linda Dunbar <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

All,

There is a fundamental question in respect to your and Linda drafts - how much service awareness should be carried by link state protocols.

Historically till today IGPs provide stable underlay reachability within the IGP coverage area (including hierarchy). Yes they were extended to carry underlay TE or SR information, but still that was within the core transport.

All external or service information where not carried by neither OSPF nor ISIS. Neither was node liveness as an extra indicator.

Various services were loaded onto BGP and BGP was and still continues to be the victim of those who think that it is cool to make network service rich and smart.

I understand now its IGP turn to overload it with lots of external and in fact opaque to native IGP function stuff. And once we open that gate we will be walking on the cliff where the edge is not rock, but clay or sand.

Very honestly I do think that information about services do not belong to link state protocols. They are much better handled at the application layer and in the end to end fashion between actual application endpoints. We should aim to decrease state carried and handled by IGPs not spending time on the absolute reverse.

See take your stub link draft ... say an area may have 100 intra-area links and 1000s of external logical links (example VLANs) which you proposed to model as link. Moreover, information advertised with those stub links may be dynamic which multiplied by scale has clear potential to overwhelm (in processing or distribution) by orders of magnitude important data coming with real transport links.

Kind regards,
Robert

On Wed, Jan 19, 2022 at 3:06 PM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert:

Aijun Wang
China Telecom

On Jan 19, 2022, at 18:19, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Linda,

Thx,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 20 Jan 2022 09:49:16 +0800

Hi, Robert:

What I want to say is that the proposed “Attributes” is actually “metric” to the prefixes, or attributes of the stub links that connected to the prefix. 

It is not different from the metric within the IGP core transport.

It should be noticed that in your mentioned scenario, all the interface address information about the stub link are already within the IGP if you configure them as “Passive”, or “Stub Link”.  The difference is only advertising the interface address(current status), or the interface prefix address(as the attributes of the stub link).

And, as we all understand, the mentioned IGP Egress Engineering(for abbreviation, we can call it “IGP-EE”) will only exist for the “ANYCAST” address. Will you spread your “ANYCAST” address on all of the stub links? If not, we need not worry the overwhelming possibilities. And I think what your worry should be considered within the operation deployment, not the protocol itself.  For example, all the metrics within the IGP are not static and can be adjusted, but we will adjust them only when necessary.   

We should also notice that the IGP are considering adding more dynamic metrics to meet the service/network requirement(for example, link delay metric).

The IGP should be evolved to have more flexible capabilities to meet various scenarios.  The operator will have their considerations or restrictions when deploying these new features.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, January 19, 2022 10:28 PM
To: lsr <[email-masked]>; Aijun Wang <[email-masked]>; Linda Dunbar <[email-masked]>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

All,

Kind regards,

Robert

On Wed, Jan 19, 2022 at 3:06 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

Aijun Wang

China Telecom

On Jan 19, 2022, at 18:19, Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

Hi Linda,

Thx,

R.