Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability

"Philipp S. Tiesel" <philipp@tiesel.net> Thu, 23 November 2023 08:37 UTC

Return-Path: <philipp@tiesel.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 19DF2C14F738 for <ipv6@ietfa.amsl.com>; Thu, 23 Nov 2023 00:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9kl4WD0Kmlc for <ipv6@ietfa.amsl.com>; Thu, 23 Nov 2023 00:37:48 -0800 (PST)
Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FE3C15199D for <ipv6@ietf.org>; Thu, 23 Nov 2023 00:37:45 -0800 (PST)
X-Envelope-From: philipp@tiesel.net
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [IPv6:2a0a:4580:1018:0:0:0:0:40]) by einhorn.in-berlin.de with ESMTPS id 3AN8baEv2212455 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 23 Nov 2023 09:37:36 +0100
Received: from x-berg.in-berlin.de ([217.197.86.42] helo=smtpclient.apple) by x-berg.in-berlin.de with esmtpa (Exim 4.94.2) (envelope-from <philipp@tiesel.net>) id 1r65DM-0000Do-7b; Thu, 23 Nov 2023 09:37:36 +0100
From: "Philipp S. Tiesel" <philipp@tiesel.net>
Message-Id: <4202668E-EEBE-4FA6-9801-F2A9FC92CBD8@tiesel.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7A18FDD8-3EBF-4865-AD67-A056A2125DC1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Thu, 23 Nov 2023 09:37:25 +0100
In-Reply-To: <CAJU8_nVQFvp_5ZnkByCvBeA7wFz9J5FVAeud2CD1Xd4UkyL_3Q@mail.gmail.com>
Cc: Ole Trøan <otroan=40employees.org@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
To: Kyle Rose <krose=40krose.org@dmarc.ietf.org>
References: <CAJU8_nV2QoGjZoegcUSXELqgeqW6OheTt32qq6YQ5XV0g5MPQw@mail.gmail.com> <10D22CA5-CD7A-471A-B4A9-21B77D16F5F7@employees.org> <CAJU8_nVQFvp_5ZnkByCvBeA7wFz9J5FVAeud2CD1Xd4UkyL_3Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/r9j2XEf6-YZIBc-VL6if-q2daBU>
Subject: Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 23 Nov 2023 08:37:50 -0000

Hi,

> On 21. Nov 2023, at 20:39, Kyle Rose <krose=40krose.org@dmarc.ietf.org> wrote:
> 
> On Tue, Nov 21, 2023 at 2:30 PM Ole Trøan <otroan=40employees.org@dmarc.ietf.org <mailto:40employees.org@dmarc.ietf.org>> wrote:
>> Covered most of this in 7157. Including signaling policy to hosts. 
> Good to know. I'll read that in-full.
> 
>> In your straw man implementation try implementing an application using the BSD socket API and make sessions survive any set of failures along the two paths. Well, try with any networking api actually.  :-)
> 
> This is mobility, and I regard mobility as an unsolved problem, and one that is potentially too complicated to solve transparently (witness: LISP).

Right. However, there are transport protocols like QUIC and MPTCP that can do it without too much hassle for the application.
I really prefer a mobility mechanism that is end to end and works on some devices now. instead of discussing about L3 mobility mechanisms we might or more likely might not getting deployed eventually. 

> In a failover scenario, I assume all connections tied to the now-down path (e.g., through provider-delegated addresses) are broken. That's fine for the use cases I am concerned about. Past some point, I'm okay with applications having to take basic remediation measures, like reconnecting, as long as that works more-or-less immediately.

Fully agreed.

AVE!
   Philipp