IETF Logo Mail Archive

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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 10 August 2021 12:05 UTC

Return-Path: <vasilenko.eduard@huawei.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 A15343A11DE; Tue, 10 Aug 2021 05:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BhsGLmLHzO1u; Tue, 10 Aug 2021 05:05:36 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FF43A11DC; Tue, 10 Aug 2021 05:05:35 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GkWq01t53z6DKRW; Tue, 10 Aug 2021 20:05:00 +0800 (CST)
Received: from msceml701-chm.china.huawei.com (10.219.141.159) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 10 Aug 2021 14:05:32 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 10 Aug 2021 15:05:31 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Tue, 10 Aug 2021 15:05:30 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Töma Gavrichenkov <ximaera@gmail.com>, Gyan Mishra <hayabusagsm@gmail.com>
CC: 6man WG <ipv6@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Theodore Ts'o <tytso@mit.edu>, IETF discussion list <ietf@ietf.org>
Subject: RE: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
Thread-Topic: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
Thread-Index: AdeITEcEgFJ2cblRTf2jVtlvbXQCSf//1HuAgAAKBoCABbMDAIAAHJEAgADFrgCAAAXCAIAAJhUAgAAd7wCAAA2xgIAADq8AgAAI1wCAADD9AIAABIYAgAAUnoCAAFXlgIAAePGAgAAF3QCAAAEcAIAAAfiAgAB9UACAAMsxgIAAC5oAgABYuACAAAWiAIAAEPyAgAAEeICAAAiaAIAAE5SAgAB7Z4CAADMQgIAAOYIA//+qiYA=
Date: Tue, 10 Aug 2021 12:05:30 +0000
Message-ID: <c4a47ca371e4421aa7899e1a671397fe@huawei.com>
References: <CALZ3u+aP=v_1=w1xqfEKof7Cc6Ba3pwOYV3O=0b=NxS4hRWhiA@mail.gmail.com> <YRBdZrKV+MrrhUCG@mit.edu> <CALZ3u+aBdE3Bw3_ry+CuV4tS016c4mWewJFpr0aCbBnwj70Vzg@mail.gmail.com> <a3833e04-c123-ef52-95f9-cae80a1390e7@foobar.org> <CAMm+LwiAbiK618+kY9JTLr7_mQd-E5TKyNsGqOLrGQoLzjJo=A@mail.gmail.com> <CALZ3u+bLVUZf1fTHQvAVzOnToiPcsXEyTNt56hNAXz4=-G5-6w@mail.gmail.com> <CAHw9_i+k9x1g3bcst6rHcXpesEVwnPtV6DzsFAxi8dC6CRMZPw@mail.gmail.com> <CALx6S346mqNaE+s1DH7S7RutTpzfrC5oX1No5Jb72sTvVQjtpQ@mail.gmail.com> <CAHw9_i+ELJS_xqcEHM4raq+f=PZ5yw1ptfG3a6VypZmWTo11-A@mail.gmail.com> <CAOj+MMGzWq1OrwBQW_Mz4gB+z9wJSdQnFCkTmWiHi_Tm3ty47g@mail.gmail.com> <YRHx4c8/nOh5aXN1@mit.edu> <CABNhwV1HdSrzHDLhuSMaWY+9UaHnFYaYo75fN3+JMgMnf+Pnhw@mail.gmail.com> <CALZ3u+Z4XYf0gLrhsA5D1pJz5O2Wn6fpBugh6LeTOkGb9Pn=7A@mail.gmail.com>
In-Reply-To: <CALZ3u+Z4XYf0gLrhsA5D1pJz5O2Wn6fpBugh6LeTOkGb9Pn=7A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.89]
Content-Type: multipart/alternative; boundary="_000_c4a47ca371e4421aa7899e1a671397fehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7AAGCxIm9j4b7_iwipYa96Oa224>
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: Tue, 10 Aug 2021 12:05:42 -0000

After the hash would be recalculated, the flow may be pushed to the same broken link or node.
Is probability 50% or 75% to repair problem good enough? (for ECMP to 2 or 4 paths)

Should RTO give a chance to IGP to repair the problem in a normal way (1s?)
Ed/
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Töma Gavrichenkov
Sent: Tuesday, August 10, 2021 12:55 PM
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: 6man WG <ipv6@ietf.org>; Phillip Hallam-Baker <phill@hallambaker.com>; Theodore Ts'o <tytso@mit.edu>; IETF discussion list <ietf@ietf.org>
Subject: Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?

Peace,
On Tue, Aug 10, 2021, 9:31 AM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:
a patch that makes default less aggressive by restoring the original default behavior to recompute hash only after multiple RTOs.

Let's now talk about hacks, right?

A flow is basically a stream of similar data within one or more connections.  This is an application layer concept.  Architecturally, it may change on a connection if the data flow within the connection changes.

E.g. we've established a connection to [youtube DNS A entry]:443, downloaded the hypertext, but now we're going to reuse the same established connection to stream video, so the network should better treat that connection somehow differently now.

The flow label was never supposed to be a legitimate control over routing.  It shouldn't change over one, two, or a hundred RTOs.  It generally only changes when the flow becomes different.
I believe this was so obvious to the authors of the original specification in 2003 that they even forgot to actually state it.

What Tom proposed is, of course, way better than how it works now.  Especially the socket option — yay, Linux is finally going to implement the "MUST" in RFC3697#3!  We harbour the hope that other operating systems would do the same good thing.

But the idea I'm trying to drive home is: fixing (temporary) network delivery issues via the control of a strictly application level feature is among the dirtiest of the hacks possible.

And it kind of amazes me how people call anycast a hack (while it's perfectly the behaviour natural to the Internet, a global self-healing internetwork, as designed in 1970s) and still consider this a legitimate behaviour.

--
Töma

v2.23.0 | Report a Bug | By Email