Re: [homenet] Updates to Homenet Architecture Principles doc

Tim Chown <tjc@ecs.soton.ac.uk> Fri, 13 June 2014 14:25 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 E883C1B293A for <homenet@ietfa.amsl.com>; Fri, 13 Jun 2014 07:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.871
X-Spam-Level:
X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] 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 3T6S0sdrw3AK for <homenet@ietfa.amsl.com>; Fri, 13 Jun 2014 07:25:42 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5ADB1B2919 for <homenet@ietf.org>; Fri, 13 Jun 2014 07:25:41 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5DEPaQG006501; Fri, 13 Jun 2014 15:25:36 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5DEPaQG006501
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1402669537; bh=PEt0J6MIthUCNaAmPmfK9mTL/sM=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=W00qWGss01tXst4/fN/myg0wctGgiRw2dHfdA1ADgLrxr00wxEqdoPhVcsx2aikGU hsqpl+nikfeo5DCgTyIkbNu3xxoQYqT8cEWkjdr7XmzwlnqZU/iGKCfIpvOt9RAila UYrP1dR0z3Hp6dCpyTrBxVmcuBTsTQorxFc8gu2Y=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id q5CFPa0546035702eg ret-id none; Fri, 13 Jun 2014 15:25:37 +0100
Received: from dhcp-207-84.wireless.soton.ac.uk (dhcp-207-84.wireless.soton.ac.uk [152.78.207.84] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5DEPa9N001863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 15:25:36 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_F69044B2-2048-4039-A045-0EC8BC1308C6"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <E66DDB31-C318-4025-BF8A-15F2336A2A08@fugue.com>
Date: Fri, 13 Jun 2014 15:25:36 +0100
Message-ID: <EMEW3|c9eee95ab0d06c016200d4557ca869f9q5CFPa03tjc|ecs.soton.ac.uk|B289FE60-E0C7-4D3B-BE21-3C7109FAC69C@ecs.soton.ac.uk>
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>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.1878.2)
X-smtpf-Report: sid=q5CFPa054603570200; tid=q5CFPa0546035702eg; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s5DEPaQG006501
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ICd-2sv5h3s2DTao3iHbUN4uKh0
Cc: Bellis Ray <Ray.Bellis@nominet.org.uk>, "homenet@ietf.org Group" <homenet@ietf.org>, Lorenzo Colitti <lorenzo@google.com>
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: Fri, 13 Jun 2014 14:25:44 -0000

On 13 Jun 2014, at 14:57, Ted Lemon <mellon@fugue.com> wrote:

> On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>> Not to me they didn't. Seriously - if you understand what we're being asked to do, and it's simple to explain, then it shouldn't take long for you to type. Please?
> 
> The working group would presumably like for there to be routing on the homenet.   What problems is the routing supposed to solve?   What things are priorities?   What things aren't priorities?
> 
> Clearly we need the routing solution to get packets to the right egress based on source address.   Do we also need it to do load sharing across parallel links, if such links exist?   Is it important to minimize the number of hops?  

Para 7 of 3.5:
" 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."

>  How long of a delay can there be between changes to the topology (e.g., a router being unplugged) and recovery, assuming that a flow was going through that router?   

Para 6 of 3.5:
"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… “

> Is it okay to break a flow in that situation, or does it need to survive the transition?   

Not stated.  Should it be different to the border router resetting?

> Does the routing protocol need to be aware of the type of media a given link crosses, and does it need to prefer one media type over another where both are available?

Para 5 of 3.5:
"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 inclusion of physical layer
   characteristics including bandwidth, loss, and latency in path
   computation should be considered for optimising communication in the
   homenet.“

> I'm basically making questions up here.   The document should say what the working group wants routing to accomplish.   Right now it's a bit of a kitchen sink, with a lot of (IMHO) inappropriately prescriptive text.

Well, 3 of the 4 questions seem to be answered, or at least considered if left relatively open.

Tim

> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet