Hi, Les: Aijun Wang China Telecom
> On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) > <[email protected]> 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 <[email protected]> On Behalf Of Linda Dunbar > Sent: Friday, January 7, 2022 11:29 AM > To: [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/ > > 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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
