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

Gert Doering <gert@space.net> Mon, 02 June 2014 16:57 UTC

Return-Path: <gert@Space.Net>
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 3B5B31A025A for <v6ops@ietfa.amsl.com>; Mon, 2 Jun 2014 09:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lNobUffRdv3j for <v6ops@ietfa.amsl.com>; Mon, 2 Jun 2014 09:57:39 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28161A023A for <v6ops@ietf.org>; Mon, 2 Jun 2014 09:57:38 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9D83060B3F for <v6ops@ietf.org>; Mon, 2 Jun 2014 18:57:31 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5D2A46038F for <v6ops@ietf.org>; Mon, 2 Jun 2014 18:57:31 +0200 (CEST)
Received: (qmail 20342 invoked by uid 1007); 2 Jun 2014 18:57:31 +0200
Date: Mon, 02 Jun 2014 18:57:31 +0200
From: Gert Doering <gert@space.net>
To: joel jaeggli <joelja@bogus.com>
Message-ID: <20140602165731.GE46558@Space.Net>
References: <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> <538C93E9.7080405@bogus.com> <20140602152642.GB46558@Space.Net> <538CA255.7070205@bogus.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="wbuTI+YEd0REWzbC"
Content-Disposition: inline
In-Reply-To: <538CA255.7070205@bogus.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4pHjFpOTPVYd7BE1XCK3HBIIFY0
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 16:57:40 -0000

Hi,

On Mon, Jun 02, 2014 at 09:12:05AM -0700, joel jaeggli wrote:
> On 6/2/14, 8:26 AM, Gert Doering wrote:
> 
> > Multi-Address multihoming has the potential to be a radical improvement
> > for "leaf networks without IT knowledge".  
> 
> You and I agree on this.

This is good :-)

> Where I disagree is that the devices attached to network should be
> assumed to bear the cost of fine grained decision making. We should not
> assume that they all should, and multihomed homenets should function
> reasonably well even if they do not.

OK, I do also agree (as this is a "should be assumed").

There's multiple aspects to it.

 - if the network devices do not care, and just follow 6724 rules, and
   the CPEs will handle "basic" failures right (detect ISP down, assign
   prefix with preferred lifetime = 0), they will generally just work,
   but the source address = ISP selection will not generally be optimal
   (whatever that means in the specific case - latency, throughput, 
   price?), and certain failure cases might involve user action ("plug
   the pull to ISP A").

 - if the network devices *do* care, and we get a bit more work done, the
   user experience can be improved
 
    - give the user (!) control over ISP selection, like in "I want my
      bittorrent to use my cable ISP, and my web surfing to use the DSL
      line" - I think this is a major benefit compared to solutions with
      a single prefix and a CPE-controlled policy, because for the normal
      end user, the CPE is a magic box that is not touched or configured
      (Owen is not a normal end user).

    - handle black-holing failure cases that only affect the packet path
      for one of the available prefixes, but for the one that might be
      selected by 6724


to point out what is obvious to me, but might not be for someone reading
this:

 - this is NOT about "managed environments".  In an "enterprise" network
   that has IT staff and policies set by "management" regarding ISP usage,
   the enterprise admins will NOT want the end systems to control policy
   - so there, "single prefix, CPE controls policy" is a more adequate 
   solution.  Which might imply NATs, or proxies, etc. - enterprisey stuff,
   according to that specific network's needs.

 - and that implies that there is not "one" solution for multihomed leaf sites

thanks :)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279