[homenet] use of MPvD in homenet

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 13 August 2017 00:09 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A8B1323A5 for <homenet@ietfa.amsl.com>; Sat, 12 Aug 2017 17:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 2i6Wg7ahTPmU for <homenet@ietfa.amsl.com>; Sat, 12 Aug 2017 17:09:27 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F000132395 for <homenet@ietf.org>; Sat, 12 Aug 2017 17:09:27 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A74102009E for <homenet@ietf.org>; Sat, 12 Aug 2017 20:11:52 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F415C806BA for <homenet@ietf.org>; Sat, 12 Aug 2017 20:09:25 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: HOMENET <homenet@ietf.org>
In-Reply-To: <8CA906A5-133D-483D-B583-0644C13A634E@fugue.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 12 Aug 2017 20:09:25 -0400
Message-ID: <29406.1502582965@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/z_fHxyfEKvi4hdWg83GXLwbi6gM>
Subject: [homenet] use of MPvD in homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Aug 2017 00:09:29 -0000

{new subject line, nuked References}

Ted Lemon <mellon@fugue.com> wrote:
    > The problem with this is that it is quite brittle—it depends on everything
    > working right. The routing has to be set up right. The operator has to set
    > the routing up right. The other operator has to not deliberately or
    > accidentally set the routing up wrong. The home network has to successfully
    > get the right routing information and use it correctly.

This seems a bit like FUD: the Internet depends upon all sorts of "brittle" things
like "not deliberately or accidentially" setting up the routing wrong.
I do agree that a malicious operator could pretend to zero-rate things and
then make it actually impossible to ever get that service.

But: MPvD seems to depend upon the same kind of brittle things!!!

    > It might be worth actually writing down why you think that's so. It's far
    > from obvious to me that it is, but I am not as familiar as you are with
    > Shim6. Unfortunately as far as I know nobody ever presented anything about
    > Shim6 in MIF; if in fact what you are saying is true, a lot of time and
    > effort could have been saved if that had happened.

MIF tried to solve all sorts of IPv4-induced problems that marketing people
thought that they had.  Many were not well defined in my opinion, or in my
opinion were not even good ideas.

Tim points out that SHIM6 was undeployable as described because of extension
headers; but I was never convinced that was what killed it, but okay.
(I believe that was the year I dealt with family illnesses)
Maybe in the end, we have LISP as a response?

SHIM6 tries to deal with multi-homing by proposing incrementally deployable
changes to hosts.  Host (pairs) that have it, benefit without infrastructure
in between being upgraded.
A host that had SHIM6, and had some HNCP and/or minimal babel listening,
would be able to intelligently do SHIM6 better.
I think that SHIM6 would also provide a channel by which a service provider
who had differential rates for different access channels to say such a thing
through the SHIM6 layer. (That would be an extension)

MPvD tries to do the same thing: avoid making any changes to the
infrastructure outside of the "device" (in the telco's case, a smartphone
that they have an agreement with the manufacturer to modify, that they lock
and "sell").

HOMENET is chartered to fix the infrastructure *in the home* such that
unmodified hosts can reasonably get basic services without changes.

MPvD only works when the end host has multiple interfaces that it can
actually provision from, *or* if we have virtual provisioning domains on the
same link! i.e. infrastructure!  Which we do have in HOMENET.

At which point MPvD requires that the infrastructure and the host cooperate
to communicate the multiple domains to the end host via the infrastructure.

That's where all the "brittle" things you describe show up!!!
MPvD requires the walled-garden ISPs to do the same configuration.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-