Linda – Please see inline.
From: Linda Dunbar <linda.dun...@futurewei.com> Sent: Wednesday, January 12, 2022 8:41 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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. [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. 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? [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 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 [LES:] Great – thanx. Les Any other issues? Linda From: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Sent: Tuesday, January 11, 2022 11:14 PM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> 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) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Sent: Monday, January 10, 2022 9:48 AM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> 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%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 From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Linda Dunbar Sent: Friday, January 7, 2022 11:29 AM To: lsr@ietf.org<mailto:lsr@ietf.org> 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%7C4e790860cb7e40ff9cac08d9d58a7534%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637775612935452545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C02rBS0oFyNztREkN2lMaCKTL%2BUfOJIZ2zHJl%2FFA2Cw%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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
