Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?

Töma Gavrichenkov <ximaera@gmail.com> Sat, 07 August 2021 22:23 UTC

Return-Path: <ximaera@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8C3A08B9; Sat, 7 Aug 2021 15:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, 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=gmail.com
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 p5be8oU8Idas; Sat, 7 Aug 2021 15:23:17 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 3E5183A08B7; Sat, 7 Aug 2021 15:23:17 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id d6so18642969edt.7; Sat, 07 Aug 2021 15:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IkpzB1zUb23PXJd3GbcKIMQSAOKWA9bJHoSFEvKPaO0=; b=fyZmKwdvZT/GbwRgLW1voFhHWQGarLXxvHWmAy48d+/xlFIN02Gzcx5OQHyR6zhukN /+rpNtgYmDu4Ur9iaPAQ5dA1iuWB3RLuY02csGrqYOhKP6sR63nxgZEafb4q+RlEoYUA Pa1sGkEwIS3u14VmTTgmX86Zp607E0TA0U+QKkntHmEygQU8Bc8WUJfl/kxj21Ya8i68 qKmgh34wy0WDI1e9thMHJXDUzjBYy6UjpTKpc4W7TZ7hJQxMC1CMT4HBJU4M8RvBDxyV CGjLo+2lgQq06Dd1D8KHzJn8V2f4LsVZ/0aUnoQbPDrLemw/Y9GJG8HuTEafR+IuvaE5 ROHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IkpzB1zUb23PXJd3GbcKIMQSAOKWA9bJHoSFEvKPaO0=; b=d1nHTOxuUWJPFGpYZ3nnKnowjyBxXuTCfb/AOLWALjw3ZYCuxByMuXso1u5+skLZzt IsmO07uIUiGzzDgv8JLeIDWNh2o1rFF2NjzTOaMas6ezfM5Dv0LGo9wNA40gvolY1+kI mCx2QX8HWkS1y34UQXurFUKr6lSWm0vlDO5iCbFy7RrfLQWePSr9woBTe2TY8nQIBGoR YuHqQaJusNMHOZ0wpQeA94sDbmi+PF//ka3O1s/e0eMY+pHe+/VRiK36WCpZ6xY+GEh8 IZhuOFHWKug/hCN51T4o1Y9ODN5DEu4ubIh5YKCnq3cFQa5aUAhMY5Gm3IaOspTBVwJm xRPQ==
X-Gm-Message-State: AOAM531L18JhIs+66984donkNIXbwj1EY1AxL3r3T6FmcYpC8o0/v7xo ISjvyw1GI7UcSVDGedn//cOdIR7aMORTLOlDOPU=
X-Google-Smtp-Source: ABdhPJzcYZslS3l+9rc2dnlsFpjWbmy9NbJLL5XX8kN8bgx9nn+mOpMUgk/RyZ1Loe7M/mv0fqy1WtDJIv39LWyiQO0=
X-Received: by 2002:a05:6402:104b:: with SMTP id e11mr4411751edu.62.1628374993510; Sat, 07 Aug 2021 15:23:13 -0700 (PDT)
MIME-Version: 1.0
References: <db8c1a5534e9412ebcfa37682d75f862@huawei.com> <C23D7023-B5B7-47C6-8AC5-65A98822A724@lurchi.franken.de> <CANMZLAZGawUjRhSSE_rA8AyqMx=mx1WFeJ_tZq0KVEXJd2XBfQ@mail.gmail.com> <20210807014730.GA28901@faui48f.informatik.uni-erlangen.de> <CAO42Z2yezZh5-B0PwCuNt2FUMAW-FjMK8QZ8uL4TsPhs26zziw@mail.gmail.com> <20210807151716.GA3098@faui48f.informatik.uni-erlangen.de> <CALZ3u+a_7XQ+R8mV+9KzwRwxa0riP-QD_2R69ycV0NL9jy_S3Q@mail.gmail.com> <20210807175410.GA63079@faui48f.informatik.uni-erlangen.de> <CALx6S36b33LD_hNFvptOJuny4g98=dhq3RtKsGeLx3ks-yYjFg@mail.gmail.com> <6F63D7FE-8768-4BD8-846E-61E50E44228F@lurchi.franken.de> <CALx6S36pbw2angEmDpu5DnX2nix9KgxFs7ExU17x+JXQFs23TA@mail.gmail.com> <CALZ3u+Yt2X3faSVW7K0eaxmaQy6iA6p4=f0c4E_F4CP0tfjHYw@mail.gmail.com> <CAOj+MMHu9wSuG87_vBaGNY0oU0kMu9KPFPAwcP9+eFviCMErPg@mail.gmail.com>
In-Reply-To: <CAOj+MMHu9wSuG87_vBaGNY0oU0kMu9KPFPAwcP9+eFviCMErPg@mail.gmail.com>
From: Töma Gavrichenkov <ximaera@gmail.com>
Date: Sun, 08 Aug 2021 01:23:02 +0300
Message-ID: <CALZ3u+YoTG7nv+4Mt+ik9SvGWi0qtUtd6WC-P6GYi0LAoyWPiQ@mail.gmail.com>
Subject: Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
To: Robert Raszuk <robert@raszuk.net>
Cc: Tom Herbert <tom@herbertland.com>, 6man WG <ipv6@ietf.org>, IETF discussion list <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/oFd-se2ElT_7azZrK-63ZNdOuAI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Aug 2021 22:23:22 -0000

Peace,

On Sun, Aug 8, 2021 at 1:09 AM Robert Raszuk <robert@raszuk.net> wrote:
> Internet last time I checked uses IP. IP is connection less by design. So is entire Internet architecture.
> Anycast in a connection less fashion - meaning stateless - will work just fine - pretty much in all cases.
> But using connection less forwarding plane and transporting connection oriented protocols (like TCP) only works between solid anchors (read endpoints).

The entire idea that there are any "solid" anchors on the Internet
kinda defeats the purpose of the Internet, doesn't it?

We're now accustomed to the Internet where the _packet_flows_ are
kinda stable.  This is how it works, in practice, 95% of the time b/c
of giant intercontinental fiber lines, b/c ISPs have their SLAs, etc.

This is probably the shiny moment in time this is true, but it's not
supposed to stay for much longer, in part because the ISPs are
merging, the controlling entities want some control over that,
peerings break, but mainly because it was never supposed to go this
way, since the Internet is _inherently_peer_to_peer_, with no
guarantee over the paths, with no SLAs over the paths and the RTTs.

It's not the anycast that doesn't meet the concept of long-living
stable connections, it's the concept of stable connections that
doesn't fit into the architecture of the Internet.


> And this is not only about flow label and hashing. Internet routing continues to churn. Every second routing may decide for you to prefer some other BGP path and your anycast destination may end up in different destination naturally only by following the destination routing paradigm.

Exactly, and you need to get your applications to be aware of that,
and not to shift this responsibility to the network which actually
bears no responsibility, in particular over that.


> PS. Of course there are more smart ways to use anycast for TCP. Those involve attracting packets only for further forwarding to the consistently selected servers/gateways.

I believe this was covered before on the thread, and I don't see any
answers here to the issues raised before.

--
Töma