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) <a...@cisco.com> 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 <lsr-boun...@ietf.org> on behalf of Robert Raszuk < > rob...@raszuk.net> > *Date: *Wednesday, January 12, 2022 at 6:07 AM > *To: *Aijun Wang <wangai...@tsinghua.org.cn> > *Cc: *"Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org>, > lsr <lsr@ietf.org>, Linda Dunbar <linda.dun...@futurewei.com> > *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 <wangai...@tsinghua.org.cn> > 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. > > Or else, all the dynamic cost can’t be used within the IGP. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* lsr-boun...@ietf.org <lsr-boun...@ietf.org> *On Behalf Of *Les > Ginsberg (ginsberg) > *Sent:* Wednesday, January 12, 2022 1:14 PM > *To:* Linda Dunbar <linda.dun...@futurewei.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Linda - > > > > *From:* Linda Dunbar <linda.dun...@futurewei.com> > *Sent:* Tuesday, January 11, 2022 7:47 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; 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> > *Sent:* Monday, January 10, 2022 9:48 AM > *To:* Linda Dunbar <linda.dun...@futurewei.com>; 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%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 <lsr-boun...@ietf.org> *On Behalf Of *Linda Dunbar > *Sent:* Friday, January 7, 2022 11:29 AM > *To:* 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%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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
