Re: [homenet] Updates to Homenet Architecture Principles doc

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 16 June 2014 20:10 UTC

Return-Path: <alexandru.petrescu@gmail.com>
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 C444A1A01CE for <homenet@ietfa.amsl.com>; Mon, 16 Jun 2014 13:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Level:
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 r2CZPi2llpNM for <homenet@ietfa.amsl.com>; Mon, 16 Jun 2014 13:10:01 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1631A01CC for <homenet@ietf.org>; Mon, 16 Jun 2014 13:09:48 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5GK9k2W001799; Mon, 16 Jun 2014 22:09:46 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C8BB220628A; Mon, 16 Jun 2014 22:11:30 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BBAF72061A2; Mon, 16 Jun 2014 22:11:30 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.86.27]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5GK9YKh020803; Mon, 16 Jun 2014 22:09:46 +0200
Message-ID: <539F4EFE.5020407@gmail.com>
Date: Mon, 16 Jun 2014 22:09:34 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Mark Townsley <mark@townsley.net>
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> <88089D9C-9CBD-4C91-A69E-BDCE0A4FEEB1@townsley.net> <01E23AA3-96CE-44A0-A513-C52D71ED6D92@fugue.com> <539B5EC9.1090001@gmail.com> <949CCE9B-67A5-4293-94ED-5DB946BD1B4F@fugue.com> <B52794B6-0516-46F0-9981-7EB4471228FA@townsley.net>
In-Reply-To: <B52794B6-0516-46F0-9981-7EB4471228FA@townsley.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1zblKsv35aFf9C9ktxuYYLbzyC4
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: Mon, 16 Jun 2014 20:10:04 -0000

Hi Mark, participants to homenet WG,

I have some comments, FWIW.

Le 14/06/2014 10:04, Mark Townsley a écrit :
>
> On Jun 13, 2014, at 10:44 PM, Ted Lemon <mellon@fugue.com
> <mailto:mellon@fugue.com>> wrote:
>
>
>> On Jun 13, 2014, at 4:27 PM, Brian E Carpenter
>> <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
>> wrote:
>>> It's prototype implementations and early deployments that will
>>> tell us the right answer, not further debate.
>>
>> Again, I didn't ask for "the answer."   I asked for a description
>> of what we want in a routing protocol that isn't so prescriptive.
>> There's a lot of prescriptive stuff in there, and the reason that
>> the particular paragraph you are proposing we remove got added was
>> to counterbalance it.   E.g., why is there a paragraph about all
>> the routers knowing the whole topology of the network?   Maybe they
>> will, maybe they won't, but why is it specified?   If we don't know
>> what we want, this bit seems awfully specific.   If we do know what
>> we want, why not say what we want?
>>
>> I think the right answer is to take out more text, but I'm not okay
>>  with just taking out the particular paragraph you mentioned, or I
>>  would not have asked for the working group's help on this.
>>
>
> While I agree with Brian here, if you want more text out, so be it.
> Here's a proposal which
>
> does that, stopping short of trying to continue word-smithing the
> document at this stage.
>
>
> I simply took section 3.5 from -16, and removed sentences that seemed
> to me to be overlyprescriptive,
>
> including the paragraph from Adrian.
>
>
> Ted, Is that good enough for you?
>
>
>
> Removed:
>
>
>
>
> Using information distributed through the routing protocol, each node
> in the homenet should be able to build a graph of the topology of the
> whole homenet including attributes such as links, nodes,
> connectivity, and (if supported by the protocol in use) link
> metrics.
>
>
> Routing within the homenet will determine the least cost path across
> the homenet towards the destination address given the source
> address. The path cost will be computed as a linear sum of the metric
> assigned to each link.  The metric may be configured or automatically
> derived per link based on consideration of factors such as worst-case
> queue depth and router processing capabilities.
>
>
> The inclusion of physical layer characteristics including bandwidth,
> loss, and latency in path computation should be considered for
> optimising communication in the homenet.
>
>
> Homenets may use a variety of underlying link layer technologies,
> and may therefore benefit from being able to use link metrics if
> available.  It may be beneficial for traffic to use multiple paths
> to a given destination within the homenet where available, rather
> than a single best path.
>
>
>
> Result:
>
>
>
>
>
>
>
>
>
>
> 3.5
> <http://tools.ietf.org/html/draft-ietf-homenet-arch-16#section-3.5>.
> Routing functionality
>
>
>
> Routing functionality is required when there are multiple routers
> deployed within the internal home network.  This functionality could
> be as simple as the current 'default route is up' model of IPv4 NAT,
> or, more likely, it would involve running an appropriate routing
> protocol.  Regardless of the solution method, the functionality
> discussed below should be met.
>
> The homenet unicast routing protocol should be based on a previously
> deployed protocol that has been shown to be reliable and robust, and
> that allows lightweight implementations, but that does not preclude
> the selection of a newer protocol for which a high quality open
> source implementation becomes available.

