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

Ted Lemon <mellon@fugue.com> Tue, 21 November 2023 14:17 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 75DD1C14CE55 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 06:17:13 -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_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=ham 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 1sZC2hysVdgy for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2023 06:17:09 -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 8E1F3C14F5E0 for <ipv6@ietf.org>; Tue, 21 Nov 2023 06:17:09 -0800 (PST)
Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-778927f2dd3so274464885a.2 for <ipv6@ietf.org>; Tue, 21 Nov 2023 06:17:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1700576228; x=1701181028; 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=Wx3qCVhF//JrPVVLx27pZ6UgDdODc9ZWDC5qj2BP9c0=; b=yvpSBhm9NRJtEtuBdKAyyOqZwBJrDaVzNcUb9EnYbxRmZpKwj0JQG6YotmlfSPIV6G nuZUwN5CWxWgaf32GlnlTOc0G5MUzqBslcesptrY3iCEIiX31/lUBwXSxXQPOY5DSZoQ NWKlaJ7+yhlil9p9bKPRcDsPb/JlJ5kfkfp9xnjm+pdaVEVXm369jqRhdICM3q+kxCP+ 9ZC9jXH0SPI+0tBoKsLdR5xznhlg6/WnEmiQBUqIEtSU56aCNfDsddErbKqvUzwhITw/ Op2DcpEbMuvqxlcEbzRURl/RPeCSUdOiVP8alrDIFGOsVVmZUbuZsLkudYz8FxTzj2q+ PKDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700576228; x=1701181028; 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=Wx3qCVhF//JrPVVLx27pZ6UgDdODc9ZWDC5qj2BP9c0=; b=fj06KbF5J5qQ9Ap6XusntaVY8jyhGJNcp3dt/MLL8ZYXXgY6f+MMbpbbOUUc8VpiL8 fdpQPPW06xbvtz8kjQ88+WbiuqlZLEWBkhc9dCub5dN9P8zA5XuWZ3iRzsg8817oeejJ 6JCHfTK1rQdN/cZf++Gleoq97oYsde1ixWtzcSS5xQ669NyGPJEwf4wIpxLJAUGTTQQ0 g0hfQUvKdnsV679ryYrk4Gwi41d+7JMcFG0wj6mXyketphNSpv/N88gTLpMx8iLs+5PM Y3MvHQmWsYValhonfz0rxGgVJ+hTKjckqGfYUP5VP0cCAoXJ9CA6c/iDazMqXoYntUPI 4uWg==
X-Gm-Message-State: AOJu0Yzw7kIteBDQGq8DQW/Gy+S9vOWtob3AAWnDqXafjsvNhMmMsVmn YkhgR9avg7M5ATxpBmtXkmBCPNo7YRKsynJvydm8yaMGyOUiZFi93WE=
X-Google-Smtp-Source: AGHT+IGwbKRHT734Qz1+1etzUSeI+anjR0AHPv240p/xbOHG7emqHsOAe78AArbA/MrxC935V0b7YOFTzOSB4c22p1w=
X-Received: by 2002:ae9:c00a:0:b0:77b:ec3a:27c8 with SMTP id u10-20020ae9c00a000000b0077bec3a27c8mr9663701qkk.63.1700576228055; Tue, 21 Nov 2023 06:17:08 -0800 (PST)
MIME-Version: 1.0
References: <CAPt1N1kjd+m3KL-KCQY=2DWZrug=g8_zdtacF9Aja7dQ9zjnUQ@mail.gmail.com> <1BA9C21A-8EDC-4E69-8749-3C703CAB678B@employees.org>
In-Reply-To: <1BA9C21A-8EDC-4E69-8749-3C703CAB678B@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Nov 2023 09:16:56 -0500
Message-ID: <CAPt1N1kFQpkkVNtk57_T3FTnVKhtqgm9Z6VGJDzOXo4KJvccSA@mail.gmail.com>
To: Ole Trøan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>, Lorenzo Colitti <lorenzo@google.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Nick Buraglio <buraglio@forwardingplane.net>
Content-Type: multipart/alternative; boundary="000000000000fcb213060aaa414c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/WtWeGVxJA3bK2VtHy2ppMCFJIPU>
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 14:17:13 -0000

Remember that my target market is end users, not enterprise. What sort of
routers can an end user buy that will automatically do what you suggest?

Op di 21 nov 2023 om 08:01 schreef Ole Trøan <otroan@employees.org>

>
>
> On 21 Nov 2023, at 13:45, Ted Lemon <mellon@fugue.com> wrote:
>
> 
> 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.
>
>
> Alternative explanation is that you are too stingy to pay to upgrade the
> forwarding engines.
> Most routers can do this with policy routing, but I am not aware of any
> efficient SADR lookup yet.
>
> Nice try, trying to deflect the problem to the network. :-)
> Updating every host stack and every application seems completely
> infeasible.
>
> I have tried MPMH at home over the last decade and a half and as far as I
> can tell we have not gotten any closer.
>
> At this point MPMH seems mostly like a distraction. Let’s focus on the
> mechanisms that can be made to work now.
>
> O.
>
>
>
> 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
>> --------------------------------------------------------------------
>>
>