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

Robert Raszuk <robert@raszuk.net> Sun, 08 August 2021 10:31 UTC

Return-Path: <robert@raszuk.net>
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 D5A193A24B0 for <ipv6@ietfa.amsl.com>; Sun, 8 Aug 2021 03:31:06 -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, HTML_MESSAGE=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=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 M6WV7lyRDqHP for <ipv6@ietfa.amsl.com>; Sun, 8 Aug 2021 03:31:01 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 87EC93A24A8 for <ipv6@ietf.org>; Sun, 8 Aug 2021 03:31:01 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id m18so7885178ljo.1 for <ipv6@ietf.org>; Sun, 08 Aug 2021 03:31:01 -0700 (PDT)
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=9uwya/H9ThlDo2fFrdk6BePi48JlFVB9An7C2INxziY=; b=USgeY1szhbhRXSVs77jv43UKg1ZEywSBEmQBpkc0HiN/elEqAUpbFt/B+Tb8YAthEN 4bPXAqLxPvQqF/xdvqkKruLqcjj/QK62pGSGKNASOPUGgmoQJJn3RvWCcOWSK2RS54E/ sF8apOAaXoRR1Nm84E+YUx+hE5hK6Zgz6AFTLoabdbAWq6coBR40+c3K0YhvYhx24IUJ Y9ilCidpVAMp29u0R6d/HCNex1CzjKWAkUlaNx+FjqTphdt75blAL6zV9K/VZ6JsfMeY s+ccFEiAul+PUPfRl+UrYSR/jtgFb+Dwo/u8g5X95Lw0TSV17n/+dbGRcFp/0G0V9LkR NLhw==
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; bh=9uwya/H9ThlDo2fFrdk6BePi48JlFVB9An7C2INxziY=; b=a6CSlgghdxlMacO8Llryz2T3XYjiPzYqLz9A7FHu1Cdnh4emJ7cnK1u0iQ+e5IJfeY xwLweo5PY9kzRyy/6REXIOWmbWxxC8ZCU+MnXYEPo7Dbkzdorlr3Kix/fkZpTTLH0ZQG 3fR46puqy45Kh1GEUMwls/H2OE3Jar/Q8C7jjkM4uwjkwKhLQYkdb9EO9488znAkM3Li zP9eY3Q2CrG8pU0DOnL9ejAhUqlOI0ig7DvE0hwW5J97UJddWG3mQYq/i5Nelzif31tf RzRNxncFpc49D7yWfGgRCk80WiwmfD51440iSTH3asvEPWUg5TE9a+/HLmjBHQnYm/Kn 6LVg==
X-Gm-Message-State: AOAM5324Yy57m2IsH6DWPZUFGV7gHHCwOzWC/sy/7JUNBre2mYQPWKvS O0dCidfQzOJNB+QmXz8CAh50E361kI7D78qoK+LICA==
X-Google-Smtp-Source: ABdhPJxsEzl24gBaxE91hZ4craYh01eyA3Pt68j1bF0UPJsw/TaO9eTMvxmK5GJtmPStuXUXR6lJghCoGcOdtXJbJuk=
X-Received: by 2002:a2e:3310:: with SMTP id d16mr12419146ljc.199.1628418657981; Sun, 08 Aug 2021 03:30:57 -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> <CALZ3u+YRfWspGYbFPQQyEGBxsS+0VhSAZq4MHWnWrMaW1HU-tQ@mail.gmail.com> <CAOj+MMF2Vr1LRin0WpBTM6UeRfi4FGQUpgp0SX4G2ftvtm23mA@mail.gmail.com> <CALZ3u+a_o8tTvBqRn2vQtrxMa8oZLA3oUgD8a_5ABg+FLPOqbg@mail.gmail.com>
In-Reply-To: <CALZ3u+a_o8tTvBqRn2vQtrxMa8oZLA3oUgD8a_5ABg+FLPOqbg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 08 Aug 2021 12:31:18 +0200
Message-ID: <CAOj+MMGqYUx29En9BRZLeLSzRJCY3+k1hRodL7WG5GGve6mQPQ@mail.gmail.com>
Subject: Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
To: Töma Gavrichenkov <ximaera@gmail.com>
Cc: Tom Herbert <tom@herbertland.com>, 6man WG <ipv6@ietf.org>, IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a7adbd05c909c347"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1xN1GOBPuv0mcHDeelvGymwmtPY>
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: Sun, 08 Aug 2021 10:31:07 -0000

>
> On Sun, Aug 8, 2021 at 2:47 AM Robert Raszuk <robert@raszuk.net> wrote:
> > if someone uses anycast to establish long lasting TCP sessions (say 12h)
> - Good Luck !
>
> Transport sessions cannot reliably last for 12 hours on the Internet.
> That's the thing.


The thing is that 1000s of people come to their desks at 8:00, they turn on
their financial application - which uses TCP - and turn it off at 17:00
local time. And the single session stays up just fine for 9h.  In fact
session stays much longer such that in such application there is hard stop
at 18 hours to kill the session. And such forced session killing does
happen a lot every day.

Of course - to make it crystal clear I would never endorse designing any
application like this - but when such apps were written X years ago
networking was taken as balck box abstraction shielded by a socket.  It is
just real proof that your point is simply not true.

> A single BGP route announcement takes some 30 seconds to propagate, and
> sometimes a route withdrawal takes more than 4 minutes.

That's a pure occurance of spreading FUD.

I do recommend running your own measurements or consult those who do it
well. For example Geoff. In fact his cats and data presented  illustrate
very well the point I was making earlier:

 https://blog.apnic.net/2019/05/15/the-speed-of-bgp-network-propagation/

And with the average of 4.3 of average AS path length maybe was something
in late 1990s where withdraws or first updates were subject to MRAI timer
in some implementations - that is just history.

Best,
R.