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

Ted Lemon <mellon@fugue.com> Tue, 21 November 2023 12:45 UTC

Return-Path: <mellon@fugue.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 10857C15152F for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 04:45:05 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
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 uoCmOSA_D72t for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 04:45:01 -0800 (PST)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 376D6C151533 for <ipv6@ietf.org>; Tue, 21 Nov 2023 04:45:00 -0800 (PST)
Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-77a453eb01cso354029085a.0 for <ipv6@ietf.org>; Tue, 21 Nov 2023 04:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1700570699; x=1701175499; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=94tVxvS3opL8zyVC7KYFqRX8+IBVMlEjNV+CsAmkMcw=; b=gB2C8MXzaxMpW3vp5fztzZ/39KQZyhr9Jzw/iEkncCRpud74PcdCBYBE0HzurGOdzV 5aw5Vo2xHfMaXP35UlzkBQ7fAk/NOfMjLYaEX8V2Bh0mVsuvGD0CYJcFW1F0t5lJp7sk wLAPdcIaayrluYcR83xRse4Z/0XXlx2Mq+ckh8pP+Qy7Y8IfVS8TUpFYtgA6U/v0fEJU Ka98IwCmNtwZ8nSNuGrY+tBv11sjpPaLC4HKNNb//Id5G+V79O9ZlGFX38omJbeM9uzA Rw62zLbAXkOKSIsYJkm4QPtiYB0EGLz+Zi+bvJAu/w81hwdF9SLb+TbccWZ9XfLDoUHM /+Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700570699; x=1701175499; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=94tVxvS3opL8zyVC7KYFqRX8+IBVMlEjNV+CsAmkMcw=; b=ETX2oZLh5c6G6OdSYx46Iq0GgdEBunFNI/BGbHi7l3QDv7Uj2/Dp018h5oOD2uiUyH quyWE609hsaUwsVIuFSW9/+hdKeacijF/5W7VTjLBj771Q788ICJVn3LgtnMOt+dTzPO 3atmCw2utdXb87QyNZMhT+ZQrRV3YRxuw/D7pPRiTFJqDszVwSMvDNvG/kej16MU8mSA 511vx3GUVr13HttoFjU3D/3i+vriAbOVO3CiGgISUX2pUKyGy2zjg5KDVuMh93m/liU3 pTK1Awz21YtA831hkfkN7eWgMNdcrin3BEEbTbs3tSkrcRp9xHtE7VikgL5AL3N/Bgb1 u9eg==
X-Gm-Message-State: AOJu0Yw7dHewEe4v0YwuZSSVIEoK9Jn/Z7T73NWXFA3DCONCc9h6Vd/S 2dvqEc1F/reQ5CjGz66pR4FUxAYMLkjXTlx2cuYJmg==
X-Google-Smtp-Source: AGHT+IElf60Aa1XfmggEZjzttNE9D4gNGbH42APpGNBUUL6a7XOtUcvfTbu4UcDYmwxq7vWp6IDpeTgx0TFt8v1rsro=
X-Received: by 2002:a05:6214:19ea:b0:675:3fed:ed with SMTP id q10-20020a05621419ea00b006753fed00edmr13170956qvc.44.1700570699320; Tue, 21 Nov 2023 04:44:59 -0800 (PST)
MIME-Version: 1.0
References: <CAKD1Yr2uD+XE+HA6vs3BfEchpWr5H2NEeoXLrXm7-U9_ckw1sA@mail.gmail.com> <CAN-Dau2Nw21wUm-mjxq3bnYczPJbApVhcZZ6oie+HiB4yvr_PQ@mail.gmail.com> <CAKD1Yr1z2x8iKXYQtPVifj-XkP7MeRq=NWe0gdWBGC1aS_j0Mg@mail.gmail.com> <CACMsEX8f_qmpZ898vKLy_56Jy1WKEju94fYEz5fuV4Pc3iJ=tw@mail.gmail.com> <CAKD1Yr1tZa0W=617hQrgYYqmUbfgFp7EhmvgqKzaBvF=r=5FuA@mail.gmail.com> <CAJU8_nUOjrO5FPPXTCNeA-9YuSPT7SmGkiM82DGiMacyfntV6w@mail.gmail.com> <CAN-Dau0FP31h3s+Fzbam7GJg-rNGsX3m8Hx3k=+895NT0a4iqw@mail.gmail.com> <CAPt1N1=_BmOZNvOc00qdhS84REnr-thBFgrjcixsEc=+jMSOfg@mail.gmail.com> <CAN-Dau1A4=5Q6mckZ35T_Gs1ty=zSAYUOS+1-nw1rAD2eH+o9w@mail.gmail.com> <CAO42Z2yU+uHDP-xi_D6tCA45UmSiCQ2bZSUe38edEWs5o_YCeg@mail.gmail.com> <CAKD1Yr2YW-ZeyooT6tzmjoE2WJAcUcohf2C6CMj3e41J8XaLvQ@mail.gmail.com> <4106220.1700174829@dyas> <8031DEBD-BC22-480E-91FF-8F9EC1EDC2A7@employees.org> <4124157.1700231123@dyas> <17E321B1-B65C-4761-96C1-D69598AB9D53@tiesel.net> <CACMsEX9RiUDKWL+47GaxQ9Q36bBjMqiTgJ16Ob+5FPbGAxNozQ@mail.gmail.com> <AFDEB5DE-8C15-4A3E-B79D-C686925CF6A3@employees.org>
In-Reply-To: <AFDEB5DE-8C15-4A3E-B79D-C686925CF6A3@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Nov 2023 07:44:47 -0500
Message-ID: <CAPt1N1kjd+m3KL-KCQY=2DWZrug=g8_zdtacF9Aja7dQ9zjnUQ@mail.gmail.com>
To: Ole Troan <otroan=40employees.org@dmarc.ietf.org>
Cc: 6man WG <ipv6@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Nick Buraglio <buraglio@forwardingplane.net>
Content-Type: multipart/alternative; boundary="00000000000072e567060aa8f88b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QDV7DlGHJPv_rLIojpdSdSp2PF0>
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: Tue, 21 Nov 2023 12:45:05 -0000

So the second tier routers would be too stupid to forward packets through
the correct exit router? Even though we have a clear rule for how to do
it?  That seems like a bug in need of fixing, not an impossible problem.

Op di 21 nov 2023 om 06:45 schreef Ole Troan <otroan=
40employees.org@dmarc.ietf.org>

> > The more I think about it, the more I am thinking that it may be a
> deployable solution for multihoming, with all of the details in appropriate
> stages of hand waving.
>
> The more I think about it, the less I think it is deployable.
>
> MHMP:
> - Rule 5.5 support in all hosts (which as Lorenzo alluded to is
> complicated)
> - Application changes to handle failover
> - No multi-homing policy available to the network
> - Only works when hosts are directly connected to exit routers. _Any_
> other topology requires routers to do SADR or SADR like behaviour
>
> I don’t see any realistic way where MHMP can be made deployable.
>
> I’d rather we focus on the multi-homing mechanisms that could work.
>
> Cheers,
> Ole
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>