Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)

Toerless Eckert <tte@cs.fau.de> Mon, 04 November 2019 08:43 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 E4853120983 for <ipv6@ietfa.amsl.com>; Mon, 4 Nov 2019 00:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level:
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, 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 S45gn632VDek for <ipv6@ietfa.amsl.com>; Mon, 4 Nov 2019 00:43:06 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415BD12083C for <6man@ietf.org>; Mon, 4 Nov 2019 00:43:06 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4870D54802E; Mon, 4 Nov 2019 09:43:01 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 43C59440015; Mon, 4 Nov 2019 09:43:01 +0100 (CET)
Date: Mon, 04 Nov 2019 09:43:01 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Nick Hilliard <nick@foobar.org>
Cc: 6MAN <6man@ietf.org>
Subject: Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)
Message-ID: <20191104084301.GN2287@faui48f.informatik.uni-erlangen.de>
References: <157277906705.13535.345852921709779212.idtracker@ietfa.amsl.com> <CAO42Z2wSU-puDaQq-PzTCTE=S3qyqUNrPhH0pgOEO_d3=StnHA@mail.gmail.com> <b97c15c0-b1fe-0d78-0897-5fc4bb6a9a34@foobar.org> <B42E6EED-5620-49BE-BB3D-B1CF6F04A1CC@gmail.com> <20191103212712.GK2287@faui48f.informatik.uni-erlangen.de> <B2A9EAB8-BF52-4302-BB77-70EE252F45E5@gmail.com> <20191103225223.GL2287@faui48f.informatik.uni-erlangen.de> <81f02a3b-fc37-348d-728e-78f33355a729@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <81f02a3b-fc37-348d-728e-78f33355a729@foobar.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kNxhZQERX25YQrGzIHa196yvw4U>
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: Mon, 04 Nov 2019 08:43:12 -0000

You are just arguing about the quantitative relevance of the
problem. I am talking about the qualitative architectual gap.

If we're not proactively fixing architectural issues in TCP/IP,
we will just ensure that IP does not proliferate into networks
where assumptions like the one you are making based on existing
practices do not work anymore. Those networks surely would instead
use some L2(.5) mechanism that can faster be improved. Why do you
think we have all L2 in most wireless/mobile access ?

TCP/IP WWW : world wide workarounds

Cheeers
    Toerless

On Sun, Nov 03, 2019 at 11:51:43PM +0000, Nick Hilliard wrote:
> Toerless Eckert wrote on 03/11/2019 22:52:
> > Aka: DNS over TCP would likely work in most cases, but not if for
> > example there is an ECMP node to two root servers along the path.
> Most n-tuple hashes used as load balancing discriminants tend to use src/dst
> ip, protocol and src/dst port.  Anycast TCP works well for tcp sessions
> which only involve a couple of exchanges back and forth, i.e. it's generally
> fine for short-lived dns-over-tcp conversations, even if there are ecmp /
> lag links somewhere along the path.
> 
> Nick
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
tte@cs.fau.de