Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert Raszuk <robert@raszuk.net> Thu, 13 January 2022 17:35 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799773A186D for <lsr@ietfa.amsl.com>; Thu, 13 Jan 2022 09:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe9HIt7ToZfU for <lsr@ietfa.amsl.com>; Thu, 13 Jan 2022 09:35:42 -0800 (PST)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716A53A1869 for <lsr@ietf.org>; Thu, 13 Jan 2022 09:35:42 -0800 (PST)
Received: by mail-vk1-xa32.google.com with SMTP id bj47so4289324vkb.13 for <lsr@ietf.org>; Thu, 13 Jan 2022 09:35:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6yc4ESYIDZgxYJK7k1WJpz5mQn4eQiGHnUL7TmQgCik=; b=eLe44fI9B4C8gTFBcw3Ry5JR88Gaw1ImVMwrU1uAo+wbBkpFvkpyqIBhzOVOSguIcB 0zCw/XjtRpr9RISWGLD8/XFy1ARhb3H6Vce4aE4BLqYaGpn4t5lst+slcfN5y6h84DGL u0cpDneTEuiX9y+G+U2fW1dctsNhcMicIg2Fll5i80EISD0K/U1WY6f/e9OWD06KTalU 983idvjmfr3wC90/nC09Pa0eloZNahpnPHYLaI0plnFKzV61If1CyknBqCHIANw+vWxB /ZSe4eEIpSLbC0CZF/BIr4WYjlORvhsUPC45ZGaEFHnBlSo1e+v3NtmCRWBVREUzMWG8 7hkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6yc4ESYIDZgxYJK7k1WJpz5mQn4eQiGHnUL7TmQgCik=; b=rFzZJI9kv+08y+79tq0z0ZPXijerBoHI7vXPkaua/rZrvepdlaudAvU+MmZYU0W/US PqIlKDcxYNg81ibLXX0CfE7K4fkap2AbM15WHE7vWcXC80UHG1MftHmSezS0bAB1jjaA vJ8PdJ5jODVWtDiO83Co4yaBI2yEXF0+k0pO6jDGqbxOXzqkVSabxXjrswxC8O/JsWRL WwDtP3O8weu6psPQHAbmODbBCbZxmIfvsoMRShVxBgcn7goR5n8yAwtRaKTT7zRV2WWO uOlIsdrCM96D8TMVIRzr2iJ4zR9JtZKJoW/Cs2mXXFJ78Hi/R40sdSjpo6m7zzbHsQi/ eZRw==
X-Gm-Message-State: AOAM531mWchWe+E5H8tILn04tB1ZdHsX+e6i+wgVrlWqIb3Iyc+mAtXy kDBbw8AOCfdCWY6RsmYdmmgWMTLcqz+EKdGh9XayDw==
X-Google-Smtp-Source: ABdhPJybYQc7wA6/ZT49IIv2auFPtxXSz7QnKackPbcK3FkNvPuNcY9TmSYZgJSpi89B63WZrAbd6MUXcxuMnswAs+U=
X-Received: by 2002:a1f:164a:: with SMTP id 71mr2892614vkw.26.1642095339060; Thu, 13 Jan 2022 09:35:39 -0800 (PST)
MIME-Version: 1.0
References: <CO1PR13MB49208C0CFE0AE200E9654D62854D9@CO1PR13MB4920.namprd13.prod.outlook.com> <BY5PR11MB43374CE0329A2D0D4CBBB56CC1509@BY5PR11MB4337.namprd11.prod.outlook.com> <CO1PR13MB49209FB2780A390C060981D285529@CO1PR13MB4920.namprd13.prod.outlook.com> <BY5PR11MB43373269E621CCC90F47D650C1529@BY5PR11MB4337.namprd11.prod.outlook.com> <CO1PR13MB492084E011B67AFF7EB45B3585529@CO1PR13MB4920.namprd13.prod.outlook.com> <BY5PR11MB43376DA8FD239B220AAA7F03C1529@BY5PR11MB4337.namprd11.prod.outlook.com> <CO1PR13MB4920EDA93692C2BE3CC49F7A85529@CO1PR13MB4920.namprd13.prod.outlook.com> <CAOj+MMH0ockwESPepB0PH-_jHxtSJ2+n0cJCsm-oGGB6ztvQtQ@mail.gmail.com> <CO1PR13MB4920561C1237ECD319B2C17B85529@CO1PR13MB4920.namprd13.prod.outlook.com> <CAOj+MMEMt845bRwhn-KTTx=7DvinocYc0JYZyzPp9BR7jC1C+w@mail.gmail.com> <CABNhwV1dB5TwtibkMthxamsSZvtm36h1vrGOhtucw8fi4avfFw@mail.gmail.com> <BY5PR11MB4337053667F17BB2F2B4BA3BC1539@BY5PR11MB4337.namprd11.prod.outlook.com> <CABNhwV0=i448_7m60ownptafJyb8VE0un_s3NVNTw8=JdZF7UQ@mail.gmail.com> <CAOj+MMGj7bnhDSr0KrW5SffZmPfmrTYRy1P4h6McT+UdFuxLuA@mail.gmail.com> <CAOj+MMFRpsX6es7GphepFb6WUAge8zRAXz7fgZrTdWmf6SnT_Q@mail.gmail.com> <CO1PR13MB49206E27840D5D6470D4AE2385539@CO1PR13MB4920.namprd13.prod.outlook.com> <CAOj+MMFBArpO5UHzef=4UfvXARg+n5GXhtQZvWqXi30AUjDtQQ@mail.gmail.com> <CO1PR13MB4920009EE5BFACBE0E67D27D85539@CO1PR13MB4920.namprd13.prod.outlook.com> <BY5PR11MB4337AD0F1699540E6821B052C1539@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MME+G2-6yGUDDY73vmBGBYbt0NCGNzr-PF0VG0akOShTAA@mail.gmail.com> <CO1PR13MB4920744645D04CB2BDFF0AF185539@CO1PR13MB4920.namprd13.prod.outlook.com> <CAOj+MMGeRO++bucE3EqFzKTLbNEXB+d-LRYNyeCgSXKjww_NTA@mail.gmail.com> <CO1PR13MB492090B4B14D4E633874AFF185539@CO1PR13MB4920.namprd13.prod.outlook.com>
In-Reply-To: <CO1PR13MB492090B4B14D4E633874AFF185539@CO1PR13MB4920.namprd13.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 13 Jan 2022 18:35:26 +0100
Message-ID: <CAOj+MMGQwej8btpU9ZRtZUoFR4eh82Dmq5CO0_2QMpbWFTCE8g@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/related; boundary="0000000000005f5f7405d57a1d2f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ztTgQ_yMj-iO35jnVU8yxlDVTtA>
Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2022 17:35:48 -0000
I am asking not for static assigned values by cfg. I am asking for dynamic values being as part of site cost your draft is describing here: The "Site-Cost", which is derived from "site-capacity + load measurement + Preference + xxx", can be raw measurements collected by the egress routers based on the instructions from a controller or can be informed by the App Controller periodically. Draft says "collected" - I am asking how is it collected ? Thx On Thu, Jan 13, 2022 at 6:29 PM Linda Dunbar <linda.dunbar@futurewei.com> wrote: > Robert, > > > > Egress routers can be assigned with a site preference index for a specific > set of prefixes attached. > > > > Linda > > > > *From:* Robert Raszuk <robert@raszuk.net> > *Sent:* Thursday, January 13, 2022 11:27 AM > *To:* Linda Dunbar <linda.dunbar@futurewei.com> > *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Gyan Mishra < > hayabusagsm@gmail.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Linda, > > > > Let me ask again ... How does ISIS process on the egress router learns the > load of the "attached" load balancer ? > > > > As far as your comment on using or not using anycast addresses I disagree, > but we will not be spamming LSR WG list to discuss this further. > > > > Thx a lot, > > R. > > > > On Thu, Jan 13, 2022 at 6:18 PM Linda Dunbar <linda.dunbar@futurewei.com> > wrote: > > Robert, > > > > The draft is about distributing the Site Index and preferences of the > Egress routers to which the application load balancers (or instances) are > attached. > > > > Thanks, Linda > > > > *From:* Robert Raszuk <robert@raszuk.net> > *Sent:* Thursday, January 13, 2022 10:52 AM > *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com> > *Cc:* Linda Dunbar <linda.dunbar@futurewei.com>; Gyan Mishra < > hayabusagsm@gmail.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > and I agree that using the IGP/Flex Algo as you are proposing is a > viable solution. > > > > Except that IGP usually does not run between application server and load > balancer ... > > > > > > On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) < > ginsberg@cisco.com> wrote: > > Linda – > > > > Are you saying that the scenario you are trying to address is to have a > given “transaction” go to the currently closest/most lightly loaded > Application Server? > > And there is no intent to support for long lived connections? > > > > If so, then this isn’t really a load balancing issue and I agree that > using the IGP/Flex Algo as you are proposing is a viable solution. > > The concern then becomes the rate of updates to the new Prefix Metric. If > this changes too rapidly this will heavily consume network resources by > triggering flooding, SPF, forwarding plane updates at a high rate. > > Can you put some language in the draft that indicates the expected rate of > updates to the metric and some guidelines on limiting the frequency? > > > > Thanx. > > > > Les > > > > > > *From:* Linda Dunbar <linda.dunbar@futurewei.com> > *Sent:* Thursday, January 13, 2022 7:58 AM > *To:* Robert Raszuk <robert@raszuk.net> > *Cc:* Gyan Mishra <hayabusagsm@gmail.com>; Les Ginsberg (ginsberg) < > ginsberg@cisco.com>; lsr@ietf.org > *Subject:* RE: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Robert, > > > > For your scenario of TCP flows lasting more than 8~18 hours, multiple > server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST > address). Each of those instances should have one distinct IP address. > > > > The draft is for different scenario where application are instantiated at > multiple locations behind multiple App Layer Load Balancers. They have > relative short flows that can go to any App Layer Load Balancers. Multiple > Load Balancers for those applications are assigned with the same IP > address. In Kubernetes, multiple load balancers for one type of > microservices are assigned with one single Virtual IP address, so that the > network can forward as one single destination. > > > > Linda > > *From:* Robert Raszuk <robert@raszuk.net> > *Sent:* Thursday, January 13, 2022 9:37 AM > *To:* Linda Dunbar <linda.dunbar@futurewei.com> > *Cc:* Gyan Mishra <hayabusagsm@gmail.com>; Les Ginsberg (ginsberg) < > ginsberg@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > Flows among micro-services are very short. > > > > While that can be true - there is nowhere in the document a restriction or > even a warning that this solution is aiming for short lived flows only and > that users should be well aware about drastic nature of proposed > mechanism to their established flows. > > > > In one of the companies I worked for average TCP flow duration was > anywhere from 8-18 hours and it was a very drastic event for the user to > loose it in the middle of the day. Various means where taken and applied > to protect such sessions from any form of disconnects. > > > > I think we are shooting here with the wrong weapon to the target. > > > > Thx, > > R. > > > > On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar <linda.dunbar@futurewei.com> > wrote: > > Robert, > > > > Your link to Traefik adds more reasons why “Site index and preference” > should be distributed by IGP: > > - Site index and preferences for a cluster of micro-service instances > are rarely dynamically changed. Most of those values are configured. > Therefore, the oscillation is minimal. > - Flows among micro-services are very short. Put less requirements to > flow affinity. > - > > > > Linda > > > > > > *From:* Robert Raszuk <robert@raszuk.net> > *Sent:* Thursday, January 13, 2022 5:00 AM > *To:* Gyan Mishra <hayabusagsm@gmail.com> > *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Linda Dunbar < > linda.dunbar@futurewei.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > And just to provide a sound alternative to the objective of this work. > > > > Please consider using Traefik - https://traefik.io/ > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pQDpf5Bl4odcr2ZowdxW9lmkJDnbvdX4YY3%2BnDU1ZCU%3D&reserved=0> > > > > Thx, > > R. > > > > > > On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk <robert@raszuk.net> wrote: > > Gyan, > > > > I see what the draft is trying to do now. /* I did not even consider this > for the reason described below. */ > > > > But what you wrote requires little correction: > > > > "So now the server you are on gets overloaded and a site cost gets > advertised in the IGP at which point the connection receives a TCP reset" > > > > if you *s/connection/all connections/* then you quickly realize that what > is proposed here is a disaster. > > > > Breaking all existing flows going to one LB to suddenly timeout and all go > to the other LB(s) is never a technique any one would seriously deploy in a > production network. > > > > Leave alone that doing that has potential to immediately overload the > other LB(s)/server(s) too. > > > > For me the conclusion is that IGP transport level is not the proper layer > to address the requirement. > > > > Cheers, > > Robert. > > > > > > On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > > > Hi Les > > > > Agreed. > > > > My thoughts are that the context of the draft is based on an Anycast VIP > address of a server which is proximity based load balancing and not > necessarily ECMP/UCMP and only if the proximity is the same for multiple > paths to the Anycast VIP would there be a ECMP/UCMP possibility. > > > > Let’s say if it’s proximity based and one path is preferred, the flow will > take that path. So now the server you are on gets overloaded and a site > cost gets advertised in the IGP at which point the connection receives a > TCP reset and flow re-establishes on the alternate path based on the site > cost and remains there until the server goes down or gets overloaded or a > better path comes along. > > > > For ECMP case, ECMP has flow affinity so the flow will stay on the same > path long lived until the connection terminates. > > > > So now in ECMP case the flow hashed to a path and maintains its affinity > to that path. Now all of sudden the server gets overloaded and we get a > better site cost advertised. So now the session terminates on current path > and establishes again on the Anycast VIP new path based on the site cost > advertised. > > > > The failover I believe results in the user refreshing their browser which > is better than hanging. > > > > As the VIP prefix is the only one that experiences reconvergence on new > path based on site cost if there is any instability with the servers that > will be reflected to the IGP Anycast prefix as well. > > > > Is that a good or bad thing. I think if you had to pick your poison as > here the issue Linda is trying to solve is a server issue but leveraging > the IGP to force re-convergence when the server is in a half baked state > meaning it’s busy and connections are being dropped or very slow QOE for > end user. If you did nothing and let it ride the the user would be stuck > on a bad connection. > > > > So this solution dynamically fixed the issue. > > > > As far as oscillation that is not a big deal as you are in a much worse > off state connected to a dying server on its last leg as far as memory and > CPU. > > > > This solution I can see can apply to any client / server connection and > not just 5G and can be used by enterprises as well as SP for their > customers to have an drastically improved QOE. > > > > I saw some feedback on the TLV and I think once that is all worked out I > am in favor of advancing this draft. > > > > Kind Regards > > > > Gyan > > > > > > On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < > ginsberg@cisco.com> wrote: > > Gyan – > > > > The difference between ECMP and UCMP is not significant in this discussion. > > I don’t want to speak for Robert, but for me his point was that IGPs can > do “multipath” well – but this does not translate into managing flows. > > Please see my other responses on this thread. > > > > Thanx. > > > > Les > > > > > > *From:* Gyan Mishra <hayabusagsm@gmail.com> > *Sent:* Wednesday, January 12, 2022 5:26 PM > *To:* Robert Raszuk <robert@raszuk.net> > *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Linda Dunbar < > linda.dunbar@futurewei.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > Robert > > > > Here are a few examples of UCMP drafts below used in core and data center > use cases. > > > > https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-unequal-lb-15&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0Cb8RsTgPhCmPuM%2FlI5p96qOI1xOv04539VnBm4pDCU%3D&reserved=0> > > > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-weighted-hrw-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=202YnLqpE835cdqWTeir%2BH5AYr9phcn4rnX9hmbpRno%3D&reserved=0> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-link-bandwidth&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pdDptGH2ZZiAp18e%2FojL9jt3tZmWLHsN64RK0u%2BSCuQ%3D&reserved=0> > > > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=08lqKu6kbqeC6HVePOnI9aUc0VPPUM%2B4mPQmg93UwZ0%3D&reserved=0> > > > > > > > > There are many use cases in routing for unequal cost load balancing > capabilities. > > > > Kind Regards > > > > Gyan > > > > On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk <robert@raszuk.net> wrote: > > Linda, > > > > > IGP has been used for the Multi-path computation for a long time > > > > IGP can and does ECMP well. Moreover, injecting metric of anycast server > destination plays no role in it as all paths would inherit that external to > the IGP cost. > > > > Unequal cost load balancing or intelligent traffic spread has always been > done at the application layer *for example MPLS* > > > > Thx a lot, > > R. > > > > On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar <linda.dunbar@futurewei.com> > wrote: > > Robert, > > > > Please see inline in green: > > > > *From:* Robert Raszuk <robert@raszuk.net> > *Sent:* Wednesday, January 12, 2022 1:00 PM > *To:* Linda Dunbar <linda.dunbar@futurewei.com> > *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Hi Linda, > > > > *[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.* > > *[Linda] Most vendors do support flow based ECMP, with Shortest Path > computed by attributes advertised by IGP.* > > > > I am with Les here. ECMP has nothing to do with his point. > > > > [Linda] Les said that “IGP only influence forwarding on a per packet > basis”. I am saying that vendors supporting “forwarding per flow” with > equal cost computed by IGP implies that forwarding on modern routers are > no longer purely per packet basis. > > > > > > Draft says: > > > > *When those multiple server instances share one IP address (ANYCAST), the > transient network and load conditions can be incorporated in selecting an > optimal path among server instances for UEs.* > > > > So if we apply any new metric to indicate load of a single anycast address > how is this going to help anything ? > > > > [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple > paths with the same routing distance. > > > > > > You would need a mechanism where the network is smart and say per src-dst > tuple or more spreads the traffic. IGP does not play that game today I am > afraid. > > [Linda] There is one SRC and multiple paths to one DST. IGP has been used > for the Multi-path computation for a long time. > > > > Thank you, Linda > > > > Thx a lot, > R. > > > > > > > > > > > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427186142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AwBn%2Bqz1xsRrnbxfDLQQEEsnnb%2Bq7ama2xRGwmlvDIg%3D&reserved=0> > > -- > > [image: Image removed by sender.] > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427342360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yfD5DEan2qhnN8REWk75DjWJmmXIErDXXj8pzn9E1BQ%3D&reserved=0> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C9683da12809c47d81bde08d9d6b9f380%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776916427342360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yfD5DEan2qhnN8REWk75DjWJmmXIErDXXj8pzn9E1BQ%3D&reserved=0> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > >
- [Lsr] Seeking feedback to the revised draft-dunba… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Tony Li
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Tony Li
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Acee Lindem (acee)
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Gyan Mishra
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Gyan Mishra
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Les Ginsberg (ginsberg)
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Gyan Mishra
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… John E Drake
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… John E Drake
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Gyan Mishra
- Re: [Lsr] Seeking feedback to the revised draft-d… Gyan Mishra
- Re: [Lsr] Seeking feedback to the revised draft-d… Acee Lindem (acee)
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Acee Lindem (acee)
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Acee Lindem (acee)
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Acee Lindem (acee)
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Muthu Arul Mozhi Perumal
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Acee Lindem (acee)
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Robert Raszuk
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Acee Lindem (acee)
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Linda Dunbar
- Re: [Lsr] Seeking feedback to the revised draft-d… Aijun Wang