IETF Logo Mail Archive

Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)

Kazuho Oku <notifications@github.com> Fri, 01 May 2020 19:49 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D143A1B92 for <quic-issues@ietfa.amsl.com>; Fri, 1 May 2020 12:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 OIuC-vaxDnDY for <quic-issues@ietfa.amsl.com>; Fri, 1 May 2020 12:49:49 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B274D3A1B8F for <quic-issues@ietf.org>; Fri, 1 May 2020 12:49:46 -0700 (PDT)
Received: from github-lowworker-2e54e43.va3-iad.github.net (github-lowworker-2e54e43.va3-iad.github.net [10.48.17.27]) by smtp.github.com (Postfix) with ESMTP id 8A5286A06B8 for <quic-issues@ietf.org>; Fri, 1 May 2020 12:49:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588362585; bh=z50ZXX1X0smHAMCMhFx5ZuWeUM7XCuVhmHHGVVoiQeU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JmlaWEdagKMVUHAkBYepc7p2DkQcmX+hUA5J85YULv5A28EfqT2r0KaInjgfkW9ei 57BMIED/1MWZXehmoSsFKWw+m3eSnOueQ+VbMK56dzCtZ1C8aiDXehlalD8CJnsmMa BRuOTIEAeaap5qcKSg1eGeX/KZQ5mUCwKzoWeDZo=
Date: Fri, 01 May 2020 12:49:45 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2RVRVJPOXTQRNI7654XBPFTEVBNHHCITYZTQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3608/622536845@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3608@github.com>
References: <quicwg/base-drafts/issues/3608@github.com>
Subject: Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eac7d5979bbd_275f3f9e21ecd96c109521"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/5LPefTEMFNgIidrE5KnuG_b8sJo>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2020 19:49:51 -0000

@ianswett 
> So your suggestion is that disable_active_migration applies only to the original address and the SPA must always support active migration, because it has to use CID routing?

Exactly. I think that that would be the correct thing to do, if we are to make changes.

I agree that existing clients might be applying `disable_active_migration` after migrating to SPA, and that they do not want change. But they can remain as they are, because the change in spec does not lead to interoperability issues.

To paraphrase, I think making the aforementioned change is strictly better than doing nothing, because it would be an improvement to some, while not hurting anybody.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3608#issuecomment-622536845

v2.23.0 | Report a Bug | By Email