Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]]

Scott Brim <scott.brim@gmail.com> Tue, 03 June 2014 20:24 UTC

Return-Path: <scott.brim@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4201A0378 for <v6ops@ietfa.amsl.com>; Tue, 3 Jun 2014 13:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 K_EmWP-lBCpT for <v6ops@ietfa.amsl.com>; Tue, 3 Jun 2014 13:24:58 -0700 (PDT)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAA41A0373 for <v6ops@ietf.org>; Tue, 3 Jun 2014 13:24:58 -0700 (PDT)
Received: by mail-ob0-f182.google.com with SMTP id wn1so6640199obc.13 for <v6ops@ietf.org>; Tue, 03 Jun 2014 13:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YiDnSkjb+zXsZdJDx3ph7LJ7YvgRnDNxk9gq/9jRgog=; b=0boscl7y4oQgHa090Fz7wyd0g30bG4xfyGABOjsXTXq5AAM71L0uzJUEyj5mHfHLvK BfjFVAs3Kjf6bsuEV6rfZIvwXsBVJ0Zz1dYyQOoSS6qxBYKyGeQB6uWs96XaSxfQKqEZ F5OmatGVxsPm/CqAZ/P+tZZLXTtzh6o8UBOOjD1KbpBdd+OQzU2XlcdoDp0JKgFLqAGp 4n3EdUh/RcqtQajn9w5UO97RV9Arn8JAYsL8rRRNxrGvcTt+4ouBwM9WeGt4XfnZtRX1 OvwOmedF88U4A59UmDdA2cEErdSJifwygjcOUCSWYqDSGfO70dXbXE0AotFDE3dn6u9U VEqw==
X-Received: by 10.60.115.202 with SMTP id jq10mr50782598oeb.0.1401827092332; Tue, 03 Jun 2014 13:24:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.183.8.7 with HTTP; Tue, 3 Jun 2014 13:24:32 -0700 (PDT)
In-Reply-To: <538E2D2E.4020903@gmail.com>
References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <CAKD1Yr2NH4Kca4EvhjN2XnDbt8F2eS56ipxu3npH9yOh1bmQaA@mail.gmail.com> <F12F173B-9FF2-4EF8-B11E-33AEDA24961F@nominum.com> <CAKD1Yr1cGx7UfxZaEhm7oHA5PLvghVc52oPVkEQF90_7Vm__vw@mail.gmail.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <20140602081743.GP46558@Space.Net> <538CE1CF.9030002@gmail.com> <20140602204730.GH46558@Space.Net> <538D7A71.6070906@uclouvain.be> <538E2D2E.4020903@gmail.com>
From: Scott Brim <scott.brim@gmail.com>
Date: Tue, 03 Jun 2014 16:24:32 -0400
Message-ID: <CAPv4CP_S61spd-QWgrGiDo0i5cpeuz2WUAr8__s=AWPF-6-HDw@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8b1ZXzvS4tVtn0fNe06vjV5irlk
Cc: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>, V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jun 2014 20:25:00 -0000

On Tue, Jun 3, 2014 at 4:16 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>> Having worked actively with both shim6 and Multipath TCP and supervised
>> their implementation in the Linux kernel, I'm convinced that solving the
>> problem in the transport layer is much better than in the network layer.
>> Multipath TCP can deal with the case that you discuss and we'd be happy
>> to perform tests with the Multipath TCP implementation in the Linux
>> kernel (see http://www.multipath-tcp.org )
>
> But, of course, the great advantage of shim6, as you know, is that it
> applies to all transport layers. MPTCP is very elegant but only works
> for TCP applications. So we have a bit of a dilemma in this area.
> It's not a v6ops issue though.

And the disadvantage of shim6 is that it's gone, sorry Brian but it's
not coming back. In the meantime, while MPTCP itself has little
deployment, the framework in it and SCTP are strongly present in HTTP
2.0, RTCWEB, and web browser space in general, and there is refreshing
work being done on transport layer improvements. If and when
multipathing proves its usefulness (imho the jury is still out, eg.
when you have paths with highly different quality) there will be
several convenient paths for its deployment.

Scott