Re: IETF network incremental plan

Jari Arkko <jari.arkko@piuha.net> Thu, 17 November 2016 16:28 UTC

Return-Path: <jari.arkko@piuha.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 C0A271294AB for <ietf@ietfa.amsl.com>; Thu, 17 Nov 2016 08:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 BR0a508RXNqz for <ietf@ietfa.amsl.com>; Thu, 17 Nov 2016 08:28:14 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1416D12942F for <ietf@ietf.org>; Thu, 17 Nov 2016 08:28:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C6F642CC95; Thu, 17 Nov 2016 18:28:12 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz5Stz4vD_KF; Thu, 17 Nov 2016 18:28:12 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id F13972CC2A; Thu, 17 Nov 2016 18:28:09 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Subject: Re: IETF network incremental plan
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CDE2B251-C289-477A-A1BC-18F0CDFF5B8C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <20161117013350.GB56946@mx2.yitter.info>
Date: Fri, 18 Nov 2016 01:28:07 +0900
Message-Id: <DF2EDD5C-1017-4524-AD09-E0D26FC7C003@piuha.net>
References: <0C5BCD32-2D2A-42B9-8DEA-A1E1A527A8BB@consulintel.es> <m2zikzq7tg.wl-randy@psg.com> <20161117013350.GB56946@mx2.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>, Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/M3dY9UqCkfAUgQiJUAsrqdLVBM8>
Cc: ietf@ietf.org
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 16:28:16 -0000

Randy, Andrew,

I’m sorry Randy that you didn’t get a chance to ask your question.

>> but essentially, before we make tactical decisions we would like to know
>> what the purpose and goal of the meeting network is.
> 
> [&c.]
> 
> If that _is_ the question, I observe that the IAB can't answer the
> question.

But, I believe it is my job to answer that question. Or at least relay the process that we use to answer that question: As with everything, what we do at the IETF is up to the community. You guys tell me that you need <something>, we try to give you <something>.

So ultimately we want to do what you tell us to do, as whole. If I am allowed to speculate, the purpose of our network from the community’s point of view is probably a mixture of few things, with obviously the most important one being to deliver the fullest service to your customers, the IETF participants. But, I know there are some participants who also have other wishes, including the ability to run tests or configurations that we think are common in the future.

I’m not going to stand here and act as a arbiter between the different interests. I think there are some future scenarios where the end state is something where we’d have to decide what the default is (e.g., “ietf” vs. “ietf-nat64” vs. “ietf-dualstack". Jim had some ideas of some other possible end states where there is no such need.

But maybe more important than thinking about the possible future conflicts in defaults is to think about what’s useful in the interim, because I at least would like to see incremental steps.

What I heard in the plenary last night was that there were many people who wanted to run with NAT64 setups. But the setup that we have that for today is pretty basic. I could imagine some data/failure collection ideas, I could imagine redundancy setups, I could imagine more tools to manage our SSIDs…. and I think most of those things would be useful improvements to the current network. And if we had them, and people actually committed to set those up and do some testing… I think this would be a win/win for the IETF. Our existing services would continue to run, volunteers would help setup new services, people would be able to use them, and some experience could be collected. Further steps could be taken if results are interesting & community members use the services. I will myself commit to using such services, if available.

But again, these are just my ideas. What do people want that we do?

Jari