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
- IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt… Khaled Omar
- RE: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Khaled Omar
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Ladislav Lhotka
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Leonir Hoxha
- RE: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Tony Hain
- Re IPv6 adoption (Was Re: IPv10 (Temp. name IPmix… Steve Crocker
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… shogunx
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… David Conrad
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… shogunx
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… John C Klensin
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- The demand for IPv4 addresses (was: IPv10) S Moonesamy
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… S Moonesamy
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Lee Howard
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… John C Klensin
- Re: IPv6, was IPv10 John Levine
- Re: multihoming, was IPv10 John Levine
- Re: IPv6, was IPv10 (fwd) John R Levine
- Re: IPv6, was IPv10 Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv6, was IPv10 (fwd) Brian E Carpenter
- Re: IPv6, was IPv10 Mark Andrews
- Re: IPv6, was IPv10 John R Levine
- Re: IPv6, was IPv10 (fwd) Mark Andrews
- Re: IPv6, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 John R Levine
- Re: multihoming, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 Randy Bush
- Re: multihoming, was IPv10 Randy Bush
- Re: multihoming, was IPv10 John Levine
- Re: multihoming, was IPv10 Mark Andrews
- Re: multihoming, was IPv10 Brian E Carpenter
- RE: multihoming, was IPv10 Michel Py
- Re: multihoming, was IPv10 John C Klensin
- Re: multihoming, was IPv10 John R Levine
- Re: IPv6, was IPv10 shogunx
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… heasley
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Patrik Fältström
- Re: multihoming, was IPv10 Masataka Ohta
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: multihoming, was IPv10 Octavio Alvarez
- Re: multihoming, was IPv10 Stewart Bryant
- Re: multihoming, was IPv10 Masataka Ohta
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: multihoming, was IPv10 Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… David Farmer
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: multihoming, was IPv10 Jeff Tantsura
- Re: why v6 still isn't ready, was IPv10 John Levine
- Re: multihoming, was IPv10 Masataka Ohta
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Brian E Carpenter
- Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00… Randy Bush
- Re: multihoming, was IPv10 Randy Bush
- Re: why v6 still isn't ready, was IPv10 Randy Bush
- Re: why v6 still isn't ready, was IPv10 Brian E Carpenter
- Re: why v6 still isn't ready, was IPv10 Randy Bush