From SRS0=mfG9=26=darou.fr=pierre.pfister@bounces.m4x.org Sun Jun 1 01:47:20 2014 Return-Path: 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 B2D6B1A01BF for ; Sun, 1 Jun 2014 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 utjCUilTTfQA for ; Sun, 1 Jun 2014 01:47:18 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D781A01BB for ; Sun, 1 Jun 2014 01:47:11 -0700 (PDT) Received: from [192.168.1.86] (AStrasbourg-157-1-36-168.w90-40.abo.wanadoo.fr [90.40.243.168]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 61FB51408EEE0; Sun, 1 Jun 2014 10:47:03 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Pierre Pfister In-Reply-To: <20140531214832.GF46558@Space.Net> Date: Sun, 1 Jun 2014 10:47:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3578EBC1-490B-497A-9EE1-B416F5585880@darou.fr> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <20140531180343.GZ46558@Space.Net> <95AE7A8A-30BA-4BDD-ABFD-C6B62FDF6A77@gmail.com> <20140531214832.GF46558@Space.Net> To: "homenet@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Sun Jun 1 10:47:04 2014 +0200 (CEST)) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5sWGKQC_l5LHN3P85w39M-SO0wk Cc: Gert Doering , Douglas Otis , Mikael Abrahamsson Subject: Re: [homenet] Single or Multiple Routing Protocols in Homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 08:47:43 -0000 Hello, I=92m not going to argue about which routing protocol to use (Juliusz = remark about GRE tunnel was interesting thought), but=85 See how hard it is ? Home routers vendors will have a bad enough time putting a single = routing protocols in their routers,=20 we can=92t ask them to put two of them. Nevertheless, their is so much = ideology beside that discussion=85 We are going to choose one, and what if we change our minds in 10 or 20 = years ? What if a new protocol is created that fits way better homenet requirements ? Once vendors are = cool with one routing protocol, we might want to allow home networks to move to a new one, or even the = next version of the previous one. I think it doesn=92t cost much (really) to allow flexibility. - Someone that administrate all the routers in the home should be able = to use a different routing protocol than the one that homenet chose. - In the future, we should be able to move from one routing protocol to = another without backward compatibility (And that might mean that = transition routers will have to support two routing protocols until it = becomes useless to support the previous one). So even if most will agree that supporting multiple routing protocol is = a madness in the general case.=20 It=92s not that hard to =92support it=92 while requiring one single = routing protocol as mandatory in home networks. And whenever we want to move to another protocol, maybe in 20 years, it = will allow transitioning softly. Have a nice day, Pierre Le 31 mai 2014 =E0 23:48, Gert Doering a =E9crit : > Hi, >=20 > On Sat, May 31, 2014 at 12:17:16PM -0700, Douglas Otis wrote: >>>> On Sat, 31 May 2014, Gert Doering wrote: >>>>=20 >>>>> So I'd keep the list of supported protocols as small as possible - = and=20 >>>>> stick to IP protocols. ISIS is great for ISP environments, but = does not=20 >>>>> nicely adapt to a unix environment where the kernel has no idea = about=20 >>>>> ISO/OSI protocols and you have to do everything via raw sockets. = Which=20 >>>>> would be a fairly typical environment for a CPE router. > [..] >>=20 >> I could be wrong, but I don't think that was the point. There are = also layer 2 protocols to consider. >=20 > I quoted my original comment above. This is the context we're talking > about: protocols to be considered for routing inside the homenet. >=20 > In *homenet*. >=20 >> Expecting everything to be handled at IP transport layer 3 will = confront extremely difficult security issues. >>=20 >> Testing using a modern printer/scanner illustrated a major problem = when devices were not restricted to link-local. Something like RBridge = supporting PPP would provide a much safer foundation upon which to = build.=20 >>=20 >> All networks must begin with layer 2 starting points. Selective = routing between Rbridges would allow an ability to share data between = HDCP enforced multi-media display devices using link-local addresses. = There will be video cameras, baby monitors, HVAC/SCADA controls, = printers and scanners offering media stick access, etc. These devices = were never intended to directly interface with the Internet. These = devices MUST NOT be assigned routable IPv4 or IPv6 addresses. Using = mDNS proxy into DNS would be setting the stage for major security = disasters. >=20 > While this is all true, I cannot see how this related to what I said > above, and to the question of "is ISIS better suited as a link-state > protocol to transport opaque LSAs than OSPFv3?" - because *both* do = that > job without "assigned routable IPv4 or IPv6 addresses" - ISIS talks = over > L2 (or potentially IPv6 link-local as was mentioned), OSPFv3 talks = over=20 > IPv6 link-local. >=20 > This thread wasn't about questioning the whole homenet architecture, = but > about a specific side aspect: would additional routing protocols be = considered > a plus. And I say "no", out of general reasoning, and because I = consider > the particular protocol to be not very well suited for typical SoHo = router > implementations. >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Sun Jun 1 03:50:32 2014 Return-Path: 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 2D4601A01D6 for ; Sun, 1 Jun 2014 03:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.651] 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 Ae9gSvgkVWkS for ; Sun, 1 Jun 2014 03:50:30 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF101A01D4 for ; Sun, 1 Jun 2014 03:50:29 -0700 (PDT) X-Original-To: homenet@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9C09060B34 for ; Sun, 1 Jun 2014 12:50:23 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6A2F4603FB for ; Sun, 1 Jun 2014 12:50:23 +0200 (CEST) Received: (qmail 61753 invoked by uid 1007); 1 Jun 2014 12:50:23 +0200 Date: Sun, 1 Jun 2014 12:50:23 +0200 From: Gert Doering To: Pierre Pfister Message-ID: <20140601105023.GI46558@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <20140531180343.GZ46558@Space.Net> <95AE7A8A-30BA-4BDD-ABFD-C6B62FDF6A77@gmail.com> <20140531214832.GF46558@Space.Net> <3578EBC1-490B-497A-9EE1-B416F5585880@darou.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="134W5fYqoZsbUgOZ" Content-Disposition: inline In-Reply-To: <3578EBC1-490B-497A-9EE1-B416F5585880@darou.fr> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/DRvoKGE7k4mZc0BlK9ANehDbH7A Cc: Gert Doering , "homenet@ietf.org" , Douglas Otis , Mikael Abrahamsson Subject: Re: [homenet] Single or Multiple Routing Protocols in Homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 10:50:31 -0000 --134W5fYqoZsbUgOZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Jun 01, 2014 at 10:47:03AM +0200, Pierre Pfister wrote: > So even if most will agree that supporting multiple routing protocol is a= madness in the general case.=20 > It?s not that hard to ?support it? while requiring one single routing pro= tocol as mandatory in home networks. > And whenever we want to move to another protocol, maybe in 20 years, it w= ill allow transitioning softly. Having multiple routing protocols and select between them is already=20 permitted by the current HNCP draft (for example). The question was more whether "add ISIS today" would bring a benefit to homenet, and I still maintain "no" - to the contrary, it is harmful - as you said, we can be happy if CPE vendors get one protocol right. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --134W5fYqoZsbUgOZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU4sFb99WwGXkzn/FAQJ3eQ/+M0DO8A+wwea6TnXakuKaF8Q1l9W9AMg1 3uv7YWm+h6ynVPyEYCWEUD0lmxCZ4wInHh625m4MoWVjKcxlVnr4oSAMvP9spPl9 GKeTX02Mwvpo8Y1Gi+7OiyfXSYsuTriXVwtjE1Ukro6SzanRN5ur2Sb7ab9PBUzD VrQRlHPugHnoNcHZNe1poCvI42t8l73+gakawhKq6vEL7vEUs/Xw+NQmizXfw1fO XYs8LaRO/s1AgvAsnT6d5AQqM+X7Fp1H4Wh9K3af95Uc798RbWDnO6p/ecZbOPF+ nrbltmvToGZUcBjfUMSENlvZe8Ta5TXmYcvWPCGPTH7wrMs8jAzqMWpsLXNNTR3o gLuYxRpCdVy6koIfnWZgnYq0i+OUXc86Erov9J9C6vgZFOTfp9EoCc3Ee8yKwZ5L 2DCMaBR1z7P8TJIXu5vWcmQkCXZAXw0UHD11apPhkWwqq3nXS25PSV52DxSHBG4R pYIa2YRlZPO1mXN6GXMfMywqrqCxhjtdKkge7TxETXAayb/KkcribunNoH/HDcXd zG52y1EMBcIGJwMixNeFYQ+GR8XUSR0Bs5lhL1dIkFAQAVS4Yt64tdeuLp+0H4PC iScggwj1GUfIlE4mrXYYtVnjPVHeKUEss4UjA2MyN1gElQ5r9nzJ+4zBFSzO25Q3 /Fa4pXxoDNw= =I+e3 -----END PGP SIGNATURE----- --134W5fYqoZsbUgOZ-- From nobody Sun Jun 1 05:38:56 2014 Return-Path: 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 8EF271A0201 for ; Sun, 1 Jun 2014 05:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.794 X-Spam-Level: X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no 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 eWFoNnOzw5Qr for ; Sun, 1 Jun 2014 05:38:54 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD911A01FF for ; Sun, 1 Jun 2014 05:38:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7F52C3A for ; Sun, 1 Jun 2014 14:38:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90lPNb+kz1ZZ for ; Sun, 1 Jun 2014 14:38:44 +0200 (CEST) Received: from [IPv6:2a00:8640:1::c0d6:438e:f562:9d5e] (unknown [IPv6:2a00:8640:1:0:c0d6:438e:f562:9d5e]) by mail.sintact.nl (Postfix) with ESMTPSA id 8D6C637 for ; Sun, 1 Jun 2014 14:38:44 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.3\)) From: Sander Steffann In-Reply-To: <20140601105023.GI46558@Space.Net> Date: Sun, 1 Jun 2014 14:38:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <20140531180343.GZ46558@Space.Net> <95AE7A8A-30BA-4BDD-ABFD-C6B62FDF6A77@gmail.com> <20140531214832.GF46558@Space.Net> <3578EBC1-490B-497A-9EE1-B416F5585880@darou.fr> <20140601105023.GI46558@Space.Net> To: "homenet@ietf.org" X-Mailer: Apple Mail (2.1878.3) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/mjEP3l-o90s9YZ-BbdS5R9nQy8E Subject: Re: [homenet] Single or Multiple Routing Protocols in Homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 12:38:55 -0000 Hi, Op 1 jun. 2014, om 12:50 heeft Gert Doering het = volgende geschreven: > On Sun, Jun 01, 2014 at 10:47:03AM +0200, Pierre Pfister wrote: >> So even if most will agree that supporting multiple routing protocol = is a madness in the general case.=20 >> It?s not that hard to ?support it? while requiring one single routing = protocol as mandatory in home networks. >> And whenever we want to move to another protocol, maybe in 20 years, = it will allow transitioning softly. >=20 > Having multiple routing protocols and select between them is already=20= > permitted by the current HNCP draft (for example). >=20 > The question was more whether "add ISIS today" would bring a benefit = to > homenet, and I still maintain "no" - to the contrary, it is harmful - = as > you said, we can be happy if CPE vendors get one protocol right. +1 I personally don't really care about which protocol that should be (I = have some preferences, but "getting one protocol right" outweighs all = those preferences by a huge margin) as long as we design something that = is easy enough for CPE vendors to implement correctly so that for the = home user everything just works. Needing to implement multiple protocols, having to negotiate with other = devices which of those protocols to use, network flaps because a device = was added to the network that doesn't support the protocol that the = other devices agreed upon etc. don't help in this regard. Please remember: the end goal is to create a situation for home users = that just works and works reliably, not to design the most fancy and = cool combination of protocols possible... Cheers, Sander From nobody Sun Jun 1 05:51:53 2014 Return-Path: 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 5E4591A020B for ; Sun, 1 Jun 2014 05:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no 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 bV4KodhkqR7p for ; Sun, 1 Jun 2014 05:51:51 -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 B17451A020A for ; Sun, 1 Jun 2014 05:51:50 -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 s51CpeMX006666; Sun, 1 Jun 2014 13:51:40 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s51CpeMX006666 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401627100; bh=7fzIzDA2ML8fn9xZpn/zpPkBjD0=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=J8PvVwHmkzF2aZn2v1FkaDTa6tqMqitGN2sSSyGDsszVEPK2YDg6ioDi3jez5ZkJ8 vYF+Xn7UsJd5aLtV89lAkuiCZ4cF2r7ctoyqEIbPeZAWjZX91ms0TwnIDKp3gdRuWa PlWOvDwS+EwL9sszR+xPXe1Hi8fl2A6Xb89Ylm4c= 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 with ESMTP (valid=N/A) id q50Dpe05460558441d ret-id none; Sun, 01 Jun 2014 13:51:40 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s51CpdmB019049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jun 2014 13:51:40 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: Date: Sun, 1 Jun 2014 13:51:38 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <20140531180343.GZ46558@Space.Net> <95AE7A8A-30BA-4BDD-ABFD-C6B62FDF6A77@gmail.com> <20140531214832.GF46558@Space.Net> <3578EBC1-490B-497A-9EE1-B416F5585880@darou.fr> <20140601105023.GI46558@Space.Net> To: Sander Steffann X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q50Dpe054605584400; tid=q50Dpe05460558441d; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s51CpeMX006666 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/Ff6HCKUbvxdo2F-tv5K7s-c7sc4 Cc: "homenet@ietf.org" Subject: Re: [homenet] Single or Multiple Routing Protocols in Homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 12:51:52 -0000 On 1 Jun 2014, at 13:38, Sander Steffann wrote: > Hi, >=20 > Op 1 jun. 2014, om 12:50 heeft Gert Doering het = volgende geschreven: >=20 >> On Sun, Jun 01, 2014 at 10:47:03AM +0200, Pierre Pfister wrote: >>> So even if most will agree that supporting multiple routing protocol = is a madness in the general case.=20 >>> It?s not that hard to ?support it? while requiring one single = routing protocol as mandatory in home networks. >>> And whenever we want to move to another protocol, maybe in 20 years, = it will allow transitioning softly. >>=20 >> Having multiple routing protocols and select between them is already=20= >> permitted by the current HNCP draft (for example). >>=20 >> The question was more whether "add ISIS today" would bring a benefit = to >> homenet, and I still maintain "no" - to the contrary, it is harmful - = as >> you said, we can be happy if CPE vendors get one protocol right. >=20 > +1 >=20 > I personally don't really care about which protocol that should be (I = have some preferences, but "getting one protocol right" outweighs all = those preferences by a huge margin) as long as we design something that = is easy enough for CPE vendors to implement correctly so that for the = home user everything just works. >=20 > Needing to implement multiple protocols, having to negotiate with = other devices which of those protocols to use, network flaps because a = device was added to the network that doesn't support the protocol that = the other devices agreed upon etc. don't help in this regard. >=20 > Please remember: the end goal is to create a situation for home users = that just works and works reliably, not to design the most fancy and = cool combination of protocols possible=85 Just as a reminder, here is what we converged on at IETF89 for text in = the homenet arch. The =93zero or one=94 protocol message was clear. I = don=92t recall a clear answer on whether to pass config info via the = routing protocol or a separate protocol, but as HNCP shapes up as a = proposal I suspect the tradeoffs will become clearer towards an answer = there. "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. 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." Tim= From nobody Sun Jun 1 05:58:58 2014 Return-Path: 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 2601F1A020E for ; Sun, 1 Jun 2014 05:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no 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 Hxszgq3tvsL3 for ; Sun, 1 Jun 2014 05:58:55 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736151A020A for ; Sun, 1 Jun 2014 05:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B21B13A; Sun, 1 Jun 2014 14:58:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzAnfHG1Umm0; Sun, 1 Jun 2014 14:58:47 +0200 (CEST) Received: from [IPv6:2a00:8640:1::c0d6:438e:f562:9d5e] (unknown [IPv6:2a00:8640:1:0:c0d6:438e:f562:9d5e]) by mail.sintact.nl (Postfix) with ESMTPSA id 9EA1837; Sun, 1 Jun 2014 14:58:47 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.3\)) From: Sander Steffann In-Reply-To: Date: Sun, 1 Jun 2014 14:58:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43BF25FD-85C0-4413-9B19-44CDFC583356@steffann.nl> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <20140531180343.GZ46558@Space.Net> <95AE7A8A-30BA-4BDD-ABFD-C6B62FDF6A77@gmail.com> <20140531214832.GF46558@Space.Net> <3578EBC1-490B-497A-9EE1-B416F5585880@darou.fr> <20140601105023.GI46558@Space.Net> To: Tim Chown X-Mailer: Apple Mail (2.1878.3) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/OFTWLS0N-Yw_g57To9pnBb87pwo Cc: "homenet@ietf.org" Subject: Re: [homenet] Single or Multiple Routing Protocols in Homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 12:58:56 -0000 Hi Tim, > Just as a reminder, here is what we converged on at IETF89 for text in = the homenet arch. The =93zero or one=94 protocol message was clear. I = don=92t recall a clear answer on whether to pass config info via the = routing protocol or a separate protocol, but as HNCP shapes up as a = proposal I suspect the tradeoffs will become clearer towards an answer = there. >=20 > "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. 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." Sounds good, and I see the need for having the possibility to introduce = a new routing protocol in the future so that we can evolve if/when = necessary. However, having multiple routing protocols will be disruptive = in some ways. When a homenet consists of devices that all support the = new protocol then connecting an older device that doesn't support it = will force the whole network to switch to the old protocol. While this = may be unavoidable when designing HomenetNG, it is not something we = should be causing today. Cheers, Sander From nobody Sun Jun 1 06:07:35 2014 Return-Path: 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 60A531A021C for ; Sun, 1 Jun 2014 06:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 wv9VW3Ylpldu for ; Sun, 1 Jun 2014 06:07:29 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 561801A0219 for ; Sun, 1 Jun 2014 06:07:29 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s51D7Nm1020039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 1 Jun 2014 15:07:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s51D7N5a014494 for ; Sun, 1 Jun 2014 15:07:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 44FA8128106 for ; Sun, 1 Jun 2014 15:07:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5LvYJAV8VpSw for ; Sun, 1 Jun 2014 15:07:07 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D59E712810E for ; Sun, 1 Jun 2014 15:07:07 +0200 (CEST) Date: Sun, 01 Jun 2014 15:07:08 +0200 Message-ID: <87iookwzgj.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "homenet@ietf.org" In-Reply-To: <87k391k95r.wl%jch@pps.univ-paris-diderot.fr> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <87k391k95r.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 01 Jun 2014 15:07:23 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 01 Jun 2014 15:07:23 +0200 (CEST) X-Miltered: at korolev with ID 538B258B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 538B258B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 538B258B.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 538B258B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 538B258B.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 538B258B.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/6KMcDSWDoofwmSJ2v9BzXNwNAvU Subject: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 13:07:31 -0000 > [...] IPv6, where routers communicate using link-local addresses. For > what it's worth, Babel is quite able to establish adjacencies before > addressing is up as well as in pure IPv4 networks. I've received a few questions about this by private mail, so please let me lecture a little. The chairs will let me know if that's too much of an off-topic for this list. Take a traditional single-stack routing protocol for IPv4, say RIPv2 or OSPFv2: 1. your neighbour database is indexed by (interface, IPv4) pairs; 2. your routes' next hops are (interface, IPv4) pairs. This means that you need to wait for an IPv4 address before you can do anything. You can work around that by putting a (site-local) static IPv4 on the loopback interface, but that involves some administrative overhead, and hence is not applicable to Homenet. Compare this with an IPv4 routing protocol that is layered directly above 802.2, say a pure IPv4 implementation of ISIS: 1. your neighbour database is indexed by (interface, MAC) pairs; 2. your routes' next hops are (interface, IPv4) pairs. Since MAC addresses always exist, you can establish neighbour relationships as soon as the interface is up -- no need to wait for global addresses to be assigned. If you're link state, you can start flooding as soon as the adjacency is up, which is pretty cool. However, since next hops are IPv4 addresses, you still cannot route until both you and your neighbour get assigned addresses. Now take the simple same single-stack protocol and port it to IPv6 (RIPng or OSPFv3): 1. your neighbour database is indexed by (interface, link-local IPv6); 2. your routes' next hops are (interface, link-local IPv6) pairs. If link-local IPv6 exist soon enough after the link is up, you get all of the benefits of a stable neighbour identifier -- you establish adjacencies and start flooding as soon as the interface is up and has a link-local IPv6. In addition, since your next hops exist, you can start routing as soon as the interface is up -- a big win if the address distribution protocol is slow or unreliable. Finally, you don't need to do anything special when you renumber, the next hops use stable identifiers. Consider now a double-stack protocol running over IPv6, such as Babel: 1. your neighbour database is indexed by (interface, link-local IPv6); 2. your routes' next hops are (interface, link-local IPv6) or (interface, IPv4) pairs, depending on the address family. Here, for IPv6 you're just like the previous case; for IPv4, you need an address before you can route. The effect is that a Babel router starts routing IPv6 as soon as the interface is up, but needs to delay installing IPv4 routes until both neighbouring interfaces have an IPv4 address. In effect, when the address configuration protocol has a hiccup, IPv6 routing remains stable but IPv4 needs to reconverge. In summary, by running your routing protocol over IPv6, you get the advantages of the ISIS approach, but in addition you gain: (1) the ability to run over GRE tunnels and OpenVPN in "tun" mode; (2) much simpler implementation on Unix -- no need to use raw sockets, just plain RFC 3493. What you don't get is the conceptual elegance of proper layering. -- Juliusz From nobody Sun Jun 1 06:18:30 2014 Return-Path: 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 0413B1A0223 for ; Sun, 1 Jun 2014 06:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 rMOc7DTwyoWH for ; Sun, 1 Jun 2014 06:18:25 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6E21A0213 for ; Sun, 1 Jun 2014 06:18:25 -0700 (PDT) Received: from ([24.40.56.121]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.98928510; Sun, 01 Jun 2014 09:18:16 -0400 Received: from PACDCEXMB18.cable.comcast.com ([fe80::d85d:4248:14e8:f24e]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.03.0181.006; Sun, 1 Jun 2014 09:18:16 -0400 From: "Leddy, John" To: Juliusz Chroboczek , "homenet@ietf.org" Thread-Topic: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] Thread-Index: AQHPfZvyFXkQahW76EK3TolpBhBuGg== Date: Sun, 1 Jun 2014 13:18:17 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <87k391k95r.wl%jch@pps.univ-paris-diderot.fr> <87iookwzgj.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87iookwzgj.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <3AB2868602B090438FA4F1EFDBCF00BC@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/TMEzNdORHvF9Y5gs93XjSLX8qek Subject: Re: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 13:18:27 -0000 Not going to weigh in on what IGP. Following on bellow, it would be good to think about what we are looking for from the IGP. Link state, full topology view, sub-second convergence? Or reachability? And stability. Independent of the choice of IGP, we still have to configure it, or recommend settings. john On 6/1/14, 9:07 AM, "Juliusz Chroboczek" wrote: >> [...] IPv6, where routers communicate using link-local addresses. For >> what it's worth, Babel is quite able to establish adjacencies before >> addressing is up as well as in pure IPv4 networks. > >I've received a few questions about this by private mail, so please let me >lecture a little. The chairs will let me know if that's too much of an >off-topic for this list. > >Take a traditional single-stack routing protocol for IPv4, say RIPv2 or >OSPFv2: > > 1. your neighbour database is indexed by (interface, IPv4) pairs; > 2. your routes' next hops are (interface, IPv4) pairs. > >This means that you need to wait for an IPv4 address before you can do >anything. You can work around that by putting a (site-local) static IPv4 >on the loopback interface, but that involves some administrative overhead, >and hence is not applicable to Homenet. > >Compare this with an IPv4 routing protocol that is layered directly above >802.2, say a pure IPv4 implementation of ISIS: > > 1. your neighbour database is indexed by (interface, MAC) pairs; > 2. your routes' next hops are (interface, IPv4) pairs. > >Since MAC addresses always exist, you can establish neighbour >relationships >as soon as the interface is up -- no need to wait for global addresses to >be assigned. If you're link state, you can start flooding as soon as the >adjacency is up, which is pretty cool. However, since next hops are IPv4 >addresses, you still cannot route until both you and your neighbour get >assigned addresses. > >Now take the simple same single-stack protocol and port it to IPv6 (RIPng >or OSPFv3): > > 1. your neighbour database is indexed by (interface, link-local IPv6); > 2. your routes' next hops are (interface, link-local IPv6) pairs. > >If link-local IPv6 exist soon enough after the link is up, you get all of >the benefits of a stable neighbour identifier -- you establish adjacencies >and start flooding as soon as the interface is up and has a link-local >IPv6. In addition, since your next hops exist, you can start routing as >soon as the interface is up -- a big win if the address distribution >protocol is slow or unreliable. Finally, you don't need to do anything >special when you renumber, the next hops use stable identifiers. > >Consider now a double-stack protocol running over IPv6, such as Babel: > > 1. your neighbour database is indexed by (interface, link-local IPv6); > 2. your routes' next hops are (interface, link-local IPv6) or > (interface, IPv4) pairs, depending on the address family. > >Here, for IPv6 you're just like the previous case; for IPv4, you need an >address before you can route. The effect is that a Babel router starts >routing IPv6 as soon as the interface is up, but needs to delay installing >IPv4 routes until both neighbouring interfaces have an IPv4 address. In >effect, when the address configuration protocol has a hiccup, IPv6 routing >remains stable but IPv4 needs to reconverge. > >In summary, by running your routing protocol over IPv6, you get the >advantages of the ISIS approach, but in addition you gain: > > (1) the ability to run over GRE tunnels and OpenVPN in "tun" mode; > (2) much simpler implementation on Unix -- no need to use raw sockets, > just plain RFC 3493. > >What you don't get is the conceptual elegance of proper layering. > >-- Juliusz > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From nobody Mon Jun 2 02:59:52 2014 Return-Path: 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 1FB421A01C5 for ; Mon, 2 Jun 2014 02:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 LXzJX7mJQN-L for ; Mon, 2 Jun 2014 02:59:49 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominetcyberassist.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2F24F1A02F1 for ; Mon, 2 Jun 2014 02:59:47 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=F9XOAip6vzjsa1TGr5ZZIq39ivyYen1qEellbP8sChqK1EgbQzlbuG1l mHVOCxNAv0XWOQSy0IKOk9BaQvxhicZeNXqz0SnmPi7Q6/5KFQABmaXwE yLZo70q/3KGURnYwJadixQ9qPZxNlZgKBYxyGCAHoTY0KP92MY5WBWuoi 6eLtDLsteCQwnQIG72AeZtkWd4iB7x9lWklt3ykTcgL6mmdb8psX3MnZf WotM0QEBr3Geic+XICqbj8HrCfFJv; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1401703184; x=1433239184; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wz27oSbD9RgZR5Zxh1dUx/EcQz9tLcXTwifK4bFcMmk=; b=P+WXOvVH+8SC4JnZiPoGAS7l79Z2WbGr3yRPbpkYixa9WadDWjScXYVZ vVPxhO+O+GQkk1JSn3JdKqAMvY9+Z4oJ7e5t5eKe+XTOxY6GVLznhXVz+ zRFrHIobHotN8t+5wLJba8cTOLZqOZfsaD4q8SBmW6fx+wWQDoY31SAWZ iRtUUmBQC8PYGstQqDslHAg6kerJ41GSrQkRRmCu7nxWLMxGb8UhHMN7S yxosorCJqouXGlt7KYZLzsgiEwRWf; X-IronPort-AV: E=Sophos;i="4.98,955,1392163200"; d="scan'208";a="10371812" X-IPAS-Result: AsQOAP1JjFPV+MWQ/2dsb2JhbABYgmUigSqNB6BujGiHdgGBEhZ0giUBAQQBOhkmBQsCAQgOKBAyJQIEDgWIOgkD1CgXjh8zB4MrgRUErS2DOIIv Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx1.nominet.org.uk with ESMTP; 02 Jun 2014 10:59:41 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 10:59:41 +0100 From: Ray Bellis To: Juliusz Chroboczek Thread-Topic: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] Thread-Index: AQHPfZp3kN8sdLgiDU2rfBSRos/La5tdhsOA Date: Mon, 2 Jun 2014 09:59:40 +0000 Message-ID: <5B89F15D-EF9D-4F5E-AF94-A3329186B001@nominet.org.uk> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <87k391k95r.wl%jch@pps.univ-paris-diderot.fr> <87iookwzgj.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87iookwzgj.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DDC5B6B43A6FF44974CC75CE3B7C46C@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Vyfqn3V9h7kl1AtvtwPKgOUZAgU Cc: "homenet@ietf.org" Subject: Re: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 09:59:51 -0000 On 1 Jun 2014, at 14:07, Juliusz Chroboczek = wrote: > The chairs will let me know if that's too much of an off-topic for this l= ist. Not at all, IMHO that was a very useful explanation. Ray From nobody Mon Jun 2 11:44:35 2014 Return-Path: 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 065E11A03A2 for ; Mon, 2 Jun 2014 11:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] autolearn=no 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 2EiXf5mRglCc for ; Mon, 2 Jun 2014 11:44:31 -0700 (PDT) Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id 345001A0348 for ; Mon, 2 Jun 2014 11:44:31 -0700 (PDT) Received: from [192.168.178.64] (55d441ad.access.ecotel.net [85.212.65.173]) by chi.subsignal.org (Postfix) with ESMTPSA id 563631BE04D for ; Mon, 2 Jun 2014 20:45:47 +0200 (CEST) Message-ID: <538CC608.1010109@openwrt.org> Date: Mon, 02 Jun 2014 20:44:24 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: homenet@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lWDFv9ny7O20cwX-ml3xFWjamrs Subject: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 18:44:33 -0000 Hello everyone, I prepared the first few changes for the upcoming HNCP draft version 01. Most of this is derived from features we already added to our reference implementation. 1. Backwards-compatibility with RFC 7084 routers. Diff: https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a1ea8f908975d 2. HNCP-routers should make interface categories (auto, internal, external) configurable and MAY offer additional categories (guest, ad-hoc). Diff: https://github.com/fingon/ietf-drafts/commit/47fdf57a1759fad6e8c6c29d741e95039aca671e 3. Some house-keeping (updating references, fixing idnits warnings) Diff: https://github.com/fingon/ietf-drafts/commit/a2e2aa1f43e91e808af56f31e5ad514568fc8a6a Feedback is welcome. Regards, Steven From nobody Mon Jun 2 12:12:01 2014 Return-Path: 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 7E0401A03F4 for ; Mon, 2 Jun 2014 12:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Mh6EkJxwHwja for ; Mon, 2 Jun 2014 12:11:53 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE2D1A0223 for ; Mon, 2 Jun 2014 12:11:52 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so5287748wib.6 for ; Mon, 02 Jun 2014 12:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XAMQ6SSttAVRgh1gs6dHfEOgVSsLP9YacK8kQwLTv60=; b=uhagKaUigNWc40d0o/6fqaSvcpgUa29pBFbu1pTSvTjpt1RRovoYRFwRlrBnXvzE5O twf0ScWqT3XpKVU/WrBrxCYmmA4TkBmSRHrPTIN7pIk97RzFL2lKAI/lFOA4PRx3lLUz X+aJvpCCjquvqF2EDizGnbeWKbTUDdD5nD/d/D3gvCrwwdUyknow636iWxkgV8njObX0 sdLfGOsjYhw8RNFzzjh6YaVFgimCr6I0Y+8LkrT65nRjZtfKvTGSfRo0XeH+lNxafJnI x2Hg1+G2DVTYRirSIMfLu8HP3bG6doTNx2G9Dllr/L4vAHPm6FUylS+vQDvwvF7AtY9x oHvw== MIME-Version: 1.0 X-Received: by 10.194.22.100 with SMTP id c4mr7751860wjf.89.1401736306618; Mon, 02 Jun 2014 12:11:46 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Mon, 2 Jun 2014 12:11:46 -0700 (PDT) In-Reply-To: <538CC608.1010109@openwrt.org> References: <538CC608.1010109@openwrt.org> Date: Mon, 2 Jun 2014 12:11:46 -0700 Message-ID: From: Dave Taht To: Steven Barth Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Yf5enpekYNfzyEvg6rS32EpfqpE Cc: HOMENET Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:11:59 -0000 On Mon, Jun 2, 2014 at 11:44 AM, Steven Barth wrote: > Hello everyone, > > I prepared the first few changes for the upcoming HNCP draft version 01. > Most of this is derived from features we already added to our reference > implementation. I confess to being more interested in a status update on the implementation= . ? > > 1. Backwards-compatibility with RFC 7084 routers. > > Diff: > https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a= 1ea8f908975d > > > 2. HNCP-routers should make interface categories (auto, internal, externa= l) > configurable and MAY offer additional categories (guest, ad-hoc). > > Diff: > https://github.com/fingon/ietf-drafts/commit/47fdf57a1759fad6e8c6c29d741e= 95039aca671e > > > 3. Some house-keeping (updating references, fixing idnits warnings) > > Diff: > https://github.com/fingon/ietf-drafts/commit/a2e2aa1f43e91e808af56f31e5ad= 514568fc8a6a > > > > Feedback is welcome. > > > Regards, > > Steven > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Mon Jun 2 12:36:25 2014 Return-Path: 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 C0D261A0275 for ; Mon, 2 Jun 2014 12:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 bNGFKWb0GZCA for ; Mon, 2 Jun 2014 12:36:22 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id AD5F11A0024 for ; Mon, 2 Jun 2014 12:36:21 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D2ABA03B21BCC; Mon, 2 Jun 2014 22:36:07 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: Date: Mon, 2 Jun 2014 22:36:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <60785B69-16FB-45B1-97D7-1472E16D1FDE@iki.fi> References: <538CC608.1010109@openwrt.org> To: Dave Taht X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/-2gyOCGlBmo1kJNpz0n8ly8YjXI Cc: Steven Barth , Markus Stenberg , HOMENET Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:36:23 -0000 On 2.6.2014, at 22.11, Dave Taht wrote: > On Mon, Jun 2, 2014 at 11:44 AM, Steven Barth = wrote: >> I prepared the first few changes for the upcoming HNCP draft version = 01. >> Most of this is derived from features we already added to our = reference >> implementation. > I confess to being more interested in a status update on the = implementation. ? I guess we=92ll present on the topic in Toronto along the draft = update(s), but highlights since London so far: - arbitrary prefix length handling in prefix assignment - ad-hoc/guest mode for interfaces (as specified by Steven=92s diff to = the -00 draft) - support for giving PDs to downstream non-HNCP routers=20 - implemented (and also somewhat tested) 6rd, dslite, map, lw4o6 = transition mechanisms - SA-aware PCP proxy/server (v4 NAT + v6 FW pinholes) on top of = miniupnpd + new proxy and of course - a lot of bugfixes / performance optimizations (notably, Pierre=92s PA = code has btries and much better alg both in terms of pseudorandom = allocation, as well as handling the =91fragmentation=92 of prefix space = with different sized allocations) We=92re working on: - improving configuration/management (more knobs that you can turn if = you feel like, and similarly better view of what=92s going on; some of = this is already done, but more work is pending) - security And at some point it would be nice to have also: - multicast (sitelocal) - UPnP (IGD perhaps via proxy, rest via multicast and/or proxy) However, this brings to my mind a thing I=92ve been meaning to ask the = list for a while now. What is the take on hncp-00 draft format? Should the strictly optional = things (such as SD TLVs) be moved elsewhere? If so, how about the somewhat more required parts such as PA or border = discovery? Cheers, -Markus= From nobody Mon Jun 2 13:05:52 2014 Return-Path: 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 E5A7D1A040A for ; Mon, 2 Jun 2014 13:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 O41jk1fQXVMU for ; Mon, 2 Jun 2014 13:05:47 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3021A0445 for ; Mon, 2 Jun 2014 13:05:46 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id q58so5712981wes.39 for ; Mon, 02 Jun 2014 13:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pXN48XCJfBdRF0GaDCD+j+erBzTYVNsT8+8avDvuEJs=; b=lKH6htwKsHak5FxsoMLCqV9ez+wkBFqcZnuVsufIRv853TSxf4klMU/mb8u2oBneO3 HhVbFhopueu+kvdRvy66p9dj9YD7z8qS3GzZZrRFdM7vEcRL6jJqGdH1Ni2bJ6Gnps1v 8jbeiVT0i1XZ5103O+aavS9h3wzLDxE6+lZUC0CHIdBgHzARh7JqS+C2QCTrEC5JQ9EI 2JEWGzytH18HRfuEfe4+qkoHJp6Sf717Zaz3f5Gd4K+vqtmagr2bV2KVQZDwuS6/81HW 9vl25aTT1gjkESm45PngLV/epwP86YH+JBLj0XuBJPkN/EVzOdYH5scV6OqYcCQOALLj QtiQ== MIME-Version: 1.0 X-Received: by 10.180.19.201 with SMTP id h9mr25655001wie.17.1401739540259; Mon, 02 Jun 2014 13:05:40 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Mon, 2 Jun 2014 13:05:40 -0700 (PDT) In-Reply-To: <60785B69-16FB-45B1-97D7-1472E16D1FDE@iki.fi> References: <538CC608.1010109@openwrt.org> <60785B69-16FB-45B1-97D7-1472E16D1FDE@iki.fi> Date: Mon, 2 Jun 2014 13:05:40 -0700 Message-ID: From: Dave Taht To: Markus Stenberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/C7NpslOpUw0NwJVdB0uav0YBSwk Cc: Steven Barth , HOMENET Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:05:49 -0000 On Mon, Jun 2, 2014 at 12:36 PM, Markus Stenberg w= rote: > On 2.6.2014, at 22.11, Dave Taht wrote: >> On Mon, Jun 2, 2014 at 11:44 AM, Steven Barth wrote: >>> I prepared the first few changes for the upcoming HNCP draft version 01= . >>> Most of this is derived from features we already added to our reference >>> implementation. >> I confess to being more interested in a status update on the implementat= ion. ? > > I guess we=E2=80=99ll present on the topic in Toronto along the draft upd= ate(s), but highlights since London so far: > > - arbitrary prefix length handling in prefix assignment selfishly I'm interested right now in hauling a few prefixes an my edge gateway 6 hops to my lab. Stable enough to try that? The documentation was rather lacking the last time I pulled the git tree so it was kind of a mystery to configure in that case... (for those that aren't tracking the work, the git tree can be had via a git clone git@github.com:sbyx/hnetd.git ) /me pulls git tree Wow, ton of updates! cool! > - ad-hoc/guest mode for interfaces (as specified by Steven=E2=80=99s diff= to the -00 draft) > > - support for giving PDs to downstream non-HNCP routers > > - implemented (and also somewhat tested) 6rd, dslite, map, lw4o6 transiti= on mechanisms > > - SA-aware PCP proxy/server (v4 NAT + v6 FW pinholes) on top of miniupnpd= + new proxy Saw the ipv6 pcp stuff land the other day. Cool. I guess. > > and of course > > - a lot of bugfixes / performance optimizations (notably, Pierre=E2=80=99= s PA code has btries and much better alg both in terms of pseudorandom allo= cation, as well as handling the =E2=80=98fragmentation=E2=80=99 of prefix s= pace with different sized allocations) In my case I only have a couple comcast /60s (multiple gateways), and 50 interfaces to configure, so it's a bit much for a home scenario, but a good test of how to break the code... at the moment, though, I'd settle for getting one /61 to the lab somehow. > > We=E2=80=99re working on: > > - improving configuration/management (more knobs that you can turn if yo= u feel like, and similarly better view of what=E2=80=99s going on; some of = this is already done, but more work is pending) > > - security > > And at some point it would be nice to have also: > > - multicast (sitelocal) > > - UPnP (IGD perhaps via proxy, rest via multicast and/or proxy) > > However, this brings to my mind a thing I=E2=80=99ve been meaning to ask = the list for a while now. > > What is the take on hncp-00 draft format? Should the strictly optional th= ings (such as SD TLVs) be moved elsewhere? > If so, how about the somewhat more required parts such as PA or border di= scovery? > > Cheers, > > -Markus --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Mon Jun 2 13:20:26 2014 Return-Path: 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 A2E3F1A043F for ; Mon, 2 Jun 2014 13:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RP_MATCHES_RCVD=-0.651] 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 yEUvQCLIFya7 for ; Mon, 2 Jun 2014 13:20:21 -0700 (PDT) Received: from ks395963.kimsufi.com (darou.fr [176.31.121.140]) by ietfa.amsl.com (Postfix) with ESMTP id 731C21A0439 for ; Mon, 2 Jun 2014 13:20:21 -0700 (PDT) Received: from [192.168.0.18] (abo-206-58-68.mts.modulonet.fr [85.68.58.206]) (Authenticated sender: pierre@darou.fr) by ks395963.kimsufi.com (Postfix) with ESMTPSA id 6125660024; Mon, 2 Jun 2014 22:20:15 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Pierre Pfister In-Reply-To: Date: Mon, 2 Jun 2014 22:20:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D5ABE6B-445F-40BD-ADDC-5A592801EDC7@darou.fr> References: <538CC608.1010109@openwrt.org> <60785B69-16FB-45B1-97D7-1472E16D1FDE@iki.fi> To: Dave Taht X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CXVEPMgrWjM4lwb3iWxEGTE_WEY Cc: Steven Barth , Markus Stenberg , HOMENET Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:20:24 -0000 Hi Dave, You=92ll find some more documentation here: http://www.homewrt.org/doku.php If explanation is missing, please tell. I=92ll complete the doc. The current version is working (quite stable for basic features, more = buggy for newer ones),=20 but we are actively debugging and now looking for feedback/testers ! It would be very helpful if you could install it on your devices and = provide us some feedback. Of course, if you have any question, we=92ll be there to help/debug. Cheers, Pierre Le 2 juin 2014 =E0 22:05, Dave Taht a =E9crit : > On Mon, Jun 2, 2014 at 12:36 PM, Markus Stenberg = wrote: >> On 2.6.2014, at 22.11, Dave Taht wrote: >>> On Mon, Jun 2, 2014 at 11:44 AM, Steven Barth = wrote: >>>> I prepared the first few changes for the upcoming HNCP draft = version 01. >>>> Most of this is derived from features we already added to our = reference >>>> implementation. >>> I confess to being more interested in a status update on the = implementation. ? >>=20 >> I guess we=92ll present on the topic in Toronto along the draft = update(s), but highlights since London so far: >>=20 >> - arbitrary prefix length handling in prefix assignment >=20 > selfishly I'm interested right now in hauling a few prefixes an my > edge gateway 6 hops to my > lab. Stable enough to try that? The documentation was rather lacking > the last time I pulled the git > tree so it was kind of a mystery to configure in that case... >=20 > (for those that aren't tracking the work, the git tree can be had via = a >=20 > git clone git@github.com:sbyx/hnetd.git >=20 > ) >=20 > /me pulls git tree >=20 > Wow, ton of updates! cool! >=20 >> - ad-hoc/guest mode for interfaces (as specified by Steven=92s diff = to the -00 draft) >>=20 >> - support for giving PDs to downstream non-HNCP routers >>=20 >> - implemented (and also somewhat tested) 6rd, dslite, map, lw4o6 = transition mechanisms >>=20 >> - SA-aware PCP proxy/server (v4 NAT + v6 FW pinholes) on top of = miniupnpd + new proxy >=20 > Saw the ipv6 pcp stuff land the other day. Cool. I guess. >=20 >>=20 >> and of course >>=20 >> - a lot of bugfixes / performance optimizations (notably, Pierre=92s = PA code has btries and much better alg both in terms of pseudorandom = allocation, as well as handling the =91fragmentation=92 of prefix space = with different sized allocations) >=20 > In my case I only have a couple comcast /60s (multiple gateways), and > 50 interfaces to configure, > so it's a bit much for a home scenario, but a good test of how to > break the code... >=20 > at the moment, though, I'd settle for getting one /61 to the lab = somehow. >=20 >=20 >>=20 >> We=92re working on: >>=20 >> - improving configuration/management (more knobs that you can turn = if you feel like, and similarly better view of what=92s going on; some = of this is already done, but more work is pending) >>=20 >> - security >>=20 >> And at some point it would be nice to have also: >>=20 >> - multicast (sitelocal) >>=20 >> - UPnP (IGD perhaps via proxy, rest via multicast and/or proxy) >>=20 >> However, this brings to my mind a thing I=92ve been meaning to ask = the list for a while now. >>=20 >> What is the take on hncp-00 draft format? Should the strictly = optional things (such as SD TLVs) be moved elsewhere? >> If so, how about the somewhat more required parts such as PA or = border discovery? >>=20 >> Cheers, >>=20 >> -Markus >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > NSFW: = https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indec= ent.article >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Mon Jun 2 15:08:26 2014 Return-Path: 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 8F9C81A03A0 for ; Mon, 2 Jun 2014 15:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Wp_QsMvrmvA5 for ; Mon, 2 Jun 2014 15:08:21 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEDA1A040C for ; Mon, 2 Jun 2014 15:08:21 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-f4-538ca2fe3a4c Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E3.DB.11744.EF2AC835; Mon, 2 Jun 2014 18:14:54 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 18:08:08 -0400 From: Acee Lindem To: Juliusz Chroboczek , "homenet@ietf.org" Thread-Topic: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] Thread-Index: AQHPfq8ij0TZfIf29EyBaDwLVqsFwQ== Date: Mon, 2 Jun 2014 22:08:08 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> <20140531124239.GS46558@Space.Net> <87k391k95r.wl%jch@pps.univ-paris-diderot.fr> <87iookwzgj.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87iookwzgj.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <50641D4295102A46BBA4CA5A813979A1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPgu6/RT3BBn1HRS3eLzrEYvH50z9W ByaPJUt+Mnlc3P2OMYApissmJTUnsyy1SN8ugSvj4YNd7AUn5SpuvzrP2sD4SKKLkZNDQsBE 4tCzDywQtpjEhXvr2boYuTiEBI4ySlx+0Q7lLGOUWLG+kw2kik1AR+L5o3/MILaIQLzEh08H gOIcHMICkRK/O3kgwlESp97vYIGw9SQ+fZ3NBGKzCKhI9G5pAGvlFTCVmP9gLQvE/ElMEk++ TmMHSXAKWElcuNoEtosR6KLvp9aANTMLiEvcejKfCeJSAYkle84zQ9iiEi8f/2MFsUWBlr07 DlOjJPHx93x2iF4diQW7P7FB2NYSs2Z8g5qpLbFs4WuogwQlTs58wjKBUXwWknWzkLTPQtI+ C0n7LCTtCxhZVzFylBanluWmGxluYgTG1TEJNscdjAs+WR5iFOBgVOLhTWjuCRZiTSwrrsw9 xCjNwaIkzrvnWlWwkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsY157tSE3YvTaq/lf65Icg6 rWFt4yFVG5+6vVN6v07oMQotPBd1rfOZsNWbKdKM/Pk6C/O/vrFY+SL+lOXT7/HzmhWiZwrk t8uesY+T4TvcsXbiVZkND1nXx355FFw0u8nIwPvg5SK3AOunrxMfFOwX3fcv8TXPtly3UjW5 pUKnX3cc4edRa1RiKc5INNRiLipOBABvesQljAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/G0VSkrWNbRHU5YkM1z2icWY_OeU Subject: Re: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 22:08:23 -0000 Note that OSPFv3 can also support advertisement of IPv4 prefixes - see RFC 5838.=20 Thanks, Acee=20 -----Original Message----- From: Juliusz Chroboczek Date: Sunday, June 1, 2014 6:07 AM To: "homenet@ietf.org" Subject: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] >> [...] IPv6, where routers communicate using link-local addresses. For >> what it's worth, Babel is quite able to establish adjacencies before >> addressing is up as well as in pure IPv4 networks. > >I've received a few questions about this by private mail, so please let me >lecture a little. The chairs will let me know if that's too much of an >off-topic for this list. > >Take a traditional single-stack routing protocol for IPv4, say RIPv2 or >OSPFv2: > > 1. your neighbour database is indexed by (interface, IPv4) pairs; > 2. your routes' next hops are (interface, IPv4) pairs. > >This means that you need to wait for an IPv4 address before you can do >anything. You can work around that by putting a (site-local) static IPv4 >on the loopback interface, but that involves some administrative overhead, >and hence is not applicable to Homenet. > >Compare this with an IPv4 routing protocol that is layered directly above >802.2, say a pure IPv4 implementation of ISIS: > > 1. your neighbour database is indexed by (interface, MAC) pairs; > 2. your routes' next hops are (interface, IPv4) pairs. > >Since MAC addresses always exist, you can establish neighbour >relationships >as soon as the interface is up -- no need to wait for global addresses to >be assigned. If you're link state, you can start flooding as soon as the >adjacency is up, which is pretty cool. However, since next hops are IPv4 >addresses, you still cannot route until both you and your neighbour get >assigned addresses. > >Now take the simple same single-stack protocol and port it to IPv6 (RIPng >or OSPFv3): > > 1. your neighbour database is indexed by (interface, link-local IPv6); > 2. your routes' next hops are (interface, link-local IPv6) pairs. > >If link-local IPv6 exist soon enough after the link is up, you get all of >the benefits of a stable neighbour identifier -- you establish adjacencies >and start flooding as soon as the interface is up and has a link-local >IPv6. In addition, since your next hops exist, you can start routing as >soon as the interface is up -- a big win if the address distribution >protocol is slow or unreliable. Finally, you don't need to do anything >special when you renumber, the next hops use stable identifiers. > >Consider now a double-stack protocol running over IPv6, such as Babel: > > 1. your neighbour database is indexed by (interface, link-local IPv6); > 2. your routes' next hops are (interface, link-local IPv6) or > (interface, IPv4) pairs, depending on the address family. > >Here, for IPv6 you're just like the previous case; for IPv4, you need an >address before you can route. The effect is that a Babel router starts >routing IPv6 as soon as the interface is up, but needs to delay installing >IPv4 routes until both neighbouring interfaces have an IPv4 address. In >effect, when the address configuration protocol has a hiccup, IPv6 routing >remains stable but IPv4 needs to reconverge. > >In summary, by running your routing protocol over IPv6, you get the >advantages of the ISIS approach, but in addition you gain: > > (1) the ability to run over GRE tunnels and OpenVPN in "tun" mode; > (2) much simpler implementation on Unix -- no need to use raw sockets, > just plain RFC 3493. > >What you don't get is the conceptual elegance of proper layering. > >-- Juliusz > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From nobody Mon Jun 2 17:10:29 2014 Return-Path: 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 ED0741A03CD for ; Mon, 2 Jun 2014 17:10:25 -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 Ja2A_9EWJS0k for ; Mon, 2 Jun 2014 17:10:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD561A03D4 for ; Mon, 2 Jun 2014 17:10:23 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B6C920028; Mon, 2 Jun 2014 20:13:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A829563B0E; Mon, 2 Jun 2014 20:10:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8D71F63AED; Mon, 2 Jun 2014 20:10:16 -0400 (EDT) From: Michael Richardson To: Markus Stenberg In-Reply-To: <60785B69-16FB-45B1-97D7-1472E16D1FDE@iki.fi> References: <538CC608.1010109@openwrt.org> <60785B69-16FB-45B1-97D7-1472E16D1FDE@iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VmFESZx3AS3YPZKSjN3R056SXlI Cc: Steven Barth , HOMENET , Dave Taht Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 00:10:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Markus Stenberg wrote: ` > - implemented (and also somewhat tested) 6rd, dslite, map, lw4o6 > transition mechanisms I assume that this is all WAN/uplink interface things. (vs ways to get IPv6 through IPv4 only internal routers...) > And at some point it would be nice to have also: > - multicast (sitelocal) > - UPnP (IGD perhaps via proxy, rest via multicast and/or proxy) > However, this brings to my mind a thing I=E2=80=99ve been meaning to = ask the > list for a while now. > What is the take on hncp-00 draft format? Should the strictly optional Are you asking specifically about the TLV format, rather than contents/semantics? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU40SZoCLcPvd0N1lAQI4Cgf/TumU8cCjk+JAer6xQzQD9LSdQ+Er4gAn Fzlia0j6VLRV1SkBkktV+0EO66kJfpIGG3oqtDEbWpz3BkyJ2+sCRoRB8sD5VzXG 75ZLQ3v6VqDxZWy+IM31HhG36kEDUXWx+OaTXg/MhxkGIg8SEnOA0MP4em26/Gfu L6bLhDbRS+Eqo+ShoYml6qV0PbZFmrt++y60mJHw7ohyCkJi+mGUTsSEgJT/Y5NP xG8QDz3spyd78hWRHJ4oyVXdFzRBxLGvr2i5NG9xDR+U/O3Iarm2h+Wg92nmdHBr w7bRzdmCa/8qiXA4jnE/ndQlYEus5gXwrIlzEG0KkXXTT5MdhSgtKQ== =ihGQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 2 20:58:44 2014 Return-Path: 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 03CE11A007F for ; Mon, 2 Jun 2014 20:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 axADSzHNCpBX for ; Mon, 2 Jun 2014 20:58:41 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7B1A007E for ; Mon, 2 Jun 2014 20:58:40 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D2ABA03B63246; Tue, 3 Jun 2014 06:58:17 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <2823.1401754216@sandelman.ca> Date: Tue, 3 Jun 2014 06:58:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <536AB4F0-0E7C-4607-A330-6332D8D29B44@iki.fi> References: <538CC608.1010109@openwrt.org> <60785B69-16FB-45B1-97D7-1472E16D1FDE@iki.fi> <2823.1401754216@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/9UgOul9-iYLLBD9QpHNye3feHdk Cc: Steven Barth , Markus Stenberg , HOMENET , Dave Taht Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 03:58:43 -0000 On 3.6.2014, at 3.10, Michael Richardson wrote: > Markus Stenberg wrote: > ` > - implemented (and also somewhat tested) 6rd, dslite, map, lw4o6 >> transition mechanisms > I assume that this is all WAN/uplink interface things. > (vs ways to get IPv6 through IPv4 only internal routers=85) Yes.. Internal connectivity is assumed to be dual stack, IPv4 NAT-less = (among HNCP-enabled routers; obviously the prefix itself is RFC1918 and = NATted for upstream access) and legacy RFC7084 inner routers will have = nested IPv4 NAT and get IPv6 PD. from HNCP-enabled routers We also test IPv6-only case to be thorough in our automated system test = suite, but practically I think that=92s some time off; in Finland, = there=92s only one ISP who even offers residential users IPv6 ;-) >> And at some point it would be nice to have also: >> - multicast (sitelocal) >> - UPnP (IGD perhaps via proxy, rest via multicast and/or proxy) >=20 >> However, this brings to my mind a thing I=92ve been meaning to ask = the >> list for a while now. >=20 >> What is the take on hncp-00 draft format? Should the strictly = optional >=20 > Are you asking specifically about the TLV format, rather than > contents/semantics? Well, bit of both; how limited should the draft be in scope? As it is, = it contains quite a lot of stuff and odds are not many will actually = implement all of those extra bits in any case. The original reasoning = was mostly to keep # of drafts low, but (based on feedback) at expense = of some lack of coherence. Cheers, -Markus= From nobody Tue Jun 3 00:06:10 2014 Return-Path: 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 20D231A0117 for ; Tue, 3 Jun 2014 00:06:08 -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 2nytinIOYyWk for ; Tue, 3 Jun 2014 00:06:06 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id F267F1A011F for ; Tue, 3 Jun 2014 00:06:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B9E39870072; Tue, 3 Jun 2014 09:05:57 +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 jslL-rcCKCUt; Tue, 3 Jun 2014 09:05:57 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:853e:3875:6de1:7c47]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 8920887006F; Tue, 3 Jun 2014 09:05:57 +0200 (CEST) Message-ID: <538D73C7.1090700@globis.net> Date: Tue, 03 Jun 2014 09:05:43 +0200 From: Ray Hunter User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: Steven Barth References: <538CC608.1010109@openwrt.org> In-Reply-To: <538CC608.1010109@openwrt.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lO8mlTNXH2SzRURzaK0rzul01-M Cc: homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:06:08 -0000 Steven Barth wrote: > Hello everyone, > > I prepared the first few changes for the upcoming HNCP draft version > 01. Most of this is derived from features we already added to our > reference implementation. > > > 1. Backwards-compatibility with RFC 7084 routers. > > Diff: > https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a1ea8f908975d > > Looks like a can of worms to me. How do you intend to do this? Are there Homenet topology limitations? How will the user know not to plug the LAN interface of a 7084 router into a WAN interface? 7084 (6204bis) was intended to be a dead end once Homenet completed AFAICS. > > 2. HNCP-routers should make interface categories (auto, internal, > external) configurable and MAY offer additional categories (guest, > ad-hoc). > > Diff: > https://github.com/fingon/ietf-drafts/commit/47fdf57a1759fad6e8c6c29d741e95039aca671e > Agreed. Sensible. > > > 3. Some house-keeping (updating references, fixing idnits warnings) > > Diff: > https://github.com/fingon/ietf-drafts/commit/a2e2aa1f43e91e808af56f31e5ad514568fc8a6a > > > Agreed. > > Feedback is welcome. > > > Regards, > > Steven > > -- Regards, RayH From nobody Tue Jun 3 00:15:32 2014 Return-Path: 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 E182D1A00FB for ; Tue, 3 Jun 2014 00:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] autolearn=no 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 5gE22oFXG16s for ; Tue, 3 Jun 2014 00:15:27 -0700 (PDT) Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id 092091A003A for ; Tue, 3 Jun 2014 00:15:27 -0700 (PDT) Received: from [192.168.178.64] (55d45e0c.access.ecotel.net [85.212.94.12]) by chi.subsignal.org (Postfix) with ESMTPSA id 913901BE056; Tue, 3 Jun 2014 09:16:43 +0200 (CEST) Message-ID: <538D7607.6030608@openwrt.org> Date: Tue, 03 Jun 2014 09:15:19 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ray Hunter References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> In-Reply-To: <538D73C7.1090700@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/mEYT3jKhD7NLluQgCGs1Fn4jVj8 Cc: homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:15:30 -0000 > Steven Barth wrote: >> >> 1. Backwards-compatibility with RFC 7084 routers. >> >> Diff: >> https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a1ea8f908975d >> >> > Looks like a can of worms to me. > > How do you intend to do this? > > Are there Homenet topology limitations? > > How will the user know not to plug the LAN interface of a 7084 router > into a WAN interface? > > 7084 (6204bis) was intended to be a dead end once Homenet completed > AFAICS. Well maybe it was worded a bit ambiguously. The main idea behind this was that an HNCP router should provide "basic connectivity" in the form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do anything fancy and just work as legacy devices believing the homenet is their ISP. This should not mean you should be able to "tunnel" through 7084 routers or so. Does that sound sane? And maybe what would be a better wording for this idea? From nobody Tue Jun 3 00:41:25 2014 Return-Path: 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 26B281A0043 for ; Tue, 3 Jun 2014 00:41:23 -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 hTNfjENpjB7K for ; Tue, 3 Jun 2014 00:41:21 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0E1A0117 for ; Tue, 3 Jun 2014 00:41:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1B24C870072; Tue, 3 Jun 2014 09:41:09 +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 jPDiZkc7zCBI; Tue, 3 Jun 2014 09:41:09 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:853e:3875:6de1:7c47]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id DBD23870047; Tue, 3 Jun 2014 09:41:08 +0200 (CEST) Message-ID: <538D7C07.4060203@globis.net> Date: Tue, 03 Jun 2014 09:40:55 +0200 From: Ray Hunter User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: Steven Barth References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> In-Reply-To: <538D7607.6030608@openwrt.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/v1EhFSQb9vIaQtNa9OMQjuR0ky0 Cc: homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:41:23 -0000 > Steven Barth > 3 June 2014 09:15 > > Well maybe it was worded a bit ambiguously. The main idea behind this > was that an HNCP router should provide "basic connectivity" in the > form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should > not do anything fancy and just work as legacy devices believing the > homenet is their ISP. > > This should not mean you should be able to "tunnel" through 7084 > routers or so. > > Does that sound sane? And maybe what would be a better wording for > this idea? It is a sane idea, and I applaud any manufacturer that can prevent that a lot of 7084 routers are destined for the landfill sooner than they should be. But it's still a can of worms and you should think very carefully whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most. e.g. What about the topology: Homenet router ----- Homenet Router | | | | L2 switch e.g. Powerline Ethernet | | 7084 router Which Homenet router acts as the Service Provider Router of 7084? That's even before considering the question, what do you do when the 7084 router is inserted between two Homenet routers? In fairness I should declare that I was extremely skeptical about publishing 7084, and whether it would be harmful for Homenet. -- Regards, RayH From nobody Tue Jun 3 00:54:22 2014 Return-Path: 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 669151A015A for ; Tue, 3 Jun 2014 00:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] autolearn=no 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 aSYgko92xZjr for ; Tue, 3 Jun 2014 00:54:19 -0700 (PDT) Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id 592131A0159 for ; Tue, 3 Jun 2014 00:54:19 -0700 (PDT) Received: from [192.168.178.64] (55d45e0c.access.ecotel.net [85.212.94.12]) by chi.subsignal.org (Postfix) with ESMTPSA id 4B79E1262DA; Tue, 3 Jun 2014 09:55:36 +0200 (CEST) Message-ID: <538D7F23.1010800@openwrt.org> Date: Tue, 03 Jun 2014 09:54:11 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ray Hunter References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> <538D7C07.4060203@globis.net> In-Reply-To: <538D7C07.4060203@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_8OKR_5ENUxq0Tb_13wcp0tDkUI Cc: homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:54:20 -0000 Am 03.06.2014 09:40, schrieb Ray Hunter: >> Steven Barth >> 3 June 2014 09:15 >> >> Well maybe it was worded a bit ambiguously. The main idea behind this >> was that an HNCP router should provide "basic connectivity" in the >> form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should >> not do anything fancy and just work as legacy devices believing the >> homenet is their ISP. >> >> This should not mean you should be able to "tunnel" through 7084 >> routers or so. >> >> Does that sound sane? And maybe what would be a better wording for >> this idea? > > It is a sane idea, and I applaud any manufacturer that can prevent > that a lot of 7084 routers are destined for the landfill sooner than > they should be. I guess this would not only apply to 7084 routers but "current IPv6-capable homerouters" in general in the end. > > But it's still a can of worms and you should think very carefully > whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most. I guess I'm fine with that. > > e.g. What about the topology: > > Homenet router ----- Homenet Router > | | > | | > L2 switch e.g. Powerline Ethernet > | > | > 7084 router > > Which Homenet router acts as the Service Provider Router of 7084? The behavior is essentially the same as with clients right now. One homenet router per link is elected as DHCP / DHCPv6-server. The only addition here is that this elected router now acts as PD-server as well. > > That's even before considering the question, what do you do when the > 7084 router is inserted between two Homenet routers? This should be same as the current situation: If you are lucky that 7084 router gives you PD then you have essentially two separate homenets, if not that homenet router behind the legacy one gets no (IPv6)-connectivity and probably nasty IPv4 double-NATs. There is not much you can do though except teach that router to speak homenet. > > > In fairness I should declare that I was extremely skeptical about > publishing 7084, and whether it would be harmful for Homenet. > Well I guess it doesn't really do much in favor of homenet by proclaiming: there is only the ISP on one side and clients on the other side you need to care about. Well at least it defines some sane requirements (and some less sane ones) regarding these 2 issues. From nobody Tue Jun 3 00:55:27 2014 Return-Path: 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 F37461A0169 for ; Tue, 3 Jun 2014 00:55:25 -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 d0oHeIkMVm4R for ; Tue, 3 Jun 2014 00:55:24 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7AD1A0159 for ; Tue, 3 Jun 2014 00:55:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id F3381870072; Tue, 3 Jun 2014 09:55:17 +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 0fT6jAdFY3TG; Tue, 3 Jun 2014 09:55:17 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:853e:3875:6de1:7c47]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id A6A63870047; Tue, 3 Jun 2014 09:55:17 +0200 (CEST) Message-ID: <538D7F57.10301@globis.net> Date: Tue, 03 Jun 2014 09:55:03 +0200 From: Ray Hunter User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: "Liubing (Leo)" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B8202@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/n8ub_egHFTqnt3at5F2lt1M8YmM Cc: Mikael Abrahamsson , "bruno.decraene@orange.com" , "homenet@ietf.org" , "ian.farrer@telekom.de" Subject: Re: [homenet] Single or Multiple Routing Protocols in Homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:55:26 -0000 Liubing (Leo) wrote: > Hi all, > > We have an ISIS auto-configuration draft under developing in ISIS WG (draft-liu-isis-auto-conf). Since Homenet/SME networks are one of the main scenarios our draft targets at, and we already have an OSPF-autoconf mechanism available (draft-ietf-ospf-ospfv3-autoconfig), during the isis meeting some people raised the question whether Homenet WG want to support multiple IGP auto-configuration mechanisms. > > I checked the meeting minutes of the last Homenet meeting. And found the status of the issue is: > - WG had decided to have both a configuration protocol (HNCP) + a routing protocol > - WG hasn't decided to have only one routing protocol or two, or even N... > - it seems only one routing protocol has more support > > May I ask a couple of questions: > > 1) Is it necessary to enforce only one routing protocol? > If HNCP is adopted, I guess multiple routing protocols could be easily supported ? > I think it might be more flexible if homenet router support multiple routing protocols. Is there any harm? > (Note: supporting multiple routing protocols here doesn't mean they need run at the same time, just more choices.) > > 2) If we decide to have only one, then what is the criteria for protocol selection? > > Look forward to your comments. Many thanks. > > Best regards, > Bing > > > I use IS-IS in a provider setting, where it has advantages. There is already a draft in 6man regarding how to signal SADR routes to end nodes http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-01 I am of the opinion that the need to communicate source address based routing information to end nodes in Homenet will only increase, or else it will turn out that there will be many more end nodes that should actually be mobile Homenet routers e.g. mobile phones with multiple radios and fixed dock connections. The logical step then from IS-IS would be that these devices either speak ES-IS or translating metrics into RA or running IS-IS on end devices. With that in mind, I think it would be harmful to add a requirement for Homenet routers (and perhaps many mobile nodes) to speak an OSI protocol. It's yet another protocol stack, we already have alternatives, and it isn't widely supported on many operating systems out of the shrink wrap. -- Regards, RayH From nobody Tue Jun 3 01:09:20 2014 Return-Path: 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 2E51E1A016C for ; Tue, 3 Jun 2014 01:09:18 -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 Bw3L5-oaF1WM for ; Tue, 3 Jun 2014 01:09:15 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3271A0169 for ; Tue, 3 Jun 2014 01:09:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0D468870072; Tue, 3 Jun 2014 10:09:04 +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 Q-CoNUPmmxQ7; Tue, 3 Jun 2014 10:09:03 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:853e:3875:6de1:7c47]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 6FA37870047; Tue, 3 Jun 2014 10:09:03 +0200 (CEST) Message-ID: <538D828C.1050403@globis.net> Date: Tue, 03 Jun 2014 10:08:44 +0200 From: Ray Hunter User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: Steven Barth References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> <538D7C07.4060203@globis.net> <538D7F23.1010800@openwrt.org> In-Reply-To: <538D7F23.1010800@openwrt.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/742PomzBRNHfSrBgVcbEJLzvxu0 Cc: homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:09:18 -0000 > Steven Barth > 3 June 2014 09:54 > > Am 03.06.2014 09:40, schrieb Ray Hunter: >>> Steven Barth >>> 3 June 2014 09:15 >>> >>> Well maybe it was worded a bit ambiguously. The main idea behind >>> this was that an HNCP router should provide "basic connectivity" in >>> the form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers >>> should not do anything fancy and just work as legacy devices >>> believing the homenet is their ISP. >>> >>> This should not mean you should be able to "tunnel" through 7084 >>> routers or so. >>> >>> Does that sound sane? And maybe what would be a better wording for >>> this idea? >> >> It is a sane idea, and I applaud any manufacturer that can prevent >> that a lot of 7084 routers are destined for the landfill sooner than >> they should be. > I guess this would not only apply to 7084 routers but "current > IPv6-capable homerouters" in general in the end. > >> >> But it's still a can of worms and you should think very carefully >> whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most. > I guess I'm fine with that. > >> >> e.g. What about the topology: >> >> Homenet router ----- Homenet Router >> | | >> | | >> L2 switch e.g. Powerline Ethernet >> | >> | >> 7084 router >> >> Which Homenet router acts as the Service Provider Router of 7084? > The behavior is essentially the same as with clients right now. One > homenet router per link is elected as DHCP / DHCPv6-server. The only > addition here is that this elected router now acts as PD-server as well. > >> >> That's even before considering the question, what do you do when the >> 7084 router is inserted between two Homenet routers? > This should be same as the current situation: If you are lucky that > 7084 router gives you PD then you have essentially two separate > homenets, if not that homenet router behind the legacy one gets no > (IPv6)-connectivity and probably nasty IPv4 double-NATs. There is not > much you can do though except teach that router to speak homenet. Homenet router --->PD--7084 router --> PD---- Homenet Router | | | | v PD | | | | ---L2 switch e.g. Powerline Ethernet ------------ | | 7084 router PD loops? End users are creative. >> >> >> In fairness I should declare that I was extremely skeptical about >> publishing 7084, and whether it would be harmful for Homenet. >> > Well I guess it doesn't really do much in favor of homenet by > proclaiming: there is only the ISP on one side and clients on the > other side you need to care about. Well at least it defines some sane > requirements (and some less sane ones) regarding these 2 issues. It was decided that any updates to 6204 for the WAN interface would be out of scope for 7084 and that these would instead be deferred into Homenet. -- Regards, RayH From SRS0=FXNF=3A=darou.fr=pierre.pfister@bounces.m4x.org Tue Jun 3 01:34:37 2014 Return-Path: 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 21F2A1A017B for ; Tue, 3 Jun 2014 01:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 1b3yJtw5wa-V for ; Tue, 3 Jun 2014 01:34:34 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2422C1A0162 for ; Tue, 3 Jun 2014 01:34:33 -0700 (PDT) Received: from [10.148.10.38] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 8C8381408EFA2; Tue, 3 Jun 2014 10:34:25 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Pierre Pfister In-Reply-To: <538D828C.1050403@globis.net> Date: Tue, 3 Jun 2014 10:34:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CE2243A-6C33-4D59-BF21-9C9A96F70CA4@darou.fr> References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> <538D7C07.4060203@globis.net> <538D7F23.1010800@openwrt.org> <538D828C.1050403@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1878.2) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Jun 3 10:34:26 2014 +0200 (CEST)) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/l1L3vhgnrIr6eifrZf13S4nI7dg Cc: Steven Barth , homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:35:06 -0000 Hello Ray, Le 3 juin 2014 =E0 10:08, Ray Hunter a =E9crit : >> Steven Barth >> 3 June 2014 09:54 >>=20 >> Am 03.06.2014 09:40, schrieb Ray Hunter: >>>> Steven Barth >>>> 3 June 2014 09:15 >>>>=20 >>>> Well maybe it was worded a bit ambiguously. The main idea behind = this was that an HNCP router should provide "basic connectivity" in the = form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should = not do anything fancy and just work as legacy devices believing the = homenet is their ISP. >>>>=20 >>>> This should not mean you should be able to "tunnel" through 7084 = routers or so. >>>>=20 >>>> Does that sound sane? And maybe what would be a better wording for = this idea? >>>=20 >>> It is a sane idea, and I applaud any manufacturer that can prevent = that a lot of 7084 routers are destined for the landfill sooner than = they should be. >> I guess this would not only apply to 7084 routers but "current = IPv6-capable homerouters" in general in the end. >>=20 >>>=20 >>> But it's still a can of worms and you should think very carefully = whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most. >> I guess I'm fine with that. >>=20 >>>=20 >>> e.g. What about the topology: >>>=20 >>> Homenet router ----- Homenet Router >>> | | >>> | | >>> L2 switch e.g. Powerline Ethernet >>> | >>> | >>> 7084 router >>>=20 >>> Which Homenet router acts as the Service Provider Router of 7084? >> The behavior is essentially the same as with clients right now. One = homenet router per link is elected as DHCP / DHCPv6-server. The only = addition here is that this elected router now acts as PD-server as well. >>=20 >>>=20 >>> That's even before considering the question, what do you do when the = 7084 router is inserted between two Homenet routers? >> This should be same as the current situation: If you are lucky that = 7084 router gives you PD then you have essentially two separate = homenets, if not that homenet router behind the legacy one gets no = (IPv6)-connectivity and probably nasty IPv4 double-NATs. There is not = much you can do though except teach that router to speak homenet. >=20 >=20 >=20 > Homenet router --->PD--7084 router --> PD---- Homenet Router > | | | > | v PD | > | | | > ---L2 switch e.g. Powerline Ethernet ------------ > | > | > 7084 router >=20 >=20 > PD loops? End users are creative. Sure they are ! The details about DHCP server selection or prefix = delegation are in the prefix assignment draft = (http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-01), = which is part of our implementation. The proposed solution to this kind of situations is =AB If a delegated = prefix is included in another delegated prefix, it is ignored. =BB. Basically, the homenet router on the right will not take into account = the delegated prefix it got from the middle 7084 router because it is a = sub-prefix from the left homenet router=92s delegated prefix. I think this logic solves most of these problematic topologies. It won=92t= prevent network split if homenet routers are not layer-2-connected = thought.=20 In general, I think supporting prefix delegation is important. Even if = HNCP is widely deployed, some network devices will make the choice of = simplicity by only using DHCPv6-PD (without sub-delegation). Cheers, Pierre >>>=20 >>>=20 >>> In fairness I should declare that I was extremely skeptical about = publishing 7084, and whether it would be harmful for Homenet. >>>=20 >> Well I guess it doesn't really do much in favor of homenet by = proclaiming: there is only the ISP on one side and clients on the other = side you need to care about. Well at least it defines some sane = requirements (and some less sane ones) regarding these 2 issues. > It was decided that any updates to 6204 for the WAN interface would be = out of scope for 7084 and that these would instead be deferred into = Homenet. >=20 > --=20 > Regards, > RayH >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Tue Jun 3 06:31:58 2014 Return-Path: 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 4FE091A026A for ; Tue, 3 Jun 2014 06:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 rHZ6tSzPnEFy for ; Tue, 3 Jun 2014 06:31:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959281A01F6 for ; Tue, 3 Jun 2014 06:31:45 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id A571C20029; Tue, 3 Jun 2014 09:34:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 133D163B0E; Tue, 3 Jun 2014 09:31:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EC9C463B0B; Tue, 3 Jun 2014 09:31:35 -0400 (EDT) From: Michael Richardson To: Ray Hunter In-Reply-To: <538D73C7.1090700@globis.net> References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tB8IN7h0BsRDxsbCPtxDV-kCouo Cc: Steven Barth , homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:31:51 -0000 --=-=-= Ray Hunter wrote: > How will the user know not to plug the LAN interface of a 7084 router > into a WAN interface? Or, more to the point, how can we detect this event and do something sensible. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU43ONYCLcPvd0N1lAQIwfAf8C4ZsC4LM+LJ7hb/3wEUKzc8/+KvJgktr u1uSOx4zhF9oV+6DzK297QI7p7tUiPZ2zDDAXuIZRq41wVlQjUeFzAV/U4/1+zgs Fb0HmONFi48t2OJbrmpg+R5ktORyiw1n4mr8TzwVtXIpX9u8xABxqeiOTrhUXIfe xV4RldZW4K+h00bk5PVHyW6HXyL2bfmMUfJMLYsvD7cVklkwpSkStuYEXhojKFkG sHZB4bHU9wfwH19os8tci57RZ6RkX5kI24ibBKc+Saqktr5EEk55APbt3nwDQjAH n6P8fozkHca9fwhLYHrftTqH0Q4g058A577gCrcnuka4zVZnLCwh1g== =087X -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 3 06:34:24 2014 Return-Path: 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 57B871A0274 for ; Tue, 3 Jun 2014 06:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 i_ix87a03gQ9 for ; Tue, 3 Jun 2014 06:34:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151121A026A for ; Tue, 3 Jun 2014 06:34:21 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 99CAD20029; Tue, 3 Jun 2014 09:37:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0A70F63B0E; Tue, 3 Jun 2014 09:34:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E5D6163B0B; Tue, 3 Jun 2014 09:34:14 -0400 (EDT) From: Michael Richardson To: Steven Barth In-Reply-To: <538D7607.6030608@openwrt.org> References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VhG1mc5S2xm1VO8mqF2jqE2NMg8 Cc: Ray Hunter , homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:34:22 -0000 --=-=-= Steven Barth wrote: > Well maybe it was worded a bit ambiguously. The main idea behind this was > that an HNCP router should provide "basic connectivity" in the form of > DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do > anything fancy > and just work as legacy devices believing the homenet is their ISP. If the person connects things in the wrong order, should we be documenting the heuristics that would permit the HNCP router to detect this situation? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU43O1ICLcPvd0N1lAQKtKgf/cLDD204CJgYtcGh4W6MTSff7j+e232KC vSdxcxKYLi5dMi3P1XJiZJut+GBI4PvpKT5mfQJtfGFfTF8h0+zVub99l4BqCzkg gTxtCayFnvdDIcf4n8MngPyRKJibXww9hsv13LC2/wdDLsHYs0/mUPoEj21YIBXY MIv1HE0jBOgUpYhyJWLiOBj2XRkRAdiDuJVZlx3snJO6NEuiuGMiDNTMCZ0kjdN3 O9Dd9B/UgQhFM2f8ZfmhlhL3z1gSM1Jr1MlHeDZfyHJPaBvWlH+pMqWUdnavvcAK TDoktqY23kZx7PiKY0eH0lwQGfUsuC7UL97hENbVaanXuscHYAHZDg== =R9cp -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 3 13:03:05 2014 Return-Path: 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 182FD1A0351 for ; Tue, 3 Jun 2014 13:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 VD0K2SDZuJxI for ; Tue, 3 Jun 2014 13:03:02 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB491A034E for ; Tue, 3 Jun 2014 13:03:02 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id p10so5063214pdj.35 for ; Tue, 03 Jun 2014 13:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TbcX5rkRlKGAc0CojkMgwghjU6yl7PtfFtqtBjVk5+M=; b=YxeMFveBKqZad5XNdZJU/1AUM2glX8of+bbu1Fz7Px4N/aMDRi1mHFNjmtWO8ptlb3 9W+6dyMwS0JngbfEL4qipUswHa70rR9wbAXJNwqGwlT7+YLrFwvh8n6GgCdB9cmks/3E n+S2yUdt5T3glQBT8UPE8xsWDa7BDHtXNnS7WoD14xOKfWWMpA2ECiNUP9R98L7b16Gx gy0hv12EhKvZ2jaTCSHy7Ee36mNvwOQ8TPIJPrwtcl1jjd3EKpWDDtd+zSTgoJ4zbTn3 nH7ozGyEtdQilP2yHdj6UxLJxSrqx8AGO5gGyUqSbRHCyGQsX6750MDPOtc/O4+V8xOV IFjQ== X-Received: by 10.68.133.7 with SMTP id oy7mr54442142pbb.43.1401825776996; Tue, 03 Jun 2014 13:02:56 -0700 (PDT) Received: from [192.168.178.23] (17.200.69.111.dynamic.snap.net.nz. [111.69.200.17]) by mx.google.com with ESMTPSA id wg7sm674886pbc.73.2014.06.03.13.02.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 13:02:56 -0700 (PDT) Message-ID: <538E29EC.2000102@gmail.com> Date: Wed, 04 Jun 2014 08:02:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> <8038.1401802454@sandelman.ca> In-Reply-To: <8038.1401802454@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Kui4AaSfWW_blDyYtKY_YupTlak Cc: Ray Hunter , Steven Barth , homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:03:04 -0000 On 04/06/2014 01:34, Michael Richardson wrote: > Steven Barth wrote: > > Well maybe it was worded a bit ambiguously. The main idea behind this was > > that an HNCP router should provide "basic connectivity" in the form of > > DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do > > anything fancy > > and just work as legacy devices believing the homenet is their ISP. > > If the person connects things in the wrong order, should we be documenting > the heuristics that would permit the HNCP router to detect this situation? Let's get real. Users *will* mix and match RFC7084, RFC6204 and neither-of- the-above IPv6 routers with HNCP-capable routers. If we can't deal with routers that are blind to HNCP in a reasonable way, those users will be unhappy. Indeed, the first stage is for HNCP routers to discover the existence of HNCP-blind routers. Brian From nobody Tue Jun 3 14:02:26 2014 Return-Path: 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 C203B1A01A8 for ; Tue, 3 Jun 2014 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 561IIrb0kKvI for ; Tue, 3 Jun 2014 14:02:22 -0700 (PDT) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with SMTP id 3608E1A0271 for ; Tue, 3 Jun 2014 14:02:11 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKU443zMBozK0oqBZA3v9jiKXCPz+vKiIG@postini.com; Tue, 03 Jun 2014 14:02:17 PDT Received: from [10.0.1.41] (c-24-62-250-24.hsd1.nh.comcast.net [24.62.250.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 4FD9F8F0078; Tue, 3 Jun 2014 17:02:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Timothy Winters In-Reply-To: <538E29EC.2000102@gmail.com> Date: Tue, 3 Jun 2014 17:02:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B306FE4-3F07-471C-A5CB-9B779BB4715D@iol.unh.edu> References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> <8038.1401802454@sandelman.ca> <538E29EC.2000102@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/nk-57cH78FhWEaqzlS9QrKX9XGA Cc: Michael Richardson , Steven Barth , homenet@ietf.org, Ray Hunter Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:02:25 -0000 On Jun 3, 2014, at 4:02 PM, Brian E Carpenter = wrote: > On 04/06/2014 01:34, Michael Richardson wrote: >> Steven Barth wrote: >>> Well maybe it was worded a bit ambiguously. The main idea behind = this was >>> that an HNCP router should provide "basic connectivity" in the form = of >>> DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do >>> anything fancy >>> and just work as legacy devices believing the homenet is their ISP. >>=20 >> If the person connects things in the wrong order, should we be = documenting >> the heuristics that would permit the HNCP router to detect this = situation? >=20 > Let's get real. Users *will* mix and match RFC7084, RFC6204 and = neither-of- > the-above IPv6 routers with HNCP-capable routers. If we can't deal = with > routers that are blind to HNCP in a reasonable way, those users will > be unhappy. Indeed, the first stage is for HNCP routers to discover > the existence of HNCP-blind routers. >=20 > Brian The following draft can from the homenet design team = (http://tools.ietf.org/html/draft-winters-homenet-sper-interaction-01) = tries to cover the border scenarios for 6204, 7084 and other routers = (SPERs) when interacting with the Homenet. It doesn't cover the case = for routers inside a homenet but as Steven pointed out that can be two = separate border router. ~Tim >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Tue Jun 3 15:03:16 2014 Return-Path: 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 96E011A038E for ; Tue, 3 Jun 2014 15:03:14 -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 KIJiI25e5cKZ for ; Tue, 3 Jun 2014 15:03:12 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 15EB31A038D for ; Tue, 3 Jun 2014 15:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A9F1C870072; Wed, 4 Jun 2014 00:03:05 +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 CuqVCke-S217; Wed, 4 Jun 2014 00:03:05 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:e4b4:3646:ef12:46e0]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 4339F870047; Wed, 4 Jun 2014 00:03:05 +0200 (CEST) Message-ID: <538E460B.8030708@globis.net> Date: Wed, 04 Jun 2014 00:02:51 +0200 From: Ray Hunter User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: Timothy Winters References: <538CC608.1010109@openwrt.org> <538D73C7.1090700@globis.net> <538D7607.6030608@openwrt.org> <8038.1401802454@sandelman.ca> <538E29EC.2000102@gmail.com> <4B306FE4-3F07-471C-A5CB-9B779BB4715D@iol.unh.edu> In-Reply-To: <4B306FE4-3F07-471C-A5CB-9B779BB4715D@iol.unh.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/6Sp8ZI4pgLjitH-ZFh_i8diuxUQ Cc: Michael Richardson , Steven Barth , homenet@ietf.org Subject: Re: [homenet] HNCP: Few proposed changes for next draft version X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 22:03:14 -0000 > Timothy Winters > 3 June 2014 23:02 > On Jun 3, 2014, at 4:02 PM, Brian E Carpenter wrote: > >> On 04/06/2014 01:34, Michael Richardson wrote: >>> Steven Barth wrote: >>>> Well maybe it was worded a bit ambiguously. The main idea behind this was >>>> that an HNCP router should provide "basic connectivity" in the form of >>>> DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do >>>> anything fancy >>>> and just work as legacy devices believing the homenet is their ISP. >>> If the person connects things in the wrong order, should we be documenting >>> the heuristics that would permit the HNCP router to detect this situation? >> Let's get real. Users *will* mix and match RFC7084, RFC6204 and neither-of- >> the-above IPv6 routers with HNCP-capable routers. If we can't deal with >> routers that are blind to HNCP in a reasonable way, those users will >> be unhappy. Indeed, the first stage is for HNCP routers to discover >> the existence of HNCP-blind routers. >> >> Brian > The following draft can from the homenet design team (http://tools.ietf.org/html/draft-winters-homenet-sper-interaction-01) tries to cover the border scenarios for 6204, 7084 and other routers (SPERs) when interacting with the Homenet. It doesn't cover the case for routers inside a homenet but as Steven pointed out that can be two separate border router. > > ~Tim >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet I don't read anything in 7084 about providing PD on the LAN interfaces. In fact it states that it must act as "a requesting router" not a "delegating router" So I don't see how the scenario of a 7084 compliant router acting as a border router or ISP router is going to pan out: a 7084 router only assigns one /64 per LAN interface (requirement L-2) > Brian E Carpenter > 3 June 2014 22:02 > > Let's get real. Users *will* mix and match RFC7084, RFC6204 and > neither-of- > the-above IPv6 routers with HNCP-capable routers. If we can't deal with > routers that are blind to HNCP in a reasonable way, those users will > be unhappy. Indeed, the first stage is for HNCP routers to discover > the existence of HNCP-blind routers. > > Brian That's a tautology. 7084 and 6204 were explicitly designed with an architecture of a single router and flat user LANs. If these existing standards supported cascaded routers in any way, we probably wouldn't need Homenet. They also cannot be assumed to deal with anything other than a default route (requirement W-3), SADR, or multiple upstream neighbours AFAICS (all requirements for PD in WPD-1 - WPD-5 talk about a (single) prefix (L-13) and single PD request (W-4), or that they have a facility to disable BCP 38 filtering (S-2). So IHMO they're going to be limited at most to leaf nodes at the edge of the Homenet. And even then they're probably going to break naming. Anything else will be a guess, as your HNCP discovery traffic will be blocked and you can't detect if this is a single 7084 router blocking HNCP, or two 7084 routers cascaded in series, or an entire homenet sandwiched between them. > Michael Richardson > 3 June 2014 15:34 > Steven Barth wrote: > > Well maybe it was worded a bit ambiguously. The main idea behind > this was > > that an HNCP router should provide "basic connectivity" in the form of > > DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do > > anything fancy > > and just work as legacy devices believing the homenet is their ISP. > > If the person connects things in the wrong order, should we be documenting > the heuristics that would permit the HNCP router to detect this situation? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > Steven Barth > 3 June 2014 09:15 > > Well maybe it was worded a bit ambiguously. The main idea behind this > was that an HNCP router should provide "basic connectivity" in the > form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should > not do anything fancy and just work as legacy devices believing the > homenet is their ISP. > > This should not mean you should be able to "tunnel" through 7084 > routers or so. > > Does that sound sane? And maybe what would be a better wording for > this idea? > Ray Hunter > 3 June 2014 09:05 > > > Steven Barth wrote: >> Hello everyone, >> >> I prepared the first few changes for the upcoming HNCP draft version >> 01. Most of this is derived from features we already added to our >> reference implementation. >> >> >> 1. Backwards-compatibility with RFC 7084 routers. >> >> Diff: >> https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a1ea8f908975d >> >> > Looks like a can of worms to me. > > How do you intend to do this? > > Are there Homenet topology limitations? > > How will the user know not to plug the LAN interface of a 7084 router > into a WAN interface? > > 7084 (6204bis) was intended to be a dead end once Homenet completed > AFAICS. > >> >> 2. HNCP-routers should make interface categories (auto, internal, >> external) configurable and MAY offer additional categories (guest, >> ad-hoc). >> >> Diff: >> https://github.com/fingon/ietf-drafts/commit/47fdf57a1759fad6e8c6c29d741e95039aca671e >> > Agreed. Sensible. >> >> >> 3. Some house-keeping (updating references, fixing idnits warnings) >> >> Diff: >> https://github.com/fingon/ietf-drafts/commit/a2e2aa1f43e91e808af56f31e5ad514568fc8a6a >> >> >> > Agreed. >> >> Feedback is welcome. >> >> >> Regards, >> >> Steven >> >> > > ------------------------------------------------------------------------ -- Regards, RayH From nobody Sun Jun 8 06:57:02 2014 Return-Path: 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 65EB01A0072; Sun, 8 Jun 2014 06:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kXcw3IrCEBF5; Sun, 8 Jun 2014 06:56:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3521A03D2; Sun, 8 Jun 2014 06:56:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140608135655.19409.56257.idtracker@ietfa.amsl.com> Date: Sun, 08 Jun 2014 06:56:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/id9Gv1FTwPGPtYLCLSTKFX3n36M Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-14.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 13:56:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : IPv6 Home Networking Architecture Principles Authors : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-14.txt Pages : 53 Date : 2014-06-08 Abstract: This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 9 05:17:16 2014 Return-Path: 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 227231A0071 for ; Mon, 9 Jun 2014 05:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 8ZeZW2aQKGF7 for ; Mon, 9 Jun 2014 05:17:11 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id D53E91A00B0 for ; Mon, 9 Jun 2014 05:17:10 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D2930043A503E; Mon, 9 Jun 2014 15:17:09 +0300 From: Markus Stenberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jun 2014 15:17:09 +0300 Message-Id: <67DB804F-A71D-4E29-8174-35438DB3F4D5@iki.fi> To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/hVgBJmDPjne4ipCf9lC1zczc0DQ Cc: Markus Stenberg Subject: [homenet] hncp-01 proposed update + question on 'features' X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 12:17:13 -0000 I added hybrid category to manually configured border discovery = interface types (MAY): = https://github.com/fingon/ietf-drafts/commit/0fb83030fd2c2b8d933417aaca240= 9a043320713 It is usable _within_ home, if (for example) CER is (legacy) RFC7084, = and two HNCP routers are plugged to it. By default, they are unable to = learn of each other (and do the HNCP services with each other such as = prefix assignment, service discovery, and so on). IPv6 on them will = probably require some manual configuration and-or RFC7084bis behavior on = part of the CER. I=92m not sure this is still a good idea, as there=92d be duplicate = prefixes retrieved from legacy router (if 7084bis), but at least it = would enable HNCP router 1 -> HNCP router 2 clients to communicate on IP = level, and to discover services.=20 Another thing I'm wondering about is how to handle services that do = _not_ need to have any explicit state. Should there be some sort of = feature announcement(/support) mechanism? A concrete example: PCP or = UPnP IGDv2 proxy on inner router needs to know _only_ about the CERs. It = does not need to know anything more, and it can _try_ to use the = protocol as-is (as almost mandated by PCP proxy discussions currently, I = guess), but given extra information about support for the feature on the = CER, the response to the host requesting services from a router that = does not support it could be better. Instead of effectively blackholing = packet for service that the CER does not support, proxy on the first-hop = inner router could provide (possibly) more useful error response = immediately. _Currently_ we implemented PCP proxying just blindly, hoping the CER = does it, and otherwise not returning any error. As in case of = multi-homing the error state would depend on the source address chosen = by the client in any case, I'm not sure non-source-address-specific = error messages would bring any extra value here anyway. For example, in = case of PCP, returning (e.g.) NO_RESOURCES may not make client try = different source address. Cheers, -Markus From nobody Mon Jun 9 14:14:02 2014 Return-Path: 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 334981A01F5; Mon, 9 Jun 2014 14:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 v91fJHG9ElKb; Mon, 9 Jun 2014 14:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 401451A0328; Mon, 9 Jun 2014 14:13:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140609211353.11181.94510.idtracker@ietfa.amsl.com> Date: Mon, 09 Jun 2014 14:13:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LfAYrjD0lLEJm-c9Sii4nOWW4f8 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-15.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:13:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : IPv6 Home Networking Architecture Principles Authors : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-15.txt Pages : 53 Date : 2014-06-09 Abstract: This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 12 05:20:23 2014 Return-Path: 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 765FB1B2880 for ; Thu, 12 Jun 2014 05:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 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, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 PtE1OAdEcXOl for ; Thu, 12 Jun 2014 05:20:19 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id A251E1B29E4 for ; Thu, 12 Jun 2014 05:20:18 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: MIME-Version; b=wFJP5u32qZsgY2exkx3VgeJIidPJGR8Z1ShoPimoP+hj1A1u1oN5cWBC 2KzbvoO7HQOZbKmmghhQjcL/eAS/EQ0ldf8pooS36F83kR81SUgxNbHWt INWEX48Gq1zQidBQQbv6VNG5WDKKRDYRb0lewpb8YBLZ3Ksotd1WCw0Jx ulmLY/dLozU3ZfhmCqHVF4mkNyfqrOK6N4KodzZNrSkjO2N+FlcLa1jzG iN6hmB9Cjvrns0KAS2Xenw13sEgnh; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1402575618; x=1434111618; h=from:to:subject:date:message-id:mime-version; bh=gJUXLEFEpr61jeitlkWd+5vadn1pCFhMzhdcSDk9Cys=; b=F4+nbPTcQsEXWjY3Ox+Z3EByTSLbQOIaP8wqwQ8aAAXuTNJoEQXeEAcA cQAUVCXu3AfQsGnzHWx98UuPCe01tUKzg4lKzhXFDviCyTDIAThUL7lZN MTIOsl4faUDsT26oGKOlTJ5U7Hu+HntcB6K27o3zy12fOFpY+ivlVIqMY UtPEQ//xkwJANETpCxF1v7vBxUYFeg+zlIyd3S/0MV8Jg6KHE4CZFnY7R Mg5bQwObqfXN0TfD9GtXunDGrp5G0; X-IronPort-AV: E=Sophos; i="5.01,464,1400022000"; d="scan'208,217"; a="10628981" X-IPAS-Result: Am0FAAmamVPV+MWQ/2dsb2JhbABagmkkAR6BDLs1iEsWdYQKUzgBGmYXEASIVgOiOq84F415CwMDAYMLD0QkgRYErgSDPIFuCBci Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx1.nominet.org.uk with ESMTP; 12 Jun 2014 13:20:17 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.03.0123.003; Thu, 12 Jun 2014 13:20:16 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Updates to Homenet Architecture Principles doc Thread-Index: AQHPhjiqxmfdZx62jkq0PP0j0HRd4w== Date: Thu, 12 Jun 2014 12:20:16 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_BEB843C7EB1D486AA9A1B99D48775D33nominetorguk_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_TD4MlKlnMI9LwUcVB48UJFCVpQ Subject: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:20:21 -0000 --_000_BEB843C7EB1D486AA9A1B99D48775D33nominetorguk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Working Group, You may have noticed multiple revisions of draft-ietf-homenet-arch posted r= ecently. After many iterations and a ton of work for our Editor In Chief, T= im Chown, all IESG =93DISCUSS=94 positions have been resolved to either =93= Yes=94 or =93No Objection=94, with the exception of one =93Abstain=94 from = one of our Routing Area ADs who had requested that the following text be ad= ded to section 3.5: =93Routing 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.=94 The Chairs felt that the first half of this text was unnecessarily prescrip= tive for this document and did not reflect something the WG had achieved co= nsensus on at this time. We proposed a compromise that incorporated the la= tter non-normative half of this text in an earlier paragraph. On the basis= that we understood that this compromise had been accepted by the respectiv= e AD, the -14 revision was posted. After -14 was posted and the AD=92s position changed to "No Objection", we = noticed that the above paragraph had inadvertently been included, in full, = in addition to the latter half included as part of the proposed compromise!= At the Chairs=92 request, Tim removed the above paragraph in -15, which ca= used the AD to object as it appeared to him that his text was being removed= after the fact. Later today, Tim will be posting a -16 revision of the document that reinst= ates the above paragraph, in full, and removes the =93compromise=94 text. O= n the basis that the new text is a potentially substantive change, our AD h= as requested that we put the document through one more Working Group Last C= all to determine WG consensus on that issue. In addition, one small change was introduced in the -15 revision based on W= G feedback where a reference to Source Specific Multicast [RFC 4607] was in= troduced, but had not been called out explicitly in London or before. That = change is as follows: Old: It is desirable that, subject to the capacities of devices on certain media types, multicast routing is supported across the homenet. New: It is desirable that, subject to the capacities of devices on certain media types, multicast routing is supported across the homenet, including source-specific multicast (SSM) [RFC4607]. The WGLC will commence immediately after the -16 is posted, and will last f= or two weeks. We very much want your feedback here, but are not aiming to revisit the doc= ument in its entirety. As such, we would like to limit the scope of the WGL= C to just the text quoted in this email. Many thanks, Ray and Mark --_000_BEB843C7EB1D486AA9A1B99D48775D33nominetorguk_ Content-Type: text/html; charset="Windows-1252" Content-ID: <437188BDE61CE24AB408A104393B8147@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable
Dear Working Group,

You may have noticed multiple revisions of draft-ietf-homenet= -arch posted recently. After many iterations and a ton of work for our Editor In Chief, Tim Chown, all IESG =93DISCUSS= =94 positions have been resolved to either =93Yes=94 or =93No Objection=94,= with the exception of one =93Abstain=94 from one of our Routing Area ADs w= ho had requested that the following text be added to section 3.5:

=93Routing within the homenet will determine the least cost p= ath across
 the homenet towards the destination address given the s= ource address.
 The path cost will be computed as a linear sum of the m= etric assigned
 to each link.  The metric may be configured or aut= omatically derived
 per link based on consideration of factors such as wors= t-case queue
 depth and router processing capabilities.=94
The Chairs felt that the first half of this text was unnecess= arily prescriptive for this document and did not reflect something the WG had achieved consensus on at this tim= e.  We proposed a compromise that incorporated the latter non-normativ= e half of this text in an earlier paragraph.  On the basis that we und= erstood that this compromise had been accepted by the respective AD, the -14 revision was posted.

After -14 was posted and the AD=92s position changed to "= ;No Objection", we noticed that the above paragraph had inadvertently been included, in full, in addition to the latter half i= ncluded as part of the proposed compromise! At the Chairs=92 request, Tim r= emoved the above paragraph in -15, which caused the AD to object as it appe= ared to him that his text was being removed after the fact.  

Later today, Tim will be posting a -16 revision of the docume= nt that reinstates the above paragraph, in full, and removes the =93compromise=94 text. On the basis that the new = text is a potentially substantive change, our AD has requested that we put = the document through one more Working Group Last Call to determine WG conse= nsus on that issue.

In addition, one small change was introduced in the -15 revis= ion based on WG feedback where a reference to Source Specific Multicast [RFC 4607] was introduced, but had not been c= alled out explicitly in London or before. That change is as follows:=

Old:
   It is desirable that, subject to= the capacities of devices on certain
   media types, multicast routing i= s supported across the homenet.

New:
   It is desirable that, subject to= the capacities of devices on certain
   media types, multicast routing i= s supported across the homenet,
   including source-specific multic= ast (SSM) [RFC4607].

The WGLC will commence immediately after the -16 is posted, a= nd will last for two weeks.

We very much want your feedback here, but are not aiming to r= evisit the document in its entirety. As such, we would like to limit the scope of the WGLC to just the text quo= ted in this email.

Many thanks,

Ray and Mark

--_000_BEB843C7EB1D486AA9A1B99D48775D33nominetorguk_-- From nobody Thu Jun 12 05:45:14 2014 Return-Path: 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 7462D1B29FC for ; Thu, 12 Jun 2014 05:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 im8ZD-3o767n for ; Thu, 12 Jun 2014 05:45:10 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id 87CE11B29F2 for ; Thu, 12 Jun 2014 05:45:10 -0700 (PDT) Received: from poro.lan (84.248.74.106) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D34B5047FBC6C; Thu, 12 Jun 2014 15:45:02 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: Date: Thu, 12 Jun 2014 15:45:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ray Bellis X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/c47oNk8bdssAUYP2ZPd9q74FaoM Cc: "homenet@ietf.org Group" , Markus Stenberg Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:45:12 -0000 On 12.6.2014, at 15.20, Ray Bellis wrote: > =93Routing 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.=94 This sounds _way_ too specific to me. Like a lot of the document by now. Specifying routing protocol path cost function in _architecture_ = document? Ha ha. I would just use -15 or replace AD. Are either of those two options? Cheers, -Markus= From nobody Thu Jun 12 05:56:13 2014 Return-Path: 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 DC41F1B286B for ; Thu, 12 Jun 2014 05:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.35 X-Spam-Level: X-Spam-Status: No, score=-4.35 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, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 HmSCo7PyYfo4 for ; Thu, 12 Jun 2014 05:56:09 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 74A051A03ED for ; Thu, 12 Jun 2014 05:56:07 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=GmQlEXJBwzsVNTPYPas1SOWn0wulQ7XtZi78UPoN2Z8LE/2bJCbYnpAY z7nkGv2cXVxiPPdJwTEFiPUYfKyaAQjKtbq596KN+NW5nJx6xizehREOJ e69V5hWqqTOfk2/lSs+24jllX+r+3oMq8aQLuj9CZ0dXlQ4P9kIivilfG lJXHT6rO1RZobLz4mfTBqoL5+coTzaYwgaLEYlWgNeZpdYaNOHpH8lfQJ 0kqf4tDK7HAYTCQSMAdkDVc3VbArO; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1402577768; x=1434113768; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=od3DNPSa2JwF7VUGOo7CPwBHdyRjd8XBoj/RMUWTHdE=; b=BQ6DbCWTERJ7ie1QCfsTdFbY2XzQOsL6OJL5jC5kdwYNT+DtUjOxW0BN pJQbqAj2COpYWzYb9m/Te9vSn0DjSW9A+C74/lRaSOonzdRT5U7qI8U7j NxCCaurWW13149IYPRKEGntBnBSJ2ZOJYdhDuyIIn7Q/MYPFI3t2fS2ja jvDGq5GbkLFgN8XguR3eug82/f8+0pMPBANy/RN+enJl4z1F007/BAu0L NKa4HGlZGJ0BdmhfVoosrRRi6hAWR; X-IronPort-AV: E=Sophos;i="5.01,465,1400022000"; d="scan'208,217";a="9926329" X-IPAS-Result: AkIFAIGimVPV+MWQ/2dsb2JhbABagmkkgSvCdgGBCRZ1hAQBBVM2AgEaNDIXDgIEiFYD0W0XjXkLAwMBV4MrgRYErgSDPIFuCBci Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx2.nominet.org.uk with ESMTP; 12 Jun 2014 13:56:06 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.03.0123.003; Thu, 12 Jun 2014 13:56:06 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Updates to Homenet Architecture Principles doc Thread-Index: AQHPhjiqxmfdZx62jkq0PP0j0HRd45ttXiKA Date: Thu, 12 Jun 2014 12:56:05 +0000 Message-ID: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_85F978F412934F9EB5C7068F95A0B626nominetorguk_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Vlf_OC0DyVzNXubGpJ97SZ6ZS1Y Subject: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:56:12 -0000 --_000_85F978F412934F9EB5C7068F95A0B626nominetorguk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [let's try that again, hopefully without b0rked line wrapping] Dear Working Group, You may have noticed multiple revisions of draft-ietf-homenet-arch posted r= ecently. After many iterations and a ton of work for our Editor In Chief, T= im Chown, all IESG =93DISCUSS=94 positions have been resolved to either =93= Yes=94 or =93No Objection=94, with the exception of one =93Abstain=94 from = one of our Routing Area ADs who had requested that the following text be ad= ded to section 3.5: =93Routing 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.=94 The Chairs felt that the first half of this text was unnecessarily prescrip= tive for this document and did not reflect something the WG had achieved co= nsensus on at this time. We proposed a compromise that incorporated the la= tter non-normative half of this text in an earlier paragraph. On the basis= that we understood that this compromise had been accepted by the respectiv= e AD, the -14 revision was posted. After -14 was posted and the AD=92s position changed to "No Objection", we = noticed that the above paragraph had inadvertently been included, in full, = in addition to the latter half included as part of the proposed compromise!= At the Chairs=92 request, Tim removed the above paragraph in -15, which ca= used the AD to object as it appeared to him that his text was being removed= after the fact. Later today, Tim will be posting a -16 revision of the document that reinst= ates the above paragraph, in full, and removes the =93compromise=94 text. O= n the basis that the new text is a potentially substantive change, our AD h= as requested that we put the document through one more Working Group Last C= all to determine WG consensus on that issue. In addition, one small change was introduced in the -15 revision based on W= G feedback where a reference to Source Specific Multicast [RFC 4607] was in= troduced, but had not been called out explicitly in London or before. That = change is as follows: Old: It is desirable that, subject to the capacities of devices on certain me= dia types, multicast routing is supported across the homenet. New: It is desirable that, subject to the capacities of devices on certain media types, multicast routing is supported across the homenet, including source-specific multicast (SSM) [RFC4607]. The WGLC will commence immediately after the -16 is posted, and will last f= or two weeks. We very much want your feedback here, but are not aiming to revisit the doc= ument in its entirety. As such, we would like to limit the scope of the WGL= C to just the text quoted in this email. Many thanks, Ray and Mark --_000_85F978F412934F9EB5C7068F95A0B626nominetorguk_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable [let's try that again, hopefully without b0rked line wrapping]

Dear Working Group,

You may have noticed multiple revisions of draft-ietf-homenet= -arch posted recently. After many iterations and a ton of work for our Editor In Chief, Tim Chown, all IESG =93DISCUSS= =94 positions have been resolved to either =93Yes=94 or =93No Objection=94,= with the exception of one =93Abstain=94 from one of our Routing Area ADs w= ho had requested that the following text be added to section 3.5:

=93Routing within the homenet will determine the least cost p= ath across
 the homenet towards the destination address given the s= ource address.
 The path cost will be computed as a linear sum of the m= etric assigned
 to each link.  The metric may be configured or aut= omatically derived
 per link based on consideration of factors such as wors= t-case queue
 depth and router processing capabilities.=94
The Chairs felt that the first half of this text was unnecess= arily prescriptive for this document and did not reflect something the WG had achieved consensus on at this tim= e.  We proposed a compromise that incorporated the latter non-normativ= e half of this text in an earlier paragraph.  On the basis that we und= erstood that this compromise had been accepted by the respective AD, the -14 revision was posted.

After -14 was posted and the AD=92s position changed to "= ;No Objection", we noticed that the above paragraph had inadvertently been included, in full, in addition to the latter half i= ncluded as part of the proposed compromise! At the Chairs=92 request, Tim r= emoved the above paragraph in -15, which caused the AD to object as it appe= ared to him that his text was being removed after the fact.  

Later today, Tim will be posting a -16 revision of the docume= nt that reinstates the above paragraph, in full, and removes the =93compromise=94 text. On the basis that the new = text is a potentially substantive change, our AD has requested that we put = the document through one more Working Group Last Call to determine WG conse= nsus on that issue.

In addition, one small change was introduced in the -15 revis= ion based on WG feedback where a reference to Source Specific Multicast [RFC 4607] was introduced, but had not been c= alled out explicitly in London or before. That change is as follows:=

Old:
 It is desirable that, subject to the capacit= ies of devices on certain   media types, multicast routing is supp= orted across the homenet.

New:

  It is desirable that, subject to the capacities o= f devices on certain
  media types, multicast routing is supported acros= s the homenet,
  including source-specific multicast (SSM) [RFC460= 7].

The WGLC will commence immediately after the -16 is posted, a= nd will last for two weeks.

We very much want your feedback here, but are not aiming to r= evisit the document in its entirety. As such, we would like to limit the scope of the WGLC to just the text quo= ted in this email.

Many thanks,

Ray and Mark

--_000_85F978F412934F9EB5C7068F95A0B626nominetorguk_-- From nobody Thu Jun 12 06:04:14 2014 Return-Path: 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 9F6DF1B2A05 for ; Thu, 12 Jun 2014 06:04:12 -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 bHg8UQnPTu4v for ; Thu, 12 Jun 2014 06:04:07 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D6D231B287D for ; Thu, 12 Jun 2014 06:04:07 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id DF0FE2381522; Thu, 12 Jun 2014 09:04:06 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Thu, 12 Jun 2014 09:04:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> References: To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oEWyrJKnISV8xnITSK7vup2209Y Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:04:12 -0000 On Jun 12, 2014, at 8:45 AM, Markus Stenberg = wrote: > This sounds _way_ too specific to me. Like a lot of the document by = now. > Specifying routing protocol path cost function in _architecture_ = document? > Ha ha. If you are just going to laugh, then I'm not going to approve the = document, and you should definitely ask nomcom to replace me if you feel = that is the right thing to do. I would prefer that we have a = discussion about what the text should say, but that's entirely up to = you. What I would like to see as feedback is a clear statement of what the = routing paradigm is, not agreement that the text as currently written is = correct. This statement should be inclusive of whatever routing = protocols the working group is inclined to consider, but it should be = selective enough that it says what the working group actually wants, and = doesn't cover all possible routing protocols. I very much do not want = the working group to fight out the routing protocol question right now, = but I think it's possible to get this text to a point where it satisfies = the DISCUSS it was supposed to satisfy. From nobody Thu Jun 12 06:33:37 2014 Return-Path: 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 5F63D1A0095 for ; Thu, 12 Jun 2014 06:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 ZSABHmva3-96 for ; Thu, 12 Jun 2014 06:33:35 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id E6AEE1A0090 for ; Thu, 12 Jun 2014 06:33:34 -0700 (PDT) Received: from poro.lan (84.248.74.106) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D34B50480D38D; Thu, 12 Jun 2014 16:33:29 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> Date: Thu, 12 Jun 2014 16:33:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/xXC4HbDC3cUjH9oQOcd8uwkCNQM Cc: Ray Bellis , "homenet@ietf.org Group" , Markus Stenberg Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:33:36 -0000 On 12.6.2014, at 16.04, Ted Lemon wrote: > On Jun 12, 2014, at 8:45 AM, Markus Stenberg = wrote: >> This sounds _way_ too specific to me. Like a lot of the document by = now. >> Specifying routing protocol path cost function in _architecture_ = document? >> Ha ha. > If you are just going to laugh, then I'm not going to approve the = document, and you should definitely ask nomcom to replace me if you feel = that is the right thing to do. I would prefer that we have a = discussion about what the text should say, but that=92s entirely up to = you. Well, I=92m just concerned that discussion led to the text as agreed = consensus. (At least judging by Ray=92s account.) As I=92m not privy to that, I=92m not assigning blame, but I find the = outcome just .. funny. So why not laugh? It=92s better than crying. Supposedly extends your = lifespan too. > What I would like to see as feedback is a clear statement of what the = routing paradigm is, not agreement that the text as currently written is = correct. This statement should be inclusive of whatever routing = protocols the working group is inclined to consider, but it should be = selective enough that it says what the working group actually wants, and = doesn't cover all possible routing protocols. I very much do not want = the working group to fight out the routing protocol question right now, = but I think it=92s possible to get this text to a point where it = satisfies the DISCUSS it was supposed to satisfy. Why do we need to do that? Specifying it in extreme detail effectively = favors some protocols, either intentionally or not. Even before this latest update, I found the routing way overspecified = and possibly in wrong direction; for example, I am currently using = mostly Babel as a routing protocol for my homenet-related things, and = it=92s not link-state. So, as a text diff.. -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. .. and so on. and link metrics show up more in the text too. 99% of typical homes care = about one _bit_ of link information - whether it=92s wired or not, and = if wired, prefer that. I still wouldn=92t want to specify that in an arch draft. Then again, perhaps we should rename this draft _the solution = specification_ draft, because there=92s lots of places that lean that = way already. Source address-aware RIP would probably be sufficient for a homenet use = case if PA/other stuff is done elsewhere (HNCP, hierarchical PD, CNP, = you name it). Looking at the homenet routing as blank slate (ignoring the arch draft), = here=92s what I think matters: - source specific (=3D> can deal with multiple ISPs) - not tied to L2 - can do unicast IPv[46] routes (multicast would be nice too but = typically separate protocol) what=92s helpful: - fast initial/incremential convergence of state (not in arch draft = currently) - some minimalist metrics (not mandatory either) If we compare this list to what=92s in arch draft, we=92re already very = diverged. I=92m not trying to fight the windmill and get rid of cruft in = arch draft, but I am not happy about AD comments (/discussions = somewhere?) adding even more of it. I provided my feedback. Care to enlighten us why your stance is that we = _do_ need insanely verbose specification of routing paradigm? Cheers, -Markus= From nobody Thu Jun 12 06:38:05 2014 Return-Path: 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 B68481A0090 for ; Thu, 12 Jun 2014 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Xd9-zSKYh1rS for ; Thu, 12 Jun 2014 06:37:52 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AD91A0086 for ; Thu, 12 Jun 2014 06:37:50 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so1297656wes.30 for ; Thu, 12 Jun 2014 06:37:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=iuXgp05Ry45m+mH2CS2UioSENVKVMDB2jyLSN98KGv8=; b=M1NIF0+d+XWagw5bhBCEGhltlmJqjccXK6bKsKTkIgCB3YDRRDpXDVGNhqxe4jAG1E mBS9GQMiN3YW1QsO+YmxpIM2RmyXoBvgX7X5h+4RGxEARemT8DahTq1h1eIisXw+4ptH wS6AjHHb9/qQKKhhJ1J7tssBQ7QJNLl2m3GN2RdGsnavqngZB/dzf4crUJ+cjoRe62AC nJFzKuNuWy+33szLxvOipqR+AMUvQKdBYO1315hnMqwn1lb2K9uvgelWfPQ7zC7VXLSx +UOWHJK5Aqyg0kfw/FOgbpmjSYktxQnz1Cm2NthmBq5UEbtXaZ3OI85IkXFiwipGYCip zwKw== X-Gm-Message-State: ALoCoQnkyzWGJ38nmXF6C1QtNeSoi8E61/uOZLrEofBvPxZR7T10FjKvYJr1BFltAdF8cmtEALin X-Received: by 10.180.73.169 with SMTP id m9mr6459718wiv.53.1402580268735; Thu, 12 Jun 2014 06:37:48 -0700 (PDT) Received: from [192.168.1.108] (AMontsouris-653-1-138-142.w92-140.abo.wanadoo.fr. [92.140.9.142]) by mx.google.com with ESMTPSA id z8sm16018331wib.12.2014.06.12.06.37.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 06:37:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Mark Townsley In-Reply-To: Date: Thu, 12 Jun 2014 15:37:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08EF339D-B35F-4344-95D7-902716340CF5@townsley.net> References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zX9LqnOb160ZGL8bT0ofULszThE Cc: Ray Bellis , "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:37:59 -0000 To be clear, it is the Routing AD who prosed the text, not Ted (Internet = AD). Ted asked that it be run by the WG as he, rightly, considered it = substantive and wanted the WG's opinion of it. - Mark On Jun 12, 2014, at 3:33 PM, Markus Stenberg = wrote: > On 12.6.2014, at 16.04, Ted Lemon wrote: >> On Jun 12, 2014, at 8:45 AM, Markus Stenberg = wrote: >>> This sounds _way_ too specific to me. Like a lot of the document by = now. >>> Specifying routing protocol path cost function in _architecture_ = document? >>> Ha ha. >> If you are just going to laugh, then I'm not going to approve the = document, and you should definitely ask nomcom to replace me if you feel = that is the right thing to do. I would prefer that we have a = discussion about what the text should say, but that=92s entirely up to = you. >=20 > Well, I=92m just concerned that discussion led to the text as agreed = consensus. (At least judging by Ray=92s account.) >=20 > As I=92m not privy to that, I=92m not assigning blame, but I find the = outcome just .. funny. >=20 > So why not laugh? It=92s better than crying. Supposedly extends your = lifespan too. >=20 >> What I would like to see as feedback is a clear statement of what the = routing paradigm is, not agreement that the text as currently written is = correct. This statement should be inclusive of whatever routing = protocols the working group is inclined to consider, but it should be = selective enough that it says what the working group actually wants, and = doesn't cover all possible routing protocols. I very much do not want = the working group to fight out the routing protocol question right now, = but I think it=92s possible to get this text to a point where it = satisfies the DISCUSS it was supposed to satisfy. >=20 > Why do we need to do that? Specifying it in extreme detail effectively = favors some protocols, either intentionally or not. >=20 > Even before this latest update, I found the routing way overspecified = and possibly in wrong direction; for example, I am currently using = mostly Babel as a routing protocol for my homenet-related things, and = it=92s not link-state. >=20 > So, as a text diff.. >=20 > -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. >=20 > .. and so on. >=20 > and link metrics show up more in the text too. 99% of typical homes = care about one _bit_ of link information - whether it=92s wired or not, = and if wired, prefer that. >=20 > I still wouldn=92t want to specify that in an arch draft. >=20 > Then again, perhaps we should rename this draft _the solution = specification_ draft, because there=92s lots of places that lean that = way already. >=20 > Source address-aware RIP would probably be sufficient for a homenet = use case if PA/other stuff is done elsewhere (HNCP, hierarchical PD, = CNP, you name it). >=20 > Looking at the homenet routing as blank slate (ignoring the arch = draft), here=92s what I think matters: >=20 > - source specific (=3D> can deal with multiple ISPs) > - not tied to L2 > - can do unicast IPv[46] routes (multicast would be nice too but = typically separate protocol) >=20 > what=92s helpful: >=20 > - fast initial/incremential convergence of state (not in arch draft = currently) > - some minimalist metrics (not mandatory either) >=20 > If we compare this list to what=92s in arch draft, we=92re already = very diverged. I=92m not trying to fight the windmill and get rid of = cruft in arch draft, but I am not happy about AD comments (/discussions = somewhere?) adding even more of it. >=20 > I provided my feedback. Care to enlighten us why your stance is that = we _do_ need insanely verbose specification of routing paradigm? >=20 > Cheers, >=20 > -Markus > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Jun 12 06:59:47 2014 Return-Path: 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 F0CA41B2A3A for ; Thu, 12 Jun 2014 06:59:44 -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 DYQdA--lCzVJ for ; Thu, 12 Jun 2014 06:59:44 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 183DC1A009A for ; Thu, 12 Jun 2014 06:59:44 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 7C3FB2381522; Thu, 12 Jun 2014 09:59:42 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Thu, 12 Jun 2014 09:59:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/34ryisZs8YMKmmC9jbWUUNReuSA Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:59:45 -0000 On Jun 12, 2014, at 9:33 AM, Markus Stenberg = wrote: > I provided my feedback. Care to enlighten us why your stance is that = we _do_ need insanely verbose specification of routing paradigm? Both of the routing ADs complained about the text in this section. I = do not actually clearly understand their complaints, but after = discussing it with Alia (who did not raise a DISCUSS, but was happy to = talk with me about it) and with Adrian (who really feels quite = discouraged about the whole conversation), the understanding I came away = with was that they felt that the document as written was quite = open-ended and left available the possibility of doing some things that = are Not A Good Idea. As a routing non-expert, I have no way to evaluate this. I don't know = what the working group wants, and I don't know why the routing ADs are = concerned about it. So when I have a routing AD spend months trying to = get the text right, and then get upset when it's changed and move to = abstain on the document, my only recourse is to either put my fingers in = my ears and hum a tune whilst pretending not to hear, or to ask the = working group for help. I have a lot of respect for the routing ADs, and don't want to just = ignore them, so I chose the latter. There's a lot of knowledge about = routing in the working group, and my hope is that in watching you = discuss this question, I can come to a better understanding of what to = do. I realize this is a pain in the neck, and I apologize for it--I = wish I had a better understanding of the issues so that I could just = propose a solution. From nobody Thu Jun 12 07:34:22 2014 Return-Path: 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 73AF01A012D for ; Thu, 12 Jun 2014 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 ILYuWLy94hMJ for ; Thu, 12 Jun 2014 07:34:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 6D6F11B2A52 for ; Thu, 12 Jun 2014 07:34:18 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5CEYCMq016326; Thu, 12 Jun 2014 16:34:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id AC38A29A75E; Thu, 12 Jun 2014 16:34:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id X3HGUrlt34uo; Thu, 12 Jun 2014 16:34:10 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 210D429A758; Thu, 12 Jun 2014 16:34:09 +0200 (CEST) Date: Thu, 12 Jun 2014 16:34:36 +0200 Message-ID: <877g4murgj.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 12 Jun 2014 16:34:12 +0200 (CEST) X-Miltered: at korolev with ID 5399BA64.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5399BA64.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5399BA64.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JD2tV1GeXzq0xHDjNQ-PE0dCMlw Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:34:20 -0000 >> This sounds _way_ too specific to me. > If you are just going to laugh, Laugh with us, Ted -- it /is/ rather funny. (I especially liked the "linear sum" touch. What's a non-linear sum?) > This statement should be inclusive of whatever routing protocols the > working group is inclined to consider, I'll do my best. There are at least four issues at hand. 1. Not all routing protocols choose the lowest-metric route -- some protocols include in their route selection criteria data that are not encoded in the metric. Examples are BGP flap avoidance, or the hysteresis algorithm used by Babel. One might argue that this is also the case of multi-area OSPF (although it is not usually expressed in that manner). For BGP and OSPF, you probably know more about the subject than I do. For Babel, see Section 3.6 of RFC 6126 and Section III.E of http://arxiv.org/pdf/1403.3488 (As far as I know, there is currently no theoretical understanding of this kind of techniques. As far as I've been able to work out, neither Sobrinho's routing algebras nor Griffin's semigroups are able to account for them.) The Arch document MUST NOT specify what kind of data the route selection algorithm is allowed to take as input. 2. Many protocols don't compute metrics as a "linear sum" of the link costs; as a matter of fact, in many protocols the metric is not a mere integer, but an element of a richer algebra. This is obviously the case of BGP (see Griffin and Sobrinho, SIGCOMM 2005), but also of Babel, which, when run over a radio link layer with interference avoidance enabled, carries a pair of an integer and (roughly speaking) a set of interfering radio frequencies. The Arch document MUST NOT specify the structure of the metric algebra. It SHOULD NOT even imply that the metric being used is modelisable as a routing algebra. 3. Finding a satisfactory and implementable metric for radio link layers is very much an open research problem. Many routing protocols just punt and expect the link layer to work like an Ethernet, which gets you horrible performance in rich layer 3 topologies. Some mesh routing protocols estimate unicast link rate and multicast packet loss and combine the two using magic, which tends to choose unusable routes in some cases. There has been a lot of noise around cross-layer techniques for the last 10 years or so, but I don't know of a production-quality implementation. (Yeah, I know, I should stop complaining and try my hand at it.) Please do not underestimate the importance of this point for Homenet -- how many wired and how many wireless links do you expect there to be in a typical home ten years from now? The Arch document MUST NOT specify what kind of data the metric computation algorithm is allowed to take as input. 4. There exist routing protocols that don't use the notion of a metric at all. We metric-based people like to jestingly call them "longest-path routing" algorithms, however we're still keeping an eye open to see if anything useful comes out from that line of research. The Arch document SHOULD NOT even imply that a metric is being used. Hope this helps, -- Juliusz From nobody Thu Jun 12 07:54:42 2014 Return-Path: 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 7FC8B1B2A80 for ; Thu, 12 Jun 2014 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 b8G355ny62eu for ; Thu, 12 Jun 2014 07:54:36 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AAC1B2A46 for ; Thu, 12 Jun 2014 07:54:36 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so882851wib.3 for ; Thu, 12 Jun 2014 07:54:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=pSdM7NO2qHKpSSjKOyz4/zckTdE66vBDn6Ofa0uyHP4=; b=eIfiQDpIapTESMfQhTHw7S0ftQWg8hKKvF3JL/kB8dMwTZU79d8pg5O31T77hMS1Co bya534UIs2diX1UhlrDXDP+BEVkdCLD+DM8hRAbCz+OIxmXYUnI0baE6vWxLcy9Ey4NC /q3VKqMDS5h42aeTZa/4q/rUmImgdflE3088YivqVEOnOSSPllyl/oz/dAAI8FRijifW w84To3aRtCgx+SWBJDNA1I9eAoudv8U0V4DoByu1gRR6gpWGCHJljm4wTCt6GY5NTNpI o5mF1wE4lD1jYgOSwMWkPJgvFd48e8mzNj3wZXFhDFyQHmJJVfmYpYZKc/SQ6q8V0uoG 6HJA== X-Gm-Message-State: ALoCoQm5x9T9+A/li2p9IjJDX9WO4Pl5/hTlZMlMLt5pkwhOZnzJZ1DFDxRnbJcKGaqmPktGg/ln X-Received: by 10.194.91.144 with SMTP id ce16mr62448437wjb.18.1402584874743; Thu, 12 Jun 2014 07:54:34 -0700 (PDT) Received: from [100.70.147.106] (71.16.90.92.rev.sfr.net. [92.90.16.71]) by mx.google.com with ESMTPSA id vc2sm1868126wjc.2.2014.06.12.07.54.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 07:54:34 -0700 (PDT) References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> Mime-Version: 1.0 (1.0) In-Reply-To: <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: "Townsley.net" Date: Thu, 12 Jun 2014 16:54:23 +0200 To: Ted Lemon Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wVLVvIJ9YxOUMQusCxeAUXaT8gE Cc: Ray Bellis , "homenet@ietf.org Group" , Markus Stenberg Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:54:39 -0000 I think for an arch document, we should talk generally about how a routing p= rotocol could plug into the rest of the system, but stop short of details wi= thin the routing protocol itself. If routing experts are concerned the worki= ng group is going to go into bad territory with cost metrics, path calculati= on, etc. toying around with text here isn't the way to go about solving tha= t. This is not a WG charter document, it's not even normative.=20 Bottom line: I would much rather have routing experts on list rather than wr= iting our documents for us one discuss at a time.=20 - Mark (Thumbtyped) > On Jun 12, 2014, at 3:59 PM, Ted Lemon wrote: >=20 >> On Jun 12, 2014, at 9:33 AM, Markus Stenberg wro= te: >> I provided my feedback. Care to enlighten us why your stance is that we _= do_ need insanely verbose specification of routing paradigm? >=20 > Both of the routing ADs complained about the text in this section. I do n= ot actually clearly understand their complaints, but after discussing it wit= h Alia (who did not raise a DISCUSS, but was happy to talk with me about it)= and with Adrian (who really feels quite discouraged about the whole convers= ation), the understanding I came away with was that they felt that the docum= ent as written was quite open-ended and left available the possibility of do= ing some things that are Not A Good Idea. >=20 > As a routing non-expert, I have no way to evaluate this. I don't know wh= at the working group wants, and I don't know why the routing ADs are concern= ed about it. So when I have a routing AD spend months trying to get the te= xt right, and then get upset when it's changed and move to abstain on the do= cument, my only recourse is to either put my fingers in my ears and hum a tu= ne whilst pretending not to hear, or to ask the working group for help. >=20 > I have a lot of respect for the routing ADs, and don't want to just ignore= them, so I chose the latter. There's a lot of knowledge about routing in t= he working group, and my hope is that in watching you discuss this question,= I can come to a better understanding of what to do. I realize this is a p= ain in the neck, and I apologize for it--I wish I had a better understanding= of the issues so that I could just propose a solution. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Jun 12 07:55:27 2014 Return-Path: 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 CB4AA1B2A76 for ; Thu, 12 Jun 2014 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YAyRgPaZnu_Y for ; Thu, 12 Jun 2014 07:55:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48D41B2A87 for ; Thu, 12 Jun 2014 07:55:19 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-0c-53996c0c04fd Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 64.96.11744.C0C69935; Thu, 12 Jun 2014 10:59:56 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 10:55:18 -0400 From: Acee Lindem To: Juliusz Chroboczek , Ted Lemon Thread-Topic: [homenet] Updates to Homenet Architecture Principles doc Thread-Index: AQHPhjiqxmfdZx62jkq0PP0j0HRd45ttrt0AgAAFU4CAABlKAP//kGsA Date: Thu, 12 Jun 2014 14:55:17 +0000 Message-ID: References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <877g4murgj.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <877g4murgj.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9BC6286CCECDEE4E8E0827B5A7FBB86B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLonQZcnZ2awwes5chbvFx1isfj86R+r xZs1R5gcmD2aLixj91iy5CeTx8Xd7xgDmKO4bFJSczLLUov07RK4Mg7s7GQumKZYsfL+dJYG xj6pLkZODgkBE4kZa5exQ9hiEhfurWcDsYUEjjJK7OwP6mLkArKXM0o8fnsYLMEmoCPx/NE/ ZhBbRCBMYvPPlSxdjBwczAL6Evd/ioOEhQVcJXa/usUKUeImMedaFyOM/a1/HROIzSKgKtG4 9yhYDa+AqcT5GQeYIHZdYZT48XA1K8hMTgEricWTikFqGIFu+35qDVgvs4C4xK0n85kgbhaQ WLLnPDOELSrx8vE/sJmiAnoSzV1vGCHiihL7+qezQ/TqSdyYOoUNwraW6J3aBDVTW2LZwtfM EPcISpyc+YRlAqPELCTrZiFpn4WkfRaS9llI2hcwsq5i5CgtTi3LTTcy3MQIjL9jEmyOOxgX fLI8xCjAwajEw7tAY0awEGtiWXFl7iFGaQ4WJXHePdeqgoUE0hNLUrNTUwtSi+KLSnNSiw8x MnFwSjUw9pfZHdA1mPpDzvG08dSmjdvFOw73P6te1D5N7K6Nxe3r9VOyLd/0t1T9+XDHf69O y37tc7f97s+bu+Rk1i2fvM8zeqdapUy8d9j4dvdKPsYNhQrFHtIf1F4J3tpe/1Ex93Fawbsa veBX5t52OYLfY/wWTD71bGbD8m8hJ0S3h3P/i944NW9+pBJLcUaioRZzUXEiAGN7/Q6gAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/agWB9zOFVcezfPok-nGW9M-elu4 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:55:25 -0000 I was involved in this discussion and the statement was merely an attempt to capture the fact that the existing unicast IGP routing protocols would meet the homenet requirements with the addition of routing based on source-address. For example, while BGP would not be precluded, BGP=B9s rich routing policy is not viewed as being required in the homenet. Thanks, Acee=20 -----Original Message----- From: Juliusz Chroboczek Date: Thursday, June 12, 2014 at 7:34 AM To: Ted Lemon Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc >>> This sounds _way_ too specific to me. > >> If you are just going to laugh, > >Laugh with us, Ted -- it /is/ rather funny. > >(I especially liked the "linear sum" touch. What's a non-linear sum?) > >> This statement should be inclusive of whatever routing protocols the >> working group is inclined to consider, > >I'll do my best. There are at least four issues at hand. > >1. Not all routing protocols choose the lowest-metric route -- some > protocols include in their route selection criteria data that are not > encoded in the metric. Examples are BGP flap avoidance, or the > hysteresis algorithm used by Babel. One might argue that this is also > the case of multi-area OSPF (although it is not usually expressed in > that manner). > > For BGP and OSPF, you probably know more about the subject than I do. > For Babel, see Section 3.6 of RFC 6126 and Section III.E of > > http://arxiv.org/pdf/1403.3488 > > (As far as I know, there is currently no theoretical understanding of > this kind of techniques. As far as I've been able to work out, neither > Sobrinho's routing algebras nor Griffin's semigroups are able to >account > for them.) > > The Arch document MUST NOT specify what kind of data the route > selection algorithm is allowed to take as input. > > >2. Many protocols don't compute metrics as a "linear sum" of the link > costs; as a matter of fact, in many protocols the metric is not a mere > integer, but an element of a richer algebra. This is obviously the > case of BGP (see Griffin and Sobrinho, SIGCOMM 2005), but also of > Babel, which, when run over a radio link layer with interference > avoidance enabled, carries a pair of an integer and (roughly speaking) > a set of interfering radio frequencies. > > The Arch document MUST NOT specify the structure of the metric algebra. > It SHOULD NOT even imply that the metric being used is modelisable as > a routing algebra. > > >3. Finding a satisfactory and implementable metric for radio link layers > is very much an open research problem. Many routing protocols just > punt and expect the link layer to work like an Ethernet, which gets you > horrible performance in rich layer 3 topologies. Some mesh routing > protocols estimate unicast link rate and multicast packet loss and > combine the two using magic, which tends to choose unusable routes in > some cases. There has been a lot of noise around cross-layer > techniques for the last 10 years or so, but I don't know of > a production-quality implementation. (Yeah, I know, I should stop > complaining and try my hand at it.) > > Please do not underestimate the importance of this point for Homenet -- > how many wired and how many wireless links do you expect there to be in > a typical home ten years from now? > > The Arch document MUST NOT specify what kind of data the metric > computation algorithm is allowed to take as input. > > >4. There exist routing protocols that don't use the notion of a metric at > all. We metric-based people like to jestingly call them "longest-path > routing" algorithms, however we're still keeping an eye open to see if > anything useful comes out from that line of research. > > The Arch document SHOULD NOT even imply that a metric is being used. > > >Hope this helps, > >-- Juliusz > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Jun 12 08:08:43 2014 Return-Path: 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 54FB91A00D2 for ; Thu, 12 Jun 2014 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 4Cke3-Fyej-Q for ; Thu, 12 Jun 2014 08:08:28 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4341E1A0522 for ; Thu, 12 Jun 2014 08:08:28 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so3071092wib.9 for ; Thu, 12 Jun 2014 08:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=g5VsQgeJGvH9tzDi7FUvGP/enMvusDQG7rlqmzRz4zE=; b=RGM7ej9nk8G5DTCfmu9RED+sg1TuxmdBJFb4LGRPGi++U1LGlRyBPIrsKFdc5qEjZY wVLrkejbC0Hhv4/E+6gw8WiAmPS47BI6SB6CabuvXTvS2yOq4dsI2Pu3yWyPWlzOXUpb 908zBQKpTAgDuEjm7Tj0QOM8TNly1rU9V0iP55Rofj8owSoa83fvwYPA7EY7L9ln4N96 DIp9DpdFMflEmzbxeAMUhTHh8IOrWs0wbriCZPhpU5Fs7hAivZwHuBUsDDMAtIpN+NIo unRDnRE/6TEit1srm5IOb4Ek8EN/Te5zhskcpVjeEa5N1yO3jIj9DbSkF7W1+DYAIqqh wVBg== X-Gm-Message-State: ALoCoQkIJKOynTl970A6sk50uEKSAQXkbEh5gf3n2Y8DarcAOs0Liwho/N8mE+dXpdlL3o2Zlf5W X-Received: by 10.180.103.228 with SMTP id fz4mr7625534wib.4.1402585700113; Thu, 12 Jun 2014 08:08:20 -0700 (PDT) Received: from [100.70.147.106] (71.16.90.92.rev.sfr.net. [92.90.16.71]) by mx.google.com with ESMTPSA id gb6sm33914736wic.6.2014.06.12.08.08.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 08:08:19 -0700 (PDT) References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <877g4murgj.wl%jch@pps.univ-paris-diderot.fr> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <86222874-BF42-4D90-A9BB-F18FA7D7175A@townsley.net> X-Mailer: iPhone Mail (11D201) From: "Townsley.net" Date: Thu, 12 Jun 2014 17:08:14 +0200 To: Acee Lindem Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/WpuqkOQDH4KxOsJmXU1761dyDbE Cc: "homenet@ietf.org Group" , Ted Lemon , Juliusz Chroboczek Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:08:35 -0000 Thank you, Acee.=20 The very first sentence of section 3.5 contains a very strong statement abou= t using existing protocols. I don't see how expanding this section with deta= iled routing protocol requirements du jour helps to underscore that point. S= o, please, let's stop.=20 - Mark (Thumbtyped) > On Jun 12, 2014, at 4:55 PM, Acee Lindem wrote:= >=20 > I was involved in this discussion and the statement was merely an attempt > to capture the fact that the existing unicast IGP routing protocols would > meet the homenet requirements with the addition of routing based on > source-address. For example, while BGP would not be precluded, BGP=C2=B9s r= ich > routing policy is not viewed as being required in the homenet. > Thanks, > Acee=20 >=20 > -----Original Message----- > From: Juliusz Chroboczek > Date: Thursday, June 12, 2014 at 7:34 AM > To: Ted Lemon > Cc: "homenet@ietf.org Group" > Subject: Re: [homenet] Updates to Homenet Architecture Principles doc >=20 >>>> This sounds _way_ too specific to me. >>=20 >>> If you are just going to laugh, >>=20 >> Laugh with us, Ted -- it /is/ rather funny. >>=20 >> (I especially liked the "linear sum" touch. What's a non-linear sum?) >>=20 >>> This statement should be inclusive of whatever routing protocols the >>> working group is inclined to consider, >>=20 >> I'll do my best. There are at least four issues at hand. >>=20 >> 1. Not all routing protocols choose the lowest-metric route -- some >> protocols include in their route selection criteria data that are not >> encoded in the metric. Examples are BGP flap avoidance, or the >> hysteresis algorithm used by Babel. One might argue that this is also >> the case of multi-area OSPF (although it is not usually expressed in >> that manner). >>=20 >> For BGP and OSPF, you probably know more about the subject than I do. >> For Babel, see Section 3.6 of RFC 6126 and Section III.E of >>=20 >> http://arxiv.org/pdf/1403.3488 >>=20 >> (As far as I know, there is currently no theoretical understanding of >> this kind of techniques. As far as I've been able to work out, neither >> Sobrinho's routing algebras nor Griffin's semigroups are able to >> account >> for them.) >>=20 >> The Arch document MUST NOT specify what kind of data the route >> selection algorithm is allowed to take as input. >>=20 >>=20 >> 2. Many protocols don't compute metrics as a "linear sum" of the link >> costs; as a matter of fact, in many protocols the metric is not a mere >> integer, but an element of a richer algebra. This is obviously the >> case of BGP (see Griffin and Sobrinho, SIGCOMM 2005), but also of >> Babel, which, when run over a radio link layer with interference >> avoidance enabled, carries a pair of an integer and (roughly speaking) >> a set of interfering radio frequencies. >>=20 >> The Arch document MUST NOT specify the structure of the metric algebra. >> It SHOULD NOT even imply that the metric being used is modelisable as >> a routing algebra. >>=20 >>=20 >> 3. Finding a satisfactory and implementable metric for radio link layers >> is very much an open research problem. Many routing protocols just >> punt and expect the link layer to work like an Ethernet, which gets you >> horrible performance in rich layer 3 topologies. Some mesh routing >> protocols estimate unicast link rate and multicast packet loss and >> combine the two using magic, which tends to choose unusable routes in >> some cases. There has been a lot of noise around cross-layer >> techniques for the last 10 years or so, but I don't know of >> a production-quality implementation. (Yeah, I know, I should stop >> complaining and try my hand at it.) >>=20 >> Please do not underestimate the importance of this point for Homenet -- >> how many wired and how many wireless links do you expect there to be in >> a typical home ten years from now? >>=20 >> The Arch document MUST NOT specify what kind of data the metric >> computation algorithm is allowed to take as input. >>=20 >>=20 >> 4. There exist routing protocols that don't use the notion of a metric at= >> all. We metric-based people like to jestingly call them "longest-path >> routing" algorithms, however we're still keeping an eye open to see if >> anything useful comes out from that line of research. >>=20 >> The Arch document SHOULD NOT even imply that a metric is being used. >>=20 >>=20 >> Hope this helps, >>=20 >> -- Juliusz >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Jun 12 08:13:00 2014 Return-Path: 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 4BD5D1B2A70 for ; Thu, 12 Jun 2014 08:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Gv0iB4PhUDoX for ; Thu, 12 Jun 2014 08:12:53 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) (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 B862B1A00FA for ; Thu, 12 Jun 2014 08:12:53 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s5CFCrd4018204 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Jun 2014 08:12:53 -0700 Message-ID: <5399C375.3080301@mtcc.com> Date: Thu, 12 Jun 2014 08:12:53 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: homenet@ietf.org References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/aEBx3hXlQKtjXUOBUCMxtnxOCI0 Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:12:55 -0000 On 06/12/2014 07:54 AM, Townsley.net wrote: > I think for an arch document, we should talk generally about how a routing protocol could plug into the rest of the system, but stop short of details within the routing protocol itself. If routing experts are concerned the working group is going to go into bad territory with cost metrics, path calculation, etc. toying around with text here isn't the way to go about solving that. This is not a WG charter document, it's not even normative. > > Bottom line: I would much rather have routing experts on list rather than writing our documents for us one discuss at a time. > > That was my problem with other parts of the document: it was *way* too prescriptive about particular technologies. That is wrong for the kind of document. That should be hashed out with actual proposed answers to the architecture document. Mike From nobody Thu Jun 12 08:27:34 2014 Return-Path: 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 A409D1A00FA for ; Thu, 12 Jun 2014 08:27:32 -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 TnjgdcIZK2SD for ; Thu, 12 Jun 2014 08:27:31 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 075441B2A75 for ; Thu, 12 Jun 2014 08:27:31 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 301482381522; Thu, 12 Jun 2014 11:27:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <5399C375.3080301@mtcc.com> Date: Thu, 12 Jun 2014 11:27:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D2A349C-1759-4AFD-8EE7-958419C01B7A@fugue.com> References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> <5399C375.3080301@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/W_sI6gkf4xJtiTOoubs79X5cLns Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:27:32 -0000 On Jun 12, 2014, at 11:12 AM, Michael Thomas wrote: > That was my problem with other parts of the document: it was *way* too = prescriptive about particular > technologies. That is wrong for the kind of document. That should be = hashed out with actual proposed > answers to the architecture document. The architecture document was supposed to say what we were trying to = build. I think it does a pretty good job of that. "Existing routing protocols" covers a lot of protocols that I think we = clearly don't want to use. From nobody Thu Jun 12 08:32:13 2014 Return-Path: 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 1A18F1B2A70 for ; Thu, 12 Jun 2014 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Fn-pkYvjHJhF for ; Thu, 12 Jun 2014 08:32:09 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) (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 844201A0370 for ; Thu, 12 Jun 2014 08:32:09 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s5CFW7tF022110 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 08:32:08 -0700 Message-ID: <5399C7F7.9060307@mtcc.com> Date: Thu, 12 Jun 2014 08:32:07 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> <5399C375.3080301@mtcc.com> <3D2A349C-1759-4AFD-8EE7-958419C01B7A@fugue.com> In-Reply-To: <3D2A349C-1759-4AFD-8EE7-958419C01B7A@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0OyKszOOlvJw05qNxBebxHcQLbs Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:32:10 -0000 On 06/12/2014 08:27 AM, Ted Lemon wrote: > On Jun 12, 2014, at 11:12 AM, Michael Thomas wrote: >> That was my problem with other parts of the document: it was *way* too prescriptive about particular >> technologies. That is wrong for the kind of document. That should be hashed out with actual proposed >> answers to the architecture document. > The architecture document was supposed to say what we were trying to build. I think it does a pretty good job of that. > > "Existing routing protocols" covers a lot of protocols that I think we clearly don't want to use. > If they want to get involved in the fight about the thread count of the toilet bolts, there's a time and place for that. Mike From nobody Thu Jun 12 08:38:45 2014 Return-Path: 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 E4CA81A0127 for ; Thu, 12 Jun 2014 08:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 9t-IKlzn7TqW for ; Thu, 12 Jun 2014 08:38:43 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 1DC021A0113 for ; Thu, 12 Jun 2014 08:38:42 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5CFceL9003195; Thu, 12 Jun 2014 17:38:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 354FB29A7FC; Thu, 12 Jun 2014 17:22:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TdqinQKYEfYu; Thu, 12 Jun 2014 17:22:22 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0318029A7FA; Thu, 12 Jun 2014 17:22:21 +0200 (CEST) Date: Thu, 12 Jun 2014 17:22:49 +0200 Message-ID: <871tuuup86.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Acee Lindem In-Reply-To: References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <877g4murgj.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 12 Jun 2014 17:38:40 +0200 (CEST) X-Miltered: at korolev with ID 5399C980.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5399C980.005 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5399C980.005 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/AvPORHMoW04UD2fZhTt0MdLtDXE Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:38:44 -0000 > I was involved in this discussion I'm genuinely sorry to hear that, Acee. > the statement was merely an attempt to capture the fact that the > existing unicast IGP routing protocols would meet the homenet > requirements [...] while BGP would not be precluded, BGP's rich routing > policy is not viewed as being required in the homenet. Was it meant to preclude or discourage the following: * route selection involving hysteresis; * radio interference avoidance; * cross-layer metric computation techniques? If it wasn't, then somebody didn't do their homework. If it was, then somebody needs to drop by on this list to explain their position to us. -- Juliusz From nobody Thu Jun 12 09:34:16 2014 Return-Path: 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 BB9731B2AAE for ; Thu, 12 Jun 2014 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EQYL_lAEHZ2m for ; Thu, 12 Jun 2014 09:34:13 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F18E1B2AB1 for ; Thu, 12 Jun 2014 09:34:13 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-2f-539983375206 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.4D.11744.73389935; Thu, 12 Jun 2014 12:38:48 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 12:34:10 -0400 From: Acee Lindem To: Juliusz Chroboczek Thread-Topic: [homenet] Updates to Homenet Architecture Principles doc Thread-Index: AQHPhjiqxmfdZx62jkq0PP0j0HRd45ttrt0AgAAFU4CAABlKAP//kGsAgAB9DoD//56UAA== Date: Thu, 12 Jun 2014 16:34:10 +0000 Message-ID: References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <877g4murgj.wl%jch@pps.univ-paris-diderot.fr> <871tuuup86.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <871tuuup86.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonXNeieWawwdMmbov3iw6xWHz+9I/V gcljyZKfTB4Xd79jDGCK4rJJSc3JLEst0rdL4Mr4sek1U8FnrorfK/MbGD9ydDFyckgImEhc WfqHFcIWk7hwbz1bFyMXh5DAUUaJ3rsX2UASQgLLGSUatkuB2GwCOhLPH/1jBrFFBMwk5vU8 Z+xi5OBgFtCXuP9THCQsLOAqsfvVLVaIEjeJOde6wEpEBMIkPjUIgIRZBFQlvjfOYAexeQVM JS79nsoOsXYDk8SkOZfYQeo5Bawknn5TB6lhBDrt+6k1TCA2s4C4xK0n85kgThaQWLLnPDOE LSrx8vE/sLWiAnoSzV1vGCHiShKTlp5jhejVkViw+xMbhG0t0bjiLJStLbFs4WtmiHsEJU7O fMIygVFiFpJ1s5C0z0LSPgtJ+ywk7QsYWVcxcpQWp5blphsZbmIExtkxCTbHHYwLPlkeYhTg YFTi4V2gMSNYiDWxrLgy9xCjNAeLkjjvnmtVwUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY axonrv52NelGJh9LpSTzZ36/XrtdB6dnfJuj3fLG60PZ52yRrOq6Yg+r3Y2hbFFq945teyM2 z+X4u4MGp89u5vToTVv57DLXjNZkd3bOyea5JzdsUvVRmHiSW2Ei60EVD50/Oy9sPdJ6uOnX RgPnluS/+eo19xWVJ2UaXmxS57bgXpKttvC2EktxRqKhFnNRcSIAfvmfpZQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3N-lWhYrvuMruXG3fXkq5pdiyws Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:34:14 -0000 -----Original Message----- From: Juliusz Chroboczek Date: Thursday, June 12, 2014 at 8:22 AM To: Ericsson Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc >> I was involved in this discussion > >I'm genuinely sorry to hear that, Acee. Comments, debate, and discussion are a normal part of the IETF process. > >> the statement was merely an attempt to capture the fact that the >> existing unicast IGP routing protocols would meet the homenet >> requirements [...] while BGP would not be precluded, BGP's rich routing >> policy is not viewed as being required in the homenet. > >Was it meant to preclude or discourage the following: > > * route selection involving hysteresis; > * radio interference avoidance; > * cross-layer metric computation techniques? > >If it wasn't, then somebody didn't do their homework. If it was, then >somebody needs to drop by on this list to explain their position to us. As I stated above, it was not meant to preclude additional capabilities and I agree with the chairs that the document is fine without it. Thanks, Acee > >-- Juliusz > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Jun 12 11:44:03 2014 Return-Path: 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 CCB091A0236; Thu, 12 Jun 2014 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Yx_yEjjRZjHL; Thu, 12 Jun 2014 11:43:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E86081B2AEB; Thu, 12 Jun 2014 11:43:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140612184351.6700.10752.idtracker@ietfa.amsl.com> Date: Thu, 12 Jun 2014 11:43:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/DsiRIYESv8ERs-IIZIdNVQprXxA Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-16.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:44:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : IPv6 Home Networking Architecture Principles Authors : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-16.txt Pages : 53 Date : 2014-06-12 Abstract: This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 12 14:21:08 2014 Return-Path: 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 296AE1B2815 for ; Thu, 12 Jun 2014 14:21:06 -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 nvF74aj439Zu for ; Thu, 12 Jun 2014 14:21:04 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D13041B2814 for ; Thu, 12 Jun 2014 14:21:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 88EED871519; Thu, 12 Jun 2014 23:21:02 +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 c7hi+gS08ZKw; Thu, 12 Jun 2014 23:21:02 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:28ee:e319:aeae:2bce]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 3F181870056; Thu, 12 Jun 2014 23:21:02 +0200 (CEST) Message-ID: <539A19AE.2080605@globis.net> Date: Thu, 12 Jun 2014 23:20:46 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ray Bellis References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/C0cUVwRrnkeFw78Qf4Dc3a0cInA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:21:06 -0000 Here's my 2c worth on Section 3.5 I'm on record as preferring a "common Homenet routing protocol" without having any fingers in any particular choice. I believe there is rough consensus around the choice of 0 or 1 routing protocol. Going through Section 3.5 line by line. > 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. Fine by me. > > 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. 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. > > Fine by me. Apart from the use of the word "graph" which could be overloaded or suggest a preference for link state protocols. s/graph/consistent view/ ? > > > 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 is thus > desirable, to avoid upstream ISP BCP 38 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. Fine be me. > > Routing within the homenet will determine the least cost path across > the homenet towards the destination address given the source address. Too explicit IMHO. What is wrong with s/determine the least cost path across the homenet towards the destination address given the source address /maintain a loop free forwarding path between any given source address and destination pair/ > The path cost will be computed as a linear sum of the metric assigned > to each link. Way too explicit IMHO. EIGRP is a perfectly good routing protocol that would be excluded by this requirement as the routing metric is a non linear sum of different individual link metrics, including minimum path bandwidth. Not that I'm urging use of EIGRP, but I don't see why it should be excluded on these grounds alone. > 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. > It's a may so fine by me. > Multiple types of physical interfaces must be accounted for in the > homenet routed topology. Fine be me. > 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. Fine be me. > The inclusion of physical layer > characteristics including bandwidth, loss, and latency in path > computation should be considered for optimising communication in the > homenet. > Fine be me. > The routing environment should be self-configuring, as discussed > previously. Minimising convergence time should be a goal in any > routed environment, Fine by me. > 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). > Way too explicit IMHO. I don't see why a figure of 30 seconds for convergence time is even given. I'm not happy to wait 30 seconds for video distribution over Homenet. Surely acceptable convergence time is a function of user expectations relative to the nature of the traffic being carried by the Homenet, combined with the available buffering before the user becomes aware of any topology change. > 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. > Fine be me. But is totally inconsistent with the sentence above to always choose the shortest path. The "shortest path" may not be "the best" for all traffic. Again look at the concept behind EIGRP metrics, where high bandwidth traffic might be routed over a different route to latency sensitive traffic. > At most one routing protocol should be in use at a given time in a > given homenet. Definitely agree. > In some simple topologies, no routing protocol may be > needed. Consistent with the 0 or 1 consensus. > 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. > > Fine be me. I'd rather just chose one, but this appears to me like trying to get a group consisting of more than one economist to agree on anything. > > > 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. > Fine be me. > 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. > Fine be me. It might be worth adding that we do not expect LLN network to act as transit networks between more traditional areas of the Homenet if you are going to revise the text anyway. Ray Bellis wrote: > > Dear Working Group, > > You may have noticed multiple revisions of draft-ietf-homenet-arch > posted recently. After many iterations and a ton of work for our > Editor In Chief, Tim Chown, all IESG “DISCUSS” positions have been > resolved to either “Yes” or “No Objection”, with the exception of one > “Abstain” from one of our Routing Area ADs who had requested that the > following text be added to section 3.5: > > “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 Chairs felt that the first half of this text was unnecessarily > prescriptive for this document and did not reflect something the WG > had achieved consensus on at this time. We proposed a compromise that > incorporated the latter non-normative half of this text in an earlier > paragraph. On the basis that we understood that this compromise had > been accepted by the respective AD, the -14 revision was posted. > > After -14 was posted and the AD’s position changed to "No Objection", > we noticed that the above paragraph had inadvertently been included, > in full, in addition to the latter half included as part of the > proposed compromise! At the Chairs’ request, Tim removed the above > paragraph in -15, which caused the AD to object as it appeared to him > that his text was being removed after the fact. > > Later today, Tim will be posting a -16 revision of the document that > reinstates the above paragraph, in full, and removes the “compromise” > text. On the basis that the new text is a potentially substantive > change, our AD has requested that we put the document through one more > Working Group Last Call to determine WG consensus on that issue. > > In addition, one small change was introduced in the -15 revision based > on WG feedback where a reference to Source Specific Multicast [RFC > 4607] was introduced, but had not been called out explicitly in London > or before. That change is as follows: > > Old: > It is desirable that, subject to the capacities of devices on certain > media types, multicast routing is supported across the homenet. > > New: > It is desirable that, subject to the capacities of devices on certain > media types, multicast routing is supported across the homenet, > including source-specific multicast (SSM) [RFC4607]. > > The WGLC will commence immediately after the -16 is posted, and will > last for two weeks. > > We very much want your feedback here, but are not aiming to revisit > the document in its entirety. As such, we would like to limit the > scope of the WGLC to just the text quoted in this email. > > Many thanks, > > Ray and Mark > -- Regards, RayH From nobody Thu Jun 12 14:56:07 2014 Return-Path: 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 5C1C11A02BC for ; Thu, 12 Jun 2014 14:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 JYOSgIsJukOJ for ; Thu, 12 Jun 2014 14:55:56 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 955281A0095 for ; Thu, 12 Jun 2014 14:55:55 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5CLtqQo017811; Thu, 12 Jun 2014 23:55:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BB8D129A7CF; Thu, 12 Jun 2014 23:55:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id aj2B46VOXR3d; Thu, 12 Jun 2014 23:55:51 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 367A429A7C9; Thu, 12 Jun 2014 23:55:51 +0200 (CEST) Date: Thu, 12 Jun 2014 23:56:18 +0200 Message-ID: <87wqclssfx.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <539A19AE.2080605@globis.net> References: <539A19AE.2080605@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 12 Jun 2014 23:55:52 +0200 (CEST) X-Miltered: at korolev with ID 539A21E8.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 539A21E8.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 539A21E8.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/N8h2OCfSb8AIDLBEbuFNIN2iVxA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:55:59 -0000 >> 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. > Fine by me. Apart from the use of the word "graph" which could be > overloaded or suggest a preference for link state > protocols. s/graph/consistent view/ ? I've already mentioned before that I'd just remove this whole sentence. The goal of a routing protocol is to provide routes that are useful for forwarding user traffic. Whether it does that by building "a graph", "a consistent view" or through haruspicy is pretty much an implementation detail. >> Routing within the homenet will determine the least cost path across >> the homenet towards the destination address given the source address. > Too explicit IMHO. Multiple problems: inconsistent terminology (cost/metric), assumes the existence of a metric, assumes that the protocol always chooses least metric paths. Just remove this sentence and be done with it. > What is wrong with s/determine the least cost path across the homenet > towards the destination address given the source address /maintain > a loop free forwarding path between any given source address and > destination pair/ Since we're being picky, this might be understood as excluding OSPF and RIP, which may cause transient routing loops. (Exceedingly short-lived in any half-decent implementation of OSFP, granted.) >> Multiple types of physical interfaces must be accounted for in the >> homenet routed topology. > Fine be me. I think I may have already mentioned that I'm really not sure what this sentence means. Does it mean that the routing protocol must be able to automatically distinguish between wired and wireless links? Have different route selection/metric computation strategies depending on the link layer? On either count, only Babel qualifies, which I'm pretty sure is not what is intended. >> but as a guideline a maximum convergence time at most 30 seconds should >> be the target > Way too explicit IMHO. I don't see why a figure of 30 seconds for > convergence time is even given. Heh. If memory serves, RIP(ng) with triggered updates converges in exactly 30 seconds, worst case. (Snipped the part about border discovery, which I'm not competent to comment on.) > It might be worth adding that we do not expect LLN network to act as > transit networks between more traditional areas of the Homenet if you > are going to revise the text anyway. Hmm... I'm pretty certain that people will use degenerate mesh networks for transit once they realise it's a neat way to avoid laying wiring between your home and the shack at the back of the garden. Not sure about LLNs, but I'd be nervous about including such language. -- Juliusz From nobody Thu Jun 12 14:59:49 2014 Return-Path: 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 59A651A0276 for ; Thu, 12 Jun 2014 14:59:47 -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 5TdrTZgUCKhO for ; Thu, 12 Jun 2014 14:59:46 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4EE1A0095 for ; Thu, 12 Jun 2014 14:59:46 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 0CB0C2381522; Thu, 12 Jun 2014 17:59:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <87wqclssfx.wl%jch@pps.univ-paris-diderot.fr> Date: Thu, 12 Jun 2014 17:59:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6607014A-246F-4476-BF08-468C6FBC34E2@fugue.com> References: <539A19AE.2080605@globis.net> <87wqclssfx.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JrYuc5pnsLq_WPJGMWPpiOmO0gA Cc: Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:59:47 -0000 On Jun 12, 2014, at 5:56 PM, Juliusz Chroboczek = wrote: > I've already mentioned before that I'd just remove this whole = sentence. I agree. But what is the routing supposed to accomplish? Rapid convergence has = been mentioned. Load sharing? Path redundancy? I've heard some = good suggestions about this section. I wonder if convergence is = possible for the text, as opposed to the routes... :) From nobody Thu Jun 12 15:04:55 2014 Return-Path: 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 423DB1A00A9 for ; Thu, 12 Jun 2014 15:04:50 -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 oE2xKdceiFTh for ; Thu, 12 Jun 2014 15:04:48 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C99B31A0095 for ; Thu, 12 Jun 2014 15:04:48 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id CC1F423824DE; Thu, 12 Jun 2014 18:04:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <87wqclssfx.wl%jch@pps.univ-paris-diderot.fr> Date: Thu, 12 Jun 2014 18:04:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <539A19AE.2080605@globis.net> <87wqclssfx.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yCxUa_Iwxtoufm67Cd1-9xf8YFs Cc: Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:04:51 -0000 On Jun 12, 2014, at 5:56 PM, Juliusz Chroboczek = wrote: > Hmm... I'm pretty certain that people will use degenerate mesh = networks > for transit once they realise it's a neat way to avoid laying wiring > between your home and the shack at the back of the garden. Not sure = about > LLNs, but I'd be nervous about including such language. The point of excluding LLNs is that the text purports to cover routers = in the home, and LLNs are routers in the home. To force LLN routers to = provide all the functionality that we are proposing homenet routers will = provide would be overly burdensome. So LLNs are customers of whatever = connectivity the homenet routers provide, and are not themselves homenet = routers. Does that make sense? Does the text need to be clarified? From nobody Thu Jun 12 15:19:30 2014 Return-Path: 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 664531A02C4 for ; Thu, 12 Jun 2014 15:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 RFeK0LoHG42o for ; Thu, 12 Jun 2014 15:19:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 69AAE1A02BC for ; Thu, 12 Jun 2014 15:19:27 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5CMJMeu024136; Fri, 13 Jun 2014 00:19:22 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B166E2A8694; Fri, 13 Jun 2014 00:19:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VU_2uyFH36aW; Fri, 13 Jun 2014 00:19:21 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1A6622A866F; Fri, 13 Jun 2014 00:19:21 +0200 (CEST) Date: Fri, 13 Jun 2014 00:19:48 +0200 Message-ID: <87ppidsrcr.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <6607014A-246F-4476-BF08-468C6FBC34E2@fugue.com> References: <539A19AE.2080605@globis.net> <87wqclssfx.wl%jch@pps.univ-paris-diderot.fr> <6607014A-246F-4476-BF08-468C6FBC34E2@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 13 Jun 2014 00:19:22 +0200 (CEST) X-Miltered: at korolev with ID 539A276A.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 539A276A.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 539A276A.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/hePtf0Edve6o_b4Ee3fbPcWrGjg Cc: Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:19:28 -0000 > But what is the routing supposed to accomplish? Good point. The role of the routing protocol is to provide good enough end-to-end connectivity often enough, where good/often enough is defined by user expectations. > Rapid convergence has been mentioned. That's an implementation technique for achieving "often enough". (OSPF converges extremely fast, but doesn't offer any guarantees about what happens before convergence. Babel converges slower, but is usually able to route packets correctly before it converges: Babel uses a different implementation technique to achieve "often enough".) > Load sharing? That's an implementation technique for achieving "good enough". > Path redundancy? That's an implementation technique for achieving "often enough". I would suggest that the problems we've been having with the Arch document are due to describing implementation techniques rather than the expected result. -- Juliusz From nobody Thu Jun 12 15:24:15 2014 Return-Path: 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 957361A02A2 for ; Thu, 12 Jun 2014 15:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 8xDikPc_zguH for ; Thu, 12 Jun 2014 15:24:07 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 346041A0271 for ; Thu, 12 Jun 2014 15:24:06 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5CMO21i025202; Fri, 13 Jun 2014 00:24:02 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 339B92CC3C8; Fri, 13 Jun 2014 00:24:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id h0cv-jZ-M_P9; Fri, 13 Jun 2014 00:24:00 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A98732CC156; Fri, 13 Jun 2014 00:24:00 +0200 (CEST) Date: Fri, 13 Jun 2014 00:24:28 +0200 Message-ID: <87oaxxsr4z.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: References: <539A19AE.2080605@globis.net> <87wqclssfx.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 13 Jun 2014 00:24:02 +0200 (CEST) X-Miltered: at korolev with ID 539A2882.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 539A2882.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 539A2882.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/FRAqvrv3B7je1G80f63S1kUh8lA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:24:09 -0000 > So LLNs are customers of whatever connectivity the homenet routers > provide, and are not themselves homenet routers. Ah, I see. This does not preclude an LLN router from implementing support for Homenet, just makes it explicit that Homenet makes no such requirement on LLN routers, and makes no concessions to using unmodified LLN routers for transit. Sure. -- Juliusz From nobody Thu Jun 12 15:44:35 2014 Return-Path: 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 8A5391A02E8 for ; Thu, 12 Jun 2014 15:44:32 -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 9QDeIqNkmgdB for ; Thu, 12 Jun 2014 15:44:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87CE1A02BE for ; Thu, 12 Jun 2014 15:44:30 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 83E892002A; Thu, 12 Jun 2014 18:48:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 87F2763B0E; Thu, 12 Jun 2014 18:44:19 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7034A63B0B; Thu, 12 Jun 2014 18:44:19 -0400 (EDT) From: Michael Richardson To: Ray Bellis In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/NoggTWLivZI3lndG_4ieed1Bewk Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:44:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ray Bellis wrote: > You may have noticed multiple revisions of draft-ietf-homenet-arch po= sted > recently. After many iterations and a ton of work for our Editor In C= hief, Tim > Chown, all IESG =E2=80=9CDISCUSS=E2=80=9D positions have been resolve= d to either =E2=80=9CYes=E2=80=9D or =E2=80=9CNo > Objection=E2=80=9D, with the exception of one =E2=80=9CAbstain=E2=80= =9D from one of our Routing Area > ADs who had requested that the following text be added to section 3.5: wow... > The Chairs felt that the first half of this text was unnecessarily pr= escriptive > for this document and did not reflect something the WG had achieved c= onsensus I agree. > In addition, one small change was introduced in the -15 revision base= d on WG > feedback where a reference to Source Specific Multicast [RFC 4607] was > introduced, but had not been called out explicitly in London or befor= e. That > change is as follows: > Old: > It is desirable that, subject to the capacities of devices on certain > media types, multicast routing is supported across the homenet. > New: > It is desirable that, subject to the capacities of devices on certain > media types, multicast routing is supported across the homenet, > including source-specific multicast (SSM) [RFC4607]. > The WGLC will commence immediately after the -16 is posted, and will = last for > two weeks. > We very much want your feedback here, but are not aiming to revisit t= he > document in its entirety. As such, we would like to limit the scope o= f the WGLC > to just the text quoted in this email. I will attempt to read the diffs; but... It Just Doesn't Matter better is the enemy of good enough, and it was good enough a year ago. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU5otQICLcPvd0N1lAQJNWAgAsfR+KWrKpPpAr8wak8NFtq3Nu9bMy+ra TlRa8vqudAd0sTibbNsSBcX71/nJBYbGOJHJVm7GAaygIwCXw+dGen+Uk0lbOZGN leiBACNjXr0R3upSOOqp2J0XyZtTZH52gVT16oQxs9b/cWbsoLjbwRL4d3fPPh1M ayDzue4QgfYiMz2F0wdI1FFK3XJ70aWPLJqQYvJMOb7SWrf87l424NpuvQXtZunU zGvW8Lzffgh4Wzn1a2FLOFEUQV2+zJcYH8F78kcYNM7ZC7VLzRgDPMwHA8//3r2n V0bZtu2V3nxgliCWOOG19XqL3mnH0ca8zCT3bPvj6HVPEBxhmzNePw== =y+Yp -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 12 15:46:37 2014 Return-Path: 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 A8CDA1A02E8 for ; Thu, 12 Jun 2014 15:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 TBwU3ZBklalR for ; Thu, 12 Jun 2014 15:46:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9646C1A02BE for ; Thu, 12 Jun 2014 15:46:33 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9934C2002A; Thu, 12 Jun 2014 18:50:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D346363B0E; Thu, 12 Jun 2014 18:46:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BB2DD63B0B; Thu, 12 Jun 2014 18:46:32 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/SNTH-gdC6nt-AWn2_i2Vj9VE5xY Cc: Ray Bellis , "homenet@ietf.org Group" , Markus Stenberg Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:46:34 -0000 --=-=-= Ted Lemon wrote: > Both of the routing ADs complained about the text in this section. I > do not actually clearly understand their complaints, but after > discussing it with Alia (who did not raise a DISCUSS, but was happy to > talk with me about it) and with Adrian (who really feels quite > discouraged about the whole conversation), the understanding I came > away with was that they felt that the document as written was quite > open-ended and left available the possibility of doing some things that > are Not A Good Idea. Perhaps the actual fears could be made more explicit. What is it that they are worried homenet might do? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU5otxoCLcPvd0N1lAQICFAf/SKMshpTYYoBHSSVIDtuwxieCJhJa23ge wG9QGXCHVYCpLbK9kPL1v4kW1xSwWNMckBfdcI5PrQn7pVOOm1TJimceSC6qdIKV ucQdlUY/GsDAvCsZkfF481MXYlgJCmj3mfaA8p2OMNrg8nSypctNW88tonLETFFK ZlINy92GjWVe/fUgmTJTBFyYlYT8adLJjRD/U9yqpf8NoRl/UMovGFLiSYwepRyK szlQse9sD4g/tkVM8I19XPmaJHsOD6bzysABly7kj/gK0BlGXycm6MTAeYn4xVYE sCWTXlaNvsR6JwzX4AjE8yb0UUuI4OiNp1y4BUfxE+JSTLibtcnOxA== =Z0d5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 12 18:21:29 2014 Return-Path: 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 C36941B27C5 for ; Thu, 12 Jun 2014 18:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 RIUIP9uLocla for ; Thu, 12 Jun 2014 18:21:27 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E75E1A0640 for ; Thu, 12 Jun 2014 18:21:27 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id ft15so1540309pdb.11 for ; Thu, 12 Jun 2014 18:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=1ChKJ8S2JwOR0KVf73yzdHXv6RBrZdMmVHIWqV8Lt68=; b=lBf3CIgpmXXLju7wqT45jSeDQIjBtLbO06kwiizqDXrwqppJCbDSnoNn2peHBbNQnx nCJeWFVPe+48ho8UYOnQTSfOy9WrreldXM0vL6Pn5Jwa4Fyc9asY95AqEvfnTxnnn+b6 dVdr/9wY3goyNWmdIoAYztdv3qBdNkkyOMEONLpJgluGPMlaqNexPMQPJ6h9h0SbC0Jt 2PKocKYd2PUS7xT35uceZ3ETgZZhJd818dkykbTl86xgSSBb0NAvfEJDocS9NFcN7a9w aB2oRKtJwF0Y48l3agQCj3qX4vb44DN/pWzyQy6VhnvqfUulHnmmu557DRoFwjmcV3FZ OXTg== X-Received: by 10.66.176.196 with SMTP id ck4mr25870776pac.154.1402622486898; Thu, 12 Jun 2014 18:21:26 -0700 (PDT) Received: from [192.168.178.23] (148.200.69.111.dynamic.snap.net.nz. [111.69.200.148]) by mx.google.com with ESMTPSA id ao4sm376332pbc.51.2014.06.12.18.21.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 18:21:26 -0700 (PDT) Message-ID: <539A521E.9000907@gmail.com> Date: Fri, 13 Jun 2014 13:21:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/DvUVAC3f2bCg7UmVyBIgccVQfhg Subject: [homenet] Anima X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 01:21:29 -0000 Hi, Anima stands for Autonomic Networking Integrated Model and Approach, and the Anima mailing list was just created: List address: anima@ietf.org Archive: http://www.ietf.org/mail-archive/web/anima/ To subscribe: https://www.ietf.org/mailman/listinfo/anima Although the proponents have no desire to compete with HNCP, home networks are a very interesting use case for autonomic networking. The corresponding BOF has just been approved for Toronto: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90 Please look at the BOF proposal, the drafts mentioned below, and join the Anima discussion. Brian -------- Original Message -------- Subject: Reading list Date: Fri, 13 Jun 2014 08:45:35 +1200 From: Brian E Carpenter Organization: University of Auckland To: anima@ietf.org Hi, The very basic reading list for anima is: http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions =E2=80=8Bhttp://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis Our most urgent task before the BOF is to bring those drafts up to date, so please review them as soon as possible. Although they are NMRG drafts, we can discuss them here. We have only about 3 weeks until the I-D cutoff (2014-07-04). The other drafts considered relevant are in the BOF description: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90 Brian --=20 Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 From nobody Thu Jun 12 18:34:33 2014 Return-Path: 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 3B7BA1B2814 for ; Thu, 12 Jun 2014 18:34:32 -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 opMgiRg7IqvB for ; Thu, 12 Jun 2014 18:34:31 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEAD1B280D for ; Thu, 12 Jun 2014 18:34:31 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id EE4502381522; Thu, 12 Jun 2014 21:34:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <1570.1402613192@sandelman.ca> Date: Thu, 12 Jun 2014 21:34:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B1C7AA-6909-4557-88C4-D064C9229BDA@fugue.com> <56D4CB23-DC44-4B55-ACED-68D6F3D43A26@fugue.com> <1570.1402613192@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/o18wZwO_G12M3_QuKSnMf7oEKwk Cc: Ray Bellis , "homenet@ietf.org Group" , Markus Stenberg Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 01:34:32 -0000 On Jun 12, 2014, at 6:46 PM, Michael Richardson = wrote: > What is it that they are worried homenet might do? Heck if I know. From nobody Thu Jun 12 21:29:40 2014 Return-Path: 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 07BD51A0552 for ; Thu, 12 Jun 2014 21:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 VfvuWUBKQyTW for ; Thu, 12 Jun 2014 21:29:38 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DC61B28A1 for ; Thu, 12 Jun 2014 21:29:38 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id z10so228268pdj.29 for ; Thu, 12 Jun 2014 21:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jahFb2XEGb5yGrC1ZAxC9h4hFbUR5RDpeLWqR97zZS4=; b=rGRay0Rc3jXqLgSEzynTynxFkW7kTNCXbmGT7vVEZ3ny97EY0vKQFGE/41xQsrUOXN EYRnqgvsrU4S/fO/PBBQTqI7HLoq63zvDNj+LZe4GYx8ajgcxKBZDE6BZo42nUE2tl74 2pZztcGvC3E7Mqf0bgSx+BH7061NJkiL6eKuIgwyxFPp7GnxCRKMhYpt4BxtMMBtPe8H C6Ttmo/hGpAnvH64KVUcX+VlvpmJkU0/Ze/zEZmsR+tNEkWd0R8m+SgbubgZMdIvRPH+ E2nr+9H/9aTnABseMH7+W8JzcgAkwoxq5Os7omKsJXK2hi8WhPYZu7Kd0TX1j9R9wbUm SNWQ== X-Received: by 10.68.134.101 with SMTP id pj5mr376793pbb.62.1402633778467; Thu, 12 Jun 2014 21:29:38 -0700 (PDT) Received: from [192.168.178.23] (148.200.69.111.dynamic.snap.net.nz. [111.69.200.148]) by mx.google.com with ESMTPSA id bz4sm1001164pbb.12.2014.06.12.21.29.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 21:29:37 -0700 (PDT) Message-ID: <539A7E3A.400@gmail.com> Date: Fri, 13 Jun 2014 16:29:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "homenet@ietf.org Group" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LLFhfuI-XaQtnALGgBOeEEkM2O4 Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:29:40 -0000 Catching up on this thread (message times are based on NZST, UTC+12): On 13/06/2014 00:45, Markus Stenberg wrote: > This sounds _way_ too specific to me. I agree. Discussion of adding metrics together, although it seems like Routing 101, just seems out of place. On 13/06/2014 01:59, Ted Lemon wrote: > the understanding I came away with was that they felt that the > document as written was quite open-ended and left available the > possibility of doing some things that are Not A Good Idea. That would be a very valid criticism of WG charter goals. I am not at all convinced that it's a valid criticism of an Informational architecture document. On 13/06/2014 02:34, Juliusz Chroboczek wrote: > The Arch document MUST NOT specify what kind of data the metric > computation algorithm is allowed to take as input. and, I think gave authoritative reasons for that assertion. Basically, we shouldn't squeeze these very complex arguments into a general document. On 13/06/2014 02:55, Acee Lindem wrote: > I was involved in this discussion and the statement was merely an attempt > to capture the fact that the existing unicast IGP routing protocols would > meet the homenet requirements with the addition of routing based on > source-address. That's a very fair statement, but that isn't at all what the new paragraph says. On 13/06/2014 03:27, Ted Lemon wrote: > "Existing routing protocols" covers a lot of protocols that I think > we clearly don't want to use. Yes, but that's very different from defining a rigid approach to metrics. On 13/06/2014 09:20, Ray Hunter wrote: > Apart from the use of the word "graph" which could be overloaded > or suggest a preference for link state protocols. Why? It's the term of art for both Bellman-Ford and Dijkstra algorithms. Brian From nobody Thu Jun 12 23:26:51 2014 Return-Path: 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 34DE01B28D8 for ; Thu, 12 Jun 2014 23:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 0zIYCGKUsxNY for ; Thu, 12 Jun 2014 23:26:47 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73861A0384 for ; Thu, 12 Jun 2014 23:26:47 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so2086628iec.35 for ; Thu, 12 Jun 2014 23:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D2kt3KaRPF+zS2nqBWsrAHbe3ED2kP1/Zw2V/RJLBoc=; b=KIOq8bvEg4R6grNWVaGxQnt+sxS9bKCbxwFml++WGATACX59LS8vIvDuNyqfgc1jKV 1x2NBEvHtJmk6drP4ip2DoGN/KqFV1/AmQ7MzN3B36Cc+9+6HI90ulTksV1NO9Y7BVZg HuPLwpjb+2nuCVPVI9EogCpzaeBVL7/WSn0egDFC1IU2rcIffAiC4URYjyfOy1v8WvQO qC49gq687qNYSnZROzninqeNm1JGOlSG0yA8zODJL83TS9CwavaiAEZFZINaQYe4/8I8 Cc0vi2sxHkUb+E1HjAHGHXGDX5yWfKiI1EVz0p9nbsjzoPKbtYgkdx3UtFJqcrJMQTyq kbwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=D2kt3KaRPF+zS2nqBWsrAHbe3ED2kP1/Zw2V/RJLBoc=; b=beM1bAIP9fKl1xUD83OhxtGtBHS4lbbOd5DKHkITS+PSiF5U4Axwm2SDcWRr7APyiR dqDZgkiMNGfavMc1lxkif6cj9xTeE99w2ALjXaJi1oM9JvSkKXQLKVGZdyLuA9+rssk5 o3gZwvig99Zn01j2LK05y4rwzKNZWIGmlIf+AEIQXcOyofcbDyVESCTjfAK0m7MSOwFa wPY74ofDacqAbDUC0fVkNxW2k3/Uh+OBFIKpHnzwHqPWpkwK63HgQnqMCXAk4s+UgIsd 7hI5p5tqMGnBNyOSrTzCI9LxCrAnXJX5//8Bne85TVipf3/6SCT9f3dBLWSkVlje2ZmY 9j8A== X-Gm-Message-State: ALoCoQnsRUiaSU3qe5pb/VUS/flbPLW5lCPz5tawtF+MwbPih/BhW0Vu0SG15TIXnhfrtoaGSoan X-Received: by 10.43.179.73 with SMTP id oz9mr958728icc.18.1402640807086; Thu, 12 Jun 2014 23:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Thu, 12 Jun 2014 23:26:26 -0700 (PDT) In-Reply-To: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> From: Lorenzo Colitti Date: Fri, 13 Jun 2014 15:26:26 +0900 Message-ID: To: Ray Bellis Content-Type: multipart/alternative; boundary=001a11c3146c0debef04fbb1c3f1 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/K9jN7Oy9QauyBBtD89FKfnm_l-Q Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 06:26:49 -0000 --001a11c3146c0debef04fbb1c3f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2014 at 9:56 PM, Ray Bellis wrote: > 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.=E2=80=9D > I agree that this text is needlessly - no, harfmully - prescriptive. Premature overspecification is a design mistake of the worst kind, and specifying the implementation details of the routing protocol in an architecture document is silly. The IESG should know better. I vote for removing the text and returning the draft to the IESG as WG consensus, and if the IESG is not happy with that, then ask them to explain clearly what it is that they are worried about. --001a11c3146c0debef04fbb1c3f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 12, 2014 at 9:56 PM, Ray Bellis <Ray.Bellis@nominet.org.uk= > wrote:
<= div style=3D"word-wrap:break-word">
=C2=A0The path cost will be com= puted as a linear sum of the metric assigned
=C2=A0to each link. =C2=A0The metric may be configured or automat= ically derived
=C2=A0per link based on consideration of factors such as worst-ca= se queue
=C2=A0depth and router processing capabilities.=E2=80=9D
<= div class=3D"gmail_extra">
I agree that= this text is needlessly - no, harfmully - prescriptive. Premature overspec= ification is a design mistake of the worst kind, and specifying the impleme= ntation details of the routing protocol in an architecture document is sill= y. The IESG should know better.

I vote for = removing the text and returning the draft to the IESG as WG consensus, and = if the IESG is not happy with that, then ask them to explain clearly what i= t is that they are worried about.
--001a11c3146c0debef04fbb1c3f1-- From nobody Fri Jun 13 04:40:12 2014 Return-Path: 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 D12C81B2841 for ; Fri, 13 Jun 2014 04:40:08 -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 S5yZlxvw2VyO for ; Fri, 13 Jun 2014 04:40:06 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D4C601A0340 for ; Fri, 13 Jun 2014 04:40:06 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 4A64923824E2; Fri, 13 Jun 2014 07:40:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Fri, 13 Jun 2014 07:40:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dP9gbuzmWCmxKDD2uQmOkzaHZGs Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 11:40:08 -0000 On Jun 13, 2014, at 2:26 AM, Lorenzo Colitti wrote: > I vote for removing the text and returning the draft to the IESG as WG = consensus, and if the IESG is not happy with that, then ask them to = explain clearly what it is that they are worried about. People have already made suggestions for how to fix the text, which I = would like implemented. "The IESG" isn't asking for a change. Adrian = has been trying to negotiate a change for several months, and that = resulted in some text that was reluctantly agreed to, but that the = chairs felt didn't reflect the working group consensus, which appears to = have been a correct evaluation. The proposed text sucks, and is not = what the IESG asked for. It is just text that was agreed to because = the AD who raised the DISCUSS was tired of arguing. So blaming the = IESG for the bad text and demanding that we do something to fix it isn't = going to work. We don't know what the working group wants the text to = mean. That's the problem. I asked the working group to think about this a little harder because I = need your help. If your answer to this request for help is "no," then = you are basically asking _me_ to take on this burden, and I can't. So = please reconsider. As I said, we've already had some good suggestions. = There is no reason why this has to be hard. From nobody Fri Jun 13 05:56:28 2014 Return-Path: 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 45FF51B285A for ; Fri, 13 Jun 2014 05:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 kstMO_KxfPT2 for ; Fri, 13 Jun 2014 05:56:24 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id D8F6A1A04CA for ; Fri, 13 Jun 2014 05:56:23 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D29300496E1BB; Fri, 13 Jun 2014 15:56:16 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> Date: Fri, 13 Jun 2014 15:56:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <96B2D21F-235D-4449-AA9E-ABC4F1A5BCAF@iki.fi> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/32qDXUXFe1eSwJYCDJsjo7vnCFw Cc: Ray Bellis , "homenet@ietf.org Group" , Markus Stenberg , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:56:26 -0000 On 13.6.2014, at 14.40, Ted Lemon wrote: > On Jun 13, 2014, at 2:26 AM, Lorenzo Colitti = wrote: >> I vote for removing the text and returning the draft to the IESG as = WG consensus, and if the IESG is not happy with that, then ask them to = explain clearly what it is that they are worried about. > People have already made suggestions for how to fix the text, which I = would like implemented. "The IESG" isn't asking for a change. Adrian = has been trying to negotiate a change for several months, and that = resulted in some text that was reluctantly agreed to, but that the = chairs felt didn't reflect the working group consensus, which appears to = have been a correct evaluation. The proposed text sucks, and is not = what the IESG asked for. It is just text that was agreed to because = the AD who raised the DISCUSS was tired of arguing. So blaming the = IESG for the bad text and demanding that we do something to fix it isn't = going to work. We don't know what the working group wants the text to = mean. That's the problem. >=20 > I asked the working group to think about this a little harder because = I need your help. If your answer to this request for help is "no," = then you are basically asking _me_ to take on this burden, and I can't. = So please reconsider. As I said, we've already had some good = suggestions. There is no reason why this has to be hard. Problem for me is that I don=92t understand what that added text _is_ = about. What I _would_ like to do is remove even _more_ from that = section, but for some reason that doesn=92t sound like direction the = routing ADs want to go. Without understanding the reasoning behind why that text was added, it=92s= hard to figure how to fix it by anything else than using =91cut=92 tool = in text editor. As an example, = http://tools.ietf.org/html/draft-ietf-homenet-hncp-00#section-8.1 has = _two_ requirements for a routing protocol. Two. (One could argue for = physical media independence, and even the second requirement of zeroconf = in that text is arguable because if something else does the magic, you = _can_ e.g. use OSPFv3 non-AC perfectly fine given someone provides it = with unique IPv4 addreses to use as router IDs). So in IETF level = jargon, only MUST is source specific routing support. There=92s TON of = SHOULDs but I=92m not sure they belong in arch document. That said, if we=92re ever to converge on _one_ routing protocol, the = set of requirements would be much stricter. But as that discussion = hasn=92t even started, I don=92t see why we should stick _those_ = requirements into RFC and freeze them long before discussion even = starts. Cheers, -Markus= From nobody Fri Jun 13 06:20:35 2014 Return-Path: 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 5D1021B286C for ; Fri, 13 Jun 2014 06:20:31 -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 eJoFnb8ZJPgZ for ; Fri, 13 Jun 2014 06:20:30 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 19E231B287A for ; Fri, 13 Jun 2014 06:20:30 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 03AD123824E3; Fri, 13 Jun 2014 09:20:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <96B2D21F-235D-4449-AA9E-ABC4F1A5BCAF@iki.fi> Date: Fri, 13 Jun 2014 09:20:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39F2841C-0796-482B-A3D3-E138733D0A05@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <96B2D21F-235D-4449-AA9E-ABC4F1A5BCAF@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/6dwR__4vgbz_aCFL53FoceyFE3g Cc: Ray Bellis , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:20:31 -0000 On Jun 13, 2014, at 8:56 AM, Markus Stenberg = wrote: > Problem for me is that I don=92t understand what that added text _is_ = about. What I _would_ like to do is remove even _more_ from that = section, but for some reason that doesn=92t sound like direction the = routing ADs want to go. That would be perfectly fine, as long as it says what's needed to be = said. The reasoning behind adding the text was that the ADs wanted to know = what the routing paradigm for homenets is intended to be. The text as = presented to the IESG said some things that didn't make sense to them, = and didn't make clear to them what was intended. So taking out text = could definitely improve the situation. From nobody Fri Jun 13 06:27:25 2014 Return-Path: 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 47E6E1B286F for ; Fri, 13 Jun 2014 06:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yCfGZWQE_zTo for ; Fri, 13 Jun 2014 06:27:23 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1564F1B2818 for ; Fri, 13 Jun 2014 06:27:22 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r2so517225igi.12 for ; Fri, 13 Jun 2014 06:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qZyO5wXiPclpF7N6gk6trf63pW8pKDUQu99JvUftsbM=; b=ZKZq1sHwnubsi2cRVyynQZHiRH9dsuWxiJlhzhLDxMO2KYMUiPi8qClfexY1H6T/ek +AFZlt+G/dWve/J93F8cCSDQo8xG/QCiUbl/I+2ZEanjS4aw9EKF8bUguEZriD6B2+RV nI9yzeimkl3u9iqy2BDWabOe+PiI/+rfALNdj9VLxZXSjgb7oy/AQJ0GZX0I04YXGrT6 zs+ACf7Ct0iSHq6gVbfnmwGJk1JqUikIu7fucJUgr2SV5nSWzFm6I3B8myqaFQLo8Bxe s0HjXT6iWq1ioDIqsBO99map+kOnPItW6jhpLnAJsNB9O4URk2RF+F3TRQVj2bChqPoY 0qRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qZyO5wXiPclpF7N6gk6trf63pW8pKDUQu99JvUftsbM=; b=UsgpWUPZ7MmjXaE5gbwljsErFKPaGOMs94KIkk0qSzsFsxJuGLw+0CUdKIIz+8WRWN wjCWrs8/UqUjr6YTaYhUDO4aNtj0d6vQv4iWN7ujE7qobND0CoS2SB6Hs2CWzAClox7V VTlbxSyX4qsQ0unZiLIAZ/Ay4hKRJRLrTkOJVxJDATN4WVbZtvuKO6KpOQvN4YYc8KcU B/THVzVpDE/u2nVxv42hp/JJzJQNmeYIPx62rmU7TaLnjtN9bLq6sPX3XpJENVIfZ+Ie NnoLt9eL2TFiisCw+ALFAzVMMXlhk5G6BnF0MB14lkTn+6PRjaMTlh8IXuJTXfeQ4uqd sXHg== X-Gm-Message-State: ALoCoQnJStoI2tyW/jd4zHFUR++JOVNicTx8oHHOfljYcfsYdNsCNYtzvF8Mr6ghTypWy8DqSMXB X-Received: by 10.51.17.66 with SMTP id gc2mr4812793igd.5.1402666042411; Fri, 13 Jun 2014 06:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Fri, 13 Jun 2014 06:27:02 -0700 (PDT) In-Reply-To: <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> From: Lorenzo Colitti Date: Fri, 13 Jun 2014 22:27:02 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1135f3a432725d04fbb7a386 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/qJlA0Kqc0PQNnQVAA9N4ZV3RyhA Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:27:24 -0000 --001a1135f3a432725d04fbb7a386 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 8:40 PM, Ted Lemon wrote: > We don't know what the working group wants the text to mean. That's the > problem. > No, the problem is that the working group doesn't know what is being asked for. --001a1135f3a432725d04fbb7a386 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 13, 2014 at 8:40 PM, Ted Lemon <mellon@fugue.com> wro= te:
We don't know what the working group wants the text to = mean. =C2=A0 That's the problem.

<= div>No, the problem is that the working group doesn't know what is bein= g asked for.
--001a1135f3a432725d04fbb7a386-- From nobody Fri Jun 13 06:38:19 2014 Return-Path: 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 CD08C1B2902 for ; Fri, 13 Jun 2014 06:38:17 -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 u-DlQ1LROisR for ; Fri, 13 Jun 2014 06:38:16 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9781B290B for ; Fri, 13 Jun 2014 06:38:16 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 86AFA23824E3; Fri, 13 Jun 2014 09:38:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Fri, 13 Jun 2014 09:38:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <569F1126-D0A4-47ED-9261-F4E727B1C072@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8cYHjI7x3fvGGkAyKeg2YFD7ifU Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:38:18 -0000 On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti wrote: > No, the problem is that the working group doesn't know what is being = asked for. We could go around on this all week... From nobody Fri Jun 13 06:44:00 2014 Return-Path: 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 0637C1B2912 for ; Fri, 13 Jun 2014 06:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 YF6qw5fbK0Ou for ; Fri, 13 Jun 2014 06:43:55 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BC11B287D for ; Fri, 13 Jun 2014 06:43:55 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r2so537795igi.6 for ; Fri, 13 Jun 2014 06:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Yzr0Zyqhea8iRI9Ya3MtHCaRK/xaGGEpRYZEPS/WD9w=; b=dvCqFp/FtnCSZ4pI7sLQb4rsXGehZ8IOYMAtZscoEOs+lIBFohpgORC7dGsbdc+Q9M 7LJ91quHmnKZf6TzLP0tMGQvEv+syTE7N0Sq7mFJiJ2+fAw4bLsCDcoxlCUc6vw6vl1v aY+qkj6aRnmic8TIwEkMzpS1Leb3dLWx+68QwqaLESq+hpBeaDULKZlPJnFYfmxrr39X ObBrfNhybFj1YavPiQG3wEoKzzs3CFdP/TD0AneV5mofhUJqMZsaLRzFbUYykrUbhinZ ShdwOidn8m1NSA9Fr4Hh5lepol8D/4CcrtkLaP/IW3hnpyPOLO2/7AhhO6jadKpX7mk2 RXNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Yzr0Zyqhea8iRI9Ya3MtHCaRK/xaGGEpRYZEPS/WD9w=; b=iVZ12c2tLev6roFGjEGCsAPCEoYLs2NCfREZDCkBxqZYSwIb53zowwsAFKJIm3LRmD 61IsrIY4z+JF4+zGN9VCAurLo7IEp54WdJCTg+FUxbcbbsbP3rXMdYBW5vX5wIY3qTHw bNMATalXDU28Fjnepmz0UpGX0O29eumBDR1/zCpgH7MbyAuz0gIQuICxevks9K/Cz35E 8gG7U8FLrxu1t5OYDZFkwoCx4btV2qLNFOUMcnTG/bGJgTT2DTWhxD0q7YeJ0W2BTaS0 IhaVesBNrLl6wd2cNWbj+MZzedOClzRGeXhZdPwwACppMmOa5nStDe/E+DvSV/wTDToS dbxw== X-Gm-Message-State: ALoCoQlPv2BLgeVwLvN8jiBs1wIuQnmAIpLX6ZdJMQuX/0qgNzARsjtIa+lqlP4kzdhnJQ3Ynbz6 X-Received: by 10.50.129.104 with SMTP id nv8mr4824584igb.45.1402667034801; Fri, 13 Jun 2014 06:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Fri, 13 Jun 2014 06:43:34 -0700 (PDT) In-Reply-To: <569F1126-D0A4-47ED-9261-F4E727B1C072@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <569F1126-D0A4-47ED-9261-F4E727B1C072@fugue.com> From: Lorenzo Colitti Date: Fri, 13 Jun 2014 22:43:34 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b414174592f7b04fbb7de79 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4Sbr0h3INQd9QdxLy8BH7rqNUZs Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:43:58 -0000 --047d7b414174592f7b04fbb7de79 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 10:38 PM, Ted Lemon wrote: > On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti wrote: > > No, the problem is that the working group doesn't know what is being > asked for. > > We could go around on this all week... > No, seriously. Assume I'm an idiot. Can you explain to me, in a couple of sentences, what the working group is being asked to do here? --047d7b414174592f7b04fbb7de79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 13, 2014 at 10:38 PM, Ted Lemon <mellon@fugue.com> wr= ote:
On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> No, the problem is that the working group doesn't know what is bei= ng asked for.

We could go around on this all week...

No, seriously. Assume I'm an idiot. Can you explain to me, in a c= ouple of sentences, what the working group is being asked to do here?
--047d7b414174592f7b04fbb7de79-- From nobody Fri Jun 13 06:46:10 2014 Return-Path: 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 88AC51B287D for ; Fri, 13 Jun 2014 06:46:08 -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 vH89Lj8NnEtD for ; Fri, 13 Jun 2014 06:46:07 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5C71B2912 for ; Fri, 13 Jun 2014 06:46:07 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id CD0E623824E3; Fri, 13 Jun 2014 09:46:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Fri, 13 Jun 2014 09:46:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Nfbfcw_yDN3hITQS_vN36abHgYA Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:46:08 -0000 On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti wrote: > No, the problem is that the working group doesn't know what is being = asked for.\ Juliusz Chroboczek's messages yesterday at 22:19 UTC (assuming I did the = timezone math right) did a pretty good job of capturing what I've been = trying to communicate (thanks, Juliusz!). From nobody Fri Jun 13 06:49:15 2014 Return-Path: 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 19B121B287D for ; Fri, 13 Jun 2014 06:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tFnovkuDVb2h for ; Fri, 13 Jun 2014 06:49:12 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F275B1B2879 for ; Fri, 13 Jun 2014 06:49:11 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so549187igd.2 for ; Fri, 13 Jun 2014 06:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1/egR4k79ZjW/c8LgyLzxyE64rrlqP1puF8FqMVFl38=; b=P9AyCXf/WKFhh1f6qxMUt9WhFgVShFGGe0rjhhGEJKxPeVFpQzFsa5hHanWM+Ws0sL 8bM30UcacV/mINJFC9wb8I5RtA7oxVWnzK/93eUjnKhK2iJG0A9rTTKi2Qd83SPAW9dn 6QlId5b+YJbjeO3KdYBG6jCRI4UvGS8T9S7l5Np5jAT3aQHzz0g2h305YfQEAM6ru/ZM DgSY8x0S6ZGov95a/sQp/UQqxCqeMm+H97wDDpv05/V5o3LS8ZWOFWYhZUb5FRJZ1l02 KxlF0lVd+qdpFNhMjhzYqIwIE1PYjCedSBJgmEAMZb6Bb5YC6M2JrvqJKdNhdUODgZFT A8hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1/egR4k79ZjW/c8LgyLzxyE64rrlqP1puF8FqMVFl38=; b=ilqtCH1cU8irmNjpKYDeMs9I/mgEQg0fXN99SPkf3yuhUUeoiZwhh7jH16LmApSKlk 4o+LpfYX1ojDRKYy1DiSBeBZYvKP3HhSnUAmdT7Xk54FNJwrtjLxlNS1Z1r08ze/BsO/ qHmS7aHaHLG25gwMLQ3aQ48ZAfrtk16cj2ozne8Mb+P6pn1/uTttC08vDN0ZZdYCEyEG Nz4ql4DqjwJdcUCNHFxoF8KdTbwEeUbyHTUYLSGVWQXHuNHVIE9eXCeBBxzKjMd9n8IY 3mfosOWlHU1ffUL6wi78OHHklaNj8P+uEX3f6WxZVoQV9gSyJml6x/gRKnkha8/FmQ86 EBxg== X-Gm-Message-State: ALoCoQnk7e9kYbVbE/3Wb2pX6uHYJV4zPvHLGJEiJjURMuDbBxqUJOpwECUBt/Y+0t5GcTu1O/ik X-Received: by 10.42.204.197 with SMTP id fn5mr3344175icb.95.1402667351380; Fri, 13 Jun 2014 06:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Fri, 13 Jun 2014 06:48:51 -0700 (PDT) In-Reply-To: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> From: Lorenzo Colitti Date: Fri, 13 Jun 2014 22:48:51 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf303f6a0038079304fbb7f186 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/p0qoCPHTyXpp2Hnp-LRzvEm_PP8 Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:49:13 -0000 --20cf303f6a0038079304fbb7f186 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 10:46 PM, Ted Lemon wrote: > On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti wrote: > > No, the problem is that the working group doesn't know what is being > asked for.\ > > Juliusz Chroboczek's messages yesterday at 22:19 UTC (assuming I did the > timezone math right) did a pretty good job of capturing what I've been > trying to communicate (thanks, Juliusz!). > 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? --20cf303f6a0038079304fbb7f186 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 13, 2014 at 10:46 PM, Ted Lemon <mellon@fugue.com> wr= ote:
On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> No, the problem is that the working group doesn't know what is bei= ng asked for.\

Juliusz Chroboczek's messages yesterday at 22:19 UTC (assuming I did th= e timezone math right) did a pretty good job of capturing what I've bee= n trying to communicate (thanks, Juliusz!).

Not to me they didn't. Seriously - if you understand what we'r= e being asked to do, and it's simple to explain, then it shouldn't = take long for you to type. Please?
--20cf303f6a0038079304fbb7f186-- From nobody Fri Jun 13 06:57:14 2014 Return-Path: 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 6C00A1B290F for ; Fri, 13 Jun 2014 06:57:13 -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 sxGvQNSvGNmt for ; Fri, 13 Jun 2014 06:57:12 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7DB1A03ED for ; Fri, 13 Jun 2014 06:57:12 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id BD28E23824E3; Fri, 13 Jun 2014 09:57:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Fri, 13 Jun 2014 09:57:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/RN6AKgqvMW-xynkOM-awNeE8j2M Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:57:13 -0000 On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti 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? 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? Is it okay to break a flow = in that situation, or does it need to survive the transition? 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? 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. From nobody Fri Jun 13 07:11:06 2014 Return-Path: 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 E2AA21B290F for ; Fri, 13 Jun 2014 07:11:04 -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 V_Y3L0DcMVhK for ; Fri, 13 Jun 2014 07:11:00 -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 BE1D71A00FB for ; Fri, 13 Jun 2014 07:10:59 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5DE9dDX000924; Fri, 13 Jun 2014 15:09:49 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5DE9dDX000924 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1402668615; bh=TjMIzDY0G3s8lt5sLkFv59SrUio=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=VGp3pma1tPm2p8kBDWJ+ehDxfbwDEI3CCIQZPx/62owxxgO/f3AFDwP0BvrLYYrux EQnYcgSg0kryMNtTX1ZlbJ7ikMVXzblj5Zn47fLeCfXHvXHSvz0Dm2G07Zl52ALVLw MupADlw0E6cnuEJWC8uccgVbBw354vQw6Cgf8YD0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q5CF9Y05460355350O ret-id none; Fri, 13 Jun 2014 15:10:15 +0100 Received: from [IPv6:2001:630:d0:ed04:6936:1e53:cbc4:2789] ([IPv6:2001:630:d0:ed04:6936:1e53:cbc4:2789]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5DE9SDU030348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 15:09:28 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_7A87C212-B28B-4B81-922B-48BC13DFE80D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <569F1126-D0A4-47ED-9261-F4E727B1C072@fugue.com> Date: Fri, 13 Jun 2014 15:09:28 +0100 Message-ID: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <569F1126-D0A4-47ED-9261-F4E727B1C072@fugue.com> <797DA508-0CCE-4D62-9C8E-57B8BC15094C@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q5CF9Y054603553500; tid=q5CF9Y05460355350O; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s5DE9dDX000924 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/ZUH3wVZKFir2leFJP0lk8EKtp_g Cc: Bellis Ray , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:11:05 -0000 --Apple-Mail=_7A87C212-B28B-4B81-922B-48BC13DFE80D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 13 Jun 2014, at 14:38, Ted Lemon wrote: > On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti = wrote: >> No, the problem is that the working group doesn't know what is being = asked for. >=20 > We could go around on this all week=85 I must say as the editor of the arch text I am also very confused. I = don=92t understand what is required in a replacement for the = =93contentious" paragraph (paragraph 4 of section 3.5), rather than = simply removing the paragraph based on strong WG consensus. In producing the -13, which was pushed out at IETF London, it seemed to = me that there was clear WG consensus in that meeting that we should not = constrain, witness the minutes at = http://www.ietf.org/proceedings/89/minutes/minutes-89-homenet (under = Slide 9). This view was reinfroced by comments elsewhere, and by the WG = chairs. While it=92s possible the WG view may have changed since London, = it=92s not a big surprise that it hasn=92t. That message is why the one = reference to link metrics earlier in section 3.5 is clearly qualified by = =93if supported by the protocol in use=94. As Ray points out, the paragraph added by the Routing ADs does make = other some text in other paragraphs (which isn=92t so prescriptive) seem = out of place. My personal view, which happens to be in line with most = (all?) who have commented in the WG is simply to strike the proposed = prescriptive paragraph. The question of course is whether/if Ted can = square that off with our routing ADs who have genuine concern in raising = the issue=85 it=92s simply that the WG is coming back here and saying = =93it=92s OK, thanks for raising the point, but we=92re sure we want to = do it this way=94. The -13 also includes other changes in response to discussion at London, = as documented in the minutes, e.g. about the zero or one routing = protocols.=20 Tim --Apple-Mail=_7A87C212-B28B-4B81-922B-48BC13DFE80D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 13 Jun 2014, at 14:38, Ted Lemon = <mellon@fugue.com> = wrote:

On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:
No, the problem is that the working = group doesn't know what is being asked for.

We could = go around on this all week=85

I must say as = the editor of the arch text I am also very confused. I don=92t = understand what is required in a replacement for the =93contentious" = paragraph (paragraph 4 of section 3.5), rather than simply removing the = paragraph based on strong WG consensus.

In = producing the -13, which was pushed out at IETF London, it seemed to me = that there was clear WG consensus in that meeting that we should not = constrain, witness the minutes at htt= p://www.ietf.org/proceedings/89/minutes/minutes-89-homenet (under= Slide 9). This view was reinfroced by comments elsewhere, and by the WG = chairs. While it=92s possible the WG view may have changed since London, = it=92s not a big surprise that it hasn=92t. That message is why the one = reference to link metrics earlier in section 3.5 is clearly qualified by = =93if supported by the protocol in use=94.

As = Ray points out, the paragraph added by the Routing ADs does make other = some text in other paragraphs (which isn=92t so prescriptive) seem out = of place. My personal view, which happens to be in line with most (all?) = who have commented in the WG is simply to strike the proposed = prescriptive paragraph.  The question of course is whether/if Ted = can square that off with our routing ADs who have genuine concern in = raising the issue=85 it=92s simply that the WG is coming back here and = saying =93it=92s OK, thanks for raising the point, but we=92re sure we = want to do it this way=94.

The -13 also = includes other changes in response to discussion at London, as = documented in the minutes, e.g. about the zero or one routing = protocols. 

Tim

= --Apple-Mail=_7A87C212-B28B-4B81-922B-48BC13DFE80D-- From nobody Fri Jun 13 07:11:12 2014 Return-Path: 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 5A99D1B2936 for ; Fri, 13 Jun 2014 07:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ce9N1DMmgVJm for ; Fri, 13 Jun 2014 07:11:05 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9891B2933 for ; Fri, 13 Jun 2014 07:11:04 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so967727wiv.14 for ; Fri, 13 Jun 2014 07:11:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=DNopjc6T/Ag9p3gfgJPmGgBvCN6dsLV8XUflDRQxQZc=; b=iHxGG7xyey34PTSyrwaEGl5CCo2iTVfZx2GUWm+87JGU73eqacEdGPPe2MIP0mkrKN LD1IS6TOsT5coiw8EV9lwHlbVukJN9NUb52kaR7nKReF2mguP+NRpWHhbIV6rjcGAqZF j8P4rkbVs9Soqfw5cGlTI6uEfbjGCkar6+mBMPOsui573lg0e7dBzfzme1AuldRieWKs Nyzd41hy/zZcpXd4/pKp4mFRvIUiLiWCN56lugtej5AofsV4RaEAhqOZHjJClYJ9vVCx /kMHzPxgCCE4w7OFdFCYkX2cbhx4LPeSHHWyfrm1mr1XjpDQXlC5/biXRL4c6f7D1J2Y OTew== X-Gm-Message-State: ALoCoQnqP3EIVKEJ8H0dGsmQvWhcYS7ArqJ3o1APkh4XDdIcGn6XGB83K67W8QhJawm46yqiE+fN X-Received: by 10.180.186.8 with SMTP id fg8mr5127443wic.39.1402668663384; Fri, 13 Jun 2014 07:11:03 -0700 (PDT) Received: from [192.168.1.108] (AMontsouris-653-1-53-141.w92-141.abo.wanadoo.fr. [92.141.20.141]) by mx.google.com with ESMTPSA id bx2sm6005534wjb.47.2014.06.13.07.10.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 07:10:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Mark Townsley In-Reply-To: <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> Date: Fri, 13 Jun 2014 16:10:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B217E02-EC1C-4E27-AF39-FA8FE58C4A43@townsley.net> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/I7Hi8a2Xcnt6jiOXs6dyypkqrw4 Cc: Ray Bellis , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:11:09 -0000 On Jun 13, 2014, at 1:40 PM, Ted Lemon wrote: > On Jun 13, 2014, at 2:26 AM, Lorenzo Colitti = wrote: >> I vote for removing the text and returning the draft to the IESG as = WG consensus, and if the IESG is not happy with that, then ask them to = explain clearly what it is that they are worried about. >=20 > People have already made suggestions for how to fix the text, which I = would like implemented. "The IESG" isn't asking for a change. Adrian = has been trying to negotiate a change for several months, and that = resulted in some text that was reluctantly agreed to, but that the = chairs felt didn't reflect the working group consensus, which appears to = have been a correct evaluation. The proposed text sucks, and is not = what the IESG asked for. It is just text that was agreed to because = the AD who raised the DISCUSS was tired of arguing. So blaming the = IESG for the bad text and demanding that we do something to fix it isn't = going to work. We don't know what the working group wants the text to = mean. That's the problem. If it is truly Adrian alone with an individual opinion not shared by the = IESG at all, frankly he should be contributing within the WG as an = individual.=20 Over and above that though, Adrian has formally Abstained. As in, = formally declined not to ballot either for or against this document. He = has willingly taken himself out of the game, removing the AD superpowers = granted to him in the process. It sounds like he did so with some = promise from you that you would try to insert 3 sentences from him. Not = 3 sentences from the IESG, but from him, the same guy who formally said = he is done being a part of the discussion.=20 It would be different if Adrian had said "With these 3 sentences, I will = remove my DISCUSS and ballot No Objection or Yes. If the WG doesn't like = those sentences then I will continue to DISCUSS it with you or the WG = until we reach consensus" That's the whole spirit of a discuss. An = Abstain is different, a bit of a double-edged sword. On one hand, the AD = is sending a strong message that he or she doesn't think the document = is worthy (and if a document collects enough of these, it doesn't move, = I've sat through one of those cases before when I was in your shoes). On = the other hand, the Abstaining AD has removed himself or herself from = the debate. Rock meet hard place for you, so you have to make a call. Do = what your WG is telling you, or respect the wish of an AD that has = thrown in the towel with an Abstain position anyway.=20 tl;dr: Ted, you've fulfilled your commitment. Respect Adrian's Abstain = position and the consensus of the WG at the same time by removing the = text, and forwarding the document to the RFC Editor. You could even do = it without a new rev, just an RFC Editors note. As I type, the Ballot is = clear, all you have to do is push the button. - Mark > I asked the working group to think about this a little harder because = I need your help. If your answer to this request for help is "no," = then you are basically asking _me_ to take on this burden, and I can't.=20= > So please reconsider. As I said, we've already had some good = suggestions. There is no reason why this has to be hard. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Jun 13 07:14:43 2014 Return-Path: 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 17A7E1B293E for ; Fri, 13 Jun 2014 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 EYmtb6rK7fGw for ; Fri, 13 Jun 2014 07:14:40 -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 9A0431B2869 for ; Fri, 13 Jun 2014 07:14:39 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5DEEYbW002768; Fri, 13 Jun 2014 15:14:34 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5DEEYbW002768 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1402668874; bh=Ve0eaU28YkmEOsjsZ7L9Y+OrVDo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=bqhfGiQ2ut5JLaiXz8STKRk9KE1a3CTOAFuKJ5ngRdlQYwlWNgF8QkC89k5PiJlvi AgkzRF0mzCPckEFGQWmC2XUDnYsJi1E8bNugHohNuNJWSqF2g2McWmHb083qcdyrHK v3/ZKu+C7moOovvsXMW9dI65rosl38OuuO95V5OE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q5CFEY0546035605ZM ret-id none; Fri, 13 Jun 2014 15:14:34 +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 s5DEEYat031555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 15:14:34 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <539A19AE.2080605@globis.net> Date: Fri, 13 Jun 2014 15:13:58 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <539A19AE.2080605@globis.net> <3D89DDE2-9B26-45C4-98A0-FF0EDF871BD6@ecs.soton.ac.uk> To: Ray Hunter X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q5CFEY054603560500; tid=q5CFEY0546035605ZM; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s5DEEYbW002768 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/YDQcgMrhs7TIx4ZwVJDuisSNSyo Cc: Bellis Ray , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:14:42 -0000 Hi Ray, As ever, good commentary. On the 30 second thing, that was put in after discussion in a homenet = session maybe 4-5 IETFs ago. As the text says, it is a =93finger in the = air number=94, but the whole of that =93but as a guideline=85=94 part = could be removed. Tim On 12 Jun 2014, at 22:20, Ray Hunter wrote: > Here's my 2c worth on Section 3.5 >=20 > I'm on record as preferring a "common Homenet routing protocol" = without having any fingers in any particular choice. >=20 > I believe there is rough consensus around the choice of 0 or 1 routing = protocol. >=20 > Going through Section 3.5 line by line. >=20 >=20 >> Routing functionality >>=20 >> 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. > Fine by me. >>=20 >> 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. 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. >>=20 >>=20 > Fine by me. Apart from the use of the word "graph" which could be = overloaded or suggest a preference for link state protocols. = s/graph/consistent view/ ? >>=20 >>=20 >> 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 is thus >> desirable, to avoid upstream ISP BCP 38 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. > Fine be me. >>=20 >> Routing within the homenet will determine the least cost path = across >> the homenet towards the destination address given the source = address. > Too explicit IMHO. What is wrong with s/determine the least cost path = across the homenet towards the destination address given the source = address /maintain a loop free forwarding path between any given source = address and destination pair/ >> The path cost will be computed as a linear sum of the metric = assigned >> to each link. > Way too explicit IMHO. EIGRP is a perfectly good routing protocol that = would be excluded by this requirement as the routing metric is a non = linear sum of different individual link metrics, including minimum path = bandwidth. > Not that I'm urging use of EIGRP, but I don't see why it should be = excluded on these grounds alone. >=20 >> 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. >>=20 > It's a may so fine by me. >> Multiple types of physical interfaces must be accounted for in the >> homenet routed topology.=20 > Fine be me. >> 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. > Fine be me. >> The inclusion of physical layer >> characteristics including bandwidth, loss, and latency in path >> computation should be considered for optimising communication in = the >> homenet. >>=20 > Fine be me. >> The routing environment should be self-configuring, as discussed >> previously. Minimising convergence time should be a goal in any >> routed environment, > Fine by me. >> 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). >>=20 > Way too explicit IMHO. I don't see why a figure of 30 seconds for = convergence time is even given. I'm not happy to wait 30 seconds for = video distribution over Homenet. > Surely acceptable convergence time is a function of user expectations = relative to the nature of the traffic being carried by the Homenet, = combined with the available buffering before the user becomes aware of = any topology change. >> 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. >>=20 > Fine be me. But is totally inconsistent with the sentence above to = always choose the shortest path. The "shortest path" may not be "the = best" for all traffic. Again look at the concept behind EIGRP metrics, = where high bandwidth traffic might be routed over a different route to = latency sensitive traffic. >> At most one routing protocol should be in use at a given time in a >> given homenet. > Definitely agree. >> In some simple topologies, no routing protocol may be >> needed. > Consistent with the 0 or 1 consensus. >> 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. >>=20 >>=20 > Fine be me. I'd rather just chose one, but this appears to me like = trying to get a group consisting of more than one economist to agree on = anything. >>=20 >>=20 >> 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. >>=20 > Fine be me. >> 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. >>=20 > Fine be me. It might be worth adding that we do not expect LLN network = to act as transit networks between more traditional areas of the Homenet = if you are going to revise the text anyway. >=20 >=20 > Ray Bellis wrote: >>=20 >> Dear Working Group, >>=20 >> You may have noticed multiple revisions of draft-ietf-homenet-arch = posted recently. After many iterations and a ton of work for our Editor = In Chief, Tim Chown, all IESG =93DISCUSS=94 positions have been resolved = to either =93Yes=94 or =93No Objection=94, with the exception of one = =93Abstain=94 from one of our Routing Area ADs who had requested that = the following text be added to section 3.5: >>=20 >> =93Routing 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.=94 >>=20 >> The Chairs felt that the first half of this text was unnecessarily = prescriptive for this document and did not reflect something the WG had = achieved consensus on at this time. We proposed a compromise that = incorporated the latter non-normative half of this text in an earlier = paragraph. On the basis that we understood that this compromise had = been accepted by the respective AD, the -14 revision was posted. >>=20 >> After -14 was posted and the AD=92s position changed to "No = Objection", we noticed that the above paragraph had inadvertently been = included, in full, in addition to the latter half included as part of = the proposed compromise! At the Chairs=92 request, Tim removed the above = paragraph in -15, which caused the AD to object as it appeared to him = that his text was being removed after the fact. >>=20 >> Later today, Tim will be posting a -16 revision of the document that = reinstates the above paragraph, in full, and removes the =93compromise=94 = text. On the basis that the new text is a potentially substantive = change, our AD has requested that we put the document through one more = Working Group Last Call to determine WG consensus on that issue. >>=20 >> In addition, one small change was introduced in the -15 revision = based on WG feedback where a reference to Source Specific Multicast [RFC = 4607] was introduced, but had not been called out explicitly in London = or before. That change is as follows: >>=20 >> Old: >> It is desirable that, subject to the capacities of devices on = certain >> media types, multicast routing is supported across the homenet. >>=20 >> New: >> It is desirable that, subject to the capacities of devices on = certain >> media types, multicast routing is supported across the homenet, >> including source-specific multicast (SSM) [RFC4607]. >>=20 >> The WGLC will commence immediately after the -16 is posted, and will = last for two weeks. >>=20 >> We very much want your feedback here, but are not aiming to revisit = the document in its entirety. As such, we would like to limit the scope = of the WGLC to just the text quoted in this email. >>=20 >> Many thanks, >>=20 >> Ray and Mark >>=20 >=20 > --=20 > Regards, > RayH >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Jun 13 07:16:22 2014 Return-Path: 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 12EED1B2869 for ; Fri, 13 Jun 2014 07:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Pz8NuuUoEtuV for ; Fri, 13 Jun 2014 07:16:20 -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 D31531A00FB for ; Fri, 13 Jun 2014 07:16:19 -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 s5DEGF3R003816; Fri, 13 Jun 2014 15:16:15 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5DEGF3R003816 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1402668978; bh=8gc/7VjZWQO6J0CpDDQpuX8NEqU=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=oiIrG45mJq7mZ8Tt81HdpUUcinuz4bWJjneEPtUPZz9+Qt3rrshpULgO+zSbsCqHN YOZA6rgn/GTVeOQtdSUBMY4+xBP9D8QjwHwqPBRxnqxIIUvUhH2NYK+nBkE0Bk8Hqv p0nBR1Z0HKLYWZcDNygHuc3k5wIxrvETvDZV8lG8= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q5CFGF0546035624ms ret-id none; Fri, 13 Jun 2014 15:16:18 +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 s5DEGEx0032430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 15:16:15 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <1055.1402613059@sandelman.ca> Date: Fri, 13 Jun 2014 15:16:15 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1055.1402613059@sandelman.ca> <20DFFD45-AD7E-4A0F-B2AE-16A8A0BF39A3@ecs.soton.ac.uk> To: Michael Richardson X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q5CFGF054603562400; tid=q5CFGF0546035624ms; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s5DEGF3R003816 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/Avij80T9QVZ6ZAQu1wCl99nm-yU Cc: Bellis Ray , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:16:21 -0000 On 12 Jun 2014, at 23:44, Michael Richardson = wrote: >=20 > I will attempt to read the diffs; but... It Just Doesn't Matter > better is the enemy of good enough, and it was good enough a year ago. Well=85 :) The last few months have basically been about bashing through a list of = around 80+ IESG comments and discusses. The good news is that this one = paragraph is (I really really hope) the last outstanding issue of that = list to resolve.=20 Tim= From nobody Fri Jun 13 07:20:51 2014 Return-Path: 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 0770D1B2934 for ; Fri, 13 Jun 2014 07:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 KKJCdUkov9LG for ; Fri, 13 Jun 2014 07:20:48 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4883D1A00D1 for ; Fri, 13 Jun 2014 07:20:48 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so976126wiw.17 for ; Fri, 13 Jun 2014 07:20:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Ogq3BI+DGYuYOluTx51+UXDOiveoFABL233DxOJxjN8=; b=gX+vN++/gJL9IIGn56zuSzggRMp+v0it0LXvsVMSt6DvdjKJ+lMK4uAGf85rUPQLn5 4d+Brxyww+sNEmx/kTdJqEZVNG/1Hf29kaH3prDcz9SUsYziMun1SSNMV3hbcs0vpxkm lKTgMrOcmvJFB+ikNX8s9eB7IHZWwL3I4ZZ2iv1kD+r8hyo0T3gMAkoWwM2FZS/4b/7f 7IWuoBWrOwbw5rj3GrgPFC3zCfZWe1l3LnVALoN2BM50BTWblNxaKPfzq/IbyBxiVt8Q UqsqQ4XoEkkrEycd11G2bSeeyH+fFqTux5wYc376PVsJ0HNW972caLoTw9vQZ9mSeduI jDtg== X-Gm-Message-State: ALoCoQnhB3hrRtHIsgSUqycIDXnWpuGf6ZSvzf1P7hsrleMUDYfa4+TH4wa3X2YqxfCfMIdZ91gu X-Received: by 10.180.38.38 with SMTP id d6mr5437902wik.12.1402669246817; Fri, 13 Jun 2014 07:20:46 -0700 (PDT) Received: from [192.168.1.108] (AMontsouris-653-1-53-141.w92-141.abo.wanadoo.fr. [92.141.20.141]) by mx.google.com with ESMTPSA id cz8sm6059862wjc.11.2014.06.13.07.20.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 07:20:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Mark Townsley In-Reply-To: Date: Fri, 13 Jun 2014 16:20:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88089D9C-9CBD-4C91-A69E-BDCE0A4FEEB1@townsley.net> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CuKR0yZUIqVfdZODIFS-38EJi6c Cc: Ray Bellis , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:20:50 -0000 On Jun 13, 2014, at 3:57 PM, Ted Lemon wrote: > On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti = 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? >=20 > 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? >=20 > 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? 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? Is it okay to = break a flow in that situation, or does it need to survive the = transition? 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? >=20 > 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. Ted, you asked Ray and I to issue a WGLC on a very specific set of text. = You are falling into your own trap of going beyond that. Yes, the document could be improved. In fact, after another year of = coding and protocol development, I bet we could write a descriptive = architecture document of what actually came out on the other side that = is even better than we could today!=20 The discussion here has actually been pretty good at tearing apart some = of the things NOT to say, it's also made me think more about whether the = IESG should keep stats on how much text it removes during a review = rather than adds (I'll be asking Jari to include that in his doc stats, = and I bet he'll find time to do it - the guy is amazing like that).=20 Do we really want to crack open this document again? I really don't = trust how the process has been working of late to believe that it would = not lead to another round of DISCUSSes and Last Calls. - Mark >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Jun 13 07:25:44 2014 Return-Path: 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 ; 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 ; 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 ; 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 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 In-Reply-To: Date: Fri, 13 Jun 2014 15:25:36 +0100 Message-ID: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Ted Lemon 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 , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:25:44 -0000 --Apple-Mail=_F69044B2-2048-4039-A045-0EC8BC1308C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 13 Jun 2014, at 14:57, Ted Lemon wrote: > On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti = 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? >=20 > 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? >=20 > 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? =20 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? =20 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=85 =93 > Is it okay to break a flow in that situation, or does it need to = survive the transition? =20 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.=93 > 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 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_F69044B2-2048-4039-A045-0EC8BC1308C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
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=85 =93

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.=93

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


_______________________________________________
homen= et mailing list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail=_F69044B2-2048-4039-A045-0EC8BC1308C6-- From nobody Fri Jun 13 07:29:14 2014 Return-Path: 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 92C1C1A00CD for ; Fri, 13 Jun 2014 07:29:13 -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 4qLRQrEJ-Dwl for ; Fri, 13 Jun 2014 07:29:12 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 871A11A0090 for ; Fri, 13 Jun 2014 07:29:12 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 76CF223824E3; Fri, 13 Jun 2014 10:29:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <88089D9C-9CBD-4C91-A69E-BDCE0A4FEEB1@townsley.net> Date: Fri, 13 Jun 2014 10:29:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01E23AA3-96CE-44A0-A513-C52D71ED6D92@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <88089D9C-9CBD-4C91-A69E-BDCE0A4FEEB1@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/h5L-lFbKWr2Tx1bul5ib7RpVadE Cc: Ray Bellis , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:29:13 -0000 On Jun 13, 2014, at 10:20 AM, Mark Townsley wrote: > Ted, you asked Ray and I to issue a WGLC on a very specific set of = text. You are falling into your own trap of going beyond that. No, Mark, I agreed with Ray that the proposed text needed a last call. = Last calls are not for rubber stamps. They often produce proposed = changes. This is what I wanted, and why I asked for the last call. I = don't think the text is right as is. From nobody Fri Jun 13 07:31:47 2014 Return-Path: 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 70DB01B2936 for ; Fri, 13 Jun 2014 07:31:45 -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 Lq_vCewRKq9n for ; Fri, 13 Jun 2014 07:31:44 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A38C91B2935 for ; Fri, 13 Jun 2014 07:31:44 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 455AE23824FE; Fri, 13 Jun 2014 10:31:42 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Fri, 13 Jun 2014 10:31:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <768588EA-A904-40AA-B7B5-E1D578A65C56@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> To: Tim Chown X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7-_3ewfgAr6J90dd6bUC4ixpZNs Cc: Bellis Ray , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:31:45 -0000 On Jun 13, 2014, at 10:25 AM, Tim Chown wrote: > Well, 3 of the 4 questions seem to be answered, or at least considered = if left relatively open. None of the text there looks like requirements, but yes, I agree the = text already addresses some of the points I brought up. Unfortunately, = it does a lot of other stuff too. From nobody Fri Jun 13 08:06:00 2014 Return-Path: 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 DBBAA1B2948 for ; Fri, 13 Jun 2014 08:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 x2FPRF03a19n for ; Fri, 13 Jun 2014 08:05:55 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40E21A0132 for ; Fri, 13 Jun 2014 08:05:54 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so2976000wes.16 for ; Fri, 13 Jun 2014 08:05:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qctGin3PLwk2azyKQkvgUFEt394gC+cPcMQZyTrwrkg=; b=ZuYs0Bb7h6+TIj9M+FwIOWDW1HP6fPFQOzLCwi7NA+s2+uWtePhvGTrMqsZHw4AHcu 9lewj7bAzblmm3vauorhvi01TOSVhgiT51c6vf21KHtKOpFA/STeUGh4LWQIhuS+bSDO KyNprQar4kYBVicF3erxarUBPRkREx51PYRawtb4G8X+TYQIlndQ/xOA8zY+S0MiziPh CIMiHo9JjLYhtTiuKzbIMALO3tKoMKMHWU8gPt8LnAfWuTnkAKV2jtExs1eLp95xgckm KdbKdmODI/MzUCIJUgI41V2E8TTEY9IT1p7lOdWStABPbcwMlQrbBKr7/BPsMeLbWwVn 8YAQ== X-Gm-Message-State: ALoCoQn/h4J2mdmv99qeJW4h/ZJup4ppStjnJgGk1fBfqGNR3H6+QKEDBSeW3NfLWbs1xG1YXSLI X-Received: by 10.194.23.135 with SMTP id m7mr5364693wjf.2.1402671952294; Fri, 13 Jun 2014 08:05:52 -0700 (PDT) Received: from [192.168.1.108] (AMontsouris-653-1-53-141.w92-141.abo.wanadoo.fr. [92.141.20.141]) by mx.google.com with ESMTPSA id fh5sm2975131wic.9.2014.06.13.08.05.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 08:05:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Mark Townsley In-Reply-To: <01E23AA3-96CE-44A0-A513-C52D71ED6D92@fugue.com> Date: Fri, 13 Jun 2014 17:05:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <88089D9C-9CBD-4C91-A69E-BDCE0A4FEEB1@townsley.net> <01E23AA3-96CE-44A0-A513-C52D71ED6D92@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QbDkg8hDXUktDsuKPy-7NfKl8I4 Cc: Ray Bellis , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:05:57 -0000 On Jun 13, 2014, at 4:29 PM, Ted Lemon wrote: > On Jun 13, 2014, at 10:20 AM, Mark Townsley wrote: >> Ted, you asked Ray and I to issue a WGLC on a very specific set of = text. You are falling into your own trap of going beyond that. >=20 > No, Mark, I agreed with Ray that the proposed text needed a last call. = Last calls are not for rubber stamps. They often produce proposed = changes. This is what I wanted, and why I asked for the last call. I = don't think the text is right as is. Ted, that is not at all what Ray explained to me. In fact, I relaxed the = WGLC scoping text we sent to the group vs. what he thought had been = agreed between the two of you. But that's neither here nor there - of = course any text is up for changing at any time, and WGLCs are not rubber = stamps, which is why the text from Adrian is being rejected, just as we = said it would be. Let's not put words in my mouth. I will repeat, I agree some of the text isn't right, and the WG agrees = as well. Current thinking has diverged, partially due to the length of = time the document has spent sitting in committee. Given the number of = comments and compromises up to this point, it is obviously a hornets = nest that could unravel any number of past discussions, agreements, and = compromises.=20 Not all of the text is wrong though, and above all I am hearing "better = is the enemy of good enough" comments that I have great sympathy for at = this stage. - Mark From nobody Fri Jun 13 13:27:47 2014 Return-Path: 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 7088F1B2A48 for ; Fri, 13 Jun 2014 13:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 j_hFw0NLIo5G for ; Fri, 13 Jun 2014 13:27:44 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A371B2A35 for ; Fri, 13 Jun 2014 13:27:44 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id z10so1002741pdj.1 for ; Fri, 13 Jun 2014 13:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wz1VUBDzAMUHVDGcpqas7en4UBJW0j0/JCH7nF5nK1w=; b=QwddU+8ms+rV6T5EnwQFzJQlpXPcgmlkkKLY4JWe4niTQSAAAVV32cW0cSsYCLNuJZ DVJ59zS0/XVnWT99NKVno1fF0Kp3Ba/IGT9J5UC7Bjsz0jks0areiqwFptson60fFuOS 0auZRPBWf4foVLZWwxMV161hdFVSV+CUce1zoYRyc2r2MpFM0AvS2Kc+Z3rY7s4BoThv tK9y0xDcECGwVuNDKazlZXP3tUKA56tcJha5rG1j6SSXqq289m8T+Q33iP6o4wrt/tWk BoMgQkYhFOeYkT+NbzOR0osWYgAJzv9CxQRX8/q0QkCyPTJ6VWpqUnnGf1vAiHkbtzss 5EZw== X-Received: by 10.68.139.137 with SMTP id qy9mr6006875pbb.11.1402691264207; Fri, 13 Jun 2014 13:27:44 -0700 (PDT) Received: from [192.168.178.23] (115.199.69.111.dynamic.snap.net.nz. [111.69.199.115]) by mx.google.com with ESMTPSA id ei4sm5156241pbb.42.2014.06.13.13.27.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 13:27:43 -0700 (PDT) Message-ID: <539B5EC9.1090001@gmail.com> Date: Sat, 14 Jun 2014 08:27:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <88089D9C-9CBD-4C91-A69E-BDCE0A4FEEB1@townsley.net> <01E23AA3-96CE-44A0-A513-C52D71ED6D92@fugue.com> In-Reply-To: <01E23AA3-96CE-44A0-A513-C52D71ED6D92@fugue.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dyJkJOTYFIf1u3R2NhjYQsjAQ0M Cc: Ray Bellis , "homenet@ietf.org Group" , Mark Townsley , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:27:45 -0000 On 14/06/2014 02:29, Ted Lemon wrote: > On Jun 13, 2014, at 10:20 AM, Mark Townsley wrote: >> Ted, you asked Ray and I to issue a WGLC on a very specific set of text. You are falling into your own trap of going beyond that. > > No, Mark, I agreed with Ray that the proposed text needed a last call. Last calls are not for rubber stamps. They often produce proposed changes. This is what I wanted, and why I asked for the last call. I don't think the text is right as is. There seems to be general agreement that the stuff about metrics is over-specification. The rest of the text has already got the OK from the ISEG. So why are we still discussing it? Just delete that paragraph. The worst that happens is that the document advances with one IESG abstention against it. It's prototype implementations and early deployments that will tell us the right answer, not further debate. Brian From nobody Fri Jun 13 13:44:46 2014 Return-Path: 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 9CD1A1B2A51 for ; Fri, 13 Jun 2014 13:44:43 -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 A2MOY-YGkTR8 for ; Fri, 13 Jun 2014 13:44:42 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 45E871A029A for ; Fri, 13 Jun 2014 13:44:42 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 4AA36238004A; Fri, 13 Jun 2014 16:44:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <539B5EC9.1090001@gmail.com> Date: Fri, 13 Jun 2014 16:44:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <949CCE9B-67A5-4293-94ED-5DB946BD1B4F@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <88089D9C-9CBD-4C91-A69E-BDCE0A4FEEB1@townsley.net> <01E23AA3-96CE-44A0-A513-C52D71ED6D92@fugue.com> <539B5EC9.1090001@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ila951hQ5H8oAx35fBT8IendITo Cc: Ray Bellis , "homenet@ietf.org Group" , Mark Townsley , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:44:43 -0000 On Jun 13, 2014, at 4:27 PM, Brian E Carpenter = 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. From nobody Sat Jun 14 01:04:40 2014 Return-Path: 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 9EE331B2BCA for ; Sat, 14 Jun 2014 01:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Y9QFewiRBlPQ for ; Sat, 14 Jun 2014 01:04:35 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E71A1B2BC9 for ; Sat, 14 Jun 2014 01:04:34 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so3599495wes.21 for ; Sat, 14 Jun 2014 01:04:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=k1SEJ02fT7pos4uPa/jvJ4JfofXTsBau6IICsG9jFIg=; b=H6yDWiTC/U1fjQ27wqTGlLlLssuN7se68wfpAPc51McS65u2yM51SkMZrdWsoUvPi+ E4Nj2Jjms/e4AK9M03MnOgKGVoAup7LZYT8nJ/8w58QRqda8FTVcnCqfqXbyGBCR0ISh rh7bWmbAUAd4ndZnbQIR6knEtiZNe4y+UJLZD/vuIvVSuiweGpzH2/aRjqPA2YRN4iIR gGlYji+VbZMN9DKVNARiV3BCSBZgkNrS3S5L6SItNUdFU3Gm7uGEyriqJR1Pl/ASEalG GJqvZxwxZCGhlRvhnQHFObTBrnR4VWDZQoGSXGvTDhNeye1GXjOYI9NZbG+UmDrvrv3a Xoew== X-Gm-Message-State: ALoCoQks3mc44huWJXKSUzawhQTZJ99VhxIaLBAeVEP5GiHkzu0DRB6urrKXvcfRpcfOiW47N+QS X-Received: by 10.180.94.37 with SMTP id cz5mr10898744wib.19.1402733072649; Sat, 14 Jun 2014 01:04:32 -0700 (PDT) Received: from [192.168.1.108] (AMontsouris-653-1-53-141.w92-141.abo.wanadoo.fr. [92.141.20.141]) by mx.google.com with ESMTPSA id o10sm9063146wjy.0.2014.06.14.01.04.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Jun 2014 01:04:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_54A8922D-FD7B-4AE1-A3E1-8F6B6D34A449" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Mark Townsley In-Reply-To: <949CCE9B-67A5-4293-94ED-5DB946BD1B4F@fugue.com> Date: Sat, 14 Jun 2014 10:04:27 +0200 Message-Id: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@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> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/umvfK-0Xqcm3Hk_HLKaeOnL9niA Cc: Ray Bellis , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:04:38 -0000 --Apple-Mail=_54A8922D-FD7B-4AE1-A3E1-8F6B6D34A449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 13, 2014, at 10:44 PM, Ted Lemon wrote: > On Jun 13, 2014, at 4:27 PM, Brian E Carpenter = wrote: >> It's prototype implementations and early deployments that will >> tell us the right answer, not further debate. >=20 > 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? >=20 > 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. >=20 While I agree with Brian here, if you want more text out, so be it. = Here's a proposal which=20 does that, stopping short of trying to continue word-smithing the = document at this stage. =20 I simply took section 3.5 from -16, and removed sentences that seemed to = me to be overly prescriptive,=20 including the paragraph from Adrian.=20 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. 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. =20 Chown, et al. Expires December 12, 2014 [Page 28] =20 Internet-Draft IPv6 Home Networking June 2014 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 is thus desirable, to avoid upstream ISP BCP 38 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. =20 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. 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. Chown, et al. Expires December 12, 2014 [Page 29] =20 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. 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. --Apple-Mail=_54A8922D-FD7B-4AE1-A3E1-8F6B6D34A449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 

On Jun 13, 2014, at 10:44 PM, Ted Lemon <mellon@fugue.com> =
wrote:

On Jun 13, =
2014, at 4:27 PM, Brian E Carpenter <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 overly =
prescriptive, 
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.  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. =20




Chown, et al.  =
         Expires December 12, 2014              [Page 28]

 
Internet-Draft =
           IPv6 Home Networking                 June 2014


   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 is thus
   desirable, to avoid upstream ISP BCP 38 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. =20

   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.  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.




Chown, et al.  =
         Expires December 12, 2014              [Page 29]

 
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.

   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.
=



= --Apple-Mail=_54A8922D-FD7B-4AE1-A3E1-8F6B6D34A449-- From nobody Sat Jun 14 06:44:47 2014 Return-Path: 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 99E031B2BE8 for ; Sat, 14 Jun 2014 06:44:45 -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 cNoBWFdosQrp for ; Sat, 14 Jun 2014 06:44:43 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BDB771B2BAB for ; Sat, 14 Jun 2014 06:44:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id ABA61871518; Sat, 14 Jun 2014 15:44:41 +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 iiY-kvZXT9zX; Sat, 14 Jun 2014 15:44:41 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 8ACE5870056; Sat, 14 Jun 2014 15:44:41 +0200 (CEST) Message-ID: <539C51BA.6030901@globis.net> Date: Sat, 14 Jun 2014 15:44:26 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tim Chown References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/aZQ22iitAIxmrIegpd5ifSwudX8 Cc: Bellis Ray , "homenet@ietf.org Group" , Ted Lemon , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 13:44:45 -0000 Tim Chown wrote: > > On 13 Jun 2014, at 14:57, Ted Lemon > wrote: > >> On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti > > 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 > OK. Ted asked for additional questions and answers, and I think he has a point in that there should be hooks to requirements in the architecture that facilitate selection of the correct routing protocol(s) later, without unnecessarily limiting the choice. Here's my contribution after going through a few comparisons texts of common routing protocols that I found online. I pose a question, give my personal view, and then check if I can find an answer in the current text. Does the Homenet Architecture require the routing protocol to carry arbitrary configuration information? [my view] No. Assuming the existence of a separate Homenet configuration protocol, the routing protocol must facilitate auto-configuration, but does not necessarily have to supply configuration to other processes. [this is not currently explicitly defined the architecture document AFAICS] Does the Homenet Architecture require the routing protocol to support multiple address families? [my view] No. The Homenet architecture is IPv6 only. Although support for IPv4 and other address families may be beneficial, it is not an explicit requirement to carry the routing information in the same routing protocol. [this is not currently in the architecture document AFAICS] Does the Homenet Architecture require the routing protocol to support SADR? [my view] Yes. [this is in the current architecture document] "A routing protocol that can make routing decisions based on source and destination addresses is thus desirable, to avoid upstream ISP BCP 38 ingress filtering problems." Does the Homenet Architecture require the routing protocol to be tolerant of lossy unstable links? [my view] Yes. [this is in the current architecture document] "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." Does the Homenet Architecture explicitly require use of a distance vector or link state algorithms? [my view] No. The Homenet architecture should be agnostic on this point. [this is not currently in the architecture document AFAICS] Does the Homenet Architecture need an EGP or an IGP? [my view] An IGP. [this is in the current architecture document] This implies that internal routing functionality is required, and that the homenet's ISP both provides a large enough prefix to allocate a prefix to each subnet, and that a method is supported for such prefixes to be delegated efficiently to those subnets. Is there a minimum hop count limit that must be supported? [my view] No. The Homenet architecture is agnostic on this point, although use of Homenet in small offices and small enterprise site may require higher hop counts. [this is not currently in the architecture document AFAICS] Is there a penalty for the protocol being chatty? [my view] No. LLN is not envisaged to be used as a transit network, and as such would be connected by a gateway router. It is not envisaged that there will be significant limits on bandwidth consumption or Homenet routers having to sleep for power efficiency. [this is not currently in the architecture document AFAICS] [The current text is in relation to LLN only] In general, message utilisation should be efficient considering the network technologies and constrained devices that the service may need to operate over. [plus the need for diverse routing metrics to cover a large range of bandwidths, but I can't see any requirements on the routing protocol itself.] Is a specific update address preferred? [my view] The routing protocol should support both use of unicast and multicast updates. [this is not currently in the architecture document AFAICS although you could argue it is covered by] Further, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low- power and lossy networks (LLNs), such as those used for certain types of sensor devices. Scalability? [my view] The protocol should scale up to ±50 routers? [this is not currently in the architecture document AFAICS] Proprietary protocols allowed or protocols requiring Intellectual Property agreements? [my view] No. Must not be proprietary or be limited by IP. [this is not currently in the architecture document AFAICS] Multi-path support? [my view] yes. [this is in the current architecture document] "The inclusion of physical layer characteristics including bandwidth, loss, and latency in path computation should be considered for optimising communication in the homenet." Resource Consumption Limits? [my view] Yes. Should be light weight with a small footprint suitable for inclusion into consumer products. [this is not currently in the architecture document AFAICS] Explicit support for Ad Hoc networks? [my view] I don't know. [this is not currently in the architecture document AFAICS] Make your own mind up whether the current text is sufficient to cover all necessary requirements, without being unnecessarily over-specified. -- Regards, RayH From nobody Sat Jun 14 06:48:25 2014 Return-Path: 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 0DE4F1B2BAB for ; Sat, 14 Jun 2014 06:48:24 -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 k7e6wVjoIT19 for ; Sat, 14 Jun 2014 06:48:23 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 32BEE1B28F1 for ; Sat, 14 Jun 2014 06:48:23 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 885072381566; Sat, 14 Jun 2014 09:48:21 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <539C51BA.6030901@globis.net> Date: Sat, 14 Jun 2014 09:48:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5135D41D-197B-468C-ADE3-C8D203471A64@fugue.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Jr87HvYpXSi7SXTt1tCHul8cQnw Cc: Bellis Ray , Tim Chown , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 13:48:24 -0000 That's really helpful, Ray. Thanks! (I don't know the answers to those questions, but they're just the sort = of questions I wouldn't have thought to ask, which is why I tossed this = back to the working group.) From nobody Sat Jun 14 07:25:21 2014 Return-Path: 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 DA0511B2904 for ; Sat, 14 Jun 2014 07:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 UzXhn5nxga68 for ; Sat, 14 Jun 2014 07:25:19 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 167081B2902 for ; Sat, 14 Jun 2014 07:25:18 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5EEPGqI004792; Sat, 14 Jun 2014 16:25:16 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5F3AA293E54; Sat, 14 Jun 2014 16:25:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TH3-H4jmqEE4; Sat, 14 Jun 2014 16:25:15 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E8EFB293E51; Sat, 14 Jun 2014 16:25:14 +0200 (CEST) Date: Sat, 14 Jun 2014 16:25:46 +0200 Message-ID: <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <539C51BA.6030901@globis.net> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 14 Jun 2014 16:25:16 +0200 (CEST) X-Miltered: at korolev with ID 539C5B4C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 539C5B4C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 539C5B4C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Bu81cyBJftytbfqyFfsEZ6g3Ot0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 14:25:21 -0000 > 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. > 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 From nobody Sat Jun 14 08:18:22 2014 Return-Path: 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 ; 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 ; 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 ; 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 User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Juliusz Chroboczek References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <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" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 15:18:21 -0000 > Juliusz Chroboczek > 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 From nobody Sat Jun 14 08:49:36 2014 Return-Path: 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 C17491B2C2F for ; Sat, 14 Jun 2014 08:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 hcoWKFrh1BAu for ; Sat, 14 Jun 2014 08:49:32 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D92D21B2C2D for ; Sat, 14 Jun 2014 08:49:31 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5EFnTmn026394; Sat, 14 Jun 2014 17:49:29 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7C33E293E5D; Sat, 14 Jun 2014 17:49:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qYG1UvIECwUE; Sat, 14 Jun 2014 17:49:28 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0776C293E5B; Sat, 14 Jun 2014 17:49:27 +0200 (CEST) Date: Sat, 14 Jun 2014 17:49:58 +0200 Message-ID: <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <539C67AA.4030501@globis.net> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 14 Jun 2014 17:49:29 +0200 (CEST) X-Miltered: at korolev with ID 539C6F09.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 539C6F09.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 539C6F09.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/9HzMJ0m8Nk-ZTYrUUZrj10FNvKI Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 15:49:32 -0000 > 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. Ah, I see. Yes, that makes sense. >> 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? > "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. I don't. I interpret that as meaning that the routing protocol should be able to pick a path using more refined criteria than just hop count. E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops to a single wireless one. Doing that is not too difficult, and yields dramatic performance improvements in some fairly simple, realistic topologies. Load sharing is a completely different headache. Done carelessly, load sharing causes issues with increased latency and jitter, and causes intermittent connectivity problems that are very difficult to troubleshoot if one of the links is unreliable. It also has ghastly performance if you balance across wireless links without taking radio interference into account. While it's certainly an area worth experimenting with, I'd be cautious about requiring load sharing in Homenet unless somebody knows how to do it right in the general unadministered case. -- Juliusz From nobody Sun Jun 15 03:51:27 2014 Return-Path: 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 7D7B11B2BEC for ; Sun, 15 Jun 2014 03:51:26 -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 h77UqoGY7qlW for ; Sun, 15 Jun 2014 03:51:25 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 037251B2BEA for ; Sun, 15 Jun 2014 03:51:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B351A871517; Sun, 15 Jun 2014 12:51:23 +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 iHc7nQbpo5oL; Sun, 15 Jun 2014 12:51:23 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 8EA8987005A; Sun, 15 Jun 2014 12:51:23 +0200 (CEST) Message-ID: <539D7A9F.5000407@globis.net> Date: Sun, 15 Jun 2014 12:51:11 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Juliusz Chroboczek References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87ioo35w49.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/BF5d3qEgJc6744xs0KXkOTbJvSQ Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 10:51:26 -0000 Juliusz Chroboczek wrote: >> 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. > > Ah, I see. Yes, that makes sense. > >>> 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? > >> "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. > > I don't. I interpret that as meaning that the routing protocol should be > able to pick a path using more refined criteria than just hop count. > E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops > to a single wireless one. Doing that is not too difficult, and yields > dramatic performance improvements in some fairly simple, realistic > topologies. > > Load sharing is a completely different headache. Done carelessly, load > sharing causes issues with increased latency and jitter, and causes > intermittent connectivity problems that are very difficult to troubleshoot > if one of the links is unreliable. It also has ghastly performance if you > balance across wireless links without taking radio interference into account. > > While it's certainly an area worth experimenting with, I'd be cautious > about requiring load sharing in Homenet unless somebody knows how to do it > right in the general unadministered case. > > -- Juliusz > > Your interpretation of the current architecture text also seems perfectly valid, and is indeed much simpler to implement. Should the text then rather say "Path selection in Homenet needs to be more sophisticated than measuring pure hop count due to the use of heterogeneous link technologies, and therefore the routing protocol should be capable of utilising multiple link-dependent metrics, such as bandwidth, delay, and link reliability", rather than mentioning "optimised"? IMHO That revised text would provide a very clear selection criteria for preferring certain routing protocols over others. Or do you think the text is OK as is? -- Regards, RayH From nobody Sun Jun 15 09:04:01 2014 Return-Path: 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 7C3561B2915 for ; Sun, 15 Jun 2014 09:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 4jlPWXvUxu42 for ; Sun, 15 Jun 2014 09:03:59 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 C70B71B2913 for ; Sun, 15 Jun 2014 09:03:58 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5FG3tbP009231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Jun 2014 18:03:55 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s5FG3t7T021075; Sun, 15 Jun 2014 18:03:55 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 87D532940E1; Sun, 15 Jun 2014 18:03:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id domuzo8mEUAK; Sun, 15 Jun 2014 18:03:53 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 71E3B2940DE; Sun, 15 Jun 2014 18:03:53 +0200 (CEST) Date: Sun, 15 Jun 2014 18:03:51 +0200 Message-ID: <87y4wyqhw8.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <539D7A9F.5000407@globis.net> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> <539D7A9F.5000407@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 15 Jun 2014 18:03:55 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 15 Jun 2014 18:03:55 +0200 (CEST) X-Miltered: at korolev with ID 539DC3EB.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 539DC3EB.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 539DC3EB.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 539DC3EB.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 539DC3EB.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 539DC3EB.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/OgsaVnfDzzavurtmLuxcOrhO9n0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 16:04:00 -0000 >>> "The inclusion of physical layer characteristics including bandwidth, >>> loss, and latency in path computation should be considered for >>> optimising communication in the homenet." > Should the text then rather say "Path selection in Homenet needs to be > more sophisticated than measuring pure hop count due to the use of > heterogeneous link technologies, and therefore the routing protocol should > be capable of utilising multiple link-dependent metrics, such as > bandwidth, delay, and link reliability", rather than mentioning > "optimised"? I'm happy with either. The current text leaves it to the protocol people to decide what "optimising" means, but I also like the way you spell out the requirement. If you'll allow me to indulge in some minor nit picking wrt. your suggested wording: - you require "multiple [...] metrics", which is what we do in Babel, but we certainly don't wish to prevent somebody from being smart enough to design a single metric that works satisfactorily on all link layers; - you use "bandwdith" where you mean "throughput" (yeah, I know, I'm a pedant); - I'm on a personal crusade against the utilisation of the verb "to utilise". So perhaps something like: Due to the use of heterogeneous link technologies, path selection in a homenet needs to be more refined than minimising hop count. The homenet routing protocol should be able to select paths according to criteria such as latency, throughput, link reliability (e.g. measured packet loss) or other performance metrics. -- Juliusz From nobody Mon Jun 16 10:23:32 2014 Return-Path: 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 E823D1A0125 for ; Mon, 16 Jun 2014 10:23:29 -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 tD-sfpl3SIKi for ; Mon, 16 Jun 2014 10:23:28 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3391A00C9 for ; Mon, 16 Jun 2014 10:23:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5D089871513; Mon, 16 Jun 2014 19:23:27 +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 NGtkOxymC9bq; Mon, 16 Jun 2014 19:23:27 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 393D0870026; Mon, 16 Jun 2014 19:23:27 +0200 (CEST) Message-ID: <539F2808.5030506@globis.net> Date: Mon, 16 Jun 2014 19:23:20 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Juliusz Chroboczek References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> <539D7A9F.5000407@globis.net> <87y4wyqhw8.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87y4wyqhw8.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/ANElZNWVsOm_zIWqwfQcVPc8lUw Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 17:23:30 -0000 Juliusz Chroboczek wrote: >>>> "The inclusion of physical layer characteristics including bandwidth, >>>> loss, and latency in path computation should be considered for >>>> optimising communication in the homenet." > >> Should the text then rather say "Path selection in Homenet needs to be >> more sophisticated than measuring pure hop count due to the use of >> heterogeneous link technologies, and therefore the routing protocol should >> be capable of utilising multiple link-dependent metrics, such as >> bandwidth, delay, and link reliability", rather than mentioning >> "optimised"? > > I'm happy with either. The current text leaves it to the protocol people > to decide what "optimising" means, but I also like the way you spell out > the requirement. If you'll allow me to indulge in some minor nit picking > wrt. your suggested wording: > > - you require "multiple [...] metrics", which is what we do in Babel, but > we certainly don't wish to prevent somebody from being smart enough to > design a single metric that works satisfactorily on all link layers; > - you use "bandwdith" where you mean "throughput" (yeah, I know, I'm > a pedant); > - I'm on a personal crusade against the utilisation of the verb "to utilise". > > So perhaps something like: > > Due to the use of heterogeneous link technologies, path selection in > a homenet needs to be more refined than minimising hop count. The > homenet routing protocol should be able to select paths according to > criteria such as latency, throughput, link reliability (e.g. measured > packet loss) or other performance metrics. > > -- Juliusz > > I could certainly live with your text, and if the WG ever moved to evaluating competing candidate routing protocols against requirements derived from the architecture, it could provide a useful and objective differentiator, which is possibly something that has been lacking up until now. e.g. {BABEL, EIGRP, full IS-IS .....} might be preferred over {OSPFv3....} which might be preferred over {RIPng, HNCP native routing, IS-IS (only using cost and default cost=10) , AODV (without link quality extensions) ....} on this particular measure of suitability. -- Regards, RayH From nobody Mon Jun 16 11:13:57 2014 Return-Path: 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 C0F0F1A00B8 for ; Mon, 16 Jun 2014 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no 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 vQ5vrahSEQoC for ; Mon, 16 Jun 2014 11:13:40 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 612C01A0157 for ; Mon, 16 Jun 2014 11:13:40 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5GIDbIU020185; Mon, 16 Jun 2014 20:13:37 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 925922943CA; Mon, 16 Jun 2014 20:13:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id hmBnRzpp2RbV; Mon, 16 Jun 2014 20:13:36 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2806A2943C7; Mon, 16 Jun 2014 20:13:35 +0200 (CEST) Date: Mon, 16 Jun 2014 20:13:34 +0200 Message-ID: <87tx7kn2nl.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <539F2808.5030506@globis.net> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> <539D7A9F.5000407@globis.net> <87y4wyqhw8.wl%jch@pps.univ-paris-diderot.fr> <539F2808.5030506@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 16 Jun 2014 20:13:37 +0200 (CEST) X-Miltered: at korolev with ID 539F33D1.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 539F33D1.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 539F33D1.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/DiNsqQIoG4V53RTsgygeQEZhj2s Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:13:44 -0000 >> path selection in a homenet needs to be more refined than minimising >> hop count. > {BABEL, EIGRP, full IS-IS .....} might be preferred over {OSPFv3....} To be fair, there's nothing *in principle* preventing an implementation of OSPFv3 from encoding interesting stuff within its metric -- there's 16 bits to play with, if memory serves, just like in Babel. Whether it's actually doable in practice would require somebody actually doing the work and trying it out. Just like SADR. (ducks) -- Juliusz From nobody Mon Jun 16 11:40:16 2014 Return-Path: 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 093611A0150 for ; Mon, 16 Jun 2014 11:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Pa8r8mD-mVJ7 for ; Mon, 16 Jun 2014 11:40:14 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179D61A014E for ; Mon, 16 Jun 2014 11:40:14 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-35-539ee685d501 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 76.77.11744.586EE935; Mon, 16 Jun 2014 14:43:49 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Mon, 16 Jun 2014 14:40:05 -0400 From: Acee Lindem To: Juliusz Chroboczek Thread-Topic: [homenet] Updates to Homenet Architecture Principles doc Thread-Index: AQHPhjiqxmfdZx62jkq0PP0j0HRd45ttXiKAgAF5SQCAAFeeAIAAHeUAgAAFUgCAAADHgIAAAlAAgAAH9ACAAYbVAIAAC4wAgAAOmwCAAAjsAIABPtqAgABXW4CAAaiKAIAADgkAgAAHaAA= Date: Mon, 16 Jun 2014 18:40:04 +0000 Message-ID: <072A76E3-0A43-47C2-BF7F-CA3B3D5F3180@ericsson.com> References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> <539D7A9F.5000407@globis.net> <87y4wyqhw8.wl%jch@pps.univ-paris-diderot.fr> <539F2808.5030506@globis.net> <87tx7kn2nl.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87tx7kn2nl.wl%jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <008055992B520249A9D17B234FA4D453@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonULf12bxgg6+31S3eLzrEYvH50z9W iz1X6x2YPZ6cvc7msWTJTyaPi7vfMQYwR3HZpKTmZJalFunbJXBlXG4ULtjGXrF60wHWBsb/ rF2MnBwSAiYS+/ubmCBsMYkL99azdTFycQgJHGWUmLdhJpSznFHi89kHjCBVbAI6Es8f/WMG sUUEzCTm9TwHizML+Emc+HAKbJKwgKvE7le3WCFq3CTmXOtihLDnMUp0PAsEsVkEVCVOLT8P FucVsJc4NekaI8Syy+wSX/sfsYAkOAWsJI7tOAC2jBHovO+n1jBBLBOXuPVkPtTZAhJL9pxn hrBFJV4+/gf1mpLEnNfXmCHqdSQW7P4E9A0HkG0tsfOJBkRYW2LZwtfMEDcISpyc+YRlAqP4 LCQbZiHpnoXQPQtJ9ywk3QsYWVcxcpQWp5blphsZbmIERtkxCTbHHYwLPlkeYhTgYFTi4U0Q nxcsxJpYVlyZe4hRmoNFSZxXsxooJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgfHwtFNb0vfy fszgSup/dn3uiWUfBCuMvGKT5FXnftg5i/tWRwObUlMmlzmn1N/W3W93GB9/oL3bNeF9SPke hoQtBjY/H85ZsKLsrnEXu512xo17EgW7N666V8c+1/id3gfFEN/Tjy59fi3flJfa/dTwZVC4 TPW5Bi2frQXJr16FbGZ3rcpVqFViKc5INNRiLipOBAAPInrZkwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/a_NNrM47vfGoRHoa5Tr4uMBww74 Cc: Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:40:16 -0000 On Jun 16, 2014, at 2:13 PM, Juliusz Chroboczek wrote: >>> path selection in a homenet needs to be more refined than minimising >>> hop count. >=20 >> {BABEL, EIGRP, full IS-IS .....} might be preferred over {OSPFv3....} >=20 > To be fair, there's nothing *in principle* preventing an implementation o= f > OSPFv3 from encoding interesting stuff within its metric -- there's 16 > bits to play with, if memory serves, just like in Babel. Whether it's > actually doable in practice would require somebody actually doing the wor= k > and trying it out. There is actually an implementation using a composite metric for OSPFv3 MAN= ET. It was never standardized.=20 Thanks, Acee=20 >=20 > Just like SADR. (ducks) >=20 > -- Juliusz >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Mon Jun 16 13:10:06 2014 Return-Path: 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 ; 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 ; 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 ; 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 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 References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@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> In-Reply-To: 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" Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > wrote: > > >> On Jun 13, 2014, at 4:27 PM, Brian E Carpenter >> > >> 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 > . > 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 > 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] > > > 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 From nobody Mon Jun 16 13:12:16 2014 Return-Path: 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 D5F441A01CD for ; Mon, 16 Jun 2014 13:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, 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 SCV9Hw855NO6 for ; Mon, 16 Jun 2014 13:12:12 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FD21A01C7 for ; Mon, 16 Jun 2014 13:12:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5GKCAQR006615 for ; Mon, 16 Jun 2014 22:12:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B6E34206278 for ; Mon, 16 Jun 2014 22:13:54 +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 AF19D2061A2 for ; Mon, 16 Jun 2014 22:13:54 +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 s5GKC9pJ022148 for ; Mon, 16 Jun 2014 22:12:10 +0200 Message-ID: <539F4F99.90008@gmail.com> Date: Mon, 16 Jun 2014 22:12:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: homenet@ietf.org References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tXrbRB6CQIfYUnifA45AVd-NA2c Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:12:15 -0000 Le 14/06/2014 17:49, Juliusz Chroboczek a écrit : >> 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. > > Ah, I see. Yes, that makes sense. > >>> 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? > >> "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. > > I don't. I interpret that as meaning that the routing protocol should be > able to pick a path using more refined criteria than just hop count. > E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops > to a single wireless one. Doing that is not too difficult, and yields > dramatic performance improvements in some fairly simple, realistic > topologies. I agree. We did that in a lab experiment with OSPF on Ethernet/Bluetooth/WiFi and by defining new metrics. Alex > > Load sharing is a completely different headache. Done carelessly, load > sharing causes issues with increased latency and jitter, and causes > intermittent connectivity problems that are very difficult to troubleshoot > if one of the links is unreliable. It also has ghastly performance if you > balance across wireless links without taking radio interference into account. > > While it's certainly an area worth experimenting with, I'd be cautious > about requiring load sharing in Homenet unless somebody knows how to do it > right in the general unadministered case. > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From nobody Mon Jun 16 13:17:23 2014 Return-Path: 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 37D081A01E8 for ; Mon, 16 Jun 2014 13:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, 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 2flWF-Si4W39 for ; Mon, 16 Jun 2014 13:17:20 -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 1A2FB1A01E4 for ; Mon, 16 Jun 2014 13:17:19 -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 s5GKHIdg005169 for ; Mon, 16 Jun 2014 22:17:18 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C0F182061DA for ; Mon, 16 Jun 2014 22:19:02 +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 B944B20163A for ; Mon, 16 Jun 2014 22:19:02 +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 s5GKHHG1023967 for ; Mon, 16 Jun 2014 22:17:18 +0200 Message-ID: <539F50CD.7050901@gmail.com> Date: Mon, 16 Jun 2014 22:17:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: homenet@ietf.org References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <87d2ebbmad.wl%jch@pps.univ-paris-diderot.fr> <539C67AA.4030501@globis.net> <87ioo35w49.wl%jch@pps.univ-paris-diderot.fr> <539D7A9F.5000407@globis.net> <87y4wyqhw8.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87y4wyqhw8.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/nBIweNELe5mOyeC3QuG8bXSHdkw Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:17:22 -0000 Le 15/06/2014 18:03, Juliusz Chroboczek a écrit : >>>> "The inclusion of physical layer characteristics including bandwidth, >>>> loss, and latency in path computation should be considered for >>>> optimising communication in the homenet." > >> Should the text then rather say "Path selection in Homenet needs to be >> more sophisticated than measuring pure hop count due to the use of >> heterogeneous link technologies, and therefore the routing protocol should >> be capable of utilising multiple link-dependent metrics, such as >> bandwidth, delay, and link reliability", rather than mentioning >> "optimised"? > > I'm happy with either. The current text leaves it to the protocol people > to decide what "optimising" means, but I also like the way you spell out > the requirement. If you'll allow me to indulge in some minor nit picking > wrt. your suggested wording: > > - you require "multiple [...] metrics", which is what we do in Babel, but > we certainly don't wish to prevent somebody from being smart enough to > design a single metric that works satisfactorily on all link layers; > - you use "bandwdith" where you mean "throughput" (yeah, I know, I'm > a pedant); > - I'm on a personal crusade against the utilisation of the verb "to utilise". > > So perhaps something like: > > Due to the use of heterogeneous link technologies, path selection in > a homenet needs to be more refined than minimising hop count. The > homenet routing protocol should be able to select paths according to > criteria such as latency, throughput, link reliability (e.g. measured > packet loss) or other performance metrics. I agree. Some of the new performance metrics which are unaccounted for, but present in deployments, is the quantity of radio energy in the air. This is a real customer issue for which current deployed solutions are on/off knobs (I want a knob to turn off all WiFi in my home, turn off all cellular in my home, turn off all Bluetooth in my home, etc). More sophisticated solutions would involve metrics which quantify this and compare meaningfully. An example is the DAS parameter for mobile phones. Alex > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > From nobody Mon Jun 16 13:18:05 2014 Return-Path: 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 348AC1A01D1 for ; Mon, 16 Jun 2014 13:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 571a-cF2Kx2i for ; Mon, 16 Jun 2014 13:18:02 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6589B1A01D2 for ; Mon, 16 Jun 2014 13:18:02 -0700 (PDT) X-Original-To: homenet@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B102560AC5 for ; Mon, 16 Jun 2014 22:18:00 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7FFFB604B0 for ; Mon, 16 Jun 2014 22:18:00 +0200 (CEST) Received: (qmail 29737 invoked by uid 1007); 16 Jun 2014 22:18:00 +0200 Date: Mon, 16 Jun 2014 22:18:00 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20140616201800.GZ46558@Space.Net> References: <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> <539F4EFE.5020407@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539F4EFE.5020407@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/-fHHwCzdBuzbcnpBf_8BEaP_QsI Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:18:04 -0000 Hi, On Mon, Jun 16, 2014 at 10:09:34PM +0200, Alexandru Petrescu wrote: > 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. This is not a "homenet" as per this architecture document. The key is "it needs to work for your parents, without you driving over and setting it up for them". I know people that have BGP routing with PI space at home, but the fact that it's "at home" does not make it a *homenet*. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jun 17 07:40:01 2014 Return-Path: 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 C10DC1A0091 for ; Tue, 17 Jun 2014 07:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, 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 ZUk36ADOFjaY for ; Tue, 17 Jun 2014 07:39:58 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5398D1A0024 for ; Tue, 17 Jun 2014 07:39:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5HEdt33027040; Tue, 17 Jun 2014 16:39:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 93790206353; Tue, 17 Jun 2014 16:41:40 +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 86063206334; Tue, 17 Jun 2014 16:41:40 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5HEdk26025014; Tue, 17 Jun 2014 16:39:54 +0200 Message-ID: <53A05332.8060000@gmail.com> Date: Tue, 17 Jun 2014 16:39:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gert Doering References: <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> <539F4EFE.5020407@gmail.com> <20140616201800.GZ46558@Space.Net> In-Reply-To: <20140616201800.GZ46558@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Awja_hYKn-tFAvUxJlpzZdbe1YI Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 14:39:59 -0000 Le 16/06/2014 22:18, Gert Doering a écrit : > Hi, > > On Mon, Jun 16, 2014 at 10:09:34PM +0200, Alexandru Petrescu wrote: >> 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. > > This is not a "homenet" as per this architecture document. The key is > "it needs to work for your parents, without you driving over and > setting it up for them". I suppose parents will likely ask the IPv6 specialists something like this: - should I click on '6rd' or '6to4' or on 'DHCPv6' or on 'PPPoE'? - should I click on ULA or not? - should I click on private addresses or not? - should I click on Delegate inside when using Delegate from outside, or not? - what should I fill in as next-hop address? - what does "dotted-decimal notation" mean with IPv6 addresses? (these are examples from existing consumer equipment for in-house) Little chances are there that parents will ask whether to use BGP or OSPF or please design a protocol for me. (haven't seen these options on consumer equipment GUIs). > I know people that have BGP routing with PI space at home, but the fact > that it's "at home" does not make it a *homenet*. I agree. Alex > > Gert Doering > -- NetMaster > From nobody Tue Jun 17 09:12:03 2014 Return-Path: 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 7E5A21A0066 for ; Tue, 17 Jun 2014 09:12:02 -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 b1twbCJd3ZnN for ; Tue, 17 Jun 2014 09:11:57 -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 EC8191A0043 for ; Tue, 17 Jun 2014 09:11:56 -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 s5HGBdex013087; Tue, 17 Jun 2014 17:11:39 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5HGBdex013087 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1403021500; bh=qzdgBj3B7vAJwwzoiKKdLwnWxZE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=PS2vCUfw5dOCff6t5mI5+zOVALxeq3TRUlJrrsYbGAf1eu1PWIg7YWuzpoczmcCZD 7b5Zlj61gkDLdeWDc7SSde8rDA6jLZbazMe/AURSR//hzFY20IDeZ3p5Q8QCNXrXR/ jTlCv7/wDkI6TxYf+/UowHKBovKiL1LVsZjnt1cs= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q5GHBd0546064332AF ret-id none; Tue, 17 Jun 2014 17:11:40 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5HGBdxl020657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2014 17:11:39 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_787FF1A6-69F1-4CC3-885A-D073BCAB985C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <539C51BA.6030901@globis.net> Date: Tue, 17 Jun 2014 17:11:38 +0100 Message-ID: References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q5GHBd054606433200; tid=q5GHBd0546064332AF; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s5HGBdex013087 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/j9kDU9rat5deWxPIKnHCse6co2M Cc: Bellis Ray , "homenet@ietf.org Group" , Ted Lemon , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 16:12:02 -0000 --Apple-Mail=_787FF1A6-69F1-4CC3-885A-D073BCAB985C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ray, I like your questions, and I think many of your own suggested answers to = your questions are in line with what I believe the WG has assumed in its = discussions. I find myself in agreement with most (and perhaps all) of = them. But obviously I can=92t speak for the WG, only my perception of = WG consensus as the document editor. I would say we did shy away from a specific answer on a separate = configuration protocol in London, but since then HNCP has evolved. I = agree the multi-path clarification is needed. I think Alex is heading into too much detail, when we are trying to = avoid that (what Ray describes are general principles). I=92m talking with Ted and the chairs on the approach to take. Expect = news soon :) Tim On 14 Jun 2014, at 14:44, Ray Hunter wrote: >=20 >=20 > Tim Chown wrote: >>=20 >> On 13 Jun 2014, at 14:57, Ted Lemon > wrote: >>=20 >>> On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti > 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? >>>=20 >>> 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? >>>=20 >>> 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?=20 >>=20 >> 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." >>=20 >>> 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?=20 >>=20 >> 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=85=93 >>=20 >>> Is it okay to break a flow in that situation, or does it need to = survive the transition?=20 >>=20 >> Not stated. Should it be different to the border router resetting? >>=20 >>> 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? >>=20 >> 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.=93 >>=20 >>> 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. >>=20 >> Well, 3 of the 4 questions seem to be answered, or at least = considered if left relatively open. >>=20 >> Tim >>=20 >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >=20 > OK. Ted asked for additional questions and answers, and I think he has = a point in that there should be hooks to requirements in the = architecture that facilitate selection of the correct routing = protocol(s) later, without unnecessarily limiting the choice. >=20 >=20 > Here's my contribution after going through a few comparisons texts of = common routing protocols that I found online. I pose a question, give my = personal view, and then check if I can find an answer in the current = text. >=20 >=20 > Does the Homenet Architecture require the routing protocol to carry = arbitrary configuration information? > [my view] No. Assuming the existence of a separate Homenet = configuration protocol, the routing protocol must facilitate = auto-configuration, but does not necessarily have to supply = configuration to other processes. > [this is not currently explicitly defined the architecture document = AFAICS] >=20 >=20 > Does the Homenet Architecture require the routing protocol to support = multiple address families? > [my view] No. The Homenet architecture is IPv6 only. Although support = for IPv4 and other address families may be beneficial, it is not an = explicit requirement to carry the routing information in the same = routing protocol. > [this is not currently in the architecture document AFAICS] >=20 >=20 > Does the Homenet Architecture require the routing protocol to support = SADR? > [my view] Yes. > [this is in the current architecture document] >=20 > "A routing protocol that can make routing > decisions based on source and destination addresses is thus > desirable, to avoid upstream ISP BCP 38 ingress filtering problems." >=20 >=20 > Does the Homenet Architecture require the routing protocol to be = tolerant of lossy unstable links? > [my view] Yes. > [this is in the current architecture document] > "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." >=20 >=20 > Does the Homenet Architecture explicitly require use of a distance = vector or link state algorithms? > [my view] No. The Homenet architecture should be agnostic on this = point. > [this is not currently in the architecture document AFAICS] >=20 >=20 > Does the Homenet Architecture need an EGP or an IGP? > [my view] An IGP. > [this is in the current architecture document] > This implies that internal routing > functionality is required, and that the homenet's ISP both provides = a > large enough prefix to allocate a prefix to each subnet, and that a > method is supported for such prefixes to be delegated efficiently to > those subnets. >=20 >=20 > Is there a minimum hop count limit that must be supported? > [my view] No. The Homenet architecture is agnostic on this point, = although use of Homenet in small offices and small enterprise site may = require higher hop counts. > [this is not currently in the architecture document AFAICS] >=20 >=20 > Is there a penalty for the protocol being chatty? > [my view] No. LLN is not envisaged to be used as a transit network, = and as such would be connected by a gateway router. > It is not envisaged that there will be significant limits on bandwidth = consumption or Homenet routers having to sleep for power efficiency. > [this is not currently in the architecture document AFAICS] >=20 > [The current text is in relation to LLN only] >=20 > In general, message > utilisation should be efficient considering the network technologies > and constrained devices that the service may need to operate over. >=20 > [plus the need for diverse routing metrics to cover a large range of = bandwidths, but I can't see any requirements on the routing protocol = itself.] >=20 >=20 >=20 > Is a specific update address preferred? > [my view] The routing protocol should support both use of unicast = and multicast updates. > [this is not currently in the architecture document AFAICS although = you could argue it is covered by] >=20 > Further, link layer networking technology is > poised to become more heterogeneous, as networks begin to employ = both > traditional Ethernet technology and link layers designed for low- > power and lossy networks (LLNs), such as those used for certain = types > of sensor devices. >=20 >=20 > Scalability? > [my view] The protocol should scale up to =B150 routers? > [this is not currently in the architecture document AFAICS] >=20 >=20 > Proprietary protocols allowed or protocols requiring Intellectual = Property agreements? > [my view] No. Must not be proprietary or be limited by IP. > [this is not currently in the architecture document AFAICS] >=20 >=20 > Multi-path support? > [my view] yes. > [this is in the current architecture document] > "The inclusion of physical layer > characteristics including bandwidth, loss, and latency in path > computation should be considered for optimising communication in the > homenet." >=20 >=20 > Resource Consumption Limits? > [my view] Yes. Should be light weight with a small footprint suitable = for inclusion into consumer products. > [this is not currently in the architecture document AFAICS] >=20 > Explicit support for Ad Hoc networks? > [my view] I don't know. > [this is not currently in the architecture document AFAICS] >=20 >=20 > Make your own mind up whether the current text is sufficient to cover = all necessary requirements, without being unnecessarily over-specified. >=20 > --=20 > Regards, > RayH >=20 --Apple-Mail=_787FF1A6-69F1-4CC3-885A-D073BCAB985C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Ray,

I like your questions, and I think many of your = own suggested answers to your questions are in line with what I believe = the WG has assumed in its discussions. I find myself in agreement with = most (and perhaps all) of them.  But obviously I can=92t speak for = the WG, only my perception of WG consensus as the document = editor.

I would say we did shy away from a = specific answer on a separate configuration protocol in London, but = since then HNCP has evolved. I agree the multi-path clarification is = needed.

I think Alex is heading into too much = detail, when we are trying to avoid that (what Ray describes are general = principles).

I=92m talking with Ted and the = chairs on the approach to take.  Expect news soon :)

Tim

On 14 Jun 2014, at 14:44, Ray Hunter <v6ops@globis.net> = wrote:



Tim Chown wrote:

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

On Jun 13, 2014, at 9:48 AM, = Lorenzo Colitti <lorenzo@google.com <mailto: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=85=93

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.=93

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


_______________________________________________
homen= et mailing list
homenet@ietf.org <mailto:homenet@ietf.org>
https://www.ietf.or= g/mailman/listinfo/homenet


OK. = Ted asked for additional questions and answers, and I think he has a = point in that there should be hooks to requirements in the architecture = that facilitate selection of the correct routing protocol(s) later, = without unnecessarily limiting the choice.


Here's my = contribution after going through a few comparisons texts of common = routing protocols that I found online. I pose a question, give my = personal view, and then check if I can find an answer in the current = text.


Does the Homenet Architecture require the routing = protocol to carry arbitrary configuration information?
[my view] No. = Assuming the existence of a separate Homenet configuration protocol, the = routing protocol must facilitate auto-configuration, but does not = necessarily have to supply configuration to other processes.
[this is = not currently explicitly defined the architecture document = AFAICS]


Does the Homenet Architecture require the routing = protocol to support multiple address families?
[my view] No. The = Homenet architecture is IPv6 only. Although support for IPv4 and other = address families may be beneficial, it is not an explicit requirement to = carry the routing information in the same routing protocol.
[this is = not currently in the architecture document AFAICS]


Does the = Homenet Architecture require the routing protocol to support = SADR?
[my view] Yes.
[this is in the current architecture = document]

"A routing protocol that can make routing
=   decisions based on source and destination addresses is = thus
  desirable, to avoid upstream ISP BCP 38 ingress = filtering problems."


Does the Homenet Architecture require = the routing protocol to be tolerant of lossy unstable links?
[my = view] Yes.
[this is in the current architecture = document]
"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."


Does the Homenet Architecture = explicitly require use of a distance vector or link state = algorithms?
[my view] No. The Homenet architecture should be agnostic = on this point.
[this is not currently in the architecture document = AFAICS]


Does the Homenet Architecture need an EGP or an = IGP?
[my view] An IGP.
[this is in the current architecture = document]
This implies that internal routing
=   functionality is required, and that the homenet's ISP both = provides a
  large enough prefix to allocate a prefix to = each subnet, and that a
  method is supported for such = prefixes to be delegated efficiently to
  those = subnets.


Is there a minimum hop count limit that must be = supported?
[my view] No. The Homenet architecture is agnostic on this = point, although use of Homenet in small offices and small enterprise = site may require higher hop counts.
[this is not currently in the = architecture document AFAICS]


Is there a penalty for the = protocol being chatty?
[my view] No. LLN is not envisaged to be used = as a transit network, and as such would be connected by a gateway = router.
It is not envisaged that there will be significant limits on = bandwidth consumption or Homenet routers having to sleep for power = efficiency.
[this is not currently in the architecture document = AFAICS]

[The current text is in relation to LLN only]

In = general, message
  utilisation should be efficient = considering the network technologies
  and constrained = devices that the service may need to operate over.

[plus the need = for diverse routing metrics to cover a large range of bandwidths, but I = can't see any requirements on the routing protocol = itself.]



Is a specific update address preferred?
[my = view]   The routing protocol should support both use of = unicast and multicast updates.
[this is not currently in the = architecture document AFAICS although you could argue it is covered = by]

Further, link layer networking technology is
=   poised to become more heterogeneous, as networks begin to = employ both
  traditional Ethernet technology and link = layers designed for low-
  power and lossy networks = (LLNs), such as those used for certain types
  of sensor = devices.


Scalability?
[my view] The protocol should scale = up to =B150 routers?
[this is not currently in the architecture = document AFAICS]


Proprietary protocols allowed or protocols = requiring Intellectual Property agreements?
[my view] No. Must not be = proprietary or be limited by IP.
[this is not currently in the = architecture document AFAICS]


Multi-path support?
[my = view] yes.
[this is in the current architecture document]
"The = inclusion of physical layer
  characteristics including = bandwidth, loss, and latency in path
  computation should = be considered for optimising communication in the
=   homenet."


Resource Consumption Limits?
[my = view] Yes. Should be light weight with a small footprint suitable for = inclusion into consumer products.
[this is not currently in the = architecture document AFAICS]

Explicit support for Ad Hoc = networks?
[my view] I don't know.
[this is not currently in the = architecture document AFAICS]


Make your own mind up whether = the current text is sufficient to cover all necessary requirements, = without being unnecessarily over-specified.

-- =
Regards,
RayH


= --Apple-Mail=_787FF1A6-69F1-4CC3-885A-D073BCAB985C-- From nobody Tue Jun 17 10:39:47 2014 Return-Path: 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 04C8A1A03BD for ; Tue, 17 Jun 2014 10:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 oBNIbd-W0o4v for ; Tue, 17 Jun 2014 10:39:43 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFE41A03B4 for ; Tue, 17 Jun 2014 10:39:35 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta10.westchester.pa.mail.comcast.net with comcast id FRoP1o0040xGWP85AVfaGf; Tue, 17 Jun 2014 17:39:34 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta12.westchester.pa.mail.comcast.net with comcast id FVfa1o00C2yZEBF3YVfa3p; Tue, 17 Jun 2014 17:39:34 +0000 From: "ietfdbh" To: "'Alexandru Petrescu'" , "'Gert Doering'" References: <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> <539F4EFE.5020407@gmail.com> <20140616201800.GZ46558@Space.Net> <53A05332.8060000@gmail.com> In-Reply-To: <53A05332.8060000@gmail.com> Date: Tue, 17 Jun 2014 13:38:10 -0400 Message-ID: <035901cf8a52$e8c7e700$ba57b500$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGSTqqWc4VHMCGWTeGYRpTGOPtTCgGUNfNAAnFXaiACQzi4HwKGp3yCAU8UzrICFxtWDQK/rBqOAjba7ysClhBg/QF+0STpAX79VqCbOgQlwA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403026774; bh=3Ooh61vISpHenB74w4QPcA+UL9MFTiNl0Ia4aMCzJkI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=BYz/ERMwjLbeeELC3Hf/uIklk48EqD9LJyqsCtXH3mue8MLVkzgTl+K4YtZMSh5Tk FnDKlNcik3v1psVTCoumNYf64g0+o7Bc2r4h6EUsb9wM4QKNK/bjmhM7o/JB5WDl3r BPoFSGPHKtWw6bCvU0lg0Je6ZN5qlldtxfPxQUxFp0IfaKW7WwkCuez8kCrbwatWBe SL2Ofh00+6nno82KYTj7dk48AtI5RuUfGbrV92c1cN/R7GWhJY5dUM844HbC/UO2jz MgFJfAPJNKMR38FzYhgTCwDFWsgZdIuI/DIsbpbA9lMyHU91v9Y7MNijCpeQbW82mc sQxPfDWh7Yl/g== Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/TmS6Hn2_x0af38oDm6KPkPzXX_I Cc: homenet@ietf.org, 'Mark Townsley' Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:39:45 -0000 > -----Original Message----- > From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Alexandru > Petrescu [...] > > I suppose parents will likely ask the IPv6 specialists something like this: > - should I click on '6rd' or '6to4' or on 'DHCPv6' or on 'PPPoE'? > - should I click on ULA or not? > - should I click on private addresses or not? > - should I click on Delegate inside when using Delegate from outside, > or not? > - what should I fill in as next-hop address? > - what does "dotted-decimal notation" mean with IPv6 addresses? > (these are examples from existing consumer equipment for in-house) > Wow! What parents! Mine would be more likely to ask "how do I turn this on?" David Harrington ietfdbh@comcast.net +1-603-828-1401 From nobody Tue Jun 17 10:48:48 2014 Return-Path: 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 858EF1A0111 for ; Tue, 17 Jun 2014 10:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 e4PNzl6hsTfY for ; Tue, 17 Jun 2014 10:48:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1F71A03BE for ; Tue, 17 Jun 2014 10:48:35 -0700 (PDT) Received: from mbp.local (31.66.208.web-pass.com [208.66.31.202] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s5HHmVAX062439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Jun 2014 17:48:32 GMT (envelope-from joelja@bogus.com) Message-ID: <53A07F6A.8070606@bogus.com> Date: Tue, 17 Jun 2014 10:48:26 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: ietfdbh , "'Alexandru Petrescu'" , "'Gert Doering'" References: <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> <539F4EFE.5020407@gmail.com> <20140616201800.GZ46558@Space.Net> <53A05332.8060000@gmail.com> <035901cf8a52$e8c7e700$ba57b500$@comcast.net> In-Reply-To: <035901cf8a52$e8c7e700$ba57b500$@comcast.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S5cF2KMKuW2P18PPV6vRTb33ArFcWqsuc" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 17 Jun 2014 17:48:32 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/InNumxxaF83DqQ8gh7WcHpCOT20 Cc: homenet@ietf.org, 'Mark Townsley' Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:48:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S5cF2KMKuW2P18PPV6vRTb33ArFcWqsuc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/17/14, 10:38 AM, ietfdbh wrote: >=20 >> -----Original Message----- >> From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Alexandru= >> Petrescu > [...] >> >> I suppose parents will likely ask the IPv6 specialists something like > this: >> - should I click on '6rd' or '6to4' or on 'DHCPv6' or on 'PPPoE'? >> - should I click on ULA or not? >> - should I click on private addresses or not? >> - should I click on Delegate inside when using Delegate from outside, >> or not? So if you use a current IPv6 supporting CPE, normally you do nothing. very occasionally you need to tick a box to enable it. It is a mistake to assume that end users should be exposed to the selection of transition technologies and that would ever be appropriate in the general case. >> - what should I fill in as next-hop address? >> - what does "dotted-decimal notation" mean with IPv6 addresses? >> (these are examples from existing consumer equipment for in-house) >> > Wow! What parents! > Mine would be more likely to ask "how do I turn this on?" > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 --S5cF2KMKuW2P18PPV6vRTb33ArFcWqsuc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOgf2oACgkQ8AA1q7Z/VrJ2SwCeLiTS9MSPwLfLEbPmiPOFj7vA L8gAn2ogLdBrH7MnC29SscdfNNHKaQJI =Cf+C -----END PGP SIGNATURE----- --S5cF2KMKuW2P18PPV6vRTb33ArFcWqsuc-- From nobody Tue Jun 17 11:01:10 2014 Return-Path: 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 2C6F01A03B4 for ; Tue, 17 Jun 2014 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 94RLV70qkXE4 for ; Tue, 17 Jun 2014 11:01:06 -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 C07D51A00FF for ; Tue, 17 Jun 2014 11:00:55 -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 s5HHxi84010605; Tue, 17 Jun 2014 18:59:44 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5HHxi84010605 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1403027985; bh=kC71aioa26FTTUtWJzb+CYpkoUI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=6f2ZzLECp6htJlWsOBk7d6QRoPBiKzpYF6wlQSe62tys47j59ttX9zjEab96zkhEc 2EruG3V3ALe35kEyNMGRGqCL4WaBVnoKQ2TJkfu+IPupZIdr/pYz6YKlBFv8y+pQgQ YXYt/1yVuEJ4+QcpxDvMZWOwKCt2jptvN1w9Ar/E= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q5GIxi05460650416l ret-id none; Tue, 17 Jun 2014 18:59:45 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5HHxcUs008310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2014 18:59:38 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <53A07F6A.8070606@bogus.com> Date: Tue, 17 Jun 2014 18:59:37 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <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> <539F4EFE.5020407@gmail.com> <20140616201800.GZ46558@Space.Net> <53A05332.8060000@gmail.com> <035901cf8a52$e8c7e700$ba57b500$@comcast.net> <53A07F6A.8070606@bogus.com> <6A0AFDEC-B4DE-4C8A-B48B-C023CA0ED839@ecs.soton.ac.uk> To: joel jaeggli X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q5GIxi054606504100; tid=q5GIxi05460650416l; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s5HHxi84010605 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/IH83DEy9llp25VAnPb3iIztn85c Cc: Townsley Mark , Alexandru Petrescu , homenet@ietf.org, ietfdbh , Gert Doering Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 18:01:09 -0000 Hi, On 17 Jun 2014, at 18:48, joel jaeggli wrote: > On 6/17/14, 10:38 AM, ietfdbh wrote: >>=20 >>> -----Original Message----- >>> From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of = Alexandru >>> Petrescu >> [...] >>>=20 >>> I suppose parents will likely ask the IPv6 specialists something = like >> this: >>> - should I click on '6rd' or '6to4' or on 'DHCPv6' or on 'PPPoE'? >>> - should I click on ULA or not? >>> - should I click on private addresses or not? >>> - should I click on Delegate inside when using Delegate from = outside, >>> or not? >=20 > So if you use a current IPv6 supporting CPE, normally you do nothing. >=20 > very occasionally you need to tick a box to enable it. >=20 > It is a mistake to assume that end users should be exposed to the > selection of transition technologies and that would ever be = appropriate > in the general case. I agree, this conversation is heading into the weeds here, at least for = closing off the arch text. Tim >>> - what should I fill in as next-hop address? >>> - what does "dotted-decimal notation" mean with IPv6 addresses? >>> (these are examples from existing consumer equipment for in-house) >>>=20 >> Wow! What parents! >> Mine would be more likely to ask "how do I turn this on?" >>=20 >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Tue Jun 17 11:03:16 2014 Return-Path: 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 3082F1A0111 for ; Tue, 17 Jun 2014 11:03:14 -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 0ob2xpqsfPbC for ; Tue, 17 Jun 2014 11:03:12 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC431A00FF for ; Tue, 17 Jun 2014 11:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7A603871518; Tue, 17 Jun 2014 20:03:11 +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 3CcbPSEiVCnj; Tue, 17 Jun 2014 20:03:11 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:9414:31c6:b314:6aa4]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 2A98387005A; Tue, 17 Jun 2014 20:03:11 +0200 (CEST) Message-ID: <53A082D0.2070008@globis.net> Date: Tue, 17 Jun 2014 20:02:56 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tim Chown References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ulKTx6c01q3hD5XrVT3hPD1BgXo Cc: Bellis Ray , "homenet@ietf.org Group" , Ted Lemon , Lorenzo Colitti Subject: Re: [homenet] Updates to Homenet Architecture Principles doc X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 18:03:14 -0000 > Tim Chown > 17 June 2014 18:11 > Hi Ray, > > I like your questions, and I think many of your own suggested answers > to your questions are in line with what I believe the WG has assumed > in its discussions. I find myself in agreement with most (and perhaps > all) of them. Glad to read that. > But obviously I can’t speak for the WG, only my perception of WG > consensus as the document editor. I certainly don't claim to speak for the WG : I just hope my contribution moves the discussion on in a constructive way. > > I would say we did shy away from a specific answer on a separate > configuration protocol in London, but since then HNCP has evolved. ACK. > I agree the multi-path clarification is needed. ACK. > > I think Alex is heading into too much detail, when we are trying to > avoid that (what Ray describes are general principles). > > I’m talking with Ted and the chairs on the approach to take. Expect > news soon :) Thanks. > > Tim > > > -- Regards, RayH From nobody Thu Jun 19 05:19:48 2014 Return-Path: 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 13EA81A0396 for ; Thu, 19 Jun 2014 05:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 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.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 N6DEgMPUOxwo for ; Thu, 19 Jun 2014 05:19:44 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4C11A0393 for ; Thu, 19 Jun 2014 05:19:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 72EE3A2; Thu, 19 Jun 2014 14:19:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1403180382; bh=6sjUZjX6F636RxHRXsopvDZTSy2BHh1h5nelw8ONPV4=; h=Date:From:To:Subject:In-Reply-To:References:From; b=RJXR1RQX4dpvn7UNhcnscP9kV+q0nwZyUKCbfYgUQv99PuiPEYfxDmXzC9I9lPtBD w/Oxjxbhmbvnr8OBSFDdwvdKUaIan70jPvpV5+YYe4PC85hPbdfQE4j01W43CLa88P v1Y7i7zeetLpx7wUXgdbjMfOx5q80nozXNLZOc1I= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6BECAA1 for ; Thu, 19 Jun 2014 14:19:42 +0200 (CEST) Date: Thu, 19 Jun 2014 14:19:42 +0200 (CEST) From: Mikael Abrahamsson To: homenet@ietf.org In-Reply-To: <20140612184351.6700.10752.idtracker@ietfa.amsl.com> Message-ID: References: <20140612184351.6700.10752.idtracker@ietfa.amsl.com> 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/n-Ntlbry3JXlJYfBnhJrSLwkkYk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-16.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 12:19:47 -0000 I decided to re-read the entire arch document frmo scratch. I have some comments. I don't mind shipping the document as-is, but I thought I'd write down my thoughts as I read the document. 1. "This means that Layer 2 is largely out of scope, we're assuming a data link layer that supports IPv6 is present, and that we react accordingly. Any IPv6-over-Foo definitions occur elsewhere." While I personally have no problem with the above, it kinds of breaks "tone" of the rest of the document. Using "foo" in this kind of document where before in the document things are very strict and formal, stands out. It also changes from an impersonal note to "we" all of a sudden in the middle of the paragraph. 1.1 FQDN should probably have a reference to an RFC or something? 2.2 First paragraph is long and complicated. Took me 3 reads to store enough information on the stack to be able to pop at the end to the context understand. In 2.2, there could be a mention added of users expecting their devices to not be reachable from the Internet and they historically have not been reachable, but when these devices are put on an IPv6 homenet, they are suddenly reachable if there is no filtering. Users might choose weak or no passwords because historically this has been fine. 2.3. With SLAAC, devices don't "receive" addresses. Perhaps write something about "addresses can exist within one prefix per ISP" or something of that effect? This section, "devices", does that mean the CER or devices the user connects to the CER, or both? 2.6, last paragraph. To make it more clear, I propose to change to "The widespread availability of robust solutions to these types of transition technologies requirements", since "these" refers to a previous paragraph and I was confused for a while what "these" actually referred to. GENERAL: Generally throughout the document it talks about "acquiring an address" or similar wording. Perhaps this could be changed to "acquires adress(es)" ? It has specific statements around end hosts having multiple addresses, but then reverts back to mentioning adresses in singular term. 3.3.5 seems very open ended and vague. What is "the homenet DHCP server"? I thought each router within the home could be a DHCP server for a subnet. Does homenet aim to solve this information spreading problem or is it out of scope, or we don't know at this time? 3.6.1 there is no "." at the end of the last paragraph. GENERAL: Since RFC6204 has been obsoleted by RFC7084, shouldn't we refer to 7084 instead of 6204? So... as I stated initially, the above is mostly "nitpicking" and I don't require a re-spin of the document just for my comments sake, but if the document is re-spun for other reasons perhaps some of my comments could be taken into account? Oh, just to be clear, I think this document is in good shape generally and I want it progressed. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jun 19 06:03:08 2014 Return-Path: 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 095521A039C for ; Thu, 19 Jun 2014 06:03:06 -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 RiybvlO0TGfR for ; Thu, 19 Jun 2014 06:03:04 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0D1A039A for ; Thu, 19 Jun 2014 06:03:03 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id E529B238039E; Thu, 19 Jun 2014 09:03:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Thu, 19 Jun 2014 09:03:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <610F4D7E-9229-4973-8D64-B2C7BF63DB46@fugue.com> References: <20140612184351.6700.10752.idtracker@ietfa.amsl.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/l39oKhMt0lcAdgbap813_Eqo0eY Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-16.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 13:03:06 -0000 On Jun 19, 2014, at 8:19 AM, Mikael Abrahamsson = wrote: > I decided to re-read the entire arch document frmo scratch. I have = some comments. I don't mind shipping the document as-is, but I thought = I'd write down my thoughts as I read the document. The working group is not allowed to make random changes to the document = at this late stage of the process. The reason I brought this back to = the working group was to address a specific point raised by an AD during = IESG review. Please do not discuss changes to other parts of the = document, because it will just waste the working group's time. If you = want to do a -bis, I of course have no problem with that, but let's not = discuss that now. From nobody Thu Jun 19 13:37:30 2014 Return-Path: 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 114121A0161 for ; Thu, 19 Jun 2014 13:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Qh9rmIgV8Ljx for ; Thu, 19 Jun 2014 13:37:28 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096A41A00E8 for ; Thu, 19 Jun 2014 13:37:27 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id ft15so2173894pdb.35 for ; Thu, 19 Jun 2014 13:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7aU6nx3BkIRW17nGwt6ANWU3aYMatOQtlrc/2PMxsR8=; b=NqF5oS/LXiJYKuIXBDTs6iwOBtG6urTgZtSWV00bc24SqljqxEv7oiYoZ8ENkio2WT 8sMbWqOrb7H9K04lzrsIuVcnu9Mcju3tzRoKMnwzVpTTdE18Atcf6t8BJu9X5J5qgx6w fk2lgyl6CEWkkLrwLrlNj34FShKKCAw2wvZRFTOKZsMAUmt495SrjgsCYDw6K6DmZFjX OsVD7PuoIqITRKJh5/Mu/8aZtqp5JQRFVc7udoc7a+ptHFRkH1PjKY9H9GySRUCTBEOi jRdPEHS9JUNp2C7dFWvzb2E88kftrPrjLuhzBAQAIzGt7pU+7XKIokwLMOYHXWmHad7Y LFrA== X-Received: by 10.66.66.202 with SMTP id h10mr8696222pat.70.1403210247661; Thu, 19 Jun 2014 13:37:27 -0700 (PDT) Received: from [192.168.178.23] (172.196.69.111.dynamic.snap.net.nz. [111.69.196.172]) by mx.google.com with ESMTPSA id xc1sm31777879pab.39.2014.06.19.13.37.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 13:37:27 -0700 (PDT) Message-ID: <53A34A0D.4050004@gmail.com> Date: Fri, 20 Jun 2014 08:37:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <20140612184351.6700.10752.idtracker@ietfa.amsl.com> <610F4D7E-9229-4973-8D64-B2C7BF63DB46@fugue.com> In-Reply-To: <610F4D7E-9229-4973-8D64-B2C7BF63DB46@fugue.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ph5goDet5hNibLCi14KWBZDIai8 Cc: homenet@ietf.org, Mikael Abrahamsson Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-16.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 20:37:29 -0000 On 20/06/2014 01:03, Ted Lemon wrote: ... > Please do not discuss changes to other parts of the document, because it will just waste the working group's time. Nevertheless, this nit Mikael noticed should be fixed: > Since RFC6204 has been obsoleted by RFC7084, shouldn't we refer to 7084 instead of 6204? Brian From nobody Thu Jun 19 19:04:44 2014 Return-Path: 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 1AAD81A0308 for ; Thu, 19 Jun 2014 19:04:42 -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 VQ-9HLg-cWaY for ; Thu, 19 Jun 2014 19:04:39 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 991981A016B for ; Thu, 19 Jun 2014 19:04:39 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 2AC5323803D4; Thu, 19 Jun 2014 22:04:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53A34A0D.4050004@gmail.com> Date: Thu, 19 Jun 2014 21:25:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D13B741-E57C-4334-B294-07466449F30F@fugue.com> References: <20140612184351.6700.10752.idtracker@ietfa.amsl.com> <610F4D7E-9229-4973-8D64-B2C7BF63DB46@fugue.com> <53A34A0D.4050004@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/e3dqDHW8UrfACuoRibydY7hYs8s Cc: homenet@ietf.org, Mikael Abrahamsson Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-16.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 02:04:42 -0000 On Jun 19, 2014, at 4:37 PM, Brian E Carpenter = wrote: >> Since RFC6204 has been obsoleted by RFC7084, shouldn't we refer to = 7084 instead of 6204?=20 This is something I'd expect the RFC editor to catch, but yes, sure. From nobody Thu Jun 19 22:07:46 2014 Return-Path: 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 970F01A020B for ; Thu, 19 Jun 2014 22:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 Fdcnj5675RJg for ; Thu, 19 Jun 2014 22:07:43 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626B71A01F5 for ; Thu, 19 Jun 2014 22:07:43 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F011A1B81EB for ; Thu, 19 Jun 2014 22:07:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D42A8190068 for ; Thu, 19 Jun 2014 22:07:42 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 22:07:42 -0700 From: Ted Lemon Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Fri, 20 Jun 2014 01:07:40 -0400 To: "homenet@ietf.org Group" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1tJwukaI3OPRuXv-VFbQzedcACM Subject: [homenet] Moving forward with the routing section of the architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 05:07:44 -0000 As Tim mentioned a couple of days ago, there has been some productive = discussion about how to fix the routing section of the architecture = document so that it satisfies the concerns that were raised during IESG = review. Ray Hunter posted a nice list of questions; I've asked him to = produce a first draft of a new version of this section. Once that's done, Tim will hold the pen on the text, and I would = obviously appreciate any feedback people can give on it. The text from = Ray will be a starting point, so if it's not what you think it should = be, please explain why and (if appropriate) send text. As I mentioned earlier, this will not be open season on the document=97the= IESG has already reviewed it, and making substantial changes at this = point that aren't addressing points raised in the IESG review is out of = scope. Thanks for whatever remaining patience you have to offer on this topic. From nobody Fri Jun 20 00:08:19 2014 Return-Path: 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 9D47C1B279D for ; Fri, 20 Jun 2014 00:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=unavailable 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 yJyRXE5N4qg5 for ; Fri, 20 Jun 2014 00:07:58 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7941A0654 for ; Fri, 20 Jun 2014 00:07:53 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=VDLK+nVx4XLrZUjfO1ABNSvKwTfZGUt1iVTY8KH5FKIyD/M1BpQ02oSK hYEm/aXMKqyQhJoBGp7+hE7H2zIKzyg8uLIIcYU/umcD32h3Ceu1/X8C8 Jl7g5JboYaGMXvXwyug+/MvZ+CuLln3H2X8nmQz7eRKXO3O/xXFPc6AC+ OUP3WZEX3EfqzbKUyPXJXpjl8MXUzzHrzhco26C74Asjl2stm6Ywrnqc4 tyA33Y50mfIvejgblqEyF0lVdlLaB; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1403248073; x=1434784073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sCIKfHVwk6igKlE7J2IrYuqy83oI9vRGZeHQ350ad3U=; b=w0BUcGUpabWBMoq+M2CRRnJgKFJWM0wKm13/M30gNiko60ZAnXAQ24sW 2rmIrSF9hH/ORK+ykoHPKhcAX9SSVc0hcD2ygW0fd/IbE+XaxhrwVspJ4 uF5wK1huF6WY/4I1oLlSB80tsjfENPo/dA0oDMQyBWRPtPGDX/3az1iXV Ppu1uZMdppF6qaC+9ajqlt+PpAVLxMgwqGlmD1MOZRRR490zB8cMfg/VV t81NC945gNo9MgUL8IZ2DhWuiQI+Q; X-IronPort-AV: E=Sophos;i="5.01,512,1400022000"; d="scan'208";a="10835909" X-IPAS-Result: AgoFAHTco1PV+MWR/2dsb2JhbABZgmkkgSzDUQGBAxZ1hAMBAQQBUyYFCwIBCBI0MhcOAgQOBYg6CQPLaheOQzMHgy2BFgSuG4IAgUKCMA Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 20 Jun 2014 08:07:51 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 08:07:51 +0100 From: Ray Bellis To: Ted Lemon Thread-Topic: [homenet] Moving forward with the routing section of the architecture document Thread-Index: AQHPjEWYxIRBLcJzlk6lS+OTGaENWJt5g2OA Date: Fri, 20 Jun 2014 07:07:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: <95AF42510B53BA4CA596B7A0FA0AAB73@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/pykXp6L7CMWRY2On1uvJ48OLlj8 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Moving forward with the routing section of the architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 07:08:09 -0000 On 20 Jun 2014, at 06:07, Ted Lemon wrote: > Thanks for whatever remaining patience you have to offer on this topic. and thanks Ted and Mark, for keeping this in shape while I've been off sick= . Ray From nobody Fri Jun 20 06:33:43 2014 Return-Path: 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 3D1A11A0384 for ; Fri, 20 Jun 2014 06:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, 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 sF6tnLcDvgcL for ; Fri, 20 Jun 2014 06:33:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AA51A038C for ; Fri, 20 Jun 2014 06:33:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5KDXVAQ018202 for ; Fri, 20 Jun 2014 15:33:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AC4BC204421 for ; Fri, 20 Jun 2014 15:35:21 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A46C1204409 for ; Fri, 20 Jun 2014 15:35:21 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5KDXF2F020624 for ; Fri, 20 Jun 2014 15:33:31 +0200 Message-ID: <53A4381B.40405@gmail.com> Date: Fri, 20 Jun 2014 15:33:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: homenet@ietf.org References: <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> In-Reply-To: <539C51BA.6030901@globis.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/OPvLEorxIPImm73vzsR0n4JLG3U Subject: Re: [homenet] list of questions on routing section (was: Updates to Homenet Architecture Principles doc) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 13:33:42 -0000 Le 14/06/2014 15:44, Ray Hunter a écrit : [...] > Does the Homenet Architecture require the routing protocol to carry > arbitrary configuration information? > [my view] No. Assuming the existence of a separate Homenet configuration > protocol, the routing protocol must facilitate auto-configuration, but > does not necessarily have to supply configuration to other processes. > [this is not currently explicitly defined the architecture document AFAICS] I agree a routing protocol in-house would not need to carry parameters such as printer's name. > Does the Homenet Architecture require the routing protocol to support > multiple address families? > [my view] No. The Homenet architecture is IPv6 only. Although support > for IPv4 and other address families may be beneficial, it is not an > explicit requirement to carry the routing information in the same > routing protocol. > [this is not currently in the architecture document AFAICS] I think the routing protocol must unconditionally support IPv6 natively and, if needed in some cases, IPv4. > Does the Homenet Architecture require the routing protocol to support SADR? > [my view] Yes. > [this is in the current architecture document] I think the routing protocol specs should include fields for source addresses (in addition to the traditional next-hop addresses), in order to facilitate source-and-destination rule matching in the routing tables. But I dont think the routing protocol would implement anything more than carrying fields specific to sources. > "A routing protocol that can make routing > decisions based on source and destination addresses is thus > desirable, to avoid upstream ISP BCP 38 ingress filtering problems." I doubt the routing _protocol_ makes decisions about that. > Does the Homenet Architecture require the routing protocol to be > tolerant of lossy unstable links? > [my view] Yes. > [this is in the current architecture document] > "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." Certainly yes. But this mentioning of MoCA makes wonder about a document IP-over-MoCA, which wouldn't be developped here, but would be necessary. If IP does not run over MoCA then the coexistence statement above would make little sense. Then, for the metric parameters, in addition to bandwidth, loss and latency, some parameters such as link energy consumption, or radiated energy, would make sense. > Does the Homenet Architecture explicitly require use of a distance > vector or link state algorithms? > [my view] No. The Homenet architecture should be agnostic on this point. > [this is not currently in the architecture document AFAICS] Yes, I agree. Any one of distance-vector, link-state, path-vector or any combination, should be selectable. A particular existing routing protocol should not be discarded solely on grounds of its link-state or distance-vector characteristic. It's invalid to say "in-house routing can not be satisfied by a link-state protocol". And there are other such characteristics: on-demand vs triggered, proactive vs reactive. > Does the Homenet Architecture need an EGP or an IGP? > [my view] An IGP. > [this is in the current architecture document] > This implies that internal routing > functionality is required, and that the homenet's ISP both provides a > large enough prefix to allocate a prefix to each subnet, and that a > method is supported for such prefixes to be delegated efficiently to > those subnets. I agree. > Is there a minimum hop count limit that must be supported? > [my view] No. The Homenet architecture is agnostic on this point, > although use of Homenet in small offices and small enterprise site may > require higher hop counts. > [this is not currently in the architecture document AFAICS] I agree, and I'd go as far as citing numbers. A typical in-house network would use 1, 3 to maximum 5 hops between any two most distanced nodes (hop limit decremented 5 times max). It would link typical maximum of 255 uniquely IP-addressable interfaces. A SOHO and small enterprise would require higher hop counts. > Is there a penalty for the protocol being chatty? > [my view] No. LLN is not envisaged to be used as a transit network, and > as such would be connected by a gateway router. > It is not envisaged that there will be significant limits on bandwidth > consumption or Homenet routers having to sleep for power efficiency. > [this is not currently in the architecture document AFAICS] Yes, but chattiness in-house may translate into higher electricity bill. Some people go as far as switching off the entire electricity when leaving home. Adding a new protocol reads maybe as adding something new to switch off. > > [The current text is in relation to LLN only] > > In general, message > utilisation should be efficient considering the network technologies > and constrained devices that the service may need to operate over. > > [plus the need for diverse routing metrics to cover a large range of > bandwidths, but I can't see any requirements on the routing protocol > itself.] Yes, diverse routing metrics (more metrics than the existing bandwidth, hop-count, link "quality"). > Is a specific update address preferred? > [my view] The routing protocol should support both use of unicast and > multicast updates. > [this is not currently in the architecture document AFAICS although you > could argue it is covered by] I agree. > > Further, link layer networking technology is > poised to become more heterogeneous, as networks begin to employ both > traditional Ethernet technology and link layers designed for low- > power and lossy networks (LLNs), such as those used for certain types > of sensor devices. I agree, but the phrasing could be improved. BEcause it reads as if LLNs dont use Ethernet technology, whereas the 802.15.4 LLN link does involve Ethernet headers. > Scalability? > [my view] The protocol should scale up to ±50 routers? > [this is not currently in the architecture document AFAICS] I agree, this needs to be mentioned. There is another question above mentioning number of hops, which could also be about scalability. > Proprietary protocols allowed or protocols requiring Intellectual > Property agreements? > [my view] No. Must not be proprietary or be limited by IP. > [this is not currently in the architecture document AFAICS] Hmm... this is difficult to discuss. But one is obviously aware that IPR (Intelectual Property Rights) is tagged on a number of widely used routing protocols. > > > Multi-path support? > [my view] yes. > [this is in the current architecture document] > "The inclusion of physical layer > characteristics including bandwidth, loss, and latency in path > computation should be considered for optimising communication in the > homenet." I think multi-path means something along the lines of MP-TCP? (not sure what multipath is in the context of e.g. OSPF). > Resource Consumption Limits? > [my view] Yes. Should be light weight with a small footprint suitable > for inclusion into consumer products. > [this is not currently in the architecture document AFAICS] Yes, I agree. > Explicit support for Ad Hoc networks? > [my view] I don't know. > [this is not currently in the architecture document AFAICS] There could be an architectural requirement about the support of dynamically changing networks, but not sure about ad-hoc networks. Maybe we could say something about proactive/reactive protocols (a term typically used in ad-hoc network discussions), or about the link characteristics of radio links (also often used in ad-hoc network discussions). > Make your own mind up whether the current text is sufficient to cover > all necessary requirements, without being unnecessarily over-specified. I would see a requirement about DHCP Relay-Server discovery and configuration but I am not sure how to formulate it at architectural level. I see the need to plug an 802.11ac Access Point on an in-house network, it self-configures from the existing DHCP Servers and then delivers IPv6 addresses to Clients. This is a 'research' kind of functionality. Alex > From nobody Fri Jun 20 06:49:00 2014 Return-Path: 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 3A51F1A039A for ; Fri, 20 Jun 2014 06:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, 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 KahOYBmKqoyL for ; Fri, 20 Jun 2014 06:48:54 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F501A0354 for ; Fri, 20 Jun 2014 06:48:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5KDmraP026245; Fri, 20 Jun 2014 15:48:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E37C120449C; Fri, 20 Jun 2014 15:50:42 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D047620449A; Fri, 20 Jun 2014 15:50:42 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5KDmb4O031710; Fri, 20 Jun 2014 15:48:52 +0200 Message-ID: <53A43BB5.9080503@gmail.com> Date: Fri, 20 Jun 2014 15:48:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gert Doering References: <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <539C51BA.6030901@globis.net> <53A4381B.40405@gmail.com> <20140620134458.GL46558@Space.Net> In-Reply-To: <20140620134458.GL46558@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zT57GgO9xdMjpPIpxpMv53cYy9A Cc: "homenet@ietf.org" Subject: Re: [homenet] list of questions on routing section X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 13:48:57 -0000 Le 20/06/2014 15:44, Gert Doering a écrit : > Hi, > > On Fri, Jun 20, 2014 at 03:33:15PM +0200, Alexandru Petrescu wrote: >> I would see a requirement about DHCP Relay-Server discovery and >> configuration but I am not sure how to formulate it at architectural level. > > I see a very strong need for you to read up on the homenet drafts *before* > trying to add your valuable input. > > Really. 90% of what you have written is either covered by the drafts already, > or fully out of scope. You are wasting people's time. > > Gert Doering > -- NetMaster > Sorry about that - please ignore that email. Alex From nobody Wed Jun 25 02:22:01 2014 Return-Path: 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 DCF3D1B2B17; Wed, 25 Jun 2014 02:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4IKOcUVvgGwe; Wed, 25 Jun 2014 02:21:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9ECF1B2B33; Wed, 25 Jun 2014 02:21:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140625092155.7782.72546.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 02:21:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/rjScbZJt6-AW8h87JPugPvTq6Uw Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-hncp-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 09:21:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Control Protocol Authors : Markus Stenberg Steven Barth Filename : draft-ietf-homenet-hncp-01.txt Pages : 28 Date : 2014-06-25 Abstract: This document describes the Home Networking Control Protocol (HNCP), a minimalist state synchronization protocol for Homenet routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-hncp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 25 02:28:16 2014 Return-Path: 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 F23CA1B2B24 for ; Wed, 25 Jun 2014 02:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 RFGrTJxSe5wu for ; Wed, 25 Jun 2014 02:28:08 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id A9A461B2B27 for ; Wed, 25 Jun 2014 02:28:07 -0700 (PDT) Received: from poro.lan (84.248.74.106) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A1810C007D5B69; Wed, 25 Jun 2014 12:28:06 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <20140625092155.7782.72546.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 12:28:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140625092155.7782.72546.idtracker@ietfa.amsl.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Vrn7kEGP2r_IDT6o6O0TP7mG04o Cc: Markus Stenberg Subject: Re: [homenet] I-D Action: draft-ietf-homenet-hncp-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 09:28:14 -0000 Changelog text: draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid=09 categories for interfaces. Removed old hnetv2 reference, and = now=09 pointing just to OpenWrt + github. Fixed synchronization = algorithm=09 to spread also same update number, but different data hash = case.=09 Made purge step require bidirectional connectivity between = nodes when=09 traversing the graph. Edited few other things to be = hopefully=09 slightly clearer without changing their meaning. I also bumped the SD draft with minor edits, and PA draft will be = updated soon by Pierre P. Finally, there will be preliminary separate security draft on how to = really secure HNCP hopefully by the deadline too. Cheers, -Markus From nobody Thu Jun 26 23:35:08 2014 Return-Path: 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 BB8F91B315F for ; Thu, 26 Jun 2014 23:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 d3fMbd4_O9rg for ; Thu, 26 Jun 2014 23:35:00 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7281B30BC for ; Thu, 26 Jun 2014 23:35:00 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A17F6000A5881E; Fri, 27 Jun 2014 09:34:59 +0300 From: Markus Stenberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jun 2014 09:34:59 +0300 Message-Id: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7ng-afH-vxyfzz6XqZPH5pZmONA Cc: Markus Stenberg Subject: [homenet] Securing HNCP - comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:35:04 -0000 (This could have been a draft too, but I=92m starting my vacation soon = and I don=92t want to post any more of those. Sorry.-Markus) Current HNCP draft specifies security very vaguely, as it was originally = based on just some napkin thoughts last year on =91it would be nice to = have authenticated TLVs=92. However, what are we protecting against, how, and should we go through = the trouble at all? For all of these attacks, we have to assume _some_ = network level access to a home network. Let us consider potential attacks and their applicability on a home = network: [1] Pretend to be a client: no, we cannot protect against this, all = clients are not currently authenticated and not in foreseeable future = either. 802.1x not to even mention MACSec support on wired ports is = mostly nonexistent in home routers. [2] Replace upstream router on the upstream link. We cannot do anything = about this, and as your packets already go to e.g. NSA, assumption of = privacy is moot so this battle is lost. This attack may be harder to = mount due to upstream link being typically wired, hard to reach, etc. [3] Pretend to be upstream router on some other link. We can protect = against this with fixed categories of interfaces, but securing HNCP has = nothing to do with it as upstream router doesn=92t talk HNCP. [4] Pretend to be an inner router.=20 What are their implications? [1]: Any resource in-home _can_ be accessed and there is not much that = can be done given access to a non-guest link.=20 [2,3]: Any traffic on the Internet is public (and what else is new?). [4]: If impersonation is possible, man-in-the-middle and potentially = denial of service attacks on home network become possible. How could [4] be prevented then? In ascending order of complexity.. [S4-1] Manual configuration of categories overriding automated border = discovery. Defining either in the actual router product, or via = configuration which interfaces to talk HNCP (and RP) on, where potential = upstream links may never be, can be or always are. [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual = keying as currently specified in the draft. Setting up the shared PSK = for the set of routers is left to the as manual configuration exercise = for the owner of the devices. [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as = [S4-2], may be able to get rid of manually keyed IPsec dependency. [S4-4] Some public key cryptography solution operating with just raw = keys (there is a draft in the works on how to do this in HNCP) [S4-5] Some public key cryptography solution with CA hierarchy (similar = to behringer-bootstrap) The big question is, are the S4-3+ really worth it? And what is the sane = way to do it if they are? Can we actually become RFC with just S4-1 and = S4-2? In case we go for public key-cryptography: what do we do about = routing protocols mostly relying on shared secrets for authentication? =20 - Markus and Steven From nobody Thu Jun 26 23:51:08 2014 Return-Path: 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 A8CDF1B3171 for ; Thu, 26 Jun 2014 23:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 YL0qRuCD2_32 for ; Thu, 26 Jun 2014 23:51:03 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975FF1B2AD4 for ; Thu, 26 Jun 2014 23:51:03 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id l6so5148100oag.14 for ; Thu, 26 Jun 2014 23:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xc1I+4lfx7Dz/S7dTQE3xixhrWp5SEAVoAackvC0+NE=; b=PBCOKKJj4nlX/BY3wZMwCruk+WdFyVEr59/kM/Mj9S6q+gpik9Lw1FI2VP050klVrn U20Ck0Eae+qreg5+HW5uV5m/AFo09ccSYTMnE64rNwv8EWgyBQvjRwAW18d3ELDLOgHi uD9ipfo6JCZlLqu0nIZ3n6Htv0jIuAw1LmAmYlyabhJ2fMaDMHW5yJCFmdqK7slDHkFk cXPvFjA5PvAfFuQswa+HeZ3wrFFept02Y8ioLlP9P1sEc5EUAJh+pyYQkMm0oSabfbD4 Lx6ng4DSRrXOhZ9WWYZwG6cCfRDFg3k9Nc4gqMmAxQnxIHM5pd3iO+e1i0rG8Vt598vW jqOw== MIME-Version: 1.0 X-Received: by 10.182.246.73 with SMTP id xu9mr21230162obc.63.1403851862038; Thu, 26 Jun 2014 23:51:02 -0700 (PDT) Received: by 10.202.48.200 with HTTP; Thu, 26 Jun 2014 23:51:01 -0700 (PDT) In-Reply-To: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> References: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> Date: Thu, 26 Jun 2014 23:51:01 -0700 Message-ID: From: Dave Taht To: Markus Stenberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ReG5C21XVQw2n3qpLzuGPYW5or0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Securing HNCP - comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:51:06 -0000 I have been watching this draft evolve now for a while, on authenticated routing exchanges. Perhaps it would provide some insight on 3 and 4 below. http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-09 running code (in quagga, only, at present). On Thu, Jun 26, 2014 at 11:34 PM, Markus Stenberg wrote: > (This could have been a draft too, but I=E2=80=99m starting my vacation s= oon and I don=E2=80=99t want to post any more of those. Sorry.-Markus) > > Current HNCP draft specifies security very vaguely, as it was originally = based on just some napkin thoughts last year on =E2=80=98it would be nice t= o have authenticated TLVs=E2=80=99. > > However, what are we protecting against, how, and should we go through th= e trouble at all? For all of these attacks, we have to assume _some_ networ= k level access to a home network. > > Let us consider potential attacks and their applicability on a home netwo= rk: > > [1] Pretend to be a client: no, we cannot protect against this, all clien= ts are not currently authenticated and not in foreseeable future either. 80= 2.1x not to even mention MACSec support on wired ports is mostly nonexisten= t in home routers. > > [2] Replace upstream router on the upstream link. We cannot do anything a= bout this, and as your packets already go to e.g. NSA, assumption of privac= y is moot so this battle is lost. This attack may be harder to mount due to= upstream link being typically wired, hard to reach, etc. To me an authenticated exchange could add meat to the "I'm home", or "at work" concepts much like how windows works today. Homeplug devices, for example, have the concept of "pairing", as does bluetooth, and a few other technologies. We're still screwed on rogue routers by things like mac spoofing, but at a higher level you could periodically be doing a challenge/response to the gateway router to ensure you are talking to the right thing, or (as per the above link) prefer authenticated routes. > [3] Pretend to be upstream router on some other link. We can protect agai= nst this with fixed categories of interfaces, but securing HNCP has nothing= to do with it as upstream router doesn=E2=80=99t talk HNCP. > > [4] Pretend to be an inner router. > > What are their implications? > > [1]: Any resource in-home _can_ be accessed and there is not much that ca= n be done given access to a non-guest link. What often happens today is a mac filter list, which is somewhat effective. > [2,3]: Any traffic on the Internet is public (and what else is new?). How does this bear on hncp? > > [4]: If impersonation is possible, man-in-the-middle and potentially deni= al of service attacks on home network become possible. impersonation in a routed environment has some interesting subtleties to it= . Take a world where you have a rogue device participate in the local routing protocol and announce that it's on 75.75.75.75 (comcast's dns), or 8.8.8.8, but is really acting as a dns server and sending upstream requests to a rogue dns server (a-la dnschanger) (this is partially why I made a big push to put bcp38 on, on, in cerowrt, by default) > > How could [4] be prevented then? In ascending order of complexity.. > > [S4-1] Manual configuration of categories overriding automated border dis= covery. Defining either in the actual router product, or via configuration = which interfaces to talk HNCP (and RP) on, where potential upstream links m= ay never be, can be or always are. > > [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual keyi= ng as currently specified in the draft. Setting up the shared PSK for the s= et of routers is left to the as manual configuration exercise for the owner= of the devices. > > [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as = [S4-2], may be able to get rid of manually keyed IPsec dependency. > > [S4-4] Some public key cryptography solution operating with just raw keys= (there is a draft in the works on how to do this in HNCP) > > [S4-5] Some public key cryptography solution with CA hierarchy (similar t= o behringer-bootstrap) > > The big question is, are the S4-3+ really worth it? And what is the sane = way to do it if they are? Can we actually become RFC with just S4-1 and S4-= 2? In case we go for public key-cryptography: what do we do about routing p= rotocols mostly relying on shared secrets for authentication? > > - Markus and Steven > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Sat Jun 28 00:43:29 2014 Return-Path: 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 43FDB1A030D for ; Sat, 28 Jun 2014 00:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0Ib9M6abc4Hc for ; Sat, 28 Jun 2014 00:43:26 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 56CF51A030E for ; Sat, 28 Jun 2014 00:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 23F16871515; Sat, 28 Jun 2014 09:43:25 +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 1IJi-zHxz-+e; Sat, 28 Jun 2014 09:43:25 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:14d8:7082:54cf:52cb]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id E146F871513; Sat, 28 Jun 2014 09:43:24 +0200 (CEST) Message-ID: <53AE7209.7080408@globis.net> Date: Sat, 28 Jun 2014 09:43:05 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Markus Stenberg References: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> In-Reply-To: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/RiRg--rHdmwOj0V58DrYU1NthWA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Securing HNCP - comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 07:43:28 -0000 inline Markus Stenberg wrote: > (This could have been a draft too, but I’m starting my vacation soon and I don’t want to post any more of those. Sorry.-Markus) > > Current HNCP draft specifies security very vaguely, as it was originally based on just some napkin thoughts last year on ‘it would be nice to have authenticated TLVs’. > > However, what are we protecting against, how, and should we go through the trouble at all? For all of these attacks, we have to assume _some_ network level access to a home network. > > Let us consider potential attacks and their applicability on a home network: > > [1] Pretend to be a client: no, we cannot protect against this, all clients are not currently authenticated and not in foreseeable future either. 802.1x not to even mention MACSec support on wired ports is mostly nonexistent in home routers. > > [2] Replace upstream router on the upstream link. We cannot do anything about this, and as your packets already go to e.g. NSA, assumption of privacy is moot so this battle is lost. This attack may be harder to mount due to upstream link being typically wired, hard to reach, etc. > > [3] Pretend to be upstream router on some other link. We can protect against this with fixed categories of interfaces, but securing HNCP has nothing to do with it as upstream router doesn’t talk HNCP. > > [4] Pretend to be an inner router. > > What are their implications? > > [1]: Any resource in-home _can_ be accessed and there is not much that can be done given access to a non-guest link. > > [2,3]: Any traffic on the Internet is public (and what else is new?). > > [4]: If impersonation is possible, man-in-the-middle and potentially denial of service attacks on home network become possible. > > How could [4] be prevented then? In ascending order of complexity.. > > [S4-1] Manual configuration of categories overriding automated border discovery. Defining either in the actual router product, or via configuration which interfaces to talk HNCP (and RP) on, where potential upstream links may never be, can be or always are. > > [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual keying as currently specified in the draft. Setting up the shared PSK for the set of routers is left to the as manual configuration exercise for the owner of the devices. > > [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as [S4-2], may be able to get rid of manually keyed IPsec dependency. > > [S4-4] Some public key cryptography solution operating with just raw keys (there is a draft in the works on how to do this in HNCP) > > [S4-5] Some public key cryptography solution with CA hierarchy (similar to behringer-bootstrap) > > The big question is, are the S4-3+ really worth it? And what is the sane way to do it if they are? Can we actually become RFC with just S4-1 and S4-2? In case we go for public key-cryptography: what do we do about routing protocols mostly relying on shared secrets for authentication? > > - Markus and Steven Powerline Ethernet devices have built in encryption, so I think consumers do expect some level of protection from accidental neighbouring. I agree with you questioning whether this should be solved at L2 or L3 and above. Assuming the solution has to be defined at L3 and above, I think due to the lack of any hierarchy, or root node, that you're going to have to have individual keys/signatures per device, and that you cannot assume existence of a central keying repository. S4-1 could work but relies on consumers plugging in devices into the correct ports. S4-2 does not meet the requirement for auto-configuration. S4-3 could work if you could bootstrap it, but that is not trivial either because it is chicken/egg. I don't see S5-5 flying: there is no natural root node or root CA. The problem seems to boil down to "how can we bootstrap the trust" regardless of the encryption technology. Assuming S4-3 or S4-4, when a new device is added to the network (as opposed to existing devices being replugged) you could check it against a (distributed) DB of existing pairing keys (via TBD service discovery technology). If a device hasn't paired to at least one other homenet device, HNCP messages from this device is ignored until it has. Initiating the pairing should be as simple for the end user as pressing a button on 2 connected devices (nearly) simultaneously (one new and one already in the web of trust) so that both devices go into pairing mode and learn a new HNCP pairing. Once homenet is (relatively) stable, you would also be able to flood the new pairing to all other devices in the web of trust for potential long term storage. At some point you might end up seeing old devices you've given to your neighbour, so there should also be a way of clearing the pairing DB for a specific device, or automatically flushing entries for devices that have not been seen since time X. Alternative is that you have to put all devices in homenet into pairing mode simultaneously, but that may become less practical as the number of routers increases. IF you can establish trust using HNCP (an expensive operation), it could be the basis for all other trust in the Homenet, so it is potentially a big win. e.g. To negotiate any necessary shared key for routing or other common Homenet wide parameters: think election of the root bridge in 802.1 and then that root device chooses a common shared key. Obviously distribution of the resulting shared keys from the root is going to have to be encrypted. I can certainly see this solution sketch requiring a lot of code. -- Regards, RayH From nobody Mon Jun 30 00:31:10 2014 Return-Path: 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 313421A0198 for ; Mon, 30 Jun 2014 00:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 gHFuEboxJSl0 for ; Mon, 30 Jun 2014 00:31:07 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id E96131A0197 for ; Mon, 30 Jun 2014 00:31:06 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A17E3E00D9A34F; Mon, 30 Jun 2014 10:31:03 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <53AE7209.7080408@globis.net> Date: Mon, 30 Jun 2014 10:31:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6EF005E6-2DD6-4B64-904A-2D8F9F2150BC@iki.fi> References: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> <53AE7209.7080408@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lujV0f_aVWcT2BLOQMrFMQ9Vmsc Cc: "homenet@ietf.org Group" , Markus Stenberg Subject: Re: [homenet] Securing HNCP - comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 07:31:09 -0000 On 28.6.2014, at 10.43, Ray Hunter wrote: >> How could [4] be prevented then? In ascending order of complexity.. >>=20 >> [S4-1] Manual configuration of categories overriding automated border = discovery. Defining either in the actual router product, or via = configuration which interfaces to talk HNCP (and RP) on, where potential = upstream links may never be, can be or always are. >>=20 >> [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual = keying as currently specified in the draft. Setting up the shared PSK = for the set of routers is left to the as manual configuration exercise = for the owner of the devices. >>=20 >> [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues = as [S4-2], may be able to get rid of manually keyed IPsec dependency. >>=20 >> [S4-4] Some public key cryptography solution operating with just raw = keys (there is a draft in the works on how to do this in HNCP) >>=20 >> [S4-5] Some public key cryptography solution with CA hierarchy = (similar to behringer-bootstrap) >>=20 >> The big question is, are the S4-3+ really worth it? And what is the = sane way to do it if they are? Can we actually become RFC with just S4-1 = and S4-2? In case we go for public key-cryptography: what do we do about = routing protocols mostly relying on shared secrets for authentication? >>=20 >> - Markus and Steven > Powerline Ethernet devices have built in encryption, so I think = consumers do expect some level of protection from accidental = neighbouring. I agree with you questioning whether this should be solved = at L2 or L3 and above. Same thing with WPA* too of course. So I=92m very tempted to assume L2 = takes care of security.. ;) > Assuming the solution has to be defined at L3 and above, I think due = to the lack of any hierarchy, or root node, that you're going to have to = have individual keys/signatures per device, and that you cannot assume = existence of a central keying repository. >=20 > S4-1 could work but relies on consumers plugging in devices into the = correct ports. S4-2 does not meet the requirement for = auto-configuration. S4-3 could work if you could bootstrap it, but that = is not trivial either because it is chicken/egg. I don=92t see S5-5 = flying: there is no natural root node or root CA. S4-2 and S4-3 have same characteristics in my view - they need some = (consensus) way to generate PSK, that is then either a) fed to IPsec as = manually keyed SA, or b) used to encrypt-authenticate content in the = protocol. S4-[45] have built-in ways of bootstrapping that are absent from = S4-2/S4-3 as I see them. > The problem seems to boil down to "how can we bootstrap the trust" = regardless of the encryption technology. Assuming S4-3 or S4-4, when a = new device is added to the network (as opposed to existing devices being = replugged) you could check it against a (distributed) DB of existing = pairing keys (via TBD service discovery technology). If a device hasn't = paired to at least one other homenet device, HNCP messages from this = device is ignored until it has. Initiating the pairing should be as = simple for the end user as pressing a button on 2 connected devices = (nearly) simultaneously (one new and one already in the web of trust) so = that both devices go into pairing mode and learn a new HNCP pairing. = Once homenet is (relatively) stable, you would also be able to flood the = new pairing to all other devices in the web of trust for potential long = term storage. At some point you might end up seeing old devices you've = given to your neighbour, so there should also be a way of clearing the = pairing DB for a specific device, or automatically flushing entries for = devices that have not been seen since time X. Alternative is that you = have to put all devices in homenet into pairing mode simultaneously, but = that may become less practical as the number of routers increases. > IF you can establish trust using HNCP (an expensive operation), it = could be the basis for all other trust in the Homenet, so it is = potentially a big win. e.g. To negotiate any necessary shared key for = routing or other common Homenet wide parameters: think election of the = root bridge in 802.1 and then that root device chooses a common shared = key. Obviously distribution of the resulting shared keys from the root = is going to have to be encrypted. Yeah, I agree that this scheme (on high level) is what seems sensible = _given_ the assumption you want to do the trust handling within HNCP. > I can certainly see this solution sketch requiring a lot of code. Indeed, and be also nontrivial to specify and interoperably implement. = Sigh. So back to the original question, anyone have any idea if this stuff = _must_ be implemented, really, beyond hand-wavy S4-1 and S4-2? Looking = at Babel, the routing protocol spec is 45 pages, and draft specification = of HMAC security scheme for it is 55 pages. I sense some slight = imbalance somewhere. Cheers, -Markus= From nobody Mon Jun 30 03:53:31 2014 Return-Path: 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 B02491A01F4 for ; Mon, 30 Jun 2014 03:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35] autolearn=no 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 kOUx4dYRLcNd for ; Mon, 30 Jun 2014 03:53:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 0909D1A01F9 for ; Mon, 30 Jun 2014 03:53:26 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s5UArOwi026990; Mon, 30 Jun 2014 12:53:24 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D42DA2BEF25; Mon, 30 Jun 2014 12:53:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id g2NklzSYMYVv; Mon, 30 Jun 2014 12:53:23 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 030592BEF2D; Mon, 30 Jun 2014 12:53:21 +0200 (CEST) Date: Mon, 30 Jun 2014 12:53:22 +0200 Message-ID: <87egy6brdp.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Markus Stenberg In-Reply-To: <6EF005E6-2DD6-4B64-904A-2D8F9F2150BC@iki.fi> References: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> <53AE7209.7080408@globis.net> <6EF005E6-2DD6-4B64-904A-2D8F9F2150BC@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 30 Jun 2014 12:53:25 +0200 (CEST) X-Miltered: at korolev with ID 53B141A4.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B141A4.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53B141A4.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0Q9L2Gp288XHTPyq21fydDXC69s Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Securing HNCP - comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 10:53:28 -0000 >> Powerline Ethernet devices have built in encryption, > Same thing with WPA* too of course. So I’m very tempted to assume L2 > takes care of security.. ;) Guest networks? However, I think it is premature to define a secure variant of HNCP before we have some operational experience with the protocol. It's only after we've played with it for some time that will we get a feel for what are reasonable and unreasonable operations to perform. > just use e.g. IPsec with manual keying Vulnerable to replay if done naively. Not sure about the configuration protocol, but definitely an issue for a routing protocol -- just capture a default route announcement with a low metric, and you've won. > [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as > [S4-2], may be able to get rid of manually keyed IPsec dependency. It appears that you are only looking at hop-to-hop security. I'm speaking off the top of my head here, so I'm probably saying something stupid. What about end-to-end solutions, where only routers with a trusted key can originate configuration information? This could perhaps be combined with a leap-of-faith model (a la ssh). > Looking at Babel, the routing protocol spec is 45 pages, and draft > specification of HMAC security scheme for it is 55 pages. Yeah, wouldn't it be nice if we had a common layer 3 security protocol? (We would make sure that it's actually usable before standardisation, of course.) -- Juliusz From SRS0=Tbh8=33=darou.fr=pierre.pfister@bounces.m4x.org Mon Jun 30 08:19:04 2014 Return-Path: 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 1C2351A0369 for ; Mon, 30 Jun 2014 08:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 98ULxm7mzF8z for ; Mon, 30 Jun 2014 08:19:00 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4FB1A039A for ; Mon, 30 Jun 2014 08:18:58 -0700 (PDT) Received: from [10.148.10.42] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 1A62E1408EEE0 for ; Mon, 30 Jun 2014 17:18:55 +0200 (CEST) From: Pierre Pfister Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 30 Jun 2014 17:18:54 +0200 To: HOMENET Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Mon Jun 30 17:18:56 2014 +0200 (CEST)) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/TXpxtxIb8ooLv3YcuoQJ3T9Vmdc Subject: [homenet] homenet-prefix-assignment update X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 15:19:27 -0000 Hello group, I=92d like to inform you about the changes made in the two last = homenet-prefix-assignment updates. http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02 The changes are mostly about fixing typos, but a few technical changes = have been made as well (based on the experience gained from the = implementation of the Prefix Assignment Algorithm over HNCP). =97 Changes between 00 and 01 - If a Delegated Prefix is included in another Delegated Prefix, it is = ignored. This is intended to improve support for non-homenet routers = that provide prefix sub-delegation. That way, sub-delegated prefixes are = ignored. - Adding network leader definition (The router with the highest = identifier). - Add a section about DHCPv6 downstream prefix delegation. For = downstream RFC7084 routers support. - Adding Delegated Prefix deprecation procedure in order to = differentiate prefix deprecation and node disconnection. When a node = disconnect, the DPs advertised by this node may be kept some time = (depending on the DP's lifetimes). But if a DP is actively deprecated, = nodes must stop using it immediately.=20 =97 Changes between 01 and 02 - Designated router election can make use of the information provided by = the flooding protocol (i.e. when no router is designated yet, only the = highest router id present on the link can become designated). - New implementation guideline in appendix concerning "prefix waste = avoidance". It proposes an algorithm that provides a good trade-of = between randomness, pseudo-randomness and prefix selection efficiency. Comments are welcome, Pierre Pfister= From nobody Mon Jun 30 09:23:51 2014 Return-Path: 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 C0D011A03AB for ; Mon, 30 Jun 2014 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 9zIQX77Avtx9 for ; Mon, 30 Jun 2014 09:23:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D601A0392 for ; Mon, 30 Jun 2014 09:23:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E184020028 for ; Mon, 30 Jun 2014 12:23:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4DEE463B0E; Mon, 30 Jun 2014 12:23:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 37F4363B09 for ; Mon, 30 Jun 2014 12:23:36 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org Group" In-Reply-To: <87egy6brdp.wl%jch@pps.univ-paris-diderot.fr> References: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> <53AE7209.7080408@globis.net> <6EF005E6-2DD6-4B64-904A-2D8F9F2150BC@iki.fi> <87egy6brdp.wl%jch@pps.univ-paris-diderot.fr> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/K8WQJopa9d_VGUlDTC7BnK9TCvA Subject: Re: [homenet] Securing HNCP - comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:23:47 -0000 --=-=-= Juliusz Chroboczek wrote: >> just use e.g. IPsec with manual keying > Vulnerable to replay if done naively. Not sure about the configuration > protocol, but definitely an issue for a routing protocol -- just capture > a default route announcement with a low metric, and you've won. If one goes with 64-bit replay counters, and enable the replay protection, and we have a relatively low data rate, we can get some protection, but we have to plan that we eventually rekey. >> [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as >> [S4-2], may be able to get rid of manually keyed IPsec dependency. > It appears that you are only looking at hop-to-hop security. > I'm speaking off the top of my head here, so I'm probably saying something > stupid. What about end-to-end solutions, where only routers with > a trusted key can originate configuration information? This could perhaps > be combined with a leap-of-faith model (a la ssh). Yes, it's a very good idea, if you use authentication mode only. There are two points: 1) 4301 and previous did not say what to do with an AH header with an unrecognized SPI. This is why SEND doesn't use it. If we can say that the correct answer is to skip the AH, and pretend it wasn't there at all, then new routers can join as leafs, insecurely, and then join the group (symmetric) key. 2) and/or we can define an assymetric method for AH. >> Looking at Babel, the routing protocol spec is 45 pages, and draft >> specification of HMAC security scheme for it is 55 pages. > Yeah, wouldn't it be nice if we had a common layer 3 security protocol? > (We would make sure that it's actually usable before standardisation, of > course.) I think that we could use IPsec, and yes, even manually keyed, and maybe even insist on sane definition of unknown AH SPI, given that the set of devices that we are dealing with does not need to interop with anything already deployed, and that these are custom function devices. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7GPB4CLcPvd0N1lAQJhLwf/cbFyGHcMJONg3tl3F3kBC81k0pFvSsrE pjGY1DCgD3I8dttOe4n5sL/kVl7Reh07QYJBQmH72w2+ROyehaGtXz510iRmtVN/ o6aBCyVUfiQosJRa2GdGCNVROJWjfDdL8AJs3i0a+fcUQ0bt1rZ4eFymNa+X5Ux9 FebXxMN0ZKtNN2IpawBYYpCZScl2Uk5Wko8P+zceqcWIyHq/XW2i452z6yQO4V+G el/vrg3PqhuUSHuxQzoKElL/SdgjjDo3aDg8G3+2MQSzHRjoemcAELZo8sfiX5i+ lEsiuZyNsBq+/AQDFM7iUfSHXrUBvTe171e+ia/WcNQoVcvXJhH3hw== =O/jH -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 30 12:33:05 2014 Return-Path: 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 82B3E1A0659 for ; Mon, 30 Jun 2014 12:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 wOVLGvdwArgb for ; Mon, 30 Jun 2014 12:33:02 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1281A0657 for ; Mon, 30 Jun 2014 12:33:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C845B870064; Mon, 30 Jun 2014 21:33:01 +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 nB8XOPjO6dc6; Mon, 30 Jun 2014 21:33:01 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:b441:d317:72dd:6a3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 810AC870047; Mon, 30 Jun 2014 21:33:01 +0200 (CEST) Message-ID: <53B1BB59.2070908@globis.net> Date: Mon, 30 Jun 2014 21:32:41 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Markus Stenberg References: <54D995D5-6DC9-4AF6-98F9-42A6DC351CA5@iki.fi> <53AE7209.7080408@globis.net> <6EF005E6-2DD6-4B64-904A-2D8F9F2150BC@iki.fi> In-Reply-To: <6EF005E6-2DD6-4B64-904A-2D8F9F2150BC@iki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yKN6qiAgsHZXU0ioXew8qeaDFek Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Securing HNCP - comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 19:33:04 -0000 > Markus Stenberg > 30 June 2014 09:31 > On 28.6.2014, at 10.43, Ray Hunter wrote: >>> How could [4] be prevented then? In ascending order of complexity.. >>> >>> [S4-1] Manual configuration of categories overriding automated border= discovery. Defining either in the actual router product, or via configur= ation which interfaces to talk HNCP (and RP) on, where potential upstream= links may never be, can be or always are. >>> >>> [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual = keying as currently specified in the draft. Setting up the shared PSK for= the set of routers is left to the as manual configuration exercise for t= he owner of the devices. >>> >>> [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues= as [S4-2], may be able to get rid of manually keyed IPsec dependency. >>> >>> [S4-4] Some public key cryptography solution operating with just raw = keys (there is a draft in the works on how to do this in HNCP) >>> >>> [S4-5] Some public key cryptography solution with CA hierarchy (simil= ar to behringer-bootstrap) >>> >>> The big question is, are the S4-3+ really worth it? And what is the s= ane way to do it if they are? Can we actually become RFC with just S4-1 a= nd S4-2? In case we go for public key-cryptography: what do we do about r= outing protocols mostly relying on shared secrets for authentication? >>> >>> - Markus and Steven >> Powerline Ethernet devices have built in encryption, so I think consum= ers do expect some level of protection from accidental neighbouring. I ag= ree with you questioning whether this should be solved at L2 or L3 and ab= ove. > > Same thing with WPA* too of course. So I=92m very tempted to assume L2 = takes care of security.. ;) > >> Assuming the solution has to be defined at L3 and above, I think due t= o the lack of any hierarchy, or root node, that you're going to have to h= ave individual keys/signatures per device, and that you cannot assume exi= stence of a central keying repository. >> >> S4-1 could work but relies on consumers plugging in devices into the c= orrect ports. S4-2 does not meet the requirement for auto-configuration. = S4-3 could work if you could bootstrap it, but that is not trivial either= because it is chicken/egg. I don=92t see S5-5 flying: there is no natura= l root node or root CA. > > S4-2 and S4-3 have same characteristics in my view - they need some (co= nsensus) way to generate PSK, that is then either a) fed to IPsec as manu= ally keyed SA, or b) used to encrypt-authenticate content in the protocol= =2E > > S4-[45] have built-in ways of bootstrapping that are absent from S4-2/S= 4-3 as I see them. > >> The problem seems to boil down to "how can we bootstrap the trust" reg= ardless of the encryption technology. Assuming S4-3 or S4-4, when a new d= evice is added to the network (as opposed to existing devices being replu= gged) you could check it against a (distributed) DB of existing pairing k= eys (via TBD service discovery technology). If a device hasn't paired to = at least one other homenet device, HNCP messages from this device is igno= red until it has. Initiating the pairing should be as simple for the end = user as pressing a button on 2 connected devices (nearly) simultaneously = (one new and one already in the web of trust) so that both devices go int= o pairing mode and learn a new HNCP pairing. Once homenet is (relatively)= stable, you would also be able to flood the new pairing to all other dev= ices in the web of trust for potential long term storage. At some point y= ou might end up seeing old devices you've given to your neighbour, so the= re should also be a way of clearing the pairing DB for a specific device,= or automatically flushing entries for devices that have not been seen si= nce time X. Alternative is that you have to put all devices in homenet in= to pairing mode simultaneously, but that may become less practical as the= number of routers increases. >> IF you can establish trust using HNCP (an expensive operation), it cou= ld be the basis for all other trust in the Homenet, so it is potentially = a big win. e.g. To negotiate any necessary shared key for routing or othe= r common Homenet wide parameters: think election of the root bridge in 80= 2.1 and then that root device chooses a common shared key. Obviously dist= ribution of the resulting shared keys from the root is going to have to b= e encrypted. > > Yeah, I agree that this scheme (on high level) is what seems sensible _= given_ the assumption you want to do the trust handling within HNCP. > >> I can certainly see this solution sketch requiring a lot of code. > > Indeed, and be also nontrivial to specify and interoperably implement. = Sigh. > > So back to the original question, anyone have any idea if this stuff _m= ust_ be implemented, really, beyond hand-wavy S4-1 and S4-2? Looking at = Babel, the routing protocol spec is 45 pages, and draft specification of = HMAC security scheme for it is 55 pages. I sense some slight imbalance so= mewhere. > > Cheers, > > -Markus To answer your question, I think you need to examine your threat model. I think one of the major threats will likely be accidental peering,=20 leading to inappropriate border selection, and thus incorrect default=20 firewall settings, which in turn leads to a loss of confidentiality. What characteristic or parameter defines a device's membership of a=20 particular Homenet in HNCP? How are you going to prevent 2 adjacent Homenet customers, that happen=20 to share an ISP L2 broadcast uplink like a cable TV network, from=20 peering and becoming a single Homenet? Is this an "illegal" topology, because Homenet assumes that all ISP=20 uplinks are L3, or Homenet assumes that receiving PD on an interface=20 defines it as being an ISP border? If you value ease of use higher, then you'd probably mandate that=20 Homenet should rely on existence of a L2 adjacency as being sufficient=20 to justify L3 adjacency, and such border interfaces in these special=20 topologies require manual border interface configuration to prevent=20 accidental peering. If you value privacy higher, then you'd probably mandate that all device = peerings have to be authorised in some way at L3 before they are accepted= =2E I think it's instructive to look at Bluetooth as to how this requirement = has evolved. e.g. bluejacking -> bluesnarfing -> explicit user=20 intervention required before any peering takes place. --=20 Regards, RayH