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 <lsr-boun...@ietf.org> On Behalf Of Aijun Wang Sent: Monday, January 10, 2022 9:05 AM To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org> Cc: lsr@ietf.org; Linda Dunbar <linda.dun...@futurewei.com> 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=40cisco....@dmarc.ietf.org<mailto:ginsberg=40cisco....@dmarc.ietf.org>> wrote: 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. [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 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 [WAJ] Selecting the most appropriate/optimized application server should base on the topology information which is routing protocol related. 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. [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 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/ 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<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
