Re: IETF network incremental plan

Benson Schliesser <bensons@queuefull.net> Thu, 17 November 2016 04:52 UTC

Return-Path: <bensons@queuefull.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35676129532 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 20:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=queuefull.net
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 brSBE3RUXj3C for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 20:52:49 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67881129593 for <ietf@ietf.org>; Wed, 16 Nov 2016 20:52:49 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id j191so19929603ita.1 for <ietf@ietf.org>; Wed, 16 Nov 2016 20:52:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=queuefull.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/bQZSOqYzegwD4l4SVD7NruO+OT3m9XfHpIuLWhy0oU=; b=TBd1LOwBobU8D8XNPcLvnt5o/PbS2q0XP2MgxDa8Ig4q6WzoHi1Cw+JoQXsqibfVo9 JrFDv9BdlNKOyPV1nUjbEIGEvzvcD3zY6e44V5+mV2DsgCopRaW4gv40vhsWAUiFD1Nd 6FICRWyfWNiFeGXDaBz+CXI68XyqPieXWWELc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/bQZSOqYzegwD4l4SVD7NruO+OT3m9XfHpIuLWhy0oU=; b=JXEY6Ztv/nzN7dfeduhKBDs5KQwVBmOWqX4TE163F4IpfbWabFRZQ7UPn+PowgOv8x TzQnfLKofYSzjZDrpLIWQTmsLc2a9U1REF/aldKNGmpZOOpzxkMoTC/xis6gzItqqik2 M8BJl/4BMfuRR4wHhFuaPWFqsptcGRaGtfLP1OtymQy+X0rzDVMrLwIQk+CjDBhc7ifR QUYWvVWQFf+EUT7F0h6il3aiVKiupPWbhEBDnnSJTq9EBwE9kjJdJ7d/9QRI437g2Q/X F8dJYYBF2TJ8soj+YNp1IhQOLmWLQP7GIgfyF0Jb9EGON/J6V3o2u4mtQJOYeOuZaedP UimQ==
X-Gm-Message-State: ABUngvcrE1/j2i2jmMTZuG6hSY+O3OkRg3p9a77Gq2+HjtT1+KDdwAdXgQ9QoI+RS+d+HvZ3AMi2SqxDB++s1w==
X-Received: by 10.36.181.9 with SMTP id v9mr10674496ite.48.1479358368549; Wed, 16 Nov 2016 20:52:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.11.161 with HTTP; Wed, 16 Nov 2016 20:52:48 -0800 (PST)
In-Reply-To: <04D0964A-B0E7-4F9C-A725-65D9429492E9@virtualized.org>
References: <0C5BCD32-2D2A-42B9-8DEA-A1E1A527A8BB@consulintel.es> <m2zikzq7tg.wl-randy@psg.com> <dbcca137-9fef-723c-8fbd-edb12aff0b46@gmail.com> <04D0964A-B0E7-4F9C-A725-65D9429492E9@virtualized.org>
From: Benson Schliesser <bensons@queuefull.net>
Date: Thu, 17 Nov 2016 13:52:48 +0900
Message-ID: <CAP4=VcjCTxrxhtoaN=fdbUr37zd1j9=aQP2BTgSca3o-rv91Mg@mail.gmail.com>
Subject: Re: IETF network incremental plan
To: ietf <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="f403045d99160dd390054177f622"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/T3WZ6npK5GuyKb90JPkxxzKJk3U>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 04:52:53 -0000

On Thu, Nov 17, 2016 at 10:34 AM, David Conrad <drc@virtualized.org> wrote:

>
> I sort of like the idea of making the default IETF SSID IPv6 only, with
> other SSIDs that support v4/dual stack. It would probably be an eye opening
> experience for some.
>
>
Perhaps it would be eye opening for some. For a subset of those, perhaps it
would even cause them to do something helpful: write drafts, debug
software, fix their networks, harass their service providers and IT depts,
etc. But for others, it will merely be an inconvenience.

E.g., I imagine somebody not paying close attention to announcements on the
mailing list, showing up to a Monday morning meeting, connecting to the
IETF network, wondering why their employer's VPN isn't working, not getting
email, ... This experience is certainly not the end of the world for
anybody. But it may cause extra work for chairs, the NOC, et al.

It's not clear to me how we weigh the costs vs benefits. I think it would
be valuable to consider data from the NOC such as proportions of v6 / v4
traffic. But for now I'm a skeptic of intentionally breaking network
connectivity for attendees.

-Benson