Re: [fun] status of the homenet effort

Jari Arkko <jari.arkko@piuha.net> Fri, 01 July 2011 21:48 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: fun@ietfa.amsl.com
Delivered-To: fun@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA98111E81C3 for <fun@ietfa.amsl.com>; Fri, 1 Jul 2011 14:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.043
X-Spam-Level:
X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIU3z5VeTUG9 for <fun@ietfa.amsl.com>; Fri, 1 Jul 2011 14:48:20 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44A11E80E7 for <fun@ietf.org>; Fri, 1 Jul 2011 14:48:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 20CE82D366; Sat, 2 Jul 2011 00:48:17 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRvN2OOPdkhh; Sat, 2 Jul 2011 00:48:13 +0300 (EEST)
Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B85BD2CEFF; Sat, 2 Jul 2011 00:48:12 +0300 (EEST)
Message-ID: <4E0E409C.3050106@piuha.net>
Date: Fri, 01 Jul 2011 23:48:12 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: robert@raszuk.net
References: <CA31F3ED.4AB6%jason.weil@twcable.com> <4E0DB36D.60303@raszuk.net> <7EC07A1A-CCD2-4A4A-A92D-8475430F558E@townsley.net>
In-Reply-To: <7EC07A1A-CCD2-4A4A-A92D-8475430F558E@townsley.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: fun@ietf.org
Subject: Re: [fun] status of the homenet effort
X-BeenThere: fun@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "FUture home Networking \(FUN\)" <fun.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fun>, <mailto:fun-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fun>
List-Post: <mailto:fun@ietf.org>
List-Help: <mailto:fun-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fun>, <mailto:fun-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 21:48:21 -0000

Robert,

Thank you for very interesting questions.

As Mark noted, some aspects of diagnostics and troubleshooting are 
inherent in the notion of automatic configuration. Prefix delegation, 
routing, etc. has to figure out if there is connectivity and what to do 
if there isn't. But its mostly automatic, not built for human network 
managers to play with.

Maybe the answers to your question are clearer once we have completed 
the architecture work. Maybe there are some additional diagnostics 
needs, but at this point I'll admit that I don't see them.

Whereas...

>> 2. How about multihoming with seamless switchover ?
>>     
>
> This particular elephant has been in and out of various versions of the charter. I'll plead the 5th on this one and ask Jari to describe where we are on this, in particular in relation to mif, shim6, lisp, rrg, v6ops, or any of the other areas that are touching on this. 
>
> Personally, I think it would be naive to not include the various possibilities of multihomed connectivity, at the vary least in describing the architecture for which we will work within. I don't think homenet is the place to solve the general issue of "seamless multihoming" at the protocol level, but perhaps we would point to what works well in a home setting... we might even agree to one way to do it if we are really, really, lucky. 
>   

I think multihoming solutions should be out of scope. Not because they 
are uninteresting, they're not -- they are very important. And I know 
there are specific requirements for it in some home network cases. But 
it is a very complex and challenging topic by itself, and one where we 
have multiple IETF workings groups already. I agree with Mark though 
that we may point to some solutions and think about this during the 
architecture work, but even there I'd be a bit careful not to taken on 
too ambitious tasks.

Jari