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

Mark Andrews <marka@isc.org> Sun, 01 June 2014 23:12 UTC

Return-Path: <marka@isc.org>
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 A4A8A1A00F5 for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 16:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level:
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, 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 c8QMrdZwJBKZ for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 16:12:19 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B34F21A00ED for <v6ops@ietf.org>; Sun, 1 Jun 2014 16:12:19 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 9829E3493BB; Sun, 1 Jun 2014 23:12:13 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9833A160067; Sun, 1 Jun 2014 23:17:14 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 68FE1160053; Sun, 1 Jun 2014 23:17:14 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 303E9171FD22; Mon, 2 Jun 2014 09:11:40 +1000 (EST)
To: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>
From: Mark Andrews <marka@isc.org>
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> <m1WrCJ2-0000DVC@stereo.hq.phicoh.net>
In-reply-to: Your message of "Sun, 01 Jun 2014 22:24:36 +0200." <m1WrCJ2-0000DVC@stereo.hq.phicoh.net>
Date: Mon, 02 Jun 2014 09:11:40 +1000
Message-Id: <20140601231140.303E9171FD22@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/S7Me0EGeFmtkG78c1HAK1x1Dibo
Cc: 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: Sun, 01 Jun 2014 23:12:25 -0000

In message <m1WrCJ2-0000DVC@stereo.hq.phicoh.net>, Philip Homburg writes:
> In your letter dated Sun, 1 Jun 2014 16:10:18 -0400 you wrote:
> >On Jun 1, 2014, at 1:36 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
> >> Because...?
> >
> >Because any situation where you are multi-homed, if either home fails 
> >and your software can't try both to see which one is working, there's a 
> >good chance it will fail to connect.
> 
> Nice how this thread evolves:
> - Use PI space, it works (but is not really scalable)
> - No, no, get with the program. Get multi-homed on PA.
> - We don't actually have anything for servers and multi-homed PA.
> - Every piece of software has to do HE because of how multi-homed PA fails.
> 
> Great way of advertising IPv6.

Every piece of client software should already support multi-homing.
This is about supporting it *better* so there isn't the big delay
when switching to the second address because the link at the other
end is down.  The stack should be choosing source addresses which
have working outbound paths.  Selecting destination addresses is
up to the application.

This is about making the error cases work better which quite frankly
should have been done years ago for IPv4.  The only ones that don't
benefit from this is GLB developers.

Mark

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org