Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 26 November 2015 15:15 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4E41B3AF2 for <homenet@ietfa.amsl.com>; Thu, 26 Nov 2015 07:15:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.536
X-Spam-Level:
X-Spam-Status: No, score=-4.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 mDz_tUzpV95y for <homenet@ietfa.amsl.com>; Thu, 26 Nov 2015 07:15:57 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2AA1B3AEE for <homenet@ietf.org>; Thu, 26 Nov 2015 07:15:57 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 14704A2; Thu, 26 Nov 2015 16:15:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1448550954; bh=fudV9wdgAgAfU5VS6EUQssMEODRY3OqkENIu8+VqonU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dUhhemYKJsHhfbrOQXki95nnbUnLMHAB6SfcVInwX23+aVzHarrw1pR6MrQtGQh0P dGYBd//HX93aUsUPZvC0MYvID7TOJlnFg5i2wlTtRQ9nW52I/RuKutbGiwKoenEEw4 Y9TYPx3s3Qu083KCRxkKs0icf8DKTr9DWVkiikfs=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0C7BEA1; Thu, 26 Nov 2015 16:15:54 +0100 (CET)
Date: Thu, 26 Nov 2015 16:15:54 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Ray Hunter (v6ops)" <v6ops@globis.net>
In-Reply-To: <56571260.6040504@globis.net>
Message-ID: <alpine.DEB.2.02.1511261610310.24520@uplift.swm.pp.se>
References: <20151016113242.29159.37112.idtracker@ietfa.amsl.com> <5620E158.4000309@openwrt.org> <56265237.8020202@gmail.com> <56571260.6040504@globis.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/miACx-VePBxydVkt7dfrnTm3dC4>
Cc: homenet@ietf.org
Subject: Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 26 Nov 2015 15:15:59 -0000

On Thu, 26 Nov 2015, Ray Hunter (v6ops) wrote:

> I have read this draft and find it interesting.
>
> The use of host routes would seem appealing to avoid
> 1) any need for stateful "home agent" and multiple forwarding
> 2) renumbering of the end nodes when roaming
> 3) relatively small number of hosts compared to the complexity of the 
> topology
>
> Use of RFC7217 addresses would seem appropriate, but that assumes that DAD 
> really is reliable at the time a node attaches to the homenet for the first 
> time.

Wouldn't it be better to adopt 
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 and 
just give every device its own /64 and move that around?

My worry about the whole L3 approach is how long does it take to 
re-establish packet flows after the L2 wifi handover between APs compared 
to an L2 only solution?

> What's the benefit/downside of this approach compared to having roaming 
> nodes actively take part in the HNCP acting as "multi-homed routers" 
> with an internal (invariant) /64 VLAN used to bind to applications?

I'd say this approach adds one more layer that needs to come up before 
packets can start flowing again, especially since it would require routing 
protocol participation as well, I'd imagine.

If 802.11 can assure L2 handover in 1 second (I don't know how long the 
handover time is, just guessing), how much are we willing to add in time 
because of L3 mechanisms added on top of this, before packet flows are up 
and running again?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se