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 protected] <[email protected]> On Behalf Of Les Ginsberg (ginsberg) Sent: Wednesday, January 12, 2022 1:14 PM To: Linda Dunbar <[email protected]>; [email protected] Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar <[email protected] <mailto:[email protected]> > Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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. [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) 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. [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 protected] <mailto:[email protected]> > Sent: Monday, January 10, 2022 9:48 AM To: Linda Dunbar <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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 <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 From: Lsr <[email protected] <mailto:[email protected]> > On Behalf Of Linda Dunbar Sent: Friday, January 7, 2022 11:29 AM To: [email protected] <mailto:[email protected]> Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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> 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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