Sounds as if there is no lightweight implementations high quality
open source of existing routing protocols?

> The routing protocol should support the generic use of multiple
> customer Internet connections, and the concurrent use of multiple
> delegated prefixes.  A routing protocol that can make routing
> decisions based on source and destination addresses

Sounds as if current implementations dont do that?

> is thus desirable, to avoid upstream ISPBCP 38
> <http://tools.ietf.org/html/bcp38>  ingress filtering problems.
> Multihoming support should also include load-balancing to multiple
> providers, and failover from a primary to a backup link when
> available.  The protocol however should not require upstream ISP
> connectivity to be established to continue routing within the
> homenet.
>
> Multiple types of physical interfaces must be accounted for in the
> homenet routed topology.  Technologies such as Ethernet, WiFi,
> Multimedia over Coax Alliance (MoCA), etc. must be capable of
> coexisting in the same environment and should be treated as part of
> any routed deployment.
>
> The routing environment should be self-configuring, as discussed
> previously.  Minimising convergence time should be a goal in any
> routed environment, but as a guideline a maximum convergence time at
> most 30 seconds should be the target (this target is somewhat
> arbitrary, and was chosen based on how long a typical home user
> might wait before attempting another reset; ideally the routers might
> have some status light indicating they are converging, similar to an
> ADSL router light indicating it is establishing a connection to its
> ISP).
>
> At most one routing protocol should be in use at a given time in a
> given homenet.  In some simple topologies, no routing protocol may
> be needed.

Some deployments of IPv6 homenets with multiple IP subnets dont run 
routing protocols, but static routing.  I've discovered that recently 
with much enthusiasm.  Maybe it's just a first step, but I havent seen 
documented this simple and numerous existing deployments.

> If more than one routing protocol is supported by routers
> in a given homenet, then a mechanism is required to ensure that all
> routers in that homenet use the same protocol.

Ok.

>
>
>
>
> Chown, et al.           Expires December 12, 2014              [Page
> 29]
>
> <http://tools.ietf.org/html/draft-ietf-homenet-arch-16#page-30>
> Internet-Draft            IPv6 Home Networking                 June
> 2014
>
>
> An appropriate mechanism is required to discover which router(s) in
> the homenet are providing the CER function.  Borders may include but
> are not limited to the interface to the upstream ISP, a gateway
> device to a separate home network such as a LLN network, or a
> gateway to a guest or private corporate extension network.  In some
> cases there may be no border present, which may for example occur
> before an upstream connection has been established.  The border
> discovery functionality may be integrated into the routing protocol
> itself, but may also be imported via a separate discovery mechanism.

One simple mechanism to achieve it is to adiministratively assign 
coherently the default route in all the routers.  This may sound less 
sophisticated than saying "discovery" but could work.

Maybe a simpler requirement would be a "default-route distribution 
protocol", like in Router Renumbering, rather than a routing protocol 
which includes a border discovery.

> Ideally, LLN or other logically separate networks should be able
> exchange routes such that IP traffic may be forwarded among the
> networks via gateway routers which interoperate with both the
> homenet and the LLN.  Current home deployments use largely different
> mechanisms in sensor and basic Internet connectivity networks.  IPv6
> virtual machine (VM) solutions may also add additional routing
> requirements.

This paragraph may read inconsistent by some reader (me).

I can see many sensors in home.  But the power requirements are much 
lesser than e.g. an outdoors deployments - indoors there is even IP over 
220V (PLC) so power is plenty.  There would be little reason to run an 
LLN in home.

Additionally, I think virtual machines (like in virtualization, or jvm) 
typically require much more power than real but small routers.

My two cents worth,

Alex