Re: multihoming, was IPv10

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sat, 31 December 2016 23:35 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 317351295CD for <ietf@ietfa.amsl.com>; Sat, 31 Dec 2016 15:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 CDaQdrcP4mqG for <ietf@ietfa.amsl.com>; Sat, 31 Dec 2016 15:35:16 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id A6FA3129489 for <ietf@ietf.org>; Sat, 31 Dec 2016 15:35:15 -0800 (PST)
Received: (qmail 95094 invoked from network); 31 Dec 2016 23:37:40 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 31 Dec 2016 23:37:40 -0000
Subject: Re: multihoming, was IPv10
To: ietf@ietf.org
References: <20161230024719.36002.qmail@ary.lan> <7401a840-590e-28c3-2c3f-1e4b46c34e29@gmail.com> <F04ED1585899D842B482E7ADCA581B845946D258@newserver.arneill-py.local> <685eee97-795a-6705-52a5-19707d529975@necom830.hpcl.titech.ac.jp> <a9b31b76-21cc-de14-e217-6916f3677597@alvarezp.org> <84be74e9-0e25-cbbb-4f6f-6cb21c28e7ea@necom830.hpcl.titech.ac.jp> <f6a87169-6b0a-6887-4973-ecc589267026@gmail.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <029d8895-ebe3-2be9-03d3-361679578da0@necom830.hpcl.titech.ac.jp>
Date: Sun, 1 Jan 2017 08:35:13 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <f6a87169-6b0a-6887-4973-ecc589267026@gmail.com>
Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/AR5-h4fhejZSXc17YP7jBrgL2aM>
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: Sat, 31 Dec 2016 23:35:17 -0000

Brian E Carpenter wrote:

>> Anyway, multi6 WG utterly failed because most of the members (including
>> chairs) failed to understand that *TIMELY* multihoming needs notions
>> of timeout
>
> No doubt that is why shim6, the direct result of multi6, includes probes, a
> keepalive timeout and discussion of what to do if failure occurs even during
> context creation.

That's the stupidity.

At the connectionless IP layer, never try to create a context, a
connection.

That's no different from poor NAT guessing validity of TCP connection
through timeout. The guess can not be complete, correct or *TIMELY*.

Moreover, as a connection at a higher layer already has proper
mechanisms for the timeout, providing an incomplete and incorrect
alternative somewhere else is totally useless.

According to the end to end argument:

	The function in question can completely and correctly be
	implemented only with the knowledge and help of the
	application standing at the end points of the communication
	system.

the knowledge and help is not available at the IP layer but is
already available at higher layers.

 > I have never found it very helpful to accuse discussion partners of
 > stupidity.

It isn't, unless shim6 members can recognize the collective
stupidity of the WG. But, that is not my problem.

						Masataka Ohta