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

Ted Lemon <ted.lemon@nominum.com> Mon, 02 June 2014 02:10 UTC

Return-Path: <Ted.Lemon@nominum.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 BC74B1A0155 for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 19:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.951
X-Spam-Level:
X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651] 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 aOWN_oOoy_Tq for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 19:10:17 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB7F1A0150 for <v6ops@ietf.org>; Sun, 1 Jun 2014 19:10:17 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F37031B81BC for <v6ops@ietf.org>; Sun, 1 Jun 2014 19:10:12 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E8C8719005C; Sun, 1 Jun 2014 19:10:12 -0700 (PDT)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Jun 2014 19:10:12 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <538BDA84.6030800@bogus.com>
Date: Sun, 01 Jun 2014 22:10:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com>
References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <m2iooq4oqi.wl%randy@psg.com> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <m1WqqZ4-0000DqC@stereo.hq.phicoh.net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <m1WqrFK-0000BHC@stereo.hq.phicoh.net> <23125E9D-85A1-49EB-ACE6-DB5EAC67EE02@nominum.com> <CAKD1Yr0pvet1oOip-Y2Xi_h2mSZfW1R5HtfiAGbDEns0dY-d2A@mail.gmail.com> <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>
To: Joel Jaeggli <joelja@bogus.com>
X-Mailer: Apple Mail (2.1878.2)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MbSr5BHmPZXKPh0J1KnTuISLiG8
Cc: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>, V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] 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: Mon, 02 Jun 2014 02:10:19 -0000

On Jun 1, 2014, at 9:59 PM, joel jaeggli <joelja@bogus.com> wrote:
> Ted I think you need rethink what you're claiming. for one rfc 6555
> makes no claims about ipv6 address selection between multiple addresses.
> it in fact sets aside the issue of having more than the two address
> familes to chose from. I daresay if you have six v6 routes you probably
> don't want to make six requests and see which one is fastest as a
> general rule.

How is this different than doing happy eyeballs between v4 and v6?   Is it different because you're sextuply multi-homed?   I agree that that begins to look a bit problematic, but the more usual two-provider case is pretty much the same as regular happy eyeballs.

> you'remore likely to do ecmp if you simply treat all
> nexthops as though they were equivalent, which you might not want to do
> if they aren't (backup via LTE is probably not something you want to
> exercise all the time even if it's equivlant speed to your cable
> connection because it's more costly and has a datacap).

Right, that's a problem.

> source address selection based on nexthop is pretty straight forward.
> most unixes can do that. invalidating a nexthop when the route should no
> longer be used is propertly the domain of routing.  This is not even a
> benifit of ipv6 in the sense that it can work in ipv4 as anyone with an
> appropriately configured router  can attest (it's what the multihomed
> nat box actually does after all).

I've never operated one of these, but I'll take your word for it.   The fact that it works with IPv4 and NAT isn't very interesting to me.

Correct me if I am wrong, but what you have written appears to be a more detailed way of saying "happy eyeballs for multihoming won't happen, in my opinion, and multihoming for connection originators probably won't happen either, at least without NAT."   If so, that's a fine opinion to have, and may even be correct, but it's not an opinion I am willing to just accept without trying to do better (according to my opinion as to what's "better").