Re: multihoming, was IPv10

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sat, 31 December 2016 13:30 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 7C146129538 for <ietf@ietfa.amsl.com>; Sat, 31 Dec 2016 05:30:21 -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 r5wcHQtOScP1 for <ietf@ietfa.amsl.com>; Sat, 31 Dec 2016 05:30:19 -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 2DD9C1200A0 for <ietf@ietf.org>; Sat, 31 Dec 2016 05:30:16 -0800 (PST)
Received: (qmail 89131 invoked from network); 31 Dec 2016 13:32:42 -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 13:32:42 -0000
Subject: Re: multihoming, was IPv10
To: Octavio Alvarez <octalietf@alvarezp.org>, 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>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <84be74e9-0e25-cbbb-4f6f-6cb21c28e7ea@necom830.hpcl.titech.ac.jp>
Date: Sat, 31 Dec 2016 22:30:08 +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: <a9b31b76-21cc-de14-e217-6916f3677597@alvarezp.org>
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/NjKEJhHgxtNrrt3cVLjNnR6Ka7c>
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 13:30:21 -0000

Octavio Alvarez wrote:

>>     https://tools.ietf.org/html/draft-ohta-e2e-multihoming-00
>>
>> in April 2000 and I know it is stupid to use source routing for
>> multihoming.
>
> Is source routing bad in general or is it bad only in multihoming scenarios?

Source routing is bad in general and, especially, in multihoming
scenarios involving complex topology, such as hierarchical multiple
prefixes involving TLAs, NLAs and SLAs.

Moreover, source routing is unnecessary, because currently specified
source address selection of IPv6 is stupid.

Despite all the weasel wordings of IPv6 specifications, the only
proper way for source address selection for IPv6 (and IPv4) is to
distribute source prefixes by route entries of routing protocols,
which means, if a destination address is selected, the corresponding
destination address becomes uniquely obvious. Or, an alternative
(assuming IPv6++) is to make it unnecessary by source locator
rewriting with locator ID separation.

Anyway, multi6 WG utterly failed because most of the members (including
chairs) failed to understand that *TIMELY* multihoming needs notions
of timeout and, thus, connections, which is available only at the
transport layer or above. Instead, multi6 WG, stupidly enough, tried
to solve the problem at the IP layer in vain, where there can be no
connection timeout.

That's what I wrote from the beginning that:

    To support the end to end multihoming, no change is necessary on
    routing protocols. Instead, APIs and applications must be modified to
    detect and react against the loss of connection.  In case of TCP
    where there is a network wide agreement on the semantics of the loss
    of connectivity, most of the work can be done by the kernel code at
    the transport layer. However, in general, the condition of "loss of
    connectivity" varies application by application that the multihoming
    must directly be controlled by application programs.

in

     https://tools.ietf.org/html/draft-ohta-e2e-multihoming-00

Note that routing protocol change denied in the quoted paragraph
of mine becomes necessary only if proper source address selection
is necessary.

							Masataka Ohta