Re: [homenet] Updates to Homenet Architecture Principles doc

Ray Hunter <v6ops@globis.net> Sat, 14 June 2014 15:18 UTC

Return-Path: <v6ops@globis.net>
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 EFCF41B286F for <homenet@ietfa.amsl.com>; Sat, 14 Jun 2014 08:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DTyCqeg4niaX for <homenet@ietfa.amsl.com>; Sat, 14 Jun 2014 08:18:20 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C45811A038B for <homenet@ietf.org>; Sat, 14 Jun 2014 08:18:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C0C95871517; Sat, 14 Jun 2014 17:18:18 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyY4lpcfZl76; Sat, 14 Jun 2014 17:18:18 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:749f:2481:2ef4:998d]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 90A05870056; Sat, 14 Jun 2014 17:18:18 +0200 (CEST)
Message-ID: <539C67AA.4030501@globis.net>
Date: Sat, 14 Jun 2014 17:18:02 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
References: <BEB843C7-EB1D-486A-A9A1-B99D48775D33@nominet.org.uk> <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <CAKD1Yr2mzZOvCDwyyEZHef1rk5PAxtNZRVRys43SXnD=gVxLBA@mail.gmail.com> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <CAKD1Yr0hr8Pa_QU_9mjRjbxffQ=mdgOWYSQUyLc5ewkpuf5OmA@mail.gmail.com> <F08A2136-E88F-4785-BE01-14D386B9C2D9@fugue.com> <CAKD1Yr1nhnvG2H_9eeW-Dono3cZqYaxMZaCR1vcueOQgW4xqYQ@mail.gmail.com> <E66DDB31-C318-4025-BF8A-15F2336A2A08@fugue.com> <B289FE60-E0C7-4D3B-BE21-3C7109FAC69C@ecs.soton.ac.uk> <EMEW3|c9eee95ab0d06c016200d4557ca869f9q5CFPa03tjc|ecs.soton.ac.uk|B289FE60-E0C7-4D3B-BE21-3C7109FAC69C@ecs.soton.ac.uk> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr>
In-Reply-To: <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/cFAfdf-jA37qbK2GbgwNkCWx2os
Cc: "homenet@ietf.org Group" <homenet@ietf.org>
Subject: Re: [homenet] Updates to Homenet Architecture Principles doc
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Sat, 14 Jun 2014 15:18:21 -0000

> Juliusz Chroboczek <mailto:jch@pps.univ-paris-diderot.fr>
> 14 June 2014 16:25
>> Is a specific update address preferred?
>> [my view]   The routing protocol should support both use of unicast and
>> multicast updates.
>
> Please clarify.  Are you saying that the routing protocol must be able to
> run over link layers that don't support link-local multicast?  AFAIK,
> link-local multicast is part of the base IPv6 spec.

Multicast has issues on some link topologies (e.g. where it has to be 
emulated), and in situations where devices attempt to sleep for as long 
as possible. So even though link-local multicast may be part of the IPv6 
base spec, it may be desirable to avoid use of multicast traffic where 
possible. e.g. a routing protocol could perform initial neighbor 
discovery using multicast, but then switch to unicast when maintaining 
individual neighbor associations on the longer term, or for exchanging 
information with specific neighbors.
>> Multi-path support?
>> [my view] yes.
>> [this is in the current architecture document]
>
> Then I think I don't understand what is meant by "multi-path support".  Is
> that merely the ability to switch to a better route if one becomes
> available?  Or is there something more to it?  Could you please clarify?
>
> -- Juliusz
I don't know that there is a single definition.

"The inclusion of physical layer
    characteristics including bandwidth, loss, and latency in path
    computation should be considered for optimising communication in the
    homenet."

I interpret the above text as requesting an ability to perform load 
balancing over equal cost paths, potentially taking into account packet 
loss and link quality when selecting which stream to send over which link.
Another possible interpretation of the text would be an ability to route 
packets based on traffic type, e.g. policy based routing of video 
traffic over a different link to FTP.
Or a combination of the above.

If you have a better interpretation or definition then please share.
>
>
> ------------------------------------------------------------------------


-- 
Regards,
RayH