From Ray.Bellis@nominet.org.uk Mon Jun 3 06:35:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93CC21F9774 for ; Mon, 3 Jun 2013 06:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYDixf5jNKeI for ; Mon, 3 Jun 2013 06:35:09 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id F0F9E21F962A for ; Mon, 3 Jun 2013 06:35:08 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV: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:Content-ID: Content-Transfer-Encoding:MIME-Version; b=oh6s7k35wduMfNH/aL7wSohY6B3+FDNCfdfXjdhMZIJv+wy2hLgNVnv9 MveEzB+OFGyfOWJBVxFpFdt95A7fpYV+brBWWIbei2ZNryzEMWy56vD9C zcDkSOsZxOdSPKx; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1370266509; x=1401802509; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=TW1bTjTV3XP6eh0Vg+9Lx0OCfIA3htFvKtk3NazHOo8=; b=Tm/xf5IMT7zB0/72+RfQM0npAQGOIuLi2jdrNtMB/YwHQ7Mx5ykLbOvN jbvjxHZ+YDYQ53Jp9E+2XQDEsscm5kc+V/zg0rvjD87rJb54+VcLXtoQS VWwW8o2esBlMKJf; X-IronPort-AV: E=Sophos;i="4.87,792,1363132800"; d="scan'208";a="1138025" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 03 Jun 2013 14:35:06 +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%17]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 14:35:06 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUA== Date: Mon, 3 Jun 2013 13:35:06 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> 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: <14E0F14D1CFBFA4EB3989AC41DE89FB7@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:35:16 -0000 This email marks the commencement of the second Working Group Last Call for= draft-ietf-homenet-arch-08. The WGLC will end on Monday June 17th. Please send your comments soonest, and in particular please check that any = issues that you highlighted during the previous WGLC have been addressed. Ray and Mark. From Ray.Bellis@nominet.org.uk Fri Jun 14 02:08:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714EB21F9BB9 for ; Fri, 14 Jun 2013 02:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzLGhjyV88C7 for ; Fri, 14 Jun 2013 02:08:20 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id E8C4721F9B8F for ; Fri, 14 Jun 2013 02:08:16 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV: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:Content-ID:Content-Transfer-Encoding: MIME-Version; b=o7cW+U9BeLtx6jnxM7kdYzSmo+xA4f7K5qjIPmdcDf5O/h2aGYsecXDK FZdVt+bg/mCkXyo9URnOAfcxJNSO5OlkVF4int7Wslm1qXl+uNnCH35QJ 1OsOSZDXUhsNewS; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1371200898; x=1402736898; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=km/CtcOVuk3leBaD6zYEbOeBavnBV//G0Iidi4vKWJ8=; b=ofx57o6levvUSno82OhHBwVb+ePEbFfFasmbx6YAEL/Qb+KfnzAKwTGS cyfNO1qfOsME92qqdyH+etF+Am8rDt5BeVjTg7lvCLfxJUOIc3Kacu9X/ d+akIo6RNGdRO+2; X-IronPort-AV: E=Sophos;i="4.87,864,1363132800"; d="scan'208";a="1385307" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 14 Jun 2013 10:08:14 +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%17]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 10:08:14 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OA Date: Fri, 14 Jun 2013 09:08:13 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 09:08:26 -0000 I'd like to remind the WG that this last call will expire *next Monday*. Please send any comments to the list and editor ASAP. It would also be use= ful to receive comments along the lines of "it's ready, ship it!". thanks, Ray From curtis@ipv6.occnc.com Sat Jun 15 11:36:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7621F9D38 for ; Sat, 15 Jun 2013 11:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdkziSHsko2S for ; Sat, 15 Jun 2013 11:36:20 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id E580C21F9CDE for ; Sat, 15 Jun 2013 11:36:19 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r5FIZ1De044175; Sat, 15 Jun 2013 14:35:01 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201306151835.r5FIZ1De044175@gateway1.orleans.occnc.com> To: Ray Bellis From: Curtis Villamizar In-reply-to: Your message of "Fri, 14 Jun 2013 09:08:13 -0000." <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> Date: Sat, 15 Jun 2013 14:35:01 -0400 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 18:36:25 -0000 In message <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> Ray Bellis writes: > I'd like to remind the WG that this last call will expire *next Monday*. > > Please send any comments to the list and editor ASAP. It would also be useful to receive comments along the lines of "it's ready, ship it!". > > thanks, > > Ray Hi Ray, It is helpful if the draft name is spelled right in the WGLC. draft-ietf-homenet-arch-08 but a search for homenet-arch is fine. A lot of progress has been made in the last year or so. Quite a few issues remain open in that there is no solution recommended in homenet-arch, or multiple solutions are recommended primarily because downselection has not occurred. Examples of the former is "routing functionality" and service discovery beyond the subnet, and "domain discovery". Examples of the latter is address allocation, prefix delegation. BTW- Naming used to cite draft-mglt-homenet-naming-delegation and draft-mglt-homenet-front-end-naming-delegation and I'm not sure why those citations were dropped, unless they are now abandonned (they are both expired). The point is that though this framework has tremedously improved (though it still cited mDNS and entertains the possibility of multiple zeroconf name services plus DNS :), there is a ways to go. Hopefully this draft can remain a living document rather than freeze it prematurely by moving it to the IESG and trying to get premature RFC status. On many issues the WG has converged in the last year or so, yet IMHO too many remain open. Curtis From jch@pps.univ-paris-diderot.fr Sun Jun 16 21:52:07 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CF221F99DC for ; Sun, 16 Jun 2013 21:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsgTXfJ+3wdw for ; Sun, 16 Jun 2013 21:52:01 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AEA21F96EF for ; Sun, 16 Jun 2013 21:52:00 -0700 (PDT) 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/38117) with ESMTP id r5H4pPVe029676; Mon, 17 Jun 2013 06:51:25 +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 A45134E7CD; Mon, 17 Jun 2013 06:51:25 +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 BxBlUG3JD_Dv; Mon, 17 Jun 2013 06:51:20 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6067C4E7CC; Mon, 17 Jun 2013 06:51:20 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UoRPT-0005lK-SA; Mon, 17 Jun 2013 06:51:19 +0200 Date: Mon, 17 Jun 2013 06:51:19 +0200 Message-ID: <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "homenet@ietf.org Group" In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 17 Jun 2013 06:51:25 +0200 (CEST) Cc: Ray Bellis , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 04:52:07 -0000 > This email marks the commencement of the second Working Group Last > Call for draft-ietf-homenet-arch-08. The WGLC will end on Monday > June 17th. I've read this draft with great interest. There's a lot about it that I like. Unfortunately, I've noticed one paragraph that I believe is wrong. In Section 3.5, you say: It is desirable that the routing protocol has knowledge of the homenet topology, which implies a link-state protocol is preferable. This would mean the routing protocol gives a consistent view of the network, and that it can pass around more than just routing information. This would seem to imply that only link-state protocols can "give a consistent view of the network", and that only link-state protocols can "pass around more than just routing information". I'm pretty sure BGP and EIGRP experts would disagree with that. Is it too late to remove this paragraph? -- Juliusz From swmike@swm.pp.se Mon Jun 17 00:26:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A981921F9ABA for ; Mon, 17 Jun 2013 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMU+h3At9KP0 for ; Mon, 17 Jun 2013 00:26:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5407A21F90CC for ; Mon, 17 Jun 2013 00:26:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4B7DA9C; Mon, 17 Jun 2013 09:26:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 40B3F9A; Mon, 17 Jun 2013 09:26:42 +0200 (CEST) Date: Mon, 17 Jun 2013 09:26:42 +0200 (CEST) From: Mikael Abrahamsson To: Ray Bellis In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 07:26:47 -0000 On Mon, 3 Jun 2013, Ray Bellis wrote: > This email marks the commencement of the second Working Group Last Call for draft-ietf-homenet-arch-08. The WGLC will end on Monday June 17th. > > Please send your comments soonest, and in particular please check that any issues that you highlighted during the previous WGLC have been addressed. So, I know I am late in the game, but I have re-read this document and have the following thoughts: 3.5.1. It would perhaps be beneficial if there was some text regarding multicast traffic destined for devices within (and not outside, and thus shouldn't be forwarded to the USP) the home and what might be a future "Internet multicast", or at least some text that might indicate that multicast might be received from the ISP and that multicast is not just used *within* the home. When I read the current text I am afraid some people might read it as multicast is only being used within the home and nothing else. . Apart from that, I believe that this text sums up most of the components needed for the high level goal "home network that can support multiple ISPs, organised in whatever way the customer connects the device, and which the user can connect to from whereever he is as long as he has proper Internet access". Perhaps there could be some text on IPSEC and key management, but I believe this is covered in the "discovery mechanisms" section where the document says it doesn't focus on this but just says this kind of communication should be possible. So I support this document as being a useful arch document going forward. -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=7880a3e44e=acee.lindem@ericsson.com Mon Jun 17 02:26:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2075B21F9974 for ; Mon, 17 Jun 2013 02:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFU+gywnuOga for ; Mon, 17 Jun 2013 02:25:54 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6A621F9AD5 for ; Mon, 17 Jun 2013 02:25:49 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-5a-51bed61df48a Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2D.2E.05617.D16DEB15; Mon, 17 Jun 2013 11:25:49 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 05:25:48 -0400 From: Acee Lindem To: Juliusz Chroboczek Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOaxZOD2/n0Jq0ZEK+oRQ4rPdZUJk55i2A Date: Mon, 17 Jun 2013 09:25:48 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4717CEB5@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <877ghts5ko.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.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <657280D0EE88D14885CFBE4EB1ACFB57@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPgq7stX2BBq9OyFi8X3SIxeLzp3+s Fp+6nrNaHNrznM2BxePvOlePJUt+MnmcmDuPyePi7neMASxR3DZJiSVlwZnpefp2CdwZcze8 YS9o5q6Ye/MwSwPjPY4uRk4OCQETiftPNzND2GISF+6tZ+ti5OIQEjjKKLHh6TooZzmjxP1H x9hBqtgEdCSeP/oH1iEiYCYxr+c5I0gRs0AHo8SkHx2MIAlhAU+J/+9vMEEUeUnMPtgFNIkD yDaSeLdSDiTMIqAqcXDqExaQMK+At8SqJxoQu5oZJRoefwUbwylgJTFj2XYWEJsR6Lrvp9aA jWQWEJe49WQ+E8TVAhJL9pyH+kBU4uXjf6wQtrLEkif7WSDqdSQW7P7EBmFbS+y7uA3K1pZY tvA1WC+vgKDEyZlPWCYwis9CsmIWkvZZSNpnIWmfhaR9ASPrKkaO0uLUstx0I8NNjMD4OybB 5riDccEny0OM0hwsSuK870/tChQSSE8sSc1OTS1ILYovKs1JLT7EyMTBCSK4pBoY1yetvfSY qTtzydXdi40LFy4xnKljvqXgC6/ckzZzocwbBcyPe7ivWmkb/pq3/I/xTwvNgHOmM3a9XzxT POhE1sN7Gvfra3N0pqZa3RD/8kvlf459qYL47eXeFqaXb1vzHQrkv9W8xJnL7oeixsGVTvlH 1yg/Lwy+bOl7emfYlPIdk2cGhUuEKrEUZyQaajEXFScCAIFL1mKSAgAA Cc: Ray Bellis , "homenet@ietf.org Group" , "" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 09:26:00 -0000 On Jun 17, 2013, at 12:51 AM, Juliusz Chroboczek wrote: >> This email marks the commencement of the second Working Group Last >> Call for draft-ietf-homenet-arch-08. The WGLC will end on Monday >> June 17th. >=20 > I've read this draft with great interest. There's a lot about it that > I like. >=20 > Unfortunately, I've noticed one paragraph that I believe is wrong. In > Section 3.5, you say: >=20 > It is desirable that the routing protocol has knowledge of the > homenet topology, which implies a link-state protocol is > preferable. This would mean the routing protocol gives > a consistent view of the network, and that it can pass around more > than just routing information. >=20 > This would seem to imply that only link-state protocols can "give > a consistent view of the network", and that only link-state protocols > can "pass around more than just routing information". I'm pretty sure > BGP and EIGRP experts would disagree with that. >=20 > Is it too late to remove this paragraph? It is not too late to remove it but there is no reason to remove it. BGP is= not used for constructing a topological view of the network and EIGPR isn'= t even an IETF protocol.=20 Acee=20 >=20 > -- Juliusz > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From prvs=88808b78e2=acee.lindem@ericsson.com Mon Jun 17 02:47:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B36521F9B31 for ; Mon, 17 Jun 2013 02:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1U5h6nvb1Jz for ; Mon, 17 Jun 2013 02:47:47 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC1C21F9B2F for ; Mon, 17 Jun 2013 02:47:47 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-07-51bedb42dbd5 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.B3.17537.24BDEB15; Mon, 17 Jun 2013 11:47:46 +0200 (CEST) To: undisclosed-recipients:; Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 05:47:46 -0400 From: Acee Lindem Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOaxZOD2/n0Jq0ZEK+oRQ4rPdZUA== Date: Mon, 17 Jun 2013 09:47:45 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4717CFAB@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <15C68D86-4CD9-46F2-8897-D65675E0A545@ericsson.com> In-Reply-To: <15C68D86-4CD9-46F2-8897-D65675E0A545@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHW9fp9r5AgwNTdS3eLzrEYvH50z9W i09dz1ktDu15zubA4vF3navHkiU/mTxOzJ3H5HFx9zvGAJYobpukxJKy4Mz0PH27BO6MNX9T Cw4IVKxon8zUwNjC28XIySEhYCKxrKOZHcIWk7hwbz1bFyMXh5DAUUaJ7j8PGEESIgIyEnNn P2aFSCxnlFjU9w+sg01AR+L5o3/MIAlmgX2MEu+6N4B1CAt4Svx/f4MJottLYvbBLjYIW0+i 5dspFhCbRUBV4krTCVYQm1fAW+Ls0VvsEBt2Mkq83tsB1swp4CCxfMZcZhCbEei+76fWgMWZ BcQlbj2ZzwRxt4DEkj3nmSFsUYmXj/+xQtjKEkue7GeBqNeRWLD7ExuEbS1xbmYTVFxbYtnC 18wQRwhKnJz5hGUCo/gsJCtmIWmfhaR9FpL2WUjaFzCyrmLkKC1OLctNNzLYxAiMwGMSbLo7 GPe8tDzEKM3BoiTO+/LUrkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBceGyQLtP+1fY HJ6ie+tXxGs9r9lP6g24LRYkWtepb1bOPx2r6s0cLXNXuzKZw6T69Op7E/yWSe1sut3Vc/Xn /Y6XBz2mvJx/QkpkOUN7kVbuZvG6vcVfhBceTi5ZKjttotbHa2uCfj9jUPoUnHg3U1z21K6F HGXGBXsCvi5c93aFyNQ1fNHBy5RYijMSDbWYi4oTAQCVrzSTAgAA Cc: Ray Bellis , "homenet@ietf.org Group" , "" , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 09:47:53 -0000 On Jun 17, 2013, at 5:25 AM, wrote: >=20 > On Jun 17, 2013, at 12:51 AM, Juliusz Chroboczek wrote: >=20 >>> This email marks the commencement of the second Working Group Last >>> Call for draft-ietf-homenet-arch-08. The WGLC will end on Monday >>> June 17th. >>=20 >> I've read this draft with great interest. There's a lot about it that >> I like. >>=20 >> Unfortunately, I've noticed one paragraph that I believe is wrong. In >> Section 3.5, you say: >>=20 >> It is desirable that the routing protocol has knowledge of the >> homenet topology, which implies a link-state protocol is >> preferable. This would mean the routing protocol gives >> a consistent view of the network, and that it can pass around more >> than just routing information. >>=20 >> This would seem to imply that only link-state protocols can "give >> a consistent view of the network", and that only link-state protocols >> can "pass around more than just routing information". I'm pretty sure >> BGP and EIGRP experts would disagree with that. >>=20 >> Is it too late to remove this paragraph? >=20 > It is not too late to remove it but there is no reason to remove it. BGP = is not used for constructing a topological view of the network and EIGPR is= n't even an IETF protocol.=20 s/EIGPR/EIGRP/=20 Note that I'm making this statement as Routing Advisor to the the Homenet W= G. The document is not saying that a link state protocol is the only way to= satisfy the home network routing requirements, it is saying one is prefera= ble. In my opinion, there are at least two reasons for this: 1. Nearly everyone can understand how a link state protocol provid= es a consistent view of the network and meets the home network requirements= .=20 2. There are two widely deployed IETF standard link state protocol= s.=20 Thanks, Acee=20 >=20 >=20 > Acee=20 >=20 >=20 >=20 >>=20 >> -- Juliusz >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From jch@pps.univ-paris-diderot.fr Mon Jun 17 04:21:18 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1FE21F883B for ; Mon, 17 Jun 2013 04:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8rHRAGnDoSN for ; Mon, 17 Jun 2013 04:21:07 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D621F9B38 for ; Mon, 17 Jun 2013 04:19:53 -0700 (PDT) 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/38117) with ESMTP id r5HBIroh010664; Mon, 17 Jun 2013 13:18:53 +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 BE4DF4E804; Mon, 17 Jun 2013 13:18:53 +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 daQ48ZEjIG_S; Mon, 17 Jun 2013 13:18:52 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8B6214E801; Mon, 17 Jun 2013 13:18:52 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UoXSW-00012v-73; Mon, 17 Jun 2013 13:18:52 +0200 Date: Mon, 17 Jun 2013 13:18:52 +0200 Message-ID: <87bo75dlyb.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Acee Lindem In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4717CFAB@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <15C68D86-4CD9-46F2-8897-D65675E0A545@ericsson.com> <94A203EA12AECE4BA92D42DBFFE0AE4717CFAB@eusaamb101.ericsson.se> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 17 Jun 2013 13:18:54 +0200 (CEST) Cc: , Ray Bellis , "homenet@ietf.org Group" , "" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 11:21:18 -0000 Thanks for your reply, Acee. > >> This would seem to imply that only link-state protocols can "give > >> a consistent view of the network", and that only link-state protocols > >> can "pass around more than just routing information". I'm pretty sure > >> BGP and EIGRP experts would disagree with that. > 1. Nearly everyone can understand how a link state protocol > provides a consistent view of the network and meets the > home network requirements. > 2. There are two widely deployed IETF standard link state > protocols. Granted, these are good reasons to promote OSPF. However, these are *not* the reasons given in the draft. If these are the reasons why the Homenet group promotes a link-state protocol, that's fine, but then this should be stated in the arch document. The paragraph as it is currently written is quite simply incorrect, and should either be rewritten to reflect the correct reasons or removed altogether. -- Juliusz From otroan@employees.org Mon Jun 17 04:49:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E979321F9BBD for ; Mon, 17 Jun 2013 04:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgIkf7xUfGis for ; Mon, 17 Jun 2013 04:49:07 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03121F9BA6 for ; Mon, 17 Jun 2013 04:49:07 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 3C50B5F39; Mon, 17 Jun 2013 04:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=KrWx9pC5IeJREkgX+gdUykx+dik=; b=Zd6pXcwM87uAR2pi06 nMFcFibh0B7WSpva++dilf/mkuV04UhQ3ayDiCuMeWqkRB3YvA4c9rlq/njX/zc3 EcGw6lmvRF4MOx8etBkK46y1s6XpmCNtjgpseW1zxIdSCGqAKgON09fWB3S1Y8fb uaAI+vZIdTNWTzuCmsFu2XR70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=pccSm3xwVtYxz5TvgLo26f6Bd2EfP4wBRrYltaOkmFNJosTGaJy YvM0PooLXMKpr97gjY28zQxySwP6hQe9AkuNIXdaHKaXph2XBwZXKGrL1bpZwd6A rr6/1x3WFh5GzqE8K/iK4Kzq3Oh1H6CSMotR97lDJk3dTgo/SxWmHFf4= Received: from dhcp-lys02-vla252-10-147-116-59.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4BC725F27; Mon, 17 Jun 2013 04:49:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 17 Jun 2013 13:49:03 +0200 Content-Transfer-Encoding: 7bit Message-Id: <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 11:49:14 -0000 > This would seem to imply that only link-state protocols can "give > a consistent view of the network", and that only link-state protocols > can "pass around more than just routing information". I'm pretty sure > BGP and EIGRP experts would disagree with that. > > Is it too late to remove this paragraph? why would BGP and EIGRP experts disagree with that? cheers, Ole From jch@pps.univ-paris-diderot.fr Mon Jun 17 05:14:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966CF21F9BA2 for ; Mon, 17 Jun 2013 05:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsjHNeKEIRzh for ; Mon, 17 Jun 2013 05:14:39 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC5B21F9B8A for ; Mon, 17 Jun 2013 05:14:11 -0700 (PDT) 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/38117) with ESMTP id r5HCDTA6001559; Mon, 17 Jun 2013 14:13: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 8378C4E806; Mon, 17 Jun 2013 14:13: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 2ZqwazrOkqXQ; Mon, 17 Jun 2013 14:13:28 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3910B4E805; Mon, 17 Jun 2013 14:13:28 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UoYJL-0001Dt-UL; Mon, 17 Jun 2013 14:13:27 +0200 Date: Mon, 17 Jun 2013 14:13:27 +0200 Message-ID: <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ole Troan In-Reply-To: <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 17 Jun 2013 14:13:29 +0200 (CEST) Cc: Ray Bellis , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:14:49 -0000 Hi Ole, > > This would seem to imply that only link-state protocols can "give > > a consistent view of the network", and that only link-state protocols > > can "pass around more than just routing information". I'm pretty sure > > BGP and EIGRP experts would disagree with that. > why would BGP and EIGRP experts disagree with that? BGP has an extensive attributes mechanism that allows it to "pass around more than just routing information". EIGRP has a number of mechanisms (reliable transport, active phase) that ensure that it provides a "consistent view of the network" at all times (arguably more so than multi-area OSPF). The implication that only link-state protocols can have these properties is incorrect. This is completely orthogonal to the issue of whether the Homenet group wishes to promote the use of OSPF. -- Juliusz From otroan@employees.org Mon Jun 17 05:17:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4342F21F9AD2 for ; Mon, 17 Jun 2013 05:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkMawkfSmROw for ; Mon, 17 Jun 2013 05:17:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AE36321F9AB4 for ; Mon, 17 Jun 2013 05:17:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADL9vlGQ/khR/2dsb2JhbABagwm/YnwWdIIjAQEEAR0dMQ4QCw44VwaIGwa4Q48UMweCf2EDqQSDETo X-IronPort-AV: E=Sophos;i="4.87,880,1363132800"; d="scan'208";a="155413864" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2013 12:17:37 +0000 Received: from dhcp-lys02-vla252-10-147-116-59.cisco.com (dhcp-lys02-vla252-10-147-116-59.cisco.com [10.147.116.59]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5HCHZf4016237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 12:17:35 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 17 Jun 2013 14:17:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:17:45 -0000 Juliusz, >>> This would seem to imply that only link-state protocols can "give >>> a consistent view of the network", and that only link-state = protocols >>> can "pass around more than just routing information". I'm pretty = sure >>> BGP and EIGRP experts would disagree with that. >=20 >> why would BGP and EIGRP experts disagree with that? >=20 > BGP has an extensive attributes mechanism that allows it to "pass > around more than just routing information". >=20 > EIGRP has a number of mechanisms (reliable transport, active phase) > that ensure that it provides a "consistent view of the network" at all > times (arguably more so than multi-area OSPF). >=20 > The implication that only link-state protocols can have these > properties is incorrect. This is completely orthogonal to the issue > of whether the Homenet group wishes to promote the use of OSPF. hmm, is your argument above that you can build a link state routing = protocol on top of EIGRP or BGP? cheers, Ole= From jch@pps.univ-paris-diderot.fr Mon Jun 17 05:29:24 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C099121F852D for ; Mon, 17 Jun 2013 05:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsRgx6rRM7UQ for ; Mon, 17 Jun 2013 05:29:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id D0B3321F91CE for ; Mon, 17 Jun 2013 05:27:32 -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/38117) with ESMTP id r5HCQq8Z021942; Mon, 17 Jun 2013 14:26: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 BEAE14E809; Mon, 17 Jun 2013 14:26: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 NmWucnH5CYUz; Mon, 17 Jun 2013 14:26:46 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BD4C64E808; Mon, 17 Jun 2013 14:26:46 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UoYWE-0001Ej-Cc; Mon, 17 Jun 2013 14:26:46 +0200 Date: Mon, 17 Jun 2013 14:26:46 +0200 Message-ID: <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ole Troan In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 17 Jun 2013 14:26:53 +0200 (CEST) Cc: Ray Bellis , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:29:24 -0000 > > BGP has an extensive attributes mechanism that allows it to "pass > > around more than just routing information". > > > > EIGRP has a number of mechanisms (reliable transport, active phase) > > that ensure that it provides a "consistent view of the network" at all > > times (arguably more so than multi-area OSPF). > hmm, is your argument above that you can build a link state routing > protocol on top of EIGRP or BGP? No. I said "consistent view", not "complete view". Ole, Acee, I'm not arguing about whether there are good reasons to promote link-state protocols for Homenet, which there might very well be. I'm just saying that the current formulation is technically incorrect, and that it should, er, SHOULD be fixed before publication. -- Juliusz From mike@mtcc.com Mon Jun 17 05:40:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB3C21F8900 for ; Mon, 17 Jun 2013 05:40:05 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PslYljy69GkO for ; Mon, 17 Jun 2013 05:39:59 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 0021221F88FB for ; Mon, 17 Jun 2013 05:39:58 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HCdQpc019887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 05:39:27 -0700 Message-ID: <51BF037A.2040907@mtcc.com> Date: Mon, 17 Jun 2013 05:39:22 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Juliusz Chroboczek References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=966; t=1371472767; x=1372336767; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Juliusz=20Chroboczek=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=QQjNs6/DfLYhwsQ6RfuN754PHDW5a4gi+sG4lBEuLR4=; b=jrnGpv6jQjntb5G+YC9JpCCW7rQ/h4hG7R9rh8pNvfSoJcLv0+qaRo5zpe S/L/cKeN85+59ehq5DLmQ95CRv87R+yIgti+xSFCTdMCRNPFjVKGaJFcDMmb g52otc2Y8Tx5HjG8CA8IAWeZQuJ66LdOggKch5foq16+u/e4/MyOY=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , Ole Troan , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:40:06 -0000 Juliusz Chroboczek wrote: >> hmm, is your argument above that you can build a link state routing >> protocol on top of EIGRP or BGP? > > No. I said "consistent view", not "complete view". > > Ole, Acee, I'm not arguing about whether there are good reasons to > promote link-state protocols for Homenet, which there might very well > be. I'm just saying that the current formulation is technically > incorrect, and that it should, er, SHOULD be fixed before publication. I agree: there is no reason put out incorrect facts; it just makes it look like the text is searching for a way to obtain the desired result, and weakens its case. That is consistent with my detailed feedback regarding the 'desired result' of mdns which as far as I can tell has never been resolved. And the chairs can consider that my last call feedback: my feedback was ignored, not rebutted, as far as I can tell. So what's the point of feedback/last call? Mike From v6ops@globis.net Mon Jun 17 05:49:39 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17821F9B2D for ; Mon, 17 Jun 2013 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLt+egqEhzmn for ; Mon, 17 Jun 2013 05:49:38 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5482021F9B13 for ; Mon, 17 Jun 2013 05:49:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 088088700AE; Mon, 17 Jun 2013 14:49:22 +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 0vhez9PyVLOc; Mon, 17 Jun 2013 14:49:21 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id CEA91870092; Mon, 17 Jun 2013 14:49:21 +0200 (CEST) Message-ID: <51BF05CB.60709@globis.net> Date: Mon, 17 Jun 2013 14:49:15 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Ray Bellis References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:49:39 -0000 I've read the 08 version. It's not perfect, but I think it's good enough to achieve the stated goal "to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements" Substantive comments 6204 and 6204 bis are silent of extension headers. There's been a flurry of notes recently on 6vops and 6man on the level/lack of support for extension headers. I tested my own IPv6 CPE and it doesn't seem to transmit any packets containing a fragment header, regardless of whether a firewall was configured or not. Do we need any text on this item? Section 3.6.3? Section 2.1 challenges of multiple subnets. Do we need to add "Yet another challenge is how to handle mobile devices that move around within the home and how they relate to the multiple available prefixes." Section 2.4 & Section 3.4.2 /A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet where that externally allocated globally unique prefix may change over time (e.g. due to renumbering within the subscriber's ISP) or where external connectivity may be temporarily unavailable. / I take issue with ULA being a SHOULD. MAY seems more appropriate given the lack of operational experience and the last paragraph of the section. regards, RayH Ray Bellis wrote: > I'd like to remind the WG that this last call will expire *next Monday*. > > Please send any comments to the list and editor ASAP. It would also be useful to receive comments along the lines of "it's ready, ship it!". > > thanks, > > Ray > > From Ray.Bellis@nominet.org.uk Mon Jun 17 06:06:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B060D21F9C08 for ; Mon, 17 Jun 2013 06:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dajcNzUleuvT for ; Mon, 17 Jun 2013 06:06:43 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5279621F9B90 for ; Mon, 17 Jun 2013 06:06:42 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV: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=A1TMl1oBFPq1FGRcUUy8whHXQlVE9Qlb+0Gt/2GH496lCLnHwzEsbZwv Zam4eqIm/kjoTk5I42yyVlzzrh8INpuEVaBP4gtPhHgWtVmFZdMu9tkaE zXmQX82Te0hoAyW; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1371474403; x=1403010403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JXfYw1mQzyEOJI74+tbRng07brk8iWQctRr1Wt4Jv9Q=; b=aQPAWjh09mf4CmO01gYSmz/1/omqnU2yYQYADFyC4RXhozfJ6gEgXUj/ G1NLZUbBLgLZL3Z8VxPzx58nNvGY6fUIGgYZ/bVa7T0m25j5RGq9qz7uZ N1xzW0AW7R4PQp7; X-IronPort-AV: E=Sophos;i="4.87,881,1363132800"; d="scan'208";a="1465913" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 17 Jun 2013 14:06:41 +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%17]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 14:06:40 +0100 From: Ray Bellis To: Michael Thomas Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk5WxuAgAB0toCAAAbRgIAAASiAgAACkQCAAAOFAIAAB6CA Date: Mon, 17 Jun 2013 13:06:39 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <51BF037A.2040907@mtcc.com> In-Reply-To: <51BF037A.2040907@mtcc.com> 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="iso-8859-1" Content-ID: <75BB46C780D3D74485E9AA27D1286560@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , "tjc@ecs.soton.ac.uk" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:06:48 -0000 On 17 Jun 2013, at 13:39, Michael Thomas wrote: > And the chairs can consider that my last call feedback: my feedback was i= gnored, not > rebutted, as far as I can tell. So what's the point of feedback/last call= ? Looking back at my list archive I see substantial discussion, including not= es from the document editor of changes made in response to your feedback . = You were clearly *not* ignored. Could you please enumerate which specific concerns with the document that y= ou raised during the last WGLC have not been addressed. kind regards, Ray From mike@mtcc.com Mon Jun 17 06:10:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D0821F888F for ; Mon, 17 Jun 2013 06:10:44 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5Y6u8ISmNFK for ; Mon, 17 Jun 2013 06:10:38 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 121C921F9B90 for ; Mon, 17 Jun 2013 06:10:38 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HDA76E030111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 06:10:08 -0700 Message-ID: <51BF0AAB.9050505@mtcc.com> Date: Mon, 17 Jun 2013 06:10:03 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ray Bellis References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <51BF037A.2040907@mtcc.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=876; t=1371474608; x=1372338608; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Ray=20Bellis=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=3W6F5l3y8RCZnIkeZke+Et1jJEzJOZnumjLjmdk8WVY=; b=qKsqs+wDbzpD0avMZA2HI+QhT9N+rAt7d6nU103MzpsxqVlMh0xlfbggIU A6homMEK8ovnqHEOWx2L9AZD08431ZEXb51xi4woy517ddqJHL/sc3FLXfrf u+7qTJFohYATLmlD4Udx8UcTPQXTHFUO7NGhhQoPSO2Hirot9lwQw=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" , "tjc@ecs.soton.ac.uk" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:10:44 -0000 Ray Bellis wrote: > On 17 Jun 2013, at 13:39, Michael Thomas wrote: > >> And the chairs can consider that my last call feedback: my feedback was ignored, not >> rebutted, as far as I can tell. So what's the point of feedback/last call? > > Looking back at my list archive I see substantial discussion, including notes from the document editor of changes made in response to your feedback . You were clearly *not* ignored. > > Could you please enumerate which specific concerns with the document that you raised during the last WGLC have not been addressed. > > kind regards, > > Ray As I recall, the document editor only addressed one and ignored most/all of the rest. I know there was a lot of discussion (pro/con/many other pov's), just not by the editors which is why I don't think the comments were coming from outer space. Mike From mellon@fugue.com Mon Jun 17 06:15:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EC921F88FB for ; Mon, 17 Jun 2013 06:15:46 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fEamzsAlBMo for ; Mon, 17 Jun 2013 06:15:41 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 70D8B21F8887 for ; Mon, 17 Jun 2013 06:15:41 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d9e:1628:9fcd:73b] (unknown [IPv6:2001:470:88a3:0:d9e:1628:9fcd:73b]) by toccata.fugue.com (Postfix) with ESMTPSA id 47B42238038C; Mon, 17 Jun 2013 09:15:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <51BF05CB.60709@globis.net> Date: Mon, 17 Jun 2013 09:15:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:15:46 -0000 On Jun 17, 2013, at 8:49 AM, Ray Hunter wrote: > I take issue with ULA being a SHOULD. MAY seems more appropriate given > the lack of operational experience and the last paragraph of the = section. I would have said MUST. We are trying to define a higher level of = functionality than "lack of operational experience" would imply. We = have near zero operational experience with most of what we are talking = about in homenet, because a lot of it hasn't been built, or only exists = as lab implementations that still have operational issues to resolve. = So what should be in the document is what we want to achieve, not what = we are sure we already know how to achieve. Furthermore, speaking from my own operational experience with ULAs in = the homenet, they do actually seem to work. Source address selection = does the right thing on the devices I use, although there may be issues = on primitive legacy devices that I haven't tested. So this really = isn't an unreasonable thing to have in the document, particularly at the = current rather modest level of requirement. From mike@mtcc.com Mon Jun 17 06:26:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989CC21F8FF8 for ; Mon, 17 Jun 2013 06:26:41 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xm1-nP-K9kz for ; Mon, 17 Jun 2013 06:26:31 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6021F8E8C for ; Mon, 17 Jun 2013 06:26:31 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HDPwxS003090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 06:25:59 -0700 Message-ID: <51BF0E63.9000503@mtcc.com> Date: Mon, 17 Jun 2013 06:25:55 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ray Bellis References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <51BF037A.2040907@mtcc.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1138; t=1371475560; x=1372339560; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Ray=20Bellis=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=1i/+waEWHWbBVuwzGGhidd6dilI+Th2fKJoiwIRx2LM=; b=kIje6elXVcrzTBjh/3KNj8G+xC7VAs+57aBVcjrQDSVTW4DL1E9jAhQKH5 vvcmlQfsF4KEQ2VLPvAbcRtZSFGA1890j/KHyqd0qpbYrDz54KA0Zh50SpNj 8+Sb2WVy3E+oi2uYWJ0mxE2T+R+x75PWetpHmEahYUa0rtzbrUEN0=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" , "tjc@ecs.soton.ac.uk" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:26:41 -0000 Ray Bellis wrote: > On 17 Jun 2013, at 13:39, Michael Thomas wrote: > >> And the chairs can consider that my last call feedback: my feedback was ignored, not >> rebutted, as far as I can tell. So what's the point of feedback/last call? > > Looking back at my list archive I see substantial discussion, including notes from the document editor of changes made in response to your feedback . You were clearly *not* ignored. > > Could you please enumerate which specific concerns with the document that you raised during the last WGLC have not been addressed. > > kind regards, In particular: http://www.ietf.org/mail-archive/web/homenet/current/msg02426.html as far as I can tell is the end of involvement from the editors on the initial thread and after listening to Orlando -- as I said, I wouldn't be there -- nothing was discussed there about my last call comments that I can recall. there was much discussion after that, but not much conclusive from the editors, afaict. i did, on the other hand, learn that mdns saved a major corporation from obscurity. maybe that's what's up. Mike From mike@mtcc.com Mon Jun 17 06:33:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA42221F9BB4 for ; Mon, 17 Jun 2013 06:33:52 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQhgEip6lp1S for ; Mon, 17 Jun 2013 06:33:47 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id A5F1A21F9BB3 for ; Mon, 17 Jun 2013 06:33:47 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HDXEmY005757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 06:33:15 -0700 Message-ID: <51BF1015.1020007@mtcc.com> Date: Mon, 17 Jun 2013 06:33:09 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> In-Reply-To: <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1698; t=1371475995; x=1372339995; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=j+xfvllCurDRGOBo7wQ1/1gYFIy9mMCbH2XgNlvzbRU=; b=Uf6zLFpU913ynWXL7Y1OSgx3+fDsYzKuOGAjhOKDNfxx+z4e0IiBzYV0qL 9fF8Vl0UbaJNv2tlSjjIrwfoO1PddJngjLs93R+CyyBERaZ5pw/hcMaJ4vmk RpFVm4cZKFQrV2UCGhJ8GLcnK50A0ne4wMC1/cNdqpYUlOxxUiHe8=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:33:52 -0000 Ted Lemon wrote: > On Jun 17, 2013, at 8:49 AM, Ray Hunter wrote: >> I take issue with ULA being a SHOULD. MAY seems more appropriate given >> the lack of operational experience and the last paragraph of the section. > > I would have said MUST. We are trying to define a higher level of functionality than "lack of operational experience" would imply. We have near zero operational experience with most of what we are talking about in homenet, because a lot of it hasn't been built, or only exists as lab implementations that still have operational issues to resolve. So what should be in the document is what we want to achieve, not what we are sure we already know how to achieve. Er, that seems completely backward to me. Like you're forcing an expirement onto the unwashed masses that we really don't know how it will turn out. > Furthermore, speaking from my own operational experience with ULAs in the homenet, they do actually seem to work. Source address selection does the right thing on the devices I use, although there may be issues on primitive legacy devices that I haven't tested. So this really isn't an unreasonable thing to have in the document, particularly at the current rather modest level of requirement. In particular, source address selection is still an ongoing concern. We may finally have some paper solutions that claim to address all of the issues, but I think it's far from conclusive in the field how this will all turn out. Homenet arch should be conservative, IMO. Once things get deployed to the masses, bad and/or poorly considered solutions can come back to haunt us big time. ::cough:: NAT ::cough:: Mike From mellon@fugue.com Mon Jun 17 07:11:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F9821F9BF9 for ; Mon, 17 Jun 2013 07:11:40 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-gR3lxZALhV for ; Mon, 17 Jun 2013 07:11:35 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C6C1D21F9BD3 for ; Mon, 17 Jun 2013 07:11:35 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d9e:1628:9fcd:73b] (unknown [IPv6:2001:470:88a3:0:d9e:1628:9fcd:73b]) by toccata.fugue.com (Postfix) with ESMTPSA id D3E1023805D7; Mon, 17 Jun 2013 10:11:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <51BF1015.1020007@mtcc.com> Date: Mon, 17 Jun 2013 10:11:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> <51BF1015.1020007@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:11:41 -0000 On Jun 17, 2013, at 9:33 AM, Michael Thomas wrote: > Er, that seems completely backward to me. Like you're forcing an = expirement onto the unwashed masses that we really > don't know how it will turn out. Sure. That's RFC 6204. Maybe HIPnet, if that gets cleaned up a bit = and gets traction. Homenet is about building something newer and = better than we have now, so yes, it is an experiment, and no, we are not = forcing it onto the public before it is ready (and may I say that I = really hate the term you just used for "the public"?). > In particular, source address selection is still an ongoing concern. = We may finally have some paper solutions that > claim to address all of the issues, but I think it's far from = conclusive in the field how this will all turn out. While source address selection is still an ongoing concern, it works = _quite_ reliably for ULAs, because SAS is a really easy problem to solve = for that particular use case. > Homenet arch should be conservative, IMO. Once things get deployed to = the masses, bad and/or poorly considered > solutions can come back to haunt us big time. ::cough:: NAT ::cough:: While what you say in the second sentence is certainly true, I don't see = how it applies to the first. If we only ever standardized things that = were tried and true, we would still be sending email over the PSTN with = modems using uucp. From mike@mtcc.com Mon Jun 17 07:44:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F0C21F9C97 for ; Mon, 17 Jun 2013 07:44:45 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzKth2ItnGnB for ; Mon, 17 Jun 2013 07:44:40 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 365A321F9CB2 for ; Mon, 17 Jun 2013 07:44:33 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HEi1GQ029235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 07:44:03 -0700 Message-ID: <51BF20AD.5070408@mtcc.com> Date: Mon, 17 Jun 2013 07:43:57 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> <51BF1015.1020007@mtcc.com> <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> In-Reply-To: <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2624; t=1371480243; x=1372344243; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=y+ZTYXExRbO/wuo7eoT2MDfQylAB1FckROAlBZyNor8=; b=ZTtleHVhLpoZRgNc0MMn/5QmfhKcwnMq5G7YHLfCvpPsHuqNBeov4L3E7C lW3JW2wk1VDce522F/C7s+d4r6CeZmnkGx9jApiemetuceX2a3f6Sb9TyckH BYetWtzMELyJEQ5BKxzmFry9ZSQsSS0zRcImE4gmn34DXIA1lJ6Nk=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:44:45 -0000 Ted Lemon wrote: > On Jun 17, 2013, at 9:33 AM, Michael Thomas wrote: >> Er, that seems completely backward to me. Like you're forcing an expirement onto the unwashed masses that we really >> don't know how it will turn out. > > Sure. That's RFC 6204. Maybe HIPnet, if that gets cleaned up a bit and gets traction. Homenet is about building something newer and better than we have now, so yes, it is an experiment, and no, we are not forcing it onto the public before it is ready (and may I say that I really hate the term you just used for "the public"?). A proposed standard carries a lot of weight, and I imagine that router vendors will give it due deference. So it better be a lot more than an educated guess IMO. I'd really like to see that it gets hashed out in enterprise space, for example, where there's a lot more expectation of clue to sort things out if theory doesn't exactly map to reality. > >> In particular, source address selection is still an ongoing concern. We may finally have some paper solutions that >> claim to address all of the issues, but I think it's far from conclusive in the field how this will all turn out. > > While source address selection is still an ongoing concern, it works _quite_ reliably for ULAs, because SAS is a really easy problem to solve for that particular use case. SAS is bound up in all kinds of things including ULA's. I'm not saying that ULA's are bad or anything, but really that especially in the face of mobility across administrative domains it's as far as I know rather murky. MAY is a hedge, MUST is "we're really really certain". I for one don't feel that we've made it to that degree of certainty. > >> Homenet arch should be conservative, IMO. Once things get deployed to the masses, bad and/or poorly considered >> solutions can come back to haunt us big time. ::cough:: NAT ::cough:: > > While what you say in the second sentence is certainly true, I don't see how it applies to the first. If we only ever standardized things that were tried and true, we would still be sending email over the PSTN with modems using uucp. There's an intermediate ground between theory and mass deployment without any expectation of clue: managed environments. I'd say that we ought to be cautious before we proclaim victory and drink the beer on the homenet front. It's not like enterprise, .edu, etc are not going to have to deal with these problems too, so let them take the arrows first. Of course, if you want to make homenet arch experimental, MUST's for the experiment would be appropriate. Mike From dave.taht@gmail.com Mon Jun 17 08:16:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6F21F9CB3 for ; Mon, 17 Jun 2013 08:16:30 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQFjCyjnraDC for ; Mon, 17 Jun 2013 08:16:29 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B57F821F9C91 for ; Mon, 17 Jun 2013 08:16:26 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so7295324iea.31 for ; Mon, 17 Jun 2013 08:16:26 -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=Ldz/du6zPYcdsD/idb4QgxgE46njohVXaGFkKmOj5w0=; b=00B46uAoa2i7/zPfI1GHlStlbb8INGkfrGBeMwE7jXbNLg8+aYoGWPstng1CSda5AU UHrtj4cXTuFaQWTgQ2tBJbboZNcFFeruJ8ljVR2uGcWpSEKliVzpRboQqzbMRnES6rUJ QfjUjsVsoBtE5LS2ViIxmzjxGb8yiHvCuEYrWLeh1GoorFtCIwrjxAksTqcXbwfMHQjt 1chjrA/1QZbA/kpfBOqWqCNT/6+OC4R+pj4g5pAkkI8bPSzp+wmFSN6j/m8FNBNytzrY FGpjZCNC18jDMQ2du4LPLbp2C4pIYvPNr/Thdu4gw88fWmK6R73Pw4or3DxO8QoByhIh No7Q== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr5220142igd.12.1371482186215; Mon, 17 Jun 2013 08:16:26 -0700 (PDT) Received: by 10.64.45.137 with HTTP; Mon, 17 Jun 2013 08:16:26 -0700 (PDT) In-Reply-To: <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 17 Jun 2013 08:16:26 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ray Bellis , Ole Troan , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:16:30 -0000 On Mon, Jun 17, 2013 at 5:26 AM, Juliusz Chroboczek wrote: >> > BGP has an extensive attributes mechanism that allows it to "pass >> > around more than just routing information". >> > >> > EIGRP has a number of mechanisms (reliable transport, active phase) >> > that ensure that it provides a "consistent view of the network" at all >> > times (arguably more so than multi-area OSPF). > >> hmm, is your argument above that you can build a link state routing >> protocol on top of EIGRP or BGP? > > No. I said "consistent view", not "complete view". > > Ole, Acee, I'm not arguing about whether there are good reasons to > promote link-state protocols for Homenet, which there might very well > be. I'm just saying that the current formulation is technically > incorrect, and that it should, er, SHOULD be fixed before publication. +1. > > -- Juliusz > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From dave.taht@gmail.com Mon Jun 17 08:22:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B39921F9CAC for ; Mon, 17 Jun 2013 08:22:10 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAbLbWEJbqXI for ; Mon, 17 Jun 2013 08:22:07 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0729A21F9CA1 for ; Mon, 17 Jun 2013 08:22:06 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so7271827iej.15 for ; Mon, 17 Jun 2013 08:21:52 -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=YmMLAqQ14bvJOC/RCGP4BMqUKOirCGxCoipkVcLlnRI=; b=qU6PhUNad+PD/Xrku4EhFByBMt9LuW2QaMkZpOfuS4KJXHTIYXHBtglK/8owGdmALa FE4N1BEmEYZEtFk1tzPH4CSQab72f1ufUas/Jt6vXlt1JO2CRdGsm3CxQ2QAzAZuIkVf 6jqirc2mpWAS0/P9TUjEUNXl02TX5mMcNFKMRj4VonDhtlp6wStb8gW9g6u6QcUmjTCJ 28E1vf9xuH0J2rITUKyrzA5AL87N+koJONCk9F2v8fTk9G/SPWc63pi7tDTKwXn17Dzq OMGaebL7mjnrieBRhuIFEVTujMmmwDJBWdU/CK0oi3jiW1fXcpyJC9+Lw3qbj3ij6tqH JNkw== MIME-Version: 1.0 X-Received: by 10.50.56.50 with SMTP id x18mr5316415igp.87.1371482512000; Mon, 17 Jun 2013 08:21:52 -0700 (PDT) Received: by 10.64.45.137 with HTTP; Mon, 17 Jun 2013 08:21:51 -0700 (PDT) In-Reply-To: <51BF0E63.9000503@mtcc.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <51BF037A.2040907@mtcc.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> <51BF0E63.9000503@mtcc.com> Date: Mon, 17 Jun 2013 08:21:51 -0700 Message-ID: From: Dave Taht To: Michael Thomas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ray Bellis , "homenet@ietf.org Group" , "tjc@ecs.soton.ac.uk" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:22:10 -0000 On Mon, Jun 17, 2013 at 6:25 AM, Michael Thomas wrote: > Ray Bellis wrote: >> >> On 17 Jun 2013, at 13:39, Michael Thomas wrote: >> >>> And the chairs can consider that my last call feedback: my feedback was >>> ignored, not >>> rebutted, as far as I can tell. So what's the point of feedback/last >>> call? >> >> >> Looking back at my list archive I see substantial discussion, including >> notes from the document editor of changes made in response to your feedb= ack >> . You were clearly *not* ignored. >> >> Could you please enumerate which specific concerns with the document tha= t >> you raised during the last WGLC have not been addressed. >> >> kind regards, > > > In particular: > > http://www.ietf.org/mail-archive/web/homenet/current/msg02426.html > > as far as I can tell is the end of involvement from the editors on the > initial thread > and after listening to Orlando -- as I said, I wouldn't be there -- nothi= ng > was discussed > there about my last call comments that I can recall. > > there was much discussion after that, but not much conclusive from the > editors, afaict. > i did, on the other hand, learn that mdns saved a major corporation from > obscurity. maybe > that's what's up. +10. I had generally reverted to ignoring homenet's work until working code showed up. Pointers to such on the OSPF front were discussed a month or two back, but links to it are not on the wg page, but I was totally unaware of the state of the code until then, and too busy since, to look. Some work has been going on in openwrt around implementing various homenet ideas but the work is far from baked enough to support the RFC. mdns ended up forking into mdnsext where some progress could actually be ma= de. > > Mike > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From mellon@fugue.com Mon Jun 17 09:05:18 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569D921F9CF5 for ; Mon, 17 Jun 2013 09:05:18 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyrFuwEPYsDY for ; Mon, 17 Jun 2013 09:05:12 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB0621F9D58 for ; Mon, 17 Jun 2013 09:05:12 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d9e:1628:9fcd:73b] (unknown [IPv6:2001:470:88a3:0:d9e:1628:9fcd:73b]) by toccata.fugue.com (Postfix) with ESMTPSA id 2406723805D7; Mon, 17 Jun 2013 12:05:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <51BF20AD.5070408@mtcc.com> Date: Mon, 17 Jun 2013 12:05:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> <51BF1015.1020007@mtcc.com> <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> <51BF20AD.5070408@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 16:05:18 -0000 On Jun 17, 2013, at 10:43 AM, Michael Thomas wrote: > A proposed standard carries a lot of weight, and I imagine that router = vendors will give it due deference. > So it better be a lot more than an educated guess IMO. I'd really like = to see that it gets hashed out in > enterprise space, for example, where there's a lot more expectation of = clue to sort things out if theory > doesn't exactly map to reality. Apparently you have never developed any new technology, and you expect = that router vendors never will either. > SAS is bound up in all kinds of things including ULA's. I'm not saying = that ULA's are bad or anything, but really that > especially in the face of mobility across administrative domains it's = as far as I know rather murky. MAY is a hedge, > MUST is "we're really really certain". I for one don't feel that we've = made it to that degree of certainty. Right, and my original argument was that the current requirement was = weaker than I would prefer, just as it is stronger than you would = prefer. It's almost as if it's a compromise between our two extreme = positions. > There's an intermediate ground between theory and mass deployment = without any expectation of clue: managed environments. > I'd say that we ought to be cautious before we proclaim victory and = drink the beer on the homenet front. It's not like > enterprise, .edu, etc are not going to have to deal with these = problems too, so let them take the arrows first. Again, you appear to be in the wrong working group. The homenet = working group was chartered to develop something new. The way that = happens is incrementally, and the incremental part of the process does = involve experimentation, but the goal is to get to something solid, and = it is valid for an IETF working group to attempt to get to something = solid that doesn't yet exist and hence isn't _yet_ solid. If _your_ goal is to do something really conservative, that's fine, but = we already did that. If your point is that you want to support HIPnet = as an intermediate step, I think that's fine too. But saying "we = shouldn't do this, because we haven't done it yet" is pretty circular. From mike@mtcc.com Mon Jun 17 09:46:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4321F9BCD for ; Mon, 17 Jun 2013 09:46:20 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id carhSvNJ6UzC for ; Mon, 17 Jun 2013 09:46:15 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id AF77C21F9BF7 for ; Mon, 17 Jun 2013 09:46:15 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HGjHVM005672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 09:45:18 -0700 Message-ID: <51BF3D18.4070508@mtcc.com> Date: Mon, 17 Jun 2013 09:45:12 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Dave Taht References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <51BF037A.2040907@mtcc.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> <51BF0E63.9000503@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2427; t=1371487519; x=1372351519; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20more=203.7 |Sender:=20 |To:=20Dave=20Taht=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=GY1oM0VzRqyf70fpBlSBH1RYHICYJvxoSGR5wfwgHE4=; b=MtoQMrMZ3ooEpeULzKe9ugYt0TYdulIulYNV2B6cpyZ/7cqEBXxcR/dGf0 H2pQNxC/HPVwwbLOzhwLkm3lEv73EEdjo9uP1lvHd/QHrx/qlU19nVVxMO+P GNv/1ft96lH/jrqhWHXMYeYOLKRj3U7SDmeLVmm1R/Z1htW0mCElM=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , "homenet@ietf.org Group" , "tjc@ecs.soton.ac.uk" Subject: [homenet] more 3.7 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 16:46:21 -0000 First off, i have to say that 3.7 is much improved. it's been really hard to correlate my feedback from the lack of response to my initial last call comments from the editors. 1) 3.7.1 I still think that the intro could use more motivation from the problem space before jumping in and proclaiming that users will choose from some gui. It's sort of the heart of why any of this is important. It might be nice here or in section 3.7 to have some ascii art too showing the various elements (cer repository, isp/cloud dns names, announcers/mdns'ers, local names, global names, tunnels) to have something to point at. 2) "In practice however the underlying service discovery protocols should be capable of handling moving to a network where a new device is using the same name as a device used previously in another homenet." I don't understand why they should be capable? What is the reason? 3) 3.7.8. Devices roaming from the homenet This is a new section and perhaps it's my fault, but isn't it a restatement that globally accessible names need to be part of the global dns? Or is this the "vpn"-like situation where I can see my local name space by virtue of having tunnelled back in? If the latter, it might be worthwhile to contrast it with global naming so as to make it more clear. 4) 3.7.3 Much better, but I'm still sort of uncomfortable about whether we really want the ulqdn name. It's been proposed, but it's not been very fleshed out, and I for one am not certain whether it means that I a) might have to type one in or b) have to look at the uldqn suffix to differentiate. It's not clear whether this document is the appropriate place to decide that, as I mentioned. 5) 3.7.4 Much improved. I like it a lot. Might it be better to move 3.7.8 if it's the latter interpretation into this section? This section is talking about local naming, and it seems that talking about tunnelling to see that naming might be appropriate here? (which was my mobility feedback). 6) 3.7.6 I still think it would be better to write this in terms of battery rather than specific networking technology. It speaks to the actual problem rather than one specific case. 7) 3.7.7 I still don't understand what this section is trying to highlight. Is there a piece of code here that needs to be written or not? I'm sorry if I'm being dense. Mike From mike@mtcc.com Mon Jun 17 10:03:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE84621F9CC6 for ; Mon, 17 Jun 2013 10:03:29 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1q2Y2P-gVoy for ; Mon, 17 Jun 2013 10:03:14 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id C136621F9A83 for ; Mon, 17 Jun 2013 10:03:02 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HH2WqC011621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 10:02:33 -0700 Message-ID: <51BF4123.9010307@mtcc.com> Date: Mon, 17 Jun 2013 10:02:27 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> <51BF1015.1020007@mtcc.com> <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> <51BF20AD.5070408@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3169; t=1371488553; x=1372352553; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=/WKxQMdEpVVyZdOZSjtZF+GFkCcSTs5BX4cgnRNcYqU=; b=Iow6KxGkTIjWYLopIm34jCBs+GJwJcWgK6fHziGQ/4qMJqDd9pxAmeupUd pZUsCMKNIntnV1IKSJaxdKi6D01iOS5IxjWSVLOZBbjRc7IzuABivcFE77oZ 48E6HuAN6X5WXRczNkfIflRhKx4b8ltbNT5leyk+FgXcjQIi2KygQ=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 17:03:30 -0000 Ted Lemon wrote: > On Jun 17, 2013, at 10:43 AM, Michael Thomas wrote: >> A proposed standard carries a lot of weight, and I imagine that router vendors will give it due deference. >> So it better be a lot more than an educated guess IMO. I'd really like to see that it gets hashed out in >> enterprise space, for example, where there's a lot more expectation of clue to sort things out if theory >> doesn't exactly map to reality. > > Apparently you have never developed any new technology, and you expect that router vendors never will either. Huh? I've been around this plenty. Dev managers give a lot of weight to rfc's and feed the MUST's and SHOULD's into their PERT charts (and completely ignore the MAY's). It's actually pretty shocking how much deference they are given. >> SAS is bound up in all kinds of things including ULA's. I'm not saying that ULA's are bad or anything, but really that >> especially in the face of mobility across administrative domains it's as far as I know rather murky. MAY is a hedge, >> MUST is "we're really really certain". I for one don't feel that we've made it to that degree of certainty. > > Right, and my original argument was that the current requirement was weaker than I would prefer, just as it is stronger than you would prefer. It's almost as if it's a compromise between our two extreme positions. MUST isn't strong, it's MUST. As in, no exceptions. SHOULD isn't a split the difference either. That really only leaves MAY for us to split the difference, even if that's not exactly optimal. >> There's an intermediate ground between theory and mass deployment without any expectation of clue: managed environments. >> I'd say that we ought to be cautious before we proclaim victory and drink the beer on the homenet front. It's not like >> enterprise, .edu, etc are not going to have to deal with these problems too, so let them take the arrows first. > > Again, you appear to be in the wrong working group. The homenet working group was chartered to develop something new. The way that happens is incrementally, and the incremental part of the process does involve experimentation, but the goal is to get to something solid, and it is valid for an IETF working group to attempt to get to something solid that doesn't yet exist and hence isn't _yet_ solid. > > If _your_ goal is to do something really conservative, that's fine, but we already did that. If your point is that you want to support HIPnet as an intermediate step, I think that's fine too. But saying "we shouldn't do this, because we haven't done it yet" is pretty circular. I don't think it's circular to say that we should be cautious about recommending things in the home environment which are extremely difficult to change our minds about later. That's especially true when the recommendations don't have much if any track record in the larger internet and are still a vexing problem. I'd say that SAS is absolutely in that category. We have excruciating burn marks from getting addressing wrong before with NAT's. I'd rather we not incinerate ourselves a second time. Mike From mike@mtcc.com Mon Jun 17 10:12:28 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70BD21F9B5F for ; Mon, 17 Jun 2013 10:12:28 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efs60eQTU-cY for ; Mon, 17 Jun 2013 10:12:23 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 944AA21F99DD for ; Mon, 17 Jun 2013 10:12:23 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HHBll7014561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 10:11:54 -0700 Message-ID: <51BF434F.3000103@mtcc.com> Date: Mon, 17 Jun 2013 10:11:43 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> <51BF1015.1020007@mtcc.com> <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> <51BF20AD.5070408@mtcc.com> <51BF4123.9010307@mtcc.com> In-Reply-To: <51BF4123.9010307@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=379; t=1371489115; x=1372353115; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=cLI04I4NnkgZLL0UljjhVmh6q3k8jH5zlXG53f5jQ4Q=; b=tSuTTZ14wavSqDfQPlqqkXoLBqEEZ1OG4A5w2230kGQr7YHDiSVh1teim0 n/cymBaFNq5bB2aM4SYcY5rq/FWdOWMkpQ3qlCMIa7INIvHxBCgpIPx6W62a +a57sq9E0GEXWqy0VGuRSO4CNV3j0516agMX+FCLLPSDZYhtrPojw=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 17:12:28 -0000 Michael Thomas wrote: PS: I'd contrast SAS with the routing problems that are being solved here. I personally don't find the problem all that compelling, but I do think we have a pretty damn good grip on what it means because of our vast experience with it in isp and enterprise, etc. So I'm perfectly fine with us pursuing it because of the low downside of harm. Mike From mellon@fugue.com Mon Jun 17 10:45:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127B121F99C6 for ; Mon, 17 Jun 2013 10:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMiAEi6vRnka for ; Mon, 17 Jun 2013 10:45:43 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1807E21F96D9 for ; Mon, 17 Jun 2013 10:45:43 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d9e:1628:9fcd:73b] (unknown [IPv6:2001:470:88a3:0:d9e:1628:9fcd:73b]) by toccata.fugue.com (Postfix) with ESMTPSA id F30B323805D7; Mon, 17 Jun 2013 13:45:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <51BF4123.9010307@mtcc.com> Date: Mon, 17 Jun 2013 13:45:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> <51BF1015.1020007@mtcc.com> <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> <51BF20AD.5070408@mtcc.com> <51BF4123.9010307@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 17:45:48 -0000 On Jun 17, 2013, at 1:02 PM, Michael Thomas wrote: > I don't think it's circular to say that we should be cautious about = recommending things in the home environment which > are extremely difficult to change our minds about later. What we are doing in this working group is _not_ "recommending" things = in the home environment. We are trying to solve a problem that exists = in the home environment for which no tried and true solution currently = exists. This is what I mean when I say you are in the wrong working group. You = are talking about this as if we were doing 6204bis, but that's a v6ops = document, not a homenet document. The HIPnet folks presented an interesting interim step along the way to = homenet that doesn't depend on quite as much unknown technology, = probably won't work as well ultimately, but may be a worthwhile step = along the way. I don't know if that's going to wind up being worked on = in homenet or not; if it is, you might want to look at it, because it = sounds like it's closer to what you have in mind. But it doesn't = address the full homenet architecture. And that's because the homenet = architecture document really is trying to do something new, _by design_. = If it didn't have the qualities that you ascribe to it as negatives, = it would not be addressing the work that homenet was chartered to do, = and hence couldn't be published in homenet. From mike@mtcc.com Mon Jun 17 11:36:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BBD21F9D7E for ; Mon, 17 Jun 2013 11:36:36 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTGbv77h-Dx6 for ; Mon, 17 Jun 2013 11:36:31 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3496F21F9D15 for ; Mon, 17 Jun 2013 11:36:31 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HIZxJo010528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 11:36:01 -0700 Message-ID: <51BF570B.9070205@mtcc.com> Date: Mon, 17 Jun 2013 11:35:55 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <51BF05CB.60709@globis.net> <8E756D56-64E2-4A77-A221-5BBB74115B0B@fugue.com> <51BF1015.1020007@mtcc.com> <3F004348-981D-4FD3-ADD4-21B13229D088@fugue.com> <51BF20AD.5070408@mtcc.com> <51BF4123.9010307@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1421; t=1371494161; x=1372358161; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=sYDVd4tv6tyRCbGv9Qs8oVyzlhQrZhyQTy2zK3FhqU0=; b=TGTsIu+bMsJAjCMZrGialWlW56BSe+gdtwOexqxHvzumTjz7gPNL2fqXPY 9u+BE9lgyAEwE+qQ02VU88vYRVpNkSnC48W1cjpSxw7nHp6MkSH5HU3qRJk2 hcHkwQBwAkE9nGds2cEyuUtIwmeDX3VD6GYOZUqieY+FXy0XRtzMs=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 18:36:36 -0000 Ted Lemon wrote: > On Jun 17, 2013, at 1:02 PM, Michael Thomas wrote: >> I don't think it's circular to say that we should be cautious about recommending things in the home environment which >> are extremely difficult to change our minds about later. > > What we are doing in this working group is _not_ "recommending" things in the home environment. We are trying to solve a problem that exists in the home environment for which no tried and true solution currently exists. Requiring MUST on ULA's to solve for disconnected reachability better mean that we understand the operational complexity of ULA's. ULA's are not the v6 equivalent of net 10 addresses, after all. The v6 model of acquiring as many addresses as routers advertise really exacerbate the SAS problem and our inadequacy of solving SAS in the last 10 years make this all a big science experiment, IMO. In isolation, sure, ULA's work well. But how do they interact with VPN and other tunnelling technologies, and their ULA's? How are boundaries established? What are boundaries, for that matter (one, of the charter items as I recall)? I'd really be worried that the architecture document specifies a MUST unless we're really, really sure. Maybe you are, but in the countless times I have brought this up here and elsewhere I feel that those kinds of problems just get paved over in the rush to get things out. Mike From jason.weil@twcable.com Mon Jun 17 12:13:17 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9243C21F9CF1 for ; Mon, 17 Jun 2013 12:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+Q42eJTgka2 for ; Mon, 17 Jun 2013 12:13:13 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7521F9CD8 for ; Mon, 17 Jun 2013 12:13:13 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,882,1363147200"; d="scan'208";a="91827994" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 17 Jun 2013 15:11:55 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 17 Jun 2013 15:12:42 -0400 From: "Weil, Jason" To: Ted Lemon , Michael Thomas Date: Mon, 17 Jun 2013 15:12:45 -0400 Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: Ac5rjqPyzq89/QYST/KvziUYfCYk0w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:13:17 -0000 Ted, This brings up a question that I have been struggling with for some time. The goal of this WG based on your description is to solve the home networking problems that exist with the addition of IPv6 and multiple subnets and all that entails as it relates to the removal of NAT, service discovery, naming and security impacts, etc. What is still not completely clear in my mind is whether we are creating the destination endgame design unhindered by current design/s or if we are creating the endgame design that can be incrementally reached without a greenfield deployment? If the end-game includes support for incremental migration which I for one believe it should, then it seems like some verbiage for this requirement needs to be included in the architecture. I am open for working this wording in if there is consensus. If there is consensus that this is not in scope and there is no bridge required from v6ops or other current operational groups to homenet then that will require a different group of people and maybe a different WG (maybe v6ops or something else?) to figure out how to get from where we are now to where we want to go. The HIPnet work feels like a good attempt at how to bridge the gap. It may not be the only solution, but is the only one I have seen proposed so far. My general feeling though is most people on the list aren't concerned with how to bridge the gap other than service providers and equipment vendors selling to those service providers who are actively working on pieces of this solution today. My concern is if there is no plan for an incremental solution to get to the Homenet architectural goal then there very well may be a divergence of design paths that may complicate any possibility of future convergence. Thanks, Jason On 6/17/13 1:45 PM, "Ted Lemon" wrote: >On Jun 17, 2013, at 1:02 PM, Michael Thomas wrote: >> I don't think it's circular to say that we should be cautious about >>recommending things in the home environment which >> are extremely difficult to change our minds about later. > >What we are doing in this working group is _not_ "recommending" things in >the home environment. We are trying to solve a problem that exists in >the home environment for which no tried and true solution currently >exists. > >This is what I mean when I say you are in the wrong working group. You >are talking about this as if we were doing 6204bis, but that's a v6ops >document, not a homenet document. > >The HIPnet folks presented an interesting interim step along the way to >homenet that doesn't depend on quite as much unknown technology, probably >won't work as well ultimately, but may be a worthwhile step along the >way. I don't know if that's going to wind up being worked on in homenet >or not; if it is, you might want to look at it, because it sounds like >it's closer to what you have in mind. But it doesn't address the full >homenet architecture. And that's because the homenet architecture >document really is trying to do something new, _by design_. If it >didn't have the qualities that you ascribe to it as negatives, it would >not be addressing the work that homenet was chartered to do, and hence >couldn't be published in homenet. > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From rdroms.ietf@gmail.com Mon Jun 17 13:14:02 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B678021F9D6C for ; Mon, 17 Jun 2013 13:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTeWOWnjJhJL for ; Mon, 17 Jun 2013 13:13:57 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id CF6C821F9D10 for ; Mon, 17 Jun 2013 13:13:56 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id f6so1962256qej.37 for ; Mon, 17 Jun 2013 13:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=RBSTzUW4CyfnjVfKSeo7w0qxQ5Sl8a/D2AkuQDcEaas=; b=SiQrLH+mDKN2QB3H+gWKm/RnT/62GHWezTRKAhgLB9QJKxB00GM1NEznrbueEnnWHk hdADXpFEGphjPL8bsrRwZVdcV8fMq6X2E8qVojeDuLfRM5Lh/+egkiZNxW0vYlIP5UgZ wt4g5R080lLEsrbx+Y1TzhlHXrD8g6KSjpWbAywK+pukh8I6wBaDnaSR+kM7Ou82Nn65 8Yx9yGBlx2ASpSwYxUcxreF3z1pd9QxNLTIGfEQnUCg24n++RB/XiVyesVwWz626sVa6 sYLme+Yio5UuZm8DxBcZIzZj6QCiLG42PSjbnYqVVRkfn0EehxR8aI8cP4UdGV3hjGyp Sgbw== X-Received: by 10.49.116.176 with SMTP id jx16mr22583475qeb.52.1371500036281; Mon, 17 Jun 2013 13:13:56 -0700 (PDT) Received: from [192.168.1.128] (c-24-62-231-127.hsd1.ma.comcast.net. [24.62.231.127]) by mx.google.com with ESMTPSA id ng3sm14943796qeb.0.2013.06.17.13.13.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 13:13:55 -0700 (PDT) References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> From: Ralph Droms Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B350) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> Message-Id: <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> Date: Mon, 17 Jun 2013 16:13:53 -0400 To: "homenet@ietf.org Group" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 20:14:02 -0000 In my opinion, the subnetting architecture for home networks needs to be mor= e carefully addressed in this document. As I read the document, the logical network topology is not clearly differen= tiated from the physical topology. Several of the motivations for a subnet a= rchitecture, including traffic isolation for security and traffic management= for QoS, are really dependent on the logical topology, and a physical topol= ogy of randomly connected devices is not likely to provide the desired logic= al topology. The document makes no mention of *how* a largest practical subnet architectu= re might be achieved. There should be some requirement that devices be capa= ble of acting as either a bridge or a router (or a mix of both), and that de= vices should bridge unless routing is determined necessary. Acknowledging the desire to avoid constraining future networks, I think the d= ocument would benefit from some discussion of scaling goals: how many subnet= s, how many ISP connections, etc. also, some text about how much and what u= ser configuration is acceptable should be added. As a specific example, net= work devices can't know, without user input, whether s guest network us desi= red and how devices should be guided to attach to the guest network. - Ralph From mike@mtcc.com Mon Jun 17 13:31:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6AC21F9732 for ; Mon, 17 Jun 2013 13:31:47 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3ZD-vmw7rGU for ; Mon, 17 Jun 2013 13:31:30 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id B751221F8CDD for ; Mon, 17 Jun 2013 13:31:20 -0700 (PDT) Received: from piolinux.mtcc.com (63-171-70-208.dsl.volcano.net [63.171.70.208] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5HKVIxT016792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jun 2013 13:31:19 -0700 Message-ID: <51BF7213.8040506@mtcc.com> Date: Mon, 17 Jun 2013 13:31:15 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "homenet@ietf.org Group" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=540; t=1371501079; x=1372365079; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20section=203.6.3 |Sender:=20 |To:=20=22homenet@ietf.org=20Group=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=E4AmCG1jRlaqsW0fswWvDoKSRJ0OOzvsVahDi6IgDE4=; b=GtXFXyrqKzK9Lf8kttsvqAvJmixqLLoNtEIWw+vqjEgnOgxTTEae3MoYlk pPParAAp6SjZ9JGLW2T+Lkdpu6lTB+DzuGDKBiFv6xWa8lacnfgahNbESmzK UulPBNZKFNEWOoJcxoX16WCZ53JsI7U7ao8N9Vp7lSEDICXVlYO/w=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: [homenet] section 3.6.3 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 20:31:52 -0000 dissing nat as a security measure is fine by me, but i'm not sure that going on to diss firewalls is really appropriate. i haven't heard of any great movement to remove them, even though they cause trouble with new fangled protocols. the one area that i wonder about is carrier ip connectivity on phones: i assume that they are behind the carriers firewall? if they aren't, or that firewall is really permissive maybe there's something to this section. if not, do we really have evidence to be so dismissive of firewalls? Mike From mellon@fugue.com Mon Jun 17 13:36:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5BF21F9DB9 for ; Mon, 17 Jun 2013 13:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojiz3pjOfS5x for ; Mon, 17 Jun 2013 13:36:45 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5B17021F9DB4 for ; Mon, 17 Jun 2013 13:36:43 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d9e:1628:9fcd:73b] (unknown [IPv6:2001:470:88a3:0:d9e:1628:9fcd:73b]) by toccata.fugue.com (Postfix) with ESMTPSA id 92B2A238038C; Mon, 17 Jun 2013 16:36:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: Date: Mon, 17 Jun 2013 16:36:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 20:36:54 -0000 On Jun 17, 2013, at 3:12 PM, "Weil, Jason" = wrote: > This brings up a question that I have been struggling with for some = time. > The goal of this WG based on your description is to solve the home > networking problems that exist with the addition of IPv6 and multiple > subnets and all that entails as it relates to the removal of NAT, = service > discovery, naming and security impacts, etc. Sure. Whether HIPnet will get worked on, and by which working group, is, I = think, an open question. Personally I see it as a good incremental = step between 6204bis and the full homenet solution, and I'd like to see = it worked on because it's pretty clear to me that there's demand for it = now. I would be very disappointed if HIPnet were the final output of = this working group, and I don't think here's much enthusiasm for that = path anyway. But while there might be enthusiasm for skipping HIPnet, = I think we will leave the demand for a near-term solution unmet if we do = that, and that might turn out to be expensive. My suspicion is that it will be possible once homenet, hipnet (assuming = it gets worked on) and 6204bis are done to have a provider = infrastructure that supports all three, so that no greenfield upgrade = will be required. But there's no way to deploy that architecture now, = because we don't know everything we need to know to deploy it. So I = think realistically an ISP that deploys a 6204bis or HIPnet = infrastructure in the near term will almost certainly have to re-tune = their deployment to support homenet in the future. I think there are a = lot of things that can be done to minimize the pain that's caused by = that upgrade, but I don't think anybody should plan on the homenet = router being a drop-in replacement with full functionality and no = changes on the provider network. In particular, the DNS solution isn't fully fleshed out yet. You can = deploy 6204bis with a /64, but that's not going to work for homenet or = hipnet. I _think_ those are the two sticking points, but it wouldn't = shock me deeply if more surface as we go forward. From rdroms.ietf@gmail.com Mon Jun 17 14:09:39 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFB421F9E65 for ; Mon, 17 Jun 2013 14:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfqg89mJcQcQ for ; Mon, 17 Jun 2013 14:09:34 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9632D21F9E16 for ; Mon, 17 Jun 2013 14:09:34 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so2019579qee.12 for ; Mon, 17 Jun 2013 14:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=38jLdX3CNjzlyBPgn8gF3jpQ4alc4MNjYPabXSmbLU8=; b=rS9rHA4lfz4GuerqNaDcSrDflKDOwYRACCw9QQ5c82OjU9hI2hlFUIHvW1MmuFxkok Yx455CKu5EJ+4lnv17icFsGaUtiaTx11617LiBZsAfQ1PzXIg4m+EJ5w3R+BR/4s3eK+ 72NyDzHs1STDmtM53vVetS6KJ2QEZjRwchC0vTtwVAG9eRAbCq08FKiUFsd+gceDdo9Q EYLnbfD8kPRgO5PdOUsvFHia4QJM4RKygL7Bmb7dpUvTEcyO3wdv2BwxYbvYsMmwERW/ E7exZS6opf11nPAnQB5y6gHMos0aTQEfulCiL+xCg0ZwDByfzZDNUosmKi2ABoh4S/a6 ZrhA== X-Received: by 10.229.109.68 with SMTP id i4mr7172097qcp.147.1371503374012; Mon, 17 Jun 2013 14:09:34 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:d9dc:cff:1431:8a53? ([2001:420:2481:20:d9dc:cff:1431:8a53]) by mx.google.com with ESMTPSA id ng3sm15219953qeb.0.2013.06.17.14.09.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 14:09:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ralph Droms In-Reply-To: <201306151835.r5FIZ1De044175@gateway1.orleans.occnc.com> Date: Mon, 17 Jun 2013 17:09:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <661DF4C2-B4E0-43A0-B934-0081A1E582A3@gmail.com> References: <201306151835.r5FIZ1De044175@gateway1.orleans.occnc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1503) Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 21:09:39 -0000 On Jun 15, 2013, at 2:35 PM 6/15/13, Curtis Villamizar = wrote: >=20 > In message = <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> > Ray Bellis writes: >=20 >> I'd like to remind the WG that this last call will expire *next = Monday*. >>=20 >> Please send any comments to the list and editor ASAP. It would also = be useful to receive comments along the lines of "it's ready, ship it!". >>=20 >> thanks, >>=20 >> Ray >=20 >=20 > [...] > The point is that though this framework has tremedously improved > (though it still cited mDNS and entertains the possibility of multiple > zeroconf name services plus DNS :), there is a ways to go. Hopefully > this draft can remain a living document rather than freeze it > prematurely by moving it to the IESG and trying to get premature RFC > status. >=20 > On many issues the WG has converged in the last year or so, yet IMHO > too many remain open. >=20 > Curtis I think Curtis has made a good suggestion that deserves some discussion. = I, too, have some concerns (expressed in a recent post to the WG = mailing list) about the document, yet I think it is very good and far = enough along to be used as the basis for discussion of other documents = and possible adoption of some additional WG documents. So, I suggest it's appropriate for the WG to use the current version of = homenet-arch as the basis for discussion of other documents, while, in = parallel, completing and publishing a revised version of homenet-arch as = a document of record, while maintaining, as Curtis suggests, a living = document (perhaps as a homenet-arch-bis I-D?) that records changes in = thinking about the hoemnet architecture as the protocol suite is = developed. And, I realize how many WG architecture documents have been OBE and = never published in a final version. I think the homenet WG has adopted = a wise strategy encouraging work on the architecture document to avoid = the "ready, fire, aim" syndrome. - Ralph From mcr@sandelman.ca Mon Jun 17 17:09:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B6621F9E55 for ; Mon, 17 Jun 2013 17:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY1p774wNMfo for ; Mon, 17 Jun 2013 17:09:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 97F3621F9DC2 for ; Mon, 17 Jun 2013 17:09:14 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3320320271; Mon, 17 Jun 2013 20:22:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5A769A9028; Mon, 17 Jun 2013 20:08:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4BDDB63732; Mon, 17 Jun 2013 20:08:13 -0400 (EDT) From: Michael Richardson To: Michael Thomas In-Reply-To: <51BF7213.8040506@mtcc.com> References: <51BF7213.8040506@mtcc.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 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] section 3.6.3 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 00:09:21 -0000 --=-=-= Michael Thomas wrote: mt> dissing nat as a security measure is fine by me, but i'm not sure that going on to diss firewalls mt> is really appropriate. i haven't heard of any great movement to remove them, even though they mt> cause trouble with new fangled protocols. I've yet to see any home other than mine (and 2 technical FreeS/WAN colleagues...) that had a firewall that was more complicated than NAT. (Port forwards are NAT work around) mt> the one area that i wonder about is carrier ip connectivity on phones: i assume that they are mt> behind the carriers firewall? if they aren't, or that firewall is really permissive maybe there's mt> something to this section. if not, do we really have evidence to be so dismissive of firewalls? Do you mean things like phone service sold by, for instance, incumbent cable operators? The ATA is generally built into the NAT/modem. Sometimes the cable operator provides two modems, one for phone. I have seen Rogers in Ottawa do both. The devices are not behind any firewall or on a seperate VLAN or anything. At novavision.ca, the business connectivity that we provide for phones using a hosted PBX uses a seperate VLAN. We provide firewalled IPv6 and non-routed IPv4 connectivity. (i.e. RFC1918, no NAT) to the phones, but so far, no phone manufacturer we deal with ships a phone with IPv6. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUb+k6oqHRg3pndX9AQKexQP+P4wyAR8tIWrVYOzn7BajCX3uXUMKXBmG NyI4+FLLGQu49VHe5DjySrXAV14DXGnBNTaju7V3KAN9t4r6Qd5QwyoMEYeZaNi8 hrEqTmGO+u79suCywApBN0bHnhyTfgjJ4KqgTIz725sgZwPBFjiU0kQiMA9atULQ T69FQzSuVi4= =NsVp -----END PGP SIGNATURE----- --=-=-=-- From mike@mtcc.com Mon Jun 17 17:17:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3345A21F9CA1 for ; Mon, 17 Jun 2013 17:17:47 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLOeTF++SvQW for ; Mon, 17 Jun 2013 17:17:36 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 0B31A21F9C65 for ; Mon, 17 Jun 2013 17:17:35 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5I0HVAu027192 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 17:17:32 -0700 Message-ID: <51BFA71B.8010001@mtcc.com> Date: Mon, 17 Jun 2013 17:17:31 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <51BF7213.8040506@mtcc.com> <16772.1371514093@sandelman.ca> In-Reply-To: <16772.1371514093@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1406; t=1371514652; x=1372378652; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20section=203.6.3 |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=yJW2Poyalj/fuwT3qkuETghpdloib77LtXHzt9coEp8=; b=Vq6/OiCBl1vF56duFGFRTyT3Uev+HbhfJ4N0s2jqjUCqOV06ULnDWYzAP8 +LGZIG41uZr2PoufrqWNl+s/nX/f/MEY9YndH6slJLunZZi/jaHVKbxppNre b8EwlqTp/Owf+Q959vZF1LLld4RSW+S63gMq3MCkir3AKYN/71LWE=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] section 3.6.3 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 00:17:47 -0000 On 06/17/2013 05:08 PM, Michael Richardson wrote: > Michael Thomas wrote: > mt> dissing nat as a security measure is fine by me, but i'm not sure that going on to diss firewalls > mt> is really appropriate. i haven't heard of any great movement to remove them, even though they > mt> cause trouble with new fangled protocols. > > I've yet to see any home other than mine (and 2 technical FreeS/WAN colleagues...) that > had a firewall that was more complicated than NAT. (Port forwards are NAT work around) > > mt> the one area that i wonder about is carrier ip connectivity on phones: i assume that they are > mt> behind the carriers firewall? if they aren't, or that firewall is really permissive maybe there's > mt> something to this section. if not, do we really have evidence to be so dismissive of firewalls? > > Do you mean things like phone service sold by, for instance, incumbent cable operators? > The ATA is generally built into the NAT/modem. Sometimes the cable operator > provides two modems, one for phone. I have seen Rogers in Ottawa do both. No, no, I mean smart phones connected to say, 3g cellular. Are they behind, say, VZW's firewall, or are they on their own firewallwise? (I'd actually be happy if it wasn't behind their firewall so the carrier doesn't hold my phone hostage to their firewall whims.) Mike From mcr@sandelman.ca Mon Jun 17 17:58:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0715221F9CFD for ; Mon, 17 Jun 2013 17:58:26 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opW0jrCdoOhc for ; Mon, 17 Jun 2013 17:58:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 49A9921F9CF2 for ; Mon, 17 Jun 2013 17:58:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7048720271; Mon, 17 Jun 2013 21:12:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 71CEDA9028; Mon, 17 Jun 2013 20:57:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5F29063732; Mon, 17 Jun 2013 20:57:24 -0400 (EDT) From: Michael Richardson To: Michael Thomas In-Reply-To: <51BFA71B.8010001@mtcc.com> References: <51BF7213.8040506@mtcc.com> <16772.1371514093@sandelman.ca> <51BFA71B.8010001@mtcc.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 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] section 3.6.3 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 00:58:26 -0000 --=-=-= Michael Thomas wrote: >> Do you mean things like phone service sold by, for instance, incumbent cable operators? >> The ATA is generally built into the NAT/modem. Sometimes the cable operator >> provides two modems, one for phone. I have seen Rogers in Ottawa do both. mt> No, no, I mean smart phones connected to say, 3g cellular. Are they behind, say, mt> VZW's firewall, or are they on their own firewallwise? My 3G experience has all involved NAT and IPv4. So there was a unidirectional SYN firewall. I've seen port-25 and port-139 blocked, but that was all. I don't know what happens when there IPv6. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUb+wcYqHRg3pndX9AQJ7ygP+NSDkEfMYMx6XWpXpiSm59IXmP/aRxU4e 63SKC6bH9ITlVXGGK0yJFDDEQKkR0WWUCasCUuJdFOvgmDoxov1xglaZYnjMVMw9 T4EKYkYDvW/hjPrcHD15zEM738qosfqReR6MrBGRndMzYPIBLxBO0VavYk9hdlP8 PdHV2OUYEW4= =Raje -----END PGP SIGNATURE----- --=-=-=-- From mike@mtcc.com Mon Jun 17 18:08:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D1C21F9D6F for ; Mon, 17 Jun 2013 18:08:14 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqrExO0a4q01 for ; Mon, 17 Jun 2013 18:08:10 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2182121F9D48 for ; Mon, 17 Jun 2013 18:08:10 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5I1898i011711 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 18:08:09 -0700 Message-ID: <51BFB2F9.20101@mtcc.com> Date: Mon, 17 Jun 2013 18:08:09 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <51BF7213.8040506@mtcc.com> <16772.1371514093@sandelman.ca> <51BFA71B.8010001@mtcc.com> <32443.1371517044@sandelman.ca> In-Reply-To: <32443.1371517044@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1178; t=1371517689; x=1372381689; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20section=203.6.3 |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=49a58teNvuJyNqXOqmGmM5HMgVQLKXH0/6wM3OJc9a4=; b=tE2pjWqcLq7rvFfyu5YV8bHIuethAt2zgkFk+uDdOW/MaylQwX4iok3gUF Lbh39ZPM1MIug6Ypns5O7imgeJRMr7BlPj80POyolUwyn3+AzRW6zOGuca54 Mb4VejxHCoFuawVdylKwzVA9AHG3qKxAX+VDW4Ukx+rEVlEm8Pis4=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] section 3.6.3 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 01:08:14 -0000 On 06/17/2013 05:57 PM, Michael Richardson wrote: > Michael Thomas wrote: > >> Do you mean things like phone service sold by, for instance, incumbent cable operators? > >> The ATA is generally built into the NAT/modem. Sometimes the cable operator > >> provides two modems, one for phone. I have seen Rogers in Ottawa do both. > > mt> No, no, I mean smart phones connected to say, 3g cellular. Are they behind, say, > mt> VZW's firewall, or are they on their own firewallwise? > > My 3G experience has all involved NAT and IPv4. > So there was a unidirectional SYN firewall. I've seen port-25 and port-139 > blocked, but that was all. > > I don't know what happens when there IPv6. > Yeah, I haven't actually tried listening on port 80 on my android when I happen to be on v6 and seeing if it's walled off. I was hoping that lazywebs would help me out here. *If* phones are not walled off now, I have no objection to this section as it's a stake in the ground that hosts can be their own firewalls. But I'd like to have some belief that that is true before we declare homenet firewalls obsolete. Mike Mike From marka@isc.org Mon Jun 17 19:03:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C2821F9D98 for ; Mon, 17 Jun 2013 19:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NItkP7E15lw for ; Mon, 17 Jun 2013 19:03:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0D97D21F9D92 for ; Mon, 17 Jun 2013 19:03:24 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E7591C9498; Tue, 18 Jun 2013 02:03:11 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371520999; bh=N9E1U5mymgaHoi3HWgzEhLxtl9p9k5jPJHtuDi7XhzE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=NKX06BOhU6f2gINzZNx076wmw92BL9BHVqoaflD9AEvwkhestZo0i+v6XtiSi8yZy iTp5rP0o2axY6aBhe5EuWiBTTzgmgtRpaAQYpJjbu2tD5KWXqqwrL+x/6Sl4DXcTsi xnVcyBpzXjo+aI7XEXYusGzc2TwZSGaWXJwxD8sI= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 18 Jun 2013 02:03:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 900EB216C40; Tue, 18 Jun 2013 02:03:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 855D53600559; Tue, 18 Jun 2013 12:03:08 +1000 (EST) To: Michael Thomas From: Mark Andrews References: <51BF7213.8040506@mtcc.com> <16772.1371514093@sandelman.ca> <51BFA71B.8010001@mtcc.com> <32443.1371517044@sandelman.ca> <51BFB2F9.20101@mtcc.com> In-reply-to: Your message of "Mon, 17 Jun 2013 18:08:09 -0700." <51BFB2F9.20101@mtcc.com> Date: Tue, 18 Jun 2013 12:03:08 +1000 Message-Id: <20130618020308.855D53600559@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] section 3.6.3 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 02:03:31 -0000 In message <51BFB2F9.20101@mtcc.com>, Michael Thomas writes: > On 06/17/2013 05:57 PM, Michael Richardson wrote: > > Michael Thomas wrote: > > >> Do you mean things like phone service sold by, for instance, incumbent cable operators? > > >> The ATA is generally built into the NAT/modem. Sometimes the cable operator > > >> provides two modems, one for phone. I have seen Rogers in Ottawa do both. > > > > mt> No, no, I mean smart phones connected to say, 3g cellular. Are they behind, say, > > mt> VZW's firewall, or are they on their own firewallwise? > > > > My 3G experience has all involved NAT and IPv4. > > So there was a unidirectional SYN firewall. I've seen port-25 and port-139 > > blocked, but that was all. > > > > I don't know what happens when there IPv6. > > > > Yeah, I haven't actually tried listening on port 80 on my android when I happen > to be on v6 and seeing if it's walled off. I was hoping that lazywebs would help > me out here. *If* phones are not walled off now, I have no objection to this section as > it's a stake in the ground that hosts can be their own firewalls. But I'd like to have > some belief that that is true before we declare homenet firewalls obsolete. While I don't want a reply only in firewall I do want source address filtering on by default in the border routers. The are too many places that pass spoofed addresses. Allow out only source address announced in RA's/learn't by PD. Deny in source addresses announced in RA's/learnt by PD. This would put the IPv6 side on par (or better as it would actually drop the spoofed traffic rather than map it to the public address) with IPv4 + PNAT in preventing spoofed addresses leaving the network. Mark > Mike > > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From otroan@employees.org Tue Jun 18 01:10:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1319121F88EA for ; Tue, 18 Jun 2013 01:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHxdwa1Yx3XG for ; Tue, 18 Jun 2013 01:10:51 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 4191A21F9446 for ; Tue, 18 Jun 2013 01:10:42 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 43DE05EB6; Tue, 18 Jun 2013 01:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=pxBIs3+6rhwWw2oaCUnLDP6GL9U=; b=lYO62fcmq7quUinZa7 KAO2PwEk8fqRorsakUx7EHBjBsrGyap+6wxmyS2+AgYsXvYBBy79QP5VM6YcHZir TKIvAa8+ar9rAesM7Ky75WJ3eVmRD8uhL3I0OCJaN+gLGgH6lQdwjT3u/p9PIBjl PMJTuzqFPlaOLEktaaxoPm97M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=AnsGfHlvkv2f6i/9pPhqts0CHyqiFnIMFua+bFBwnj7vXejWAQ5 qJBut+H+xZkKYFkuscWgnsylrH5fOmbbLa7QsPkLG/u8/rKsOQXD9nJhcWObwzRz FvnnhksW7y9il9c7Dnh2PihN89Lk+ToagcMtUosDlyYhCPirlGK8xUiw= Received: from dhcp-10-61-111-107.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 517FB5EA3; Tue, 18 Jun 2013 01:10:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Tue, 18 Jun 2013 10:10:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:10:54 -0000 Jason, > The HIPnet work feels like a good attempt at how to bridge the gap. It = may > not be the only solution, but is the only one I have seen proposed so = far. > My general feeling though is most people on the list aren't concerned = with > how to bridge the gap other than service providers and equipment = vendors > selling to those service providers who are actively working on pieces = of > this solution today. My concern is if there is no plan for an = incremental > solution to get to the Homenet architectural goal then there very well = may > be a divergence of design paths that may complicate any possibility of > future convergence. that's an interesting question. it isn't clear to me if hipnet is = incrementally taking us closer to the end goal, or if it makes the transition from a single CPE to a routed network much harder. if my assumption of the latter is correct, what can we do to minimize = the damage? could hipnet be scaled back to the simpler case of two routers being = piggy-backed? cheers, Ole= From mcr@sandelman.ca Tue Jun 18 06:05:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2421F8F09 for ; Tue, 18 Jun 2013 06:05:54 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eehZE9UNQhco for ; Tue, 18 Jun 2013 06:05:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 29AEA21F8B21 for ; Tue, 18 Jun 2013 06:05:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D469620188; Tue, 18 Jun 2013 10:09:31 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 31BAE63A88; Tue, 18 Jun 2013 09:04:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1D07563A7C; Tue, 18 Jun 2013 09:04:54 -0400 (EDT) From: Michael Richardson To: Ole Troan In-Reply-To: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.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 Cc: "homenet@ietf.org Group" , "Weil, Jason" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:05:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ole Troan wrote: >> The HIPnet work feels like a good attempt at how to bridge the gap. = It >> may not be the only solution, but is the only one I have seen propos= ed >> so far. My general feeling though is most people on the list aren't >> concerned with how to bridge the gap other than service providers and >> equipment vendors selling to those service providers who are actively >> working on pieces of this solution today. My concern is if there is = no >> plan for an incremental solution to get to the Homenet architectural >> goal then there very well may be a divergence of design paths that m= ay >> complicate any possibility of future convergence. ot> that's an interesting question. it isn't clear to me if hipnet is ot> incrementally taking us closer to the end goal, or if it makes the ot> transition from a single CPE to a routed network much harder. My review of the CableLabs Homenetworking stuff (I won't call it HIPnet, due to RFC4423 and friends) is that it is a dead end. If we fix it enough to accomodate an upgrade that supports topologies with loops, then we already have accomplished homenet. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcBa8oqHRg3pndX9AQL2XQP/VgIVXHVO5/llATFSQM8BGWSzy4B06lws bmqCsA3Fg+JFsn0CEkXIwdCB2ZCEBXqjiadxguFAP188jtkQ9dynRMhb4/b4IEeH vT/klwTOYiHKEs98IdOyrLEwK2ctxbc97xwer76s8Qgb6ufUmeG0l2z0uFMD7nBe nRUBdY+mfNM= =aMgp -----END PGP SIGNATURE----- --=-=-=-- From arnaud.kaiser@cea.fr Tue Jun 18 06:25:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39F821F84E3 for ; Tue, 18 Jun 2013 06:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10yqa6CyuljE for ; Tue, 18 Jun 2013 06:25:54 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9E14821F8FF3 for ; Tue, 18 Jun 2013 06:25:53 -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 r5IDPq9R025279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Jun 2013 15:25:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5IDPpWM025365 for ; Tue, 18 Jun 2013 15:25:52 +0200 (envelope-from arnaud.kaiser@cea.fr) Received: from [10.8.33.118] (is010461-4.intra.cea.fr [10.8.33.118]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5IDPpda027132 for ; Tue, 18 Jun 2013 15:25:51 +0200 Message-ID: <51C05FE7.4000408@cea.fr> Date: Tue, 18 Jun 2013 15:25:59 +0200 From: Arnaud Kaiser User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: homenet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] For information: Announced new draft on MIF WG: draft-kaiser-if-sel-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:25:59 -0000 Dear participants to homenet group, We submitted "Interface Selection Mechanism for Multiple Interfaces IPv6 Hosts" draft-kaiser-if-sel-00 available at: http://tools.ietf.org/html/draft-kaiser-if-sel-00 This document describes an interface selection mechanism that enables multiple interfaces (multihomed) IPv6 hosts to select their most appropriate egress interface to send data over the network. The mechanism extends the Neighbor Discovery (ND) protocol [RFC4861] with two new Router Advertisement options. The proposed mechanism has been developed in the context of home network and may be relevant to HOMENET WG. Your comments are very welcome. Thanks in advance, Arnaud & Alex From jason.weil@twcable.com Tue Jun 18 06:45:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD3421F9371 for ; Tue, 18 Jun 2013 06:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS9b5AaTPJNX for ; Tue, 18 Jun 2013 06:45:52 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1121F901F for ; Tue, 18 Jun 2013 06:45:51 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,889,1363147200"; d="scan'208";a="95169600" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 18 Jun 2013 09:44:39 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 18 Jun 2013 09:45:30 -0400 From: "Weil, Jason" To: Ole Troan Date: Tue, 18 Jun 2013 09:45:28 -0400 Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: Ac5sKhhJWL5BgUo4Rv+1l98BTgsjtw== Message-ID: In-Reply-To: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:45:57 -0000 I was using HIPnet as an example as it is the only one that I am aware. The question though was should the architecture have wording to support a path to the proposed destination from where we are today or are we just assuming that backward compatibility is not achievable? Ted has a good point though in that we need to see what the architecture is going to be before we are able to understand if we can migrate to it. Jason On 6/18/13 4:10 AM, "Ole Troan" wrote: >Jason, > >> The HIPnet work feels like a good attempt at how to bridge the gap. It >>may >> not be the only solution, but is the only one I have seen proposed so >>far. >> My general feeling though is most people on the list aren't concerned >>with >> how to bridge the gap other than service providers and equipment vendors >> selling to those service providers who are actively working on pieces of >> this solution today. My concern is if there is no plan for an >>incremental >> solution to get to the Homenet architectural goal then there very well >>may >> be a divergence of design paths that may complicate any possibility of >> future convergence. > >that's an interesting question. it isn't clear to me if hipnet is >incrementally >taking us closer to the end goal, or if it makes the transition >from a single CPE to a routed network much harder. > >if my assumption of the latter is correct, what can we do to minimize the >damage? >could hipnet be scaled back to the simpler case of two routers being >piggy-backed? > >cheers, >Ole This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Ray.Bellis@nominet.org.uk Tue Jun 18 06:59:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C678B21F9B16 for ; Tue, 18 Jun 2013 06:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWnNtY331CNe for ; Tue, 18 Jun 2013 06:58:55 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 895E821F9DBB for ; Tue, 18 Jun 2013 06:58:55 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV: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:Content-ID:Content-Transfer-Encoding: MIME-Version; b=rX3eUcs4t0VBGXJHTreGWpzLLTcoO5JkAGmT4hq9nspeJ+q0hVJnQl3h 6Mhk+XHB5akOQsS6rQmRWXBiV19uOqvLjeijQAZO8UPKQO7Hd7wJ9AAV8 A1d0JKerCNhm8et; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1371563935; x=1403099935; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MAFpnQh4ln+PLOIkXam62LsgG4hodnWVd51X5djMrmY=; b=txY1vdsF86foX/rq0WOI3Zft6hZcSEiu4zT8QYw1fvblC326o5hn4HME uHfei+K3x1qhgHfRwV9GqWtLVJGMCC0Bb3B2VqOdOxdxzLX6784iK8Pyw FU9EYOFMetKc5mh; X-IronPort-AV: E=Sophos;i="4.87,889,1363132800"; d="scan'208";a="1170560" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 18 Jun 2013 14:58:54 +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%17]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 14:58:54 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAT0wICAAAdSgIAABPKAgAAKvACAAAkMgIAAFqaAgAAQDICAAAwTAIAAGFWAgADZVACAAGFPgA== Date: Tue, 18 Jun 2013 13:58:53 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> In-Reply-To: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> 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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:59:00 -0000 combining a couple of messages: On 17 Jun 2013, at 21:36, Ted Lemon wrote: > My suspicion is that it will be possible once homenet, hipnet (assuming i= t gets worked on) and 6204bis are done to have a provider infrastructure th= at supports all three, so that no greenfield upgrade will be required. My expectation is that neither HIPnet nor Homenet require any specific chan= ges at the provider network. Particularly w.r.t. the network topology and prefix delegation, all of the = changes are from the LAN side of the CPE. On 18 Jun 2013, at 09:10, Ole Troan wrote: > that's an interesting question. it isn't clear to me if hipnet is increme= ntally > taking us closer to the end goal, or if it makes the transition > from a single CPE to a routed network much harder. My reading of HIPnet is that it would *not* permit a natural progression to= the full Homenet solution as currently envisaged by the WG. The corollary of that, as =D8le aludes to is that deployment of HIPnet may = indeed make it *harder* to transition to a fully routed network in the futu= re. We would welcome feedback from the HIPnet authors on how they would anticip= ate supporting co-existence and/or transition from HIPnet to "full" Homenet= . =20 kind regards, Ray From ot@cisco.com Tue Jun 18 06:59:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9500421F9F69 for ; Tue, 18 Jun 2013 06:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwS7Z+Xx-t4U for ; Tue, 18 Jun 2013 06:59:51 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5C73C21F9F68 for ; Tue, 18 Jun 2013 06:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1055; q=dns/txt; s=iport; t=1371563991; x=1372773591; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ehNpha3L/oxiXd0fkaHMVYanjPx/TzRZOKgntUdelhw=; b=QS2rkhgd+6hBfBFffWo43ykPMReG9AGkpQciHw7BWco8kZ8myvNp3P3p VzDSEUcvalcyD5e39TQDRt1yYQEH0NAOaSecWk5s70sgZyuypm6Zrz06J onKO+qdFLWJdSHPmB8ZoawOtR9EaaA9LRaB7tm/MiT1dJBM4vL5crnVeF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIHAJBmwFGQ/khR/2dsb2JhbABZgwkxq1yTeIEAFnSCIwEBAQMBOj8FCwtGVwaIGwYMumePCDMHgwBhA5dBgSmJA4cXgViBOTo X-IronPort-AV: E=Sophos;i="4.87,889,1363132800"; d="scan'208";a="14793529" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 18 Jun 2013 13:59:50 +0000 Received: from dhcp-10-61-111-107.cisco.com (dhcp-10-61-111-107.cisco.com [10.61.111.107]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5IDxlSG018305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 13:59:48 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51C05FE7.4000408@cea.fr> Date: Tue, 18 Jun 2013 15:59:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58A09DD3-366B-460B-BFC3-F1B7E7B10B61@cisco.com> References: <51C05FE7.4000408@cea.fr> To: Arnaud Kaiser X-Mailer: Apple Mail (2.1508) Cc: homenet Subject: Re: [homenet] For information: Announced new draft on MIF WG: draft-kaiser-if-sel-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:59:59 -0000 > We submitted "Interface Selection Mechanism for Multiple Interfaces = IPv6 Hosts" draft-kaiser-if-sel-00 available at: > http://tools.ietf.org/html/draft-kaiser-if-sel-00 >=20 > This document describes an interface selection mechanism that enables > multiple interfaces (multihomed) IPv6 hosts to select their most > appropriate egress interface to send data over the network. The > mechanism extends the Neighbor Discovery (ND) protocol [RFC4861] with > two new Router Advertisement options. >=20 > The proposed mechanism has been developed in the context of home = network and may be relevant to HOMENET WG. there was something similar discussed at the last IETF, about adding = meta information to prefixes: http://tools.ietf.org/html/draft-korhonen-dmm-prefix-properties-03 http://tools.ietf.org/html/draft-bhandari-dhc-class-based-prefix-04 could you do what you want with that? taking the link cost and path cost to its logical end, wouldn't you just = have the host participate in the routing protocols? cheers, Ole= From mellon@fugue.com Tue Jun 18 07:18:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A325121F9EE1 for ; Tue, 18 Jun 2013 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByhOBOffZZ23 for ; Tue, 18 Jun 2013 07:18:51 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 70B8221F9BC3 for ; Tue, 18 Jun 2013 07:18:51 -0700 (PDT) Received: from [IPv6:2001:470:88a3::cdbd:4df5:1265:653d] (unknown [IPv6:2001:470:88a3:0:cdbd:4df5:1265:653d]) by toccata.fugue.com (Postfix) with ESMTPSA id B66CB23805D7; Tue, 18 Jun 2013 10:18:49 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> Date: Tue, 18 Jun 2013 10:18:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:18:56 -0000 On Jun 18, 2013, at 9:58 AM, Ray Bellis = wrote: > My reading of HIPnet is that it would *not* permit a natural = progression to the full Homenet solution as currently envisaged by the = WG. I think by this you mean that a home network that has HIPnet routers = probably won't work if you try to add Homenet routers to it, right? From Ray.Bellis@nominet.org.uk Tue Jun 18 07:26:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96DE21F9963 for ; Tue, 18 Jun 2013 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvDT-ikIKv4T for ; Tue, 18 Jun 2013 07:26:11 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7D21F9B87 for ; Tue, 18 Jun 2013 07:26:11 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV: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=02d+fcKTg3LUhwgGhRvU8zSE2Jl7SiV8RpBEvWkvloPuz5xBpdA5kMLv Vga/oN37uJs3kpxdkusRCBJ5kXyFmIGtSuTwyWmcXFbsP0exBBvVq1IEy elc+jSM5c/xzFoR; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1371565571; x=1403101571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jp3youE2ejb/KD9szNetEUmx0h3KBTUPud6M5c6hqKw=; b=e/DeMJPUJvIHQAqNNrBXV90voh/axwQS12do6J8r1kSK2BgheDlsMwRB 1aEs4KWiTsnO5a70yQyDa1sQBaQ6SDT7/GnhUFTk6blGPuxnETM0kw2Y9 JMK8+JT4cXIImpP; X-IronPort-AV: E=Sophos;i="4.87,889,1363132800"; d="scan'208";a="1170890" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 18 Jun 2013 15:26:10 +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%17]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 15:26:09 +0100 From: Ray Bellis To: Ted Lemon Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAT0wICAAAdSgIAABPKAgAAKvACAAAkMgIAAFqaAgAAQDICAAAwTAIAAGFWAgADZVACAAGFPgIAABZEAgAACDoA= Date: Tue, 18 Jun 2013 14:26:09 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBE04B@wds-exc1.okna.nominet.org.uk> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> In-Reply-To: <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> 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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:26:16 -0000 On 18 Jun 2013, at 15:18, Ted Lemon wrote: > I think by this you mean that a home network that has HIPnet routers prob= ably won't work if you try to add Homenet routers to it, right? Something like that, yes. It might work if the Homenet routers were attached as stubs "below" HIPnet = routers, but I don't think you could fully mesh and/or mix them. Ray From mellon@fugue.com Tue Jun 18 07:29:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A202E21F9F59 for ; Tue, 18 Jun 2013 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGPBsNp-Lr-j for ; Tue, 18 Jun 2013 07:29:24 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 36CCD21F9F46 for ; Tue, 18 Jun 2013 07:29:22 -0700 (PDT) Received: from [IPv6:2001:470:88a3::cdbd:4df5:1265:653d] (unknown [IPv6:2001:470:88a3:0:cdbd:4df5:1265:653d]) by toccata.fugue.com (Postfix) with ESMTPSA id 1BFB22380089; Tue, 18 Jun 2013 10:29:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBE04B@wds-exc1.okna.nominet.org.uk> Date: Tue, 18 Jun 2013 10:29:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6EB53105-E6CC-4FEE-948C-A35C65C350C4@fugue.com> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBE04B@wds-exc1.okna.nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:29:29 -0000 On Jun 18, 2013, at 10:26 AM, Ray Bellis = wrote: > It might work if the Homenet routers were attached as stubs "below" = HIPnet routers, but I don't think you could fully mesh and/or mix them. Right. I think this limitation applies to 6204bis routers as well, = though, doesn't it? From victor@jvknet.com Tue Jun 18 07:47:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A853E21F9C02 for ; Tue, 18 Jun 2013 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eNRv-dSQbT2 for ; Tue, 18 Jun 2013 07:47:07 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id B1FD121F9C20 for ; Tue, 18 Jun 2013 07:47:06 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id id13so3011150vcb.13 for ; Tue, 18 Jun 2013 07:47:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WB62pzJrq1xonPbCUN+9uEh/5R39QD117Yf0XLsGH/A=; b=EAwU4DKxy3nTClw+UvSe2mOedkoQqs4h3MdEcQajoIM4xsH1un1DJAlHTeHsT9WEYQ m1LbHD28DX2DJ4HoK8/SGQ1pfNY3kSs/0QjcoatRSHp7Io3S8y5149zLCqbsJ/Djm4BB 2BgmUvWFbkToMKmUL8o6zMtbf9d9oQ3sNNSxQxUa3b8OHiFJZgzxbOr6L2JW8NborDwh NLXl7Ti8Z1iAlNdyJ918BP2137IYHvSAhQXwPHp3KDotbwX6nxbHPDV9mlHHcCILVTVN HaQ1E0MbTNUXfyFQ834BquzooYVfp4Sp/fqpRPgzyrNn95WOSnlcjlaiD42Mjh/TtT6j 1NXA== MIME-Version: 1.0 X-Received: by 10.220.10.193 with SMTP id q1mr6342870vcq.2.1371566826004; Tue, 18 Jun 2013 07:47:06 -0700 (PDT) Received: by 10.59.3.69 with HTTP; Tue, 18 Jun 2013 07:47:05 -0700 (PDT) X-Originating-IP: [24.114.255.99] In-Reply-To: <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> Date: Tue, 18 Jun 2013 10:47:05 -0400 Message-ID: From: Victor Kuarsingh To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c3aba673637504df6ec96e X-Gm-Message-State: ALoCoQkV5kOoyCxILGo9LqHsJdRty3Xf1q7QwgrH3WKcl13sS9d6HCfSy/bQx3pws1CkINNkStuh Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:47:11 -0000 --001a11c3aba673637504df6ec96e Content-Type: text/plain; charset=ISO-8859-1 What technical constraints are present that do not allow us to move to a homenet future (currently envisioned one in the WG) world? If they are present, are those constraints any different then the ones we have moving from what we have today (6204/6204bis) to the envisioned future homenet? I don't think greenfield is a practical way to look at how future home networks will come to be, therefore some evolution is likely needed. regards, Victor K On Tue, Jun 18, 2013 at 10:18 AM, Ted Lemon wrote: > On Jun 18, 2013, at 9:58 AM, Ray Bellis wrote: > > My reading of HIPnet is that it would *not* permit a natural progression > to the full Homenet solution as currently envisaged by the WG. > > I think by this you mean that a home network that has HIPnet routers > probably won't work if you try to add Homenet routers to it, right? > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --001a11c3aba673637504df6ec96e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


What technical constraints are present that do not allow us to move= to a homenet future (currently envisioned one in the WG) world? =A0=

If they are present, are those constraints an= y different then the ones we have moving from what we have today (6204/6204= bis) to the=A0envisioned=A0future homenet?

I don't think greenfield is a=A0practical= =A0way to look at how=A0future=A0home=A0networks=A0will come to be, therefo= re some evolution is likely needed.=A0

regards,

Victor K


<= br>
On Tue, Jun 18, 2013 at 10:18 AM, Ted Lem= on <mellon@fugue.com> wrote:
On Jun 18, 2013, at 9:58 AM, Ray Bellis <= Ray.Bellis@nominet.org.uk&= gt; wrote:
> My reading of HIPnet is that it would *not* permit a natural progressi= on to the full Homenet solution as currently envisaged by the WG.

I think by this you mean that a home network that has HIPnet routers probab= ly won't work if you try to add Homenet routers to it, right?

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

--001a11c3aba673637504df6ec96e-- From mcr@sandelman.ca Tue Jun 18 08:17:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A82221F9A27 for ; Tue, 18 Jun 2013 08:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4-kiOlyc4S0 for ; Tue, 18 Jun 2013 08:17:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id AF2D221F9A24 for ; Tue, 18 Jun 2013 08:17:08 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id F36A920273; Tue, 18 Jun 2013 12:20:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3442663A88; Tue, 18 Jun 2013 11:16:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 242CD63A7C; Tue, 18 Jun 2013 11:16:07 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: <6EB53105-E6CC-4FEE-948C-A35C65C350C4@fugue.com> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBE04B@wds-exc1.okna.nominet.org.uk> <6EB53105-E6CC-4FEE-948C-A35C65C350C4@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 Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:17:21 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: tl> On Jun 18, 2013, at 10:26 AM, Ray Bellis tl> wrote: >> It might work if the Homenet routers were attached as stubs "below" >> HIPnet routers, but I don't think you could fully mesh and/or mix >> them. tl> Right. I think this limitation applies to 6204bis routers as well, tl> though, doesn't it? 6204, for sure. is there a diff for 6204bis? 1) A 6204 would work downstream of CableLabsHome ("HIPnet") machine. 2) A homenet router, attached to the same LAN("0") as 6204, and a different ISP upstream, would cooperate, but there would be egress issues for hosts on that LAN0 if they picked the wrong default router. LANn on additional homenet router below LAN0 would be fine. 3) A homenet router, below a CableLabsHome would think that that interface was an upstream (external) interface. 4) A CableLabsHome, below a homenet router would see no Internet, so it would be turned off. =20=20=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcB5tIqHRg3pndX9AQLbrAP9FkMxnozp/nn8mlYIfImldNh9KdeBZ2J+ Sra0m6IC/zjL7ojHcNY0aNy9Oe+UwzsAkfKd2D9AkXVOrtrvgSpfZdgyh0HdHNol at8l+AtzBOm+Pgmj2IDOFmd9FgjKV+jG2GuCkU9ohnPph1qDJGJ8NFAwn8DNC6gJ TS8kFg5MSMs= =Pgaz -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Tue Jun 18 08:25:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F272B21F9B7D for ; Tue, 18 Jun 2013 08:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF5pdc0OCBC4 for ; Tue, 18 Jun 2013 08:25:09 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 656C621F9C1D for ; Tue, 18 Jun 2013 08:25:00 -0700 (PDT) Received: from [IPv6:2001:470:88a3::cdbd:4df5:1265:653d] (unknown [IPv6:2001:470:88a3:0:cdbd:4df5:1265:653d]) by toccata.fugue.com (Postfix) with ESMTPSA id 640F72380089; Tue, 18 Jun 2013 11:24:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <3237.1371568567@sandelman.ca> Date: Tue, 18 Jun 2013 11:24:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <35205B27-0049-47AD-B445-9176FAC6CBE8@fugue.com> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBE04B@wds-exc1.okna.nominet.org.uk> <6EB53105-E6CC-4FEE-948C-A35C65C350C4@fugue.com> <3237.1371568567@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:25:15 -0000 On Jun 18, 2013, at 11:16 AM, Michael Richardson = wrote: > 4) A CableLabsHome, below a homenet router would see no Internet, so > it would be turned off. This would be easy to fix. It would be hard to make it work well, but = it would be easy to make it work at least as well as 6204bis. From mcr@sandelman.ca Tue Jun 18 12:08:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11F621E80A5 for ; Tue, 18 Jun 2013 12:08:54 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqoD8hzO61Fw for ; Tue, 18 Jun 2013 12:08:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 69A0821E80AE for ; Tue, 18 Jun 2013 12:08:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FB802016E for ; Tue, 18 Jun 2013 16:12:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D791563A88; Tue, 18 Jun 2013 15:07:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C5E3063732 for ; Tue, 18 Jun 2013 15:07:44 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org Group" In-Reply-To: <35205B27-0049-47AD-B445-9176FAC6CBE8@fugue.com> References: <2D41B7EB-791E-4585-8EE4-0B0556F802AC@employees.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBDE3D@wds-exc1.okna.nominet.org.uk> <3E4E16E5-045B-4AA1-8285-ACDC52383532@fugue.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDBE04B@wds-exc1.okna.nominet.org.uk> <6EB53105-E6CC-4FEE-948C-A35C65C350C4@fugue.com> <3237.1371568567@sandelman.ca> <35205B27-0049-47AD-B445-9176FAC6CBE8@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 Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:08:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: >> 4) A CableLabsHome, below a homenet router would see no Internet, so >> it would be turned off. tl> This would be easy to fix. It would be hard to make it work well, tl> but it would be easy to make it work at least as well as 6204bis. I am incorrect on two counts.=20=20 1) IPv6. It woud do a RA, and it would get an answer, but said answer would lead to a DHCPv6 server that gives it no prefixes, if homenet distributes prefixes via zOSPF (or another routing protocol).=20 To fix it, one would have to add chained DHCPv6-PD to homenet.=20=20 Having done this, there would be no loop detection, and poor multiple-ISP support. I don't see the value in the half-step. 2) IPv4+NATwork would work "fine". (I mean, it would fail for all the reaso= ns that it fails today, including cables plugged in wrong, and printers being on the wrong side of the "switch", etc..) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcCv/YqHRg3pndX9AQIG7AP/fSYD+EqjxLVhs4KZF5pH4TRBnERXimXb z2ADQu4Jr3zdMWzaQCa5zdb4CSkAPHzqMEU5RTj0ojYT0Vt8KiMXXdNsC/IAQxbm mhiAm34uAGBlQizznYFr/GerDkbrGjOXhBZajPZeKJ4WZB8lGlt+Pc/F6+qNiU93 b3Pcv5N90bg= =O7QK -----END PGP SIGNATURE----- --=-=-=-- From jch@pps.univ-paris-diderot.fr Tue Jun 18 12:54:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A5721F9A1D for ; Tue, 18 Jun 2013 12:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtktoHacbZ1m for ; Tue, 18 Jun 2013 12:54:41 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE6521F9A19 for ; Tue, 18 Jun 2013 12:54: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/38117) with ESMTP id r5IJrvwY024113; Tue, 18 Jun 2013 21:53:57 +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 322744E98D; Tue, 18 Jun 2013 21:53:57 +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 pBP0Uiq7vAHA; Tue, 18 Jun 2013 21:53:56 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1639F4E987; Tue, 18 Jun 2013 21:53:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Up1yV-00010r-PR; Tue, 18 Jun 2013 21:53:55 +0200 Date: Tue, 18 Jun 2013 21:53:55 +0200 Message-ID: <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "homenet@ietf.org Group" In-Reply-To: <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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]); Tue, 18 Jun 2013 21:53:59 +0200 (CEST) Cc: Ray Bellis , Ole Troan , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:54:47 -0000 > Ole, Acee, I'm not arguing about whether there are good reasons to > promote link-state protocols for Homenet, which there might very well > be. I'm just saying that the current formulation is technically > incorrect, and that it should, er, SHOULD be fixed before publication. It looks like this discussion has stalled. Dear editor -- have we agreed that the second paragraph of Section 3.5 is going to be removed? -- Juliusz From otroan@employees.org Tue Jun 18 13:54:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3894E21E8096 for ; Tue, 18 Jun 2013 13:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpjK3Qy7U8zf for ; Tue, 18 Jun 2013 13:54:24 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54621F963F for ; Tue, 18 Jun 2013 13:54:24 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 16DCB5EE9; Tue, 18 Jun 2013 13:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=dJH030eauQSsfgxJ436u55zdiMg=; b=P5fyXYTKUIPPhlwOB8 0cyT0FVfrdgqQ/YKxTi37j+vT+fYiAWhSJ5cxfvn9blheUqFXlzFMXRMeKpR44A1 u7ot5fIIUMPGaa4kqbwHkvWzwkKv4czxscD7BIbJACYIqztAnGdkuyD8QyUKQdyf +QTEJZ3pyajE15uEdAHR6FGEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=prTz6SDvJ+8AoJFGFNVWdK9JPstFWoEPVxE6q1c+2XF9qEfFe9y XzBxSxe4yhcOg+YaruSOSMiboTzg9i6VQB9MwYpa+h1ULCgf6chI52Yf8beDs9eT Pj83TJ6FUEJ/HRBYTE2tn58G+TmrfxxZzsCbvMkWY4tCYuuncQBfMZnY= Received: from dhcp-10-61-100-139.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 784E05ED6; Tue, 18 Jun 2013 13:54:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 18 Jun 2013 22:54:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:54:29 -0000 Juliusz, >> Ole, Acee, I'm not arguing about whether there are good reasons to >> promote link-state protocols for Homenet, which there might very well >> be. I'm just saying that the current formulation is technically >> incorrect, and that it should, er, SHOULD be fixed before = publication. >=20 > It looks like this discussion has stalled. >=20 > Dear editor -- have we agreed that the second paragraph of Section 3.5 > is going to be removed? I agree with your statement on "consistent view of the network". I would like to keep the second paragraph, what if we did = s/consistent/complete/? and removed "which implies a link state is preferable."? second paragraph section 3.5 routing functionality: "The homenet unicast routing protocol should preferably be an = existing deployed protocol that has been shown to be reliable and robust, and it is preferable that the protocol is both 'lightweight' and that open source implementations are readily available. It is desirable that the routing protocol has knowledge of the homenet topology. This would mean the routing protocol gives a complete view of the = network, and that it can pass around more than just routing information." the one example I was thinking of that requires a complete topology view was the case where there is a single DHCP server assigning prefixes to=20= the links in the network. two routers on a link, both asking for a = prefix, the DHCP server knowing the topology could then assign a single prefix to = the link. cheers, Ole From dave.taht@gmail.com Tue Jun 18 14:20:02 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E784811E8106 for ; Tue, 18 Jun 2013 14:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OphAErapwJfu for ; Tue, 18 Jun 2013 14:19:59 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id F40EB11E80F9 for ; Tue, 18 Jun 2013 14:19:58 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so10583419ief.26 for ; Tue, 18 Jun 2013 14:19:54 -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=6j986GCnFN8NeP+Ht20ok9bgav2zLw1mLHOEUqRHnN8=; b=zbKiFn8mTscjwDz+XVEW/NVLHrEmF4oAhoTQZi2kdNJNuUWDSwonepSwhnYJeVXHVx YNH7djSGkhM5dRAwO9iJZ+gwH3yqb6EdvkWpCRvI05mLIJoJYD3WvvzQnQq1I/hwqcOx +MNEZT+5F/NuWGSlGvxP7AWMVQsmoPNaxOb8e59EpH1aXIudC7icjs01tWX7rH0uaAEQ rY0xB3GFnBnuaRsV6BUPppek5C6hAWkGuSNTjTzkQEaC4h/IPoNBOoiuCsPohk064uLn z5RqVaLSg6OYpjaeldpTwk0IIF4M3NrOq8AhTtraTyPqRJBkz3M1cb4UhP1nE9PNdEOg UB0g== MIME-Version: 1.0 X-Received: by 10.50.56.50 with SMTP id x18mr8829880igp.87.1371590394892; Tue, 18 Jun 2013 14:19:54 -0700 (PDT) Received: by 10.64.45.137 with HTTP; Tue, 18 Jun 2013 14:19:54 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 18 Jun 2013 14:19:54 -0700 Message-ID: From: Dave Taht To: Ole Troan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ray Bellis , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk, Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:20:02 -0000 On Tue, Jun 18, 2013 at 1:54 PM, Ole Troan wrote: > Juliusz, > >>> Ole, Acee, I'm not arguing about whether there are good reasons to >>> promote link-state protocols for Homenet, which there might very well >>> be. I'm just saying that the current formulation is technically >>> incorrect, and that it should, er, SHOULD be fixed before publication. >> >> It looks like this discussion has stalled. >> >> Dear editor -- have we agreed that the second paragraph of Section 3.5 >> is going to be removed? > > I agree with your statement on "consistent view of the network". > I would like to keep the second paragraph, what if we did s/consistent/co= mplete/? > and removed "which implies a link state is preferable."? > > second paragraph section 3.5 routing functionality: > > "The homenet unicast routing protocol should preferably be an existing I assume that by unicast you mean that a separate multicast routing protocol can co-exist, not that the routing protocol communicates via unicast. Perhaps it would be good to address the multicast routing protocol issue somewhere? > deployed protocol that has been shown to be reliable and robust, and Sure. My biggest bugaboo about mandating a protocol has always been is that I'm not aware of any that meet that requirement in wireless networks, which I expect to dominate in the home. I would certainly love to see people working on it... > it is preferable is mandatory. is rfc-ese dying out? MUST > that the protocol is both 'lightweight' and that > open source implementations are readily available. It is desirable that the size of the daemon and the data are also lightweight so as to be suitable for use on small embedded devices. I perversely enjoyed watching the early attempts at big daemons for dhcpv6 go by... > It is desirable > that the routing protocol has knowledge of the homenet topology. To me that's sort of a given. "the routing protocol MUST have knowledge" > This would mean the routing protocol gives a complete view of the netw= ork, If you are still trying to back in linkstate into the requirement, it's simpler to say so. > and that it can pass around more than just routing information." embedding new TLVs and behaviors are possible with any protocol. > > the one example I was thinking of that requires a complete topology view > was the case where there is a single DHCP server assigning prefixes to > the links in the network. two routers on a link, both asking for a prefix= , the > DHCP server knowing the topology could then assign a single prefix to the= link. > > cheers, > Ole > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From jch@pps.univ-paris-diderot.fr Tue Jun 18 14:48:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A5621E80CA for ; Tue, 18 Jun 2013 14:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa8q7VFn2+Ef for ; Tue, 18 Jun 2013 14:48:03 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34C21F9A2C for ; Tue, 18 Jun 2013 14:47:25 -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/38117) with ESMTP id r5ILkj9E015863; Tue, 18 Jun 2013 23:46:45 +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 352254E996; Tue, 18 Jun 2013 23:46:45 +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 kOA_YjdfReL7; Tue, 18 Jun 2013 23:46:43 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9A1094E993; Tue, 18 Jun 2013 23:46:43 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Up3jf-00013v-2F; Tue, 18 Jun 2013 23:46:43 +0200 Date: Tue, 18 Jun 2013 23:46:43 +0200 Message-ID: <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ole Troan In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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]); Tue, 18 Jun 2013 23:46:45 +0200 (CEST) Cc: Ray Bellis , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:48:08 -0000 > I would like to keep the second paragraph, what if we did > s/consistent/complete/? and removed "which implies a link state is > preferable."? I have absolutely no problem with requiring a link-state protocol. I realise that OSPF and RIP are the only widely deployed protocols that are open, implemented by multiple vendors and shown to be robust; given the bad press that RIP has received, I think we can take it as a given that OSPF will be chosen for Homenet, whether some of us like it or not. What I do want to avoid is unwarranted, overly-general statements that disparage distance-vector protocols. So please feel free to promote OSPF, there's just no need to slander the competition. > second paragraph section 3.5 routing functionality: > > "The homenet unicast routing protocol should preferably be an existing > deployed protocol that has been shown to be reliable and robust, and > it is preferable that the protocol is both 'lightweight' and that > open source implementations are readily available. It is desirable > that the routing protocol has knowledge of the homenet topology. > This would mean the routing protocol gives a complete view of the network, > and that it can pass around more than just routing information." Yeah, that's fine with me. I'm not a native speaker, but here's my best attempt: The homenet unicast routing protocol should be a previously deployed protocol that has been shown to be reliable, robust, to allow lightweight implementations, and of which open source implementations are available. It is desirable, but not absolutely required, that the routing protocol be able to give a complete view of the network, and that it be able to pass around more than just routing information. You already know my opinions about hijacking a routing protocol for passing around non-routing information -- I believe that this is better achieved by a separate flooding protocol, as I've tried to show with AHCP[1] -- which is why I'd appreciate it if you kept the "not absolutely required" formulation. > the one example I was thinking of that requires a complete topology > view was the case where there is a single DHCP server assigning > prefixes to the links in the network. two routers on a link, both > asking for a prefix, the DHCP server knowing the topology could then > assign a single prefix to the link. There are other reasons as well. I urge you not to understate the marketing value of a web interface that displays the network topology to the user. We've done quite a bit of work in distance vector protocols to do that[2], but there's absolutely no doubt that that's something that's easier to achieve with a link-state protocol. -- Juliusz [1] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ [2] http://babelweb.pps.univ-paris-diderot.fr From jch@pps.univ-paris-diderot.fr Tue Jun 18 14:51:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5965E21E80AE for ; Tue, 18 Jun 2013 14:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk58rHeNa3uS for ; Tue, 18 Jun 2013 14:51:21 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id D212A21E8092 for ; Tue, 18 Jun 2013 14:51:20 -0700 (PDT) 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/38117) with ESMTP id r5ILofwR026897; Tue, 18 Jun 2013 23:50:41 +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 427D64E99A; Tue, 18 Jun 2013 23:50:41 +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 BU3WrTVoN1JN; Tue, 18 Jun 2013 23:50:39 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B68F14E998; Tue, 18 Jun 2013 23:50:39 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Up3nT-00014Z-Ar; Tue, 18 Jun 2013 23:50:39 +0200 Date: Tue, 18 Jun 2013 23:50:39 +0200 Message-ID: <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Juliusz Chroboczek In-Reply-To: <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 18 Jun 2013 23:50:41 +0200 (CEST) Cc: Ray Bellis , Ole Troan , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:51:26 -0000 > [2] http://babelweb.pps.univ-paris-diderot.fr Sorry, that's http://babelweb.wifi.pps.univ-paris-diderot.fr --jch From otroan@employees.org Tue Jun 18 15:19:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636A921E80D9 for ; Tue, 18 Jun 2013 15:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, DIET_1=0.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEOQy5MOSbNR for ; Tue, 18 Jun 2013 15:19:52 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9574721E80C8 for ; Tue, 18 Jun 2013 15:19:52 -0700 (PDT) Received: from dhcp-10-61-100-107.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id B5D185F27 for ; Tue, 18 Jun 2013 15:19:51 -0700 (PDT) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 19 Jun 2013 00:19:48 +0200 To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:19:58 -0000 I've battled through the whole document again. I'm quite happy to see = this document proceed as is. some nits and comments below. note I'm also a co-author although I = haven't held the pen for a while. cheers, Ole ----- this document could benefit from some weight loss throughout. the text = is riddled with excess, just in the abstract alone you can cut: increasingly, general, associated, briefly, suggests, can = be employed (are used),=20 s/pro-active management/active management s/CER/CE router/? how many names do we need for a CPE, Home Gateway, Residential Gateway, = CE, CE Router, pick one of the existing ones section 2.2 on global addressablity - include a paragraph stating that = the network is exposed to ISP renumbering the network to a much larger degree than before. NAT isolated the user against ISP = renumbering to some extent. section 2.4 ULA paragraph on security by restricting reachability. ULAs can be used by = default for devices that without configuration only should offer services to the internal network. e.g. a printer could = only accept incoming connections on a ULA, until configured to be globally reachable. section 3.3.2 largest possible subnets. this seems to say, if something can be bridged together do so. is that = what we want to recommend? I don't know enough about bridging wired to wireless, versus routing = wired to wireless, but someone seemed to indicate that there were problems with bridging interfaces of = greatly differing speeds. anyone who can provide insight? remove this paragraph from section 3.4.1 There are reports that some CER equipment does not support receipt of a prefix bigger than /64, but the homenet architecture is designed for future IPv6 home networks, and we assume that such restricted equipment will become rarer over time. the sentence: "It is expected that ISPs will deliver a relatively stable = prefix" is repeated at least twice if not three times section 3.4.1 with regards to flash renumbering. it might be noted that = while the network can support flash renumbering, it will have adverse = effects on applications. section 3.4.3 s/internal prefix delegation/internal prefix assignment/ = alternatively prefix configuration "However, where ULAs are used, most likely but not necessarily in = parallel with global prefixes," remove "but not necessarily" section 3.4.3 remove references to possible solution drafts section 3.4.4 shouldn't it say something more about distribution of = other configuration information?=20 From mbaugher@cisco.com Tue Jun 18 15:31:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BAC11E8109 for ; Tue, 18 Jun 2013 15:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD6PRO1DE1Z5 for ; Tue, 18 Jun 2013 15:31:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 39F9A21F99BD for ; Tue, 18 Jun 2013 15:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=434; q=dns/txt; s=iport; t=1371594666; x=1372804266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=g6YFgc0Mh9sTZCTGqXSCg1FGi6mv22hvow6F7Hp7mYY=; b=DH1Okx1DBjW4YT/QiV4LmQ6PDWUSgbuROhlf03E10YXjwpsx+DA0Oxzl Erhh0f30BwOTjZilrMrBMwQsL/xnqJyKr562JeiYbAAuQ3wkltSBBkxsj urW0gWnEIJaWfe0FYkfRE/MQqeXZeSRWaR7837JXzDAqSPUWLvwFaqEh4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAD/fwFGtJXG8/2dsb2JhbABagwl6gjq8V4EEFnSCIwEBAQMBHVwQAgEIIiQhESUCBA4FCId0AwkGsiYNiFKMV4IxAjEHgwBhA4hojHKOBoUkgw+CKA X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224470691" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jun 2013 22:31:05 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5IMV5rF016394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 22:31:05 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 17:31:05 -0500 From: "Mark Baugher (mbaugher)" To: Dave Taht Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk5v7CAgAB0toCAAAbSgIAAASeAgAACkQCAAg9EgIAAENoAgAAHLACAABPiAA== Date: Tue, 18 Jun 2013 22:31:05 +0000 Message-ID: <9C2FF8548CD17F4AB32FC8B311470DFA1528149E@xmb-aln-x10.cisco.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.24.22] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <70B805D5A5AF224880A05B783918A0B7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Bellis , Ole Troan , Juliusz Chroboczek , "homenet@ietf.org Group" , "" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:31:11 -0000 On Jun 18, 2013, at 2:19 PM, Dave Taht wrote: >=20 > Perhaps it would be good to address the multicast routing protocol > issue somewhere? >=20 >=20 It's addressed in 3.5.1. Is there a non-flooding, self-configuring routing= protocol? I expect if there were an appropriate one, the authors would na= me it. Maybe flooding is not so bad for low-rate flows like service discov= ery. Mark= From tjc@ecs.soton.ac.uk Tue Jun 18 15:57:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8680521E809A for ; Tue, 18 Jun 2013 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d65PyLlNSwUM for ; Tue, 18 Jun 2013 15:57:35 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id ADFFE21E8094 for ; Tue, 18 Jun 2013 15:57:33 -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 r5IMvRXF014117 for ; Tue, 18 Jun 2013 23:57:27 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5IMvRXF014117 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1371596247; bh=Lt5OzgvAA7jAAVzxwmOMM5Cxm+M=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=57Tf8C8ECIcECK4rdu47PYvq9kUZieGOazR+QKMmofLv/FR7Hnj7OMZLR/D4bsA1/ 7+WwkIlRNZlIEudsyDl2OM/lZtssKJ0DY5GTOuaucnDCTkOEpQwOvtxB1CaVO6zSBR 2cNZAIIu+71d3ayc6zRZz5e5Ef1lDnMslwFFUAEk= 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 p5HNvR0430652694Uy ret-id none; Tue, 18 Jun 2013 23:57:27 +0100 Received: from [192.168.1.110] (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 r5IMv8PA009606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jun 2013 23:57:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 18 Jun 2013 23:57:11 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> <3307C836-FBDE-4EE9-BEA4-94726BF94BC0@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5HNvR043065269400; tid=p5HNvR0430652694Uy; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r5IMvRXF014117 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:57:49 -0000 Hi, Just a note to say that as the main editor I had a 30 min chat with the = WG co-chairs Ray and Mark today in which we discussed the WGLC feedback. = The chairs will be posting an update soon. Below are some responses in = the meantime. I hope these are in line with the WG chair views; if not, = I'm sure Ray or Mark will correct/clarify. Firstly, the -08 version was produced after reading some 500-600 emails = over many threads, either side of the Orlando IETF meeting. It was = impractical to respond to every point by email. No views were ignored, = rather I attempted to draw consensus from the views posted, without = being swayed by the volume of comments from some posters. It seems that = more recent comments agree that -08 is improved as a result. The architecture text describes general principles and requirements, but = not in 2119 language. As a document, it should thus be viewed as a guide = as to where homenet is heading, based on the consensus of the WG. It is = not intended to provide every specific detail in this text; further = documents will do that, e.g. for homenet naming and service discovery, = where I certainly agree that more detailed work is needed, some of which = will hopefully be linked to the BoF on that topic in Berlin. Thus, for = example, while forming the largest possible subnets has been agreed as = desirable, the text does not prescribe how that should be achieved. = Similarly the document does not intend to imply that mDNS is a given (it = is cited as an example of a zeroconf solution), or, given it's come up = in this thread, a link-state routing protocol. Perhaps the most contentious issue is the use of ULAs; may, should or = must? It seems there's consensus that the text should be at least a = "should". There is a parallel ula-usage draft that Sheng Jiang is = working on with others. This also brings up the point on whether we are = designing with today's system constraints in mind, e.g. where older = systems are less likely to do appropriate address selection when = deployed in a homenet that only has external IPv4 connectivity, but has = ULAs turned on internally. In general, I don't feel we should constrain = the design, but we do state that there is a preference for = established/proven protocols, and running (open source) code, and that = changes to hosts and routers should be minimised.=20 Regarding hipnet, it seems there needs to be a transition/coexistence = path between what we have today, hipnet, and the final homenet-arch = solution. I believe hipnet is largely homenet-arch compliant, though = there are some areas where it is not, e.g. efficient use of prefixes, = and support for multihoming. On personal drafts that have expired, or that there has been minimal = list discussion on, the plan is to continue to remove the "dangling" = references, but to ensure the spirit of the drafts is captured where = appropriate to do so. And some specific comments/proposals towards -09: - the ULQDN concept will be retained - a sentence will be added regarding supporting mobile devices within = the home - the firewall text appears appropriate, though some could be pruned = without changing the tone/balance - the routing text can make it clear that link-state is not the only = solution, or not refer to link-state at all. We have some text from Ole. = The word "consistent" should be "complete", a typo - a sentence will be added to clarify that multicast can be sourced = to/from the home, not just within it. - no text will be added about extension headers (too fine a detail) Tim From tjc@ecs.soton.ac.uk Tue Jun 18 16:14:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3DA21E8094 for ; Tue, 18 Jun 2013 16:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, DIET_1=0.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llAcEmcsIAwA for ; Tue, 18 Jun 2013 16:14:13 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D5D0111E8110 for ; Tue, 18 Jun 2013 16:14:12 -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 r5INE98u017323 for ; Wed, 19 Jun 2013 00:14:09 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5INE98u017323 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1371597249; bh=aPgFVI0x3hUUux4oX5BrzoG4K0E=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=R3E4jOieT7EtJAKtrm0mKCO56p1qjxsTkXbKyvncVdYlZrHfmVXIMUiD2bXuPrR/K WIp3DeezhRfHDTgYttqKh3/Qg0dZXxWIvobefQRp6epPrwOVtMdbBUN0bXElQ1t+14 YA9UdL7F6Al7m/AM3TRnyTbfPWRqHVknEUj8g/3w= 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 p5I0E90430652770jI ret-id none; Wed, 19 Jun 2013 00:14:09 +0100 Received: from [192.168.1.110] (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 r5INCoaD012518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Jun 2013 00:12:51 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: Date: Wed, 19 Jun 2013 00:12:53 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <840A8B85-8C60-4C51-A4A7-606B5FEE9BFC@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5I0E9043065277000; tid=p5I0E90430652770jI; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r5INE98u017323 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:14:14 -0000 On 18 Jun 2013, at 23:19, Ole Troan wrote: > I've battled through the whole document again. I'm quite happy to see = this document proceed as is. > some nits and comments below. note I'm also a co-author although I = haven't held the pen for a while. You are always welcome to pick it up again; you have the xml :) We = should agree the full list of changes first though. > this document could benefit from some weight loss throughout. the text = is riddled with excess, just in the abstract alone > you can cut: increasingly, general, associated, briefly, suggests, can = be employed (are used),=20 Probably, yes. Mark and Ray are concerned that any -08 to -09 changes = should be no more than needed, so that the tools diff view isn't bigger = than it needs to be. Let's see what they say about that. > s/pro-active management/active management >=20 > s/CER/CE router/? > how many names do we need for a CPE, Home Gateway, Residential = Gateway, CE, CE Router, pick one of the existing ones So now you want the text longer :) I really don't mind, again, let's = see what the chairs want. > section 2.2 on global addressablity - include a paragraph stating that = the network is exposed to ISP renumbering the network > to a much larger degree than before. NAT isolated the user against ISP = renumbering to some extent. True, but that is also the point of using ULAs. We can make it more = explicit though. > section 2.4 ULA > paragraph on security by restricting reachability. ULAs can be used by = default for devices that without configuration > only should offer services to the internal network. e.g. a printer = could only accept incoming connections on a ULA, > until configured to be globally reachable. Yes, I think the text talks about the user being able to toggle this. = Though I don't off-hand recall specifically where. > section 3.3.2 largest possible subnets. > this seems to say, if something can be bridged together do so. is that = what we want to recommend? > I don't know enough about bridging wired to wireless, versus routing = wired to wireless, but someone > seemed to indicate that there were problems with bridging interfaces = of greatly differing speeds. > anyone who can provide insight? My interprettaion is that it means "largest possible subnets within the = constraints of the media"; one reason we cite for multiple subnets is = the variety of media deployed in a homenet; most likely at least = Ethernet, WLAN and LLN. > remove this paragraph from section 3.4.1 > There are reports that some CER equipment does not support receipt = of > a prefix bigger than /64, but the homenet architecture is designed > for future IPv6 home networks, and we assume that such restricted > equipment will become rarer over time. OK. > the sentence: "It is expected that ISPs will deliver a relatively = stable prefix" is repeated at least twice if not three times >=20 > section 3.4.1 with regards to flash renumbering. it might be noted = that while the network can support flash renumbering, it will have = adverse effects on applications. Indeed, though ULAs should protect internal applications, provided ULA = prefixes are stable within the homenet. > section 3.4.3 s/internal prefix delegation/internal prefix assignment/ = alternatively prefix configuration >=20 > "However, where ULAs are used, most likely but not necessarily in = parallel with global prefixes," > remove "but not necessarily" OK. > section 3.4.3 remove references to possible solution drafts Ray/Mark agreed to do this more widely in the text. > section 3.4.4 shouldn't it say something more about distribution of = other configuration information?=20 It could do; this was a tpic Jari raised previously. Tim >=20 >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Tue Jun 18 22:44:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279EF21F9E90 for ; Tue, 18 Jun 2013 22:44:06 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozFWbNz7L5HS for ; Tue, 18 Jun 2013 22:44:05 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A443B21F9E88 for ; Tue, 18 Jun 2013 22:44:03 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so4161234wes.3 for ; Tue, 18 Jun 2013 22:44:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CEIy6UEGvh6JpjVxi61uETx6JP9THkWr2ruGcz5evB0=; b=H2f2s7wBkRrLHc0vRhssz/E2oyr3qCSrbGnlClv2RfkM0215T5SrSeRROhkI1ghEc3 bEqZc24pGTJU5/MHATlvhC7FDKXJ2hvNTSYV+spuZaXnB7W7QWaikgVI3MWq8jvR/Boj T7fpQid9ycZbENfbx78d+h5yEtRO4iUtr+5ry7WAMYHsQYQSGwy8Hz8fqVPDnVuP0Cc8 g9U2J74cxQnzMV1gOjpUxk3tAfv0Jgd+Xc11qyL4m19NUdQ0vpNOBfL+QBVdWS1WMj52 vvpKN+gZs2e+KzLxwbq05xMEpmyp0+Zh8ZtdeE0NEug1K73LzCRJ1LTCXIgKeHOZQGay YIRg== X-Received: by 10.194.242.136 with SMTP id wq8mr831119wjc.60.1371620642803; Tue, 18 Jun 2013 22:44:02 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id fv11sm6576895wic.11.2013.06.18.22.44.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 22:44:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> Date: Wed, 19 Jun 2013 07:43:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6EDB1A66-7B46-4B40-AD41-DF81C6B58C85@inf-net.nl> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnTTLWjZjq0XHINuk7Cq9zmx24DsiJkEVh4NQ/sPR/QHtZFG9kBn2F+3aUSXDMQM+GycpG8 Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 05:44:06 -0000 My opinion: It is a nice feature of a routing protocol if such can provide a = transport for other purposes. But let's think twice (or more) before = using. It creates unnecessary dependencies. While homenet would come up = with a single zero-config routing protocol, autoconfig is needed = everywhere. I see two options: come up with signaling that can be = transported over foo or come up with own transport. Something in the = middle: transport over something that is always there (e.g. NDP RA). RA = has the advantage that hosts can easily benefit (SAS). Teco Op 18 jun. 2013, om 23:46 heeft Juliusz Chroboczek = het volgende geschreven: >> I would like to keep the second paragraph, what if we did >> s/consistent/complete/? and removed "which implies a link state is >> preferable."? >=20 > I have absolutely no problem with requiring a link-state protocol. > I realise that OSPF and RIP are the only widely deployed protocols > that are open, implemented by multiple vendors and shown to be robust; > given the bad press that RIP has received, I think we can take it as > a given that OSPF will be chosen for Homenet, whether some of us like > it or not. >=20 > What I do want to avoid is unwarranted, overly-general statements that > disparage distance-vector protocols. So please feel free to promote > OSPF, there's just no need to slander the competition. >=20 >> second paragraph section 3.5 routing functionality: >>=20 >> "The homenet unicast routing protocol should preferably be an = existing >> deployed protocol that has been shown to be reliable and robust, = and >> it is preferable that the protocol is both 'lightweight' and that >> open source implementations are readily available. It is desirable >> that the routing protocol has knowledge of the homenet topology. >> This would mean the routing protocol gives a complete view of the = network, >> and that it can pass around more than just routing information." >=20 > Yeah, that's fine with me. I'm not a native speaker, but here's my > best attempt: >=20 > The homenet unicast routing protocol should be a previously = deployed > protocol that has been shown to be reliable, robust, to allow > lightweight implementations, and of which open source > implementations are available. It is desirable, but not absolutely > required, that the routing protocol be able to give a complete view > of the network, and that it be able to pass around more than just > routing information. >=20 > You already know my opinions about hijacking a routing protocol for > passing around non-routing information -- I believe that this is > better achieved by a separate flooding protocol, as I've tried to show > with AHCP[1] -- which is why I'd appreciate it if you kept the "not > absolutely required" formulation. >=20 >> the one example I was thinking of that requires a complete topology >> view was the case where there is a single DHCP server assigning >> prefixes to the links in the network. two routers on a link, both >> asking for a prefix, the DHCP server knowing the topology could then >> assign a single prefix to the link. >=20 > There are other reasons as well. I urge you not to understate the > marketing value of a web interface that displays the network topology > to the user. We've done quite a bit of work in distance vector > protocols to do that[2], but there's absolutely no doubt that that's > something that's easier to achieve with a link-state protocol. >=20 > -- Juliusz >=20 > [1] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ > [2] http://babelweb.pps.univ-paris-diderot.fr > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From v6ops@globis.net Tue Jun 18 23:37:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8F021F9F4C for ; Tue, 18 Jun 2013 23:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, DIET_1=0.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezpM-LJ1mIgK for ; Tue, 18 Jun 2013 23:37:58 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 714E821F9A1F for ; Tue, 18 Jun 2013 23:37:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 058658700EA; Wed, 19 Jun 2013 08:37:34 +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 YO50VW1IG3QE; Wed, 19 Jun 2013 08:37:33 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id DCF3B8700E7; Wed, 19 Jun 2013 08:37:33 +0200 (CEST) Message-ID: <51C151A7.2070304@globis.net> Date: Wed, 19 Jun 2013 08:37:27 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Ole Troan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 06:38:00 -0000 Ole Troan wrote: > I've battled through the whole document again. I'm quite happy to see this document proceed as is. > some nits and comments below. note I'm also a co-author although I haven't held the pen for a while. > > cheers, > Ole > > ----- > > > this document could benefit from some weight loss throughout. the text is riddled with excess, just in the abstract alone > you can cut: increasingly, general, associated, briefly, suggests, can be employed (are used), > > s/pro-active management/active management > > s/CER/CE router/? > how many names do we need for a CPE, Home Gateway, Residential Gateway, CE, CE Router, pick one of the existing ones > > section 2.2 on global addressablity - include a paragraph stating that the network is exposed to ISP renumbering the network > to a much larger degree than before. NAT isolated the user against ISP renumbering to some extent. > > section 2.4 ULA > paragraph on security by restricting reachability. ULAs can be used by default for devices that without configuration > only should offer services to the internal network. e.g. a printer could only accept incoming connections on a ULA, > until configured to be globally reachable. This is a good example of why I am concerned about ULA. ULA may be preferred over GUA [assuming we either take action on 6724 to inject additional /48's into the policy table or older nodes are present that still run 3484 or something else.] Although ULA prefixes are recommended to be filtered at the site boundary (Section 4.3 RFC4193) they also may be used for inter-site VPN's (section 4.7 RFC4193). Making additional/ unnecessary assumptions about reachability and security is IMHO yet another .local / RFC1918 problem waiting to strike. If you want security, the device providing the security needs to understand the topology e.g. where the site border is in relation to the endpoints of the connection request. Merely relying on addressing schemes is insufficient IMHO. > > section 3.3.2 largest possible subnets. > this seems to say, if something can be bridged together do so. is that what we want to recommend? > I don't know enough about bridging wired to wireless, versus routing wired to wireless, but someone > seemed to indicate that there were problems with bridging interfaces of greatly differing speeds. > anyone who can provide insight? > > remove this paragraph from section 3.4.1 > There are reports that some CER equipment does not support receipt of > a prefix bigger than /64, but the homenet architecture is designed > for future IPv6 home networks, and we assume that such restricted > equipment will become rarer over time. > > the sentence: "It is expected that ISPs will deliver a relatively stable prefix" is repeated at least twice if not three times > > section 3.4.1 with regards to flash renumbering. it might be noted that while the network can support flash renumbering, it will have adverse effects on applications. > > section 3.4.3 s/internal prefix delegation/internal prefix assignment/ alternatively prefix configuration > > "However, where ULAs are used, most likely but not necessarily in parallel with global prefixes," > remove "but not necessarily" > > section 3.4.3 remove references to possible solution drafts > > section 3.4.4 shouldn't it say something more about distribution of other configuration information? > > > > > From cyrus@openwrt.org Wed Jun 19 00:20:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9821F9F79 for ; Wed, 19 Jun 2013 00:20:26 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hr1sMQafaWJ for ; Wed, 19 Jun 2013 00:20:25 -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 8A07B21F9F6D for ; Wed, 19 Jun 2013 00:20:24 -0700 (PDT) Received: from [192.168.178.21] (unknown [212.255.39.215]) by chi.subsignal.org (Postfix) with ESMTPSA id 6DF441261C6; Wed, 19 Jun 2013 09:21:11 +0200 (CEST) Message-ID: <51C16A12.3030205@openwrt.org> Date: Wed, 19 Jun 2013 10:21:38 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Dave Taht References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Bellis , Ole Troan , Juliusz Chroboczek , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:20:26 -0000 On 18.06.2013 23:19, Dave Taht wrote: >> that the protocol is both 'lightweight' and that >> open source implementations are readily available. > > It is desirable that the size of the daemon and the data are also > lightweight so as to be suitable for use on small embedded devices. > > I perversely enjoyed watching the early attempts at big daemons for > dhcpv6 go by... I'd like to +1 this one. I don't really like hipnet as a whole because I think its overengineered at various points, however the general idea of using chained DHCPv6-PD kind of makes it self contained and I think it would be much easier to get deployed in the wild despite some of the architectural problems that have to be solved adequately first (say border and loop-detection). What I mean is, I don't see any bigger routing daemons and stacks getting integrated into the majority of home routers because simply of a lack of incentives. A DHCPv6-server is most likely there anyway so I guess adding the little bit of PD-support + maintaing it could be justified. However a whole separate OSPF or so daemon + routing stack with 100s of KB and all the inherent logic just for a few very advanced usecases? I doubt it. I mean we are still talking about home networks and home routers aren't we? Cheers, Steven From otroan@employees.org Wed Jun 19 00:50:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1121F9F50 for ; Wed, 19 Jun 2013 00:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGd00TGApREx for ; Wed, 19 Jun 2013 00:50:00 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3B52221F9F85 for ; Wed, 19 Jun 2013 00:50:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAERiwVGQ/khR/2dsb2JhbABagwnAE34WdIIjAQEEATo4BxALDjhXBogbBrsGjgSBBDMHgwBhA6kEgxE6gS0 X-IronPort-AV: E=Sophos;i="4.87,895,1363132800"; d="scan'208";a="83471911" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 19 Jun 2013 07:49:58 +0000 Received: from dhcp-10-61-100-174.cisco.com (dhcp-10-61-100-174.cisco.com [10.61.100.174]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5J7ntY7002260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 07:49:56 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51C151A7.2070304@globis.net> Date: Wed, 19 Jun 2013 09:49:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56680D6A-BE79-43D2-9389-5B0776625B48@employees.org> References: <51C151A7.2070304@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:50:06 -0000 Ray, >> section 2.4 ULA >> paragraph on security by restricting reachability. ULAs can be used = by default for devices that without configuration >> only should offer services to the internal network. e.g. a printer = could only accept incoming connections on a ULA, >> until configured to be globally reachable. >=20 > This is a good example of why I am concerned about ULA. >=20 > ULA may be preferred over GUA [assuming we either take action on 6724 = to > inject additional /48's into the policy table or older nodes are = present > that still run 3484 or something else.] >=20 > Although ULA prefixes are recommended to be filtered at the site > boundary (Section 4.3 RFC4193) > they also may be used for inter-site VPN's (section 4.7 RFC4193). >=20 > Making additional/ unnecessary assumptions about reachability and > security is IMHO yet another .local / RFC1918 problem waiting to = strike. >=20 > If you want security, the device providing the security needs to > understand the topology e.g. where the site border is in relation to = the > endpoints of the connection request. Merely relying on addressing > schemes is insufficient IMHO. I certainly didn't intend to equal the use of ULAs with security. but there is no doubt that the use of ULAs limit the attack surface = compared to global addresses. cheers, Ole= From swmike@swm.pp.se Wed Jun 19 00:58:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5567321F9EA7 for ; Wed, 19 Jun 2013 00:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2AeZGHxT2Lu for ; Wed, 19 Jun 2013 00:58:25 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2BD21F9DEC for ; Wed, 19 Jun 2013 00:58:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CB4559C; Wed, 19 Jun 2013 09:58:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C59D69A for ; Wed, 19 Jun 2013 09:58:09 +0200 (CEST) Date: Wed, 19 Jun 2013 09:58:09 +0200 (CEST) From: Mikael Abrahamsson To: "homenet@ietf.org Group" In-Reply-To: <51C16A12.3030205@openwrt.org> Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:58:26 -0000 On Wed, 19 Jun 2013, Steven Barth wrote: > I mean we are still talking about home networks and home routers aren't > we? I already know people with a lot of temperature sensors, power sensors etc in their residential dwellings. When I talk to non-technical people about the possibility of using an App in their phone to turn on the heater/AC in their summer home when they're on the way, they get really interested. There are a lot of use-cases where it would be beneficial to have things work well regardless of topology for devices being connected. I know people today who have connected up multiple NAT44-routers deep just because they don't know better, and this is of course not beneficial to the user experience. What is your vision of the typical home data solution in 10-20 years? I see 60Ghz wifi basestations needing to be in each room, a multitude of sensors that need separate routing domains because they're not ethernet, and my guess is that people don't want to do separate wiring for all these devices. I would like these things to "just work" when you hook them up. -- Mikael Abrahamsson email: swmike@swm.pp.se From cyrus@openwrt.org Wed Jun 19 01:22:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35FA21F9F94 for ; Wed, 19 Jun 2013 01:22:28 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk6R8tA01wpH for ; Wed, 19 Jun 2013 01:22:28 -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 D9B8E21F9F7D for ; Wed, 19 Jun 2013 01:22:21 -0700 (PDT) Received: from [192.168.178.21] (unknown [212.255.39.215]) by chi.subsignal.org (Postfix) with ESMTPSA id BA678126189; Wed, 19 Jun 2013 10:23:15 +0200 (CEST) Message-ID: <51C1789E.2050203@openwrt.org> Date: Wed, 19 Jun 2013 11:23:42 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Mikael Abrahamsson References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:22:29 -0000 On 19.06.2013 09:58, Mikael Abrahamsson wrote: > I already know people with a lot of temperature sensors, power sensors > etc in their residential dwellings. When I talk to non-technical people > about the possibility of using an App in their phone to turn on the > heater/AC in their summer home when they're on the way, they get really > interested. Nothing wrong with that and nothing preventing them from working. > > There are a lot of use-cases where it would be beneficial to have things > work well regardless of topology for devices being connected. I know > people today who have connected up multiple NAT44-routers deep just > because they don't know better, and this is of course not beneficial to > the user experience. > What is your vision of the typical home data solution in 10-20 years? I > see 60Ghz wifi basestations needing to be in each room, a multitude of > sensors that need separate routing domains because they're not ethernet, > and my guess is that people don't want to do separate wiring for all > these devices. I would like these things to "just work" when you hook > them up. > Right I agree. Especially that users do and will chain routers. Maybe even non-ethernet/WiFi at some point. This is a must for homenet but this is also what chained DHCPv6-PD / a hipnet-like solution can do. But let me ask the other way: What relevant usecase would such a solution not cover? or What would be covered better by something like OSPF in a home network? I'd just like to avoid a solution which adds much complexity and provides more features than actually needed today just because it could be useful in a later future where we don't even know if today's solution is even relevant for what we need because e.g. as you said sensors might need totally different routing. -Steven From otroan@employees.org Wed Jun 19 01:27:02 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C384F21F9F5C for ; Wed, 19 Jun 2013 01:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8ZHlGMN6ENb for ; Wed, 19 Jun 2013 01:26:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 29E0B21F9F60 for ; Wed, 19 Jun 2013 01:26:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHNqwVGQ/khM/2dsb2JhbABagwnAE34WdIIjAQEEAR0dPxALDjhXBogbBrsGjwgzB4MAYQOpBIMROg X-IronPort-AV: E=Sophos;i="4.87,895,1363132800"; d="scan'208";a="155506399" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2013 08:26:52 +0000 Received: from dhcp-10-61-100-174.cisco.com (dhcp-10-61-100-174.cisco.com [10.61.100.174]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5J8QnRL010178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 08:26:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51C16A12.3030205@openwrt.org> Date: Wed, 19 Jun 2013 10:26:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> To: Steven Barth X-Mailer: Apple Mail (2.1508) Cc: Ray Bellis , "homenet@ietf.org Group" , Dave Taht , tjc@ecs.soton.ac.uk, Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:27:02 -0000 Steven, >>> that the protocol is both 'lightweight' and that >>> open source implementations are readily available. >>=20 >> It is desirable that the size of the daemon and the data are also >> lightweight so as to be suitable for use on small embedded devices. >>=20 >> I perversely enjoyed watching the early attempts at big daemons for >> dhcpv6 go by... >=20 > I'd like to +1 this one. >=20 > I don't really like hipnet as a whole because I think its = overengineered at various points, however the general idea of using = chained DHCPv6-PD kind of makes it self contained and I think it would = be much easier to get deployed in the wild despite some of the = architectural problems that have to be solved adequately first (say = border and loop-detection). >=20 > What I mean is, I don't see any bigger routing daemons and stacks = getting integrated into the majority of home routers because simply of a = lack of incentives. A DHCPv6-server is most likely there anyway so I = guess adding the little bit of PD-support + maintaing it could be = justified. However a whole separate OSPF or so daemon + routing stack = with 100s of KB and all the inherent logic just for a few very advanced = usecases? I doubt it. I mean we are still talking about home networks = and home routers aren't we? as one of the co-authors of DHCPv6 PD, I must emphasise that PD was = never designed for this and does not work very well. DHCP does not work with multiple sources of information. meaning that if = you are multi-homed and have separate routers serving each connection, then you're in trouble. as a data point for a non advanced use case, I just moved in to a new = flat and discovered that the flat was already multi-homed with native = IPv6. a 70/10M cable connection and a 100/30M VDSL connection. I need to = make this work. what's special about the home network? we have been running routing = protocols in networks for decades. why should we only put lobotomised = schemes in the home? cheers, Ole= From cyrus@openwrt.org Wed Jun 19 01:41:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4621F9E9A for ; Wed, 19 Jun 2013 01:41:21 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIShxI52L0us for ; Wed, 19 Jun 2013 01:41:20 -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 1457B21F9E88 for ; Wed, 19 Jun 2013 01:41:18 -0700 (PDT) Received: from [192.168.178.21] (unknown [212.255.39.215]) by chi.subsignal.org (Postfix) with ESMTPSA id DC56C12618C; Wed, 19 Jun 2013 10:42:12 +0200 (CEST) Message-ID: <51C17D0F.8090709@openwrt.org> Date: Wed, 19 Jun 2013 11:42:39 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Ole Troan References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> In-Reply-To: <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Bellis , "homenet@ietf.org Group" , Dave Taht , tjc@ecs.soton.ac.uk, Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:41:21 -0000 On 19.06.2013 10:26, Ole Troan wrote: > what's special about the home network? we have been running routing protocols in networks for decades. why should we only put lobotomised schemes in the home? Well honestly from a technical perspective I wholeheartedly agree with you. I'm just pessimistic about it getting anywhere deployed widely. What's different or special about home networks? There's millions or billions of them. They usually use cheap routers with limited resources. And I don't think that is going to change anywhere in the near future. So while technically a full-blown routing protocol or even using more enterprisey routing is probably superior there are IMO other factors that limit the practically of it. I'm just saying that a DHCPv6-PD based solution - maybe with some of the most concerning issues fixed / circumvented - could have a much better chance of being adopted widely. I mean in the end defining standards that are never going to get used makes little sense as well. I know it's just one perspective and it's not even technical but I think nevertheless it should at least be considered. From swmike@swm.pp.se Wed Jun 19 01:49:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030A421F9FA3 for ; Wed, 19 Jun 2013 01:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRkSG2qhsG6K for ; Wed, 19 Jun 2013 01:49:09 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2F821F9F5F for ; Wed, 19 Jun 2013 01:49:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 66C509E; Wed, 19 Jun 2013 10:49:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 620239A for ; Wed, 19 Jun 2013 10:49:08 +0200 (CEST) Date: Wed, 19 Jun 2013 10:49:08 +0200 (CEST) From: Mikael Abrahamsson To: "homenet@ietf.org Group" In-Reply-To: <51C1787A.1070004@fon.com> Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1787A.1070004@fon.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:49:10 -0000 On Wed, 19 Jun 2013, Steven Barth wrote: > But let me ask the other way: What relevant usecase would such a > solution not cover? or What would be covered better by something like > OSPF in a home network? Let's say you have a cable Internet operator, handed off in a coax outlet next to your TV in your living room. The coax goes to their CER, which hands off an ethernet port. At the other end of the apartment/house, your FTTH connection is handed off in a media converter, also a CER. You connect a wireless AP to each of these and also connect up them together, so you have identical behaving SSID across the different domains, you prefer the APs to be routers, because you also have non-ethernet sensors you want to hook up. Now a PD hierarchy from each CER will cross each others, and how do you know what packet to send where to avoid uRPF filtering for each set of addresses? Perhaps you also want to build a ring of the APs around your house so in case you need to change out one of them, you don't break connectivity to everything else. I don't see how this can be solved without distributing more information to routers than they would have using purely DHCPv6-PD. I'm sure some will say above is bordering on overengineering and it's more "enterprise", but I believe people will want the above to work because their homenet will be more crucial to them in 10-20 years than it is today. I know a lot more people using RAID5 or RAID6 today compared to 10 years ago, same thing with backups etc. > I'd just like to avoid a solution which adds much complexity and > provides more features than actually needed today just because it could > be useful in a later future where we don't even know if today's solution > is even relevant for what we need because e.g. as you said sensors might > need totally different routing. "Totally different routing"? -- Mikael Abrahamsson email: swmike@swm.pp.se From ot@cisco.com Wed Jun 19 01:54:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E84F21F9F8D for ; Wed, 19 Jun 2013 01:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sfObcGYYVHT for ; Wed, 19 Jun 2013 01:54:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CACCB21F9EBC for ; Wed, 19 Jun 2013 01:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=717; q=dns/txt; s=iport; t=1371632071; x=1372841671; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=m5I9Q08hf653h9531tiaDixHZAXvIuC9nwRghNjA5OE=; b=SRQa3vofADu+l69D14H3vmoes2zVatJVJNigSC6w2EvurI02TOeSssy+ Ltg+wMDm+lxTHkaBVtT8J3nYQ9fp2QDs7II+uAaT12zG3cL+ydPC/0VuP uuTHnZboNcVsXMLRBNtt4LmFy3lDY9NYTbCXLJ1KZCLeYhN//biwcHdne I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIVwwVGQ/khM/2dsb2JhbABagwnAE34WdIIjAQEBAwEdHT8QCw44VwYuh20GuwaPCDMHgwBhA5dBkUODETo X-IronPort-AV: E=Sophos;i="4.87,895,1363132800"; d="scan'208";a="155507594" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2013 08:54:29 +0000 Received: from dhcp-10-61-100-174.cisco.com (dhcp-10-61-100-174.cisco.com [10.61.100.174]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5J8sQak020010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 08:54:27 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Wed, 19 Jun 2013 10:54:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1787A.1070004@fon.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:54:36 -0000 >> I'd just like to avoid a solution which adds much complexity and = provides more features than actually needed today just because it could = be useful in a later future where we don't even know if today's solution = is even relevant for what we need because e.g. as you said sensors might = need totally different routing. >=20 > "Totally different routing"? exactly. trying to create a working network with static routes created = by snooping on DHCP packets and making assumptions of the directionality = of the network by listening to RAs, creating a spanning tree at L3... now if that isn't complex and brittle... a dynamic routing protocol = seems quite simple in comparison. cheers, Ole= From mark@townsley.net Wed Jun 19 02:35:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFED921F9D98 for ; Wed, 19 Jun 2013 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DIET_1=0.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moYlOsCQOnob for ; Wed, 19 Jun 2013 02:35:25 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8535321F9D75 for ; Wed, 19 Jun 2013 02:35:24 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so4256500wgh.4 for ; Wed, 19 Jun 2013 02:35:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=u5yi9ktezzVQIsOp/uf1ZDXP/nmtcYDTK0O0wld/EQw=; b=Jg1mN+jNb0U4z5wtRGq0kZcpTJ6bjaBT7hJayCKkpps4fxx7r8/SzveiGprtlCzIDx V5Rr6ewsGCEMWJY9BdfBbSPFNJyW6apNZlUhXG82ooEPlPWwpAry8s4KcU2rt2IjQVXm O7KTO+LjDXkqEZGT8W9ZPDtZNHsenJmeyDzVqyIowW0r7hvWMSxfJnNOKqVzCHtFPyUg UuBrXCuZMdN4fgS2CAy9G4QuUJaISNG5xBCprRGyTzroSoPzT+auqgEdG1qLIHbysmD3 g1VrIxgCB57+ujrBiixKx0532a21yKzH+iMnnM8oPVq/iR9DLIIstJHiRvcaLaaFO0vI +mYA== X-Received: by 10.180.83.200 with SMTP id s8mr1379615wiy.48.1371634523270; Wed, 19 Jun 2013 02:35:23 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id o14sm7933792wiv.3.2013.06.19.02.35.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 02:35:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 19 Jun 2013 11:35:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6DBDA283-A341-4EB2-B3B9-CD031AB6ADAB@townsley.net> References: <840A8B85-8C60-4C51-A4A7-606B5FEE9BFC@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQn4VEnPbqhrhwAQXXweHwQ7Lznl611O0S0YlEGdRM1XDEgepSUIbQVoggVr3DVRf5pHBTm6 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:35:25 -0000 Let's focus on the substantive technical changes, with minimum diffs = given this is already 2nd WGLC. For the abbreviation and jargon = consistency, overuse of adverbs at the start of sentences, etc. - these = are important of course, but let's log them for inclusion in the doc = shepherd writeup for the RFC Editor to look at. They are the = professionals for that type of thing. - Mark=20 On Jun 19, 2013, at 1:12 AM, Tim Chown wrote: > On 18 Jun 2013, at 23:19, Ole Troan wrote: >=20 >> I've battled through the whole document again. I'm quite happy to see = this document proceed as is. >> some nits and comments below. note I'm also a co-author although I = haven't held the pen for a while. >=20 > You are always welcome to pick it up again; you have the xml :) We = should agree the full list of changes first though. >=20 >> this document could benefit from some weight loss throughout. the = text is riddled with excess, just in the abstract alone >> you can cut: increasingly, general, associated, briefly, suggests, = can be employed (are used),=20 >=20 > Probably, yes. Mark and Ray are concerned that any -08 to -09 changes = should be no more than needed, so that the tools diff view isn't bigger = than it needs to be. Let's see what they say about that. >=20 >> s/pro-active management/active management >>=20 >> s/CER/CE router/? >> how many names do we need for a CPE, Home Gateway, Residential = Gateway, CE, CE Router, pick one of the existing ones >=20 > So now you want the text longer :) I really don't mind, again, let's = see what the chairs want. >=20 >> section 2.2 on global addressablity - include a paragraph stating = that the network is exposed to ISP renumbering the network >> to a much larger degree than before. NAT isolated the user against = ISP renumbering to some extent. >=20 > True, but that is also the point of using ULAs. We can make it more = explicit though. >=20 >> section 2.4 ULA >> paragraph on security by restricting reachability. ULAs can be used = by default for devices that without configuration >> only should offer services to the internal network. e.g. a printer = could only accept incoming connections on a ULA, >> until configured to be globally reachable. >=20 > Yes, I think the text talks about the user being able to toggle this. = Though I don't off-hand recall specifically where. >=20 >> section 3.3.2 largest possible subnets. >> this seems to say, if something can be bridged together do so. is = that what we want to recommend? >> I don't know enough about bridging wired to wireless, versus routing = wired to wireless, but someone >> seemed to indicate that there were problems with bridging interfaces = of greatly differing speeds. >> anyone who can provide insight? >=20 > My interprettaion is that it means "largest possible subnets within = the constraints of the media"; one reason we cite for multiple subnets = is the variety of media deployed in a homenet; most likely at least = Ethernet, WLAN and LLN. >=20 >> remove this paragraph from section 3.4.1 >> There are reports that some CER equipment does not support receipt = of >> a prefix bigger than /64, but the homenet architecture is designed >> for future IPv6 home networks, and we assume that such restricted >> equipment will become rarer over time. >=20 > OK. >=20 >> the sentence: "It is expected that ISPs will deliver a relatively = stable prefix" is repeated at least twice if not three times >>=20 >> section 3.4.1 with regards to flash renumbering. it might be noted = that while the network can support flash renumbering, it will have = adverse effects on applications. >=20 > Indeed, though ULAs should protect internal applications, provided ULA = prefixes are stable within the homenet. >=20 >> section 3.4.3 s/internal prefix delegation/internal prefix = assignment/ alternatively prefix configuration >>=20 >> "However, where ULAs are used, most likely but not necessarily in = parallel with global prefixes," >> remove "but not necessarily" >=20 > OK. >=20 >> section 3.4.3 remove references to possible solution drafts >=20 > Ray/Mark agreed to do this more widely in the text. >=20 >> section 3.4.4 shouldn't it say something more about distribution of = other configuration information?=20 >=20 > It could do; this was a tpic Jari raised previously. >=20 > Tim >>=20 >>=20 >>=20 >>=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 mark@townsley.net Wed Jun 19 02:59:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE2021F9FA1 for ; Wed, 19 Jun 2013 02:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J3LxlrIdWuh for ; Wed, 19 Jun 2013 02:59:56 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8A621F9FA4 for ; Wed, 19 Jun 2013 02:59:52 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so4380483wgh.29 for ; Wed, 19 Jun 2013 02:59:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=a+NeJ7BEijKB2UfljAIs7AlTQF2106IXXrCAsonpUOk=; b=lJNHIXhkqoWxynbacFq9alu/CRLvNnJ9t6xKbIr0qXVkm1r/rgMvGEMh1/fGKqY8MP Chf0HPjgpXaQsqRLLgvuabRc7PQ0weXJgT5PoSPjvNkDnqI/KxVdX4klgXZa/2MZZFot mjqaJPgd5XUUSuHtyJbPHymhu6zdgC3oxqwHf+lPg8N9wn0g4FTXY+Qor05tf4RhUMxd tP8dggs86rITjIuF3svkiI6sXgQVgwCP2aLBmv/AS8fgXXf5jss44urX50MiUMf0qkSh 0b2H6wfU1I/qWhF/bOy8SjOwe/5Q0LQmkw0HQPUOPZlrltS7wYrvOu1fP5zOhfsK7RJz +Kig== X-Received: by 10.194.63.46 with SMTP id d14mr1563041wjs.81.1371635991317; Wed, 19 Jun 2013 02:59:51 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id x13sm8088372wib.3.2013.06.19.02.59.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 02:59:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <51C17D0F.8090709@openwrt.org> Date: Wed, 19 Jun 2013 11:59:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13E7BF83-A1E6-468C-83E9-CF51C99B18C6@townsley.net> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> <51C17D0F.8090709@openwrt.org> To: Steven Barth X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnNIHgueQ2ivJFArsaen6FoHpUlailhupiBh4DzBAZJGPmrNxTqwaXpP305uobuzbEm5ooJ Cc: Juliusz Chroboczek , tjc@ecs.soton.ac.uk, Dave Taht , Ray Bellis , Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:59:57 -0000 On Jun 19, 2013, at 11:42 AM, Steven Barth wrote: > On 19.06.2013 10:26, Ole Troan wrote: >> what's special about the home network? we have been running routing = protocols in networks for decades. why should we only put lobotomised = schemes in the home? > Well honestly from a technical perspective I wholeheartedly agree with = you. > I'm just pessimistic about it getting anywhere deployed widely. I understand your pessimism. That said, based on what we saw presented = at the last IETF, even the IEEE seems to be headed towards using IS-IS = in the home. Imagine the Irony of not having a routing protocol at L3 in = the IETF, while having one defined in the IEEE for use at L2. The = 6lowpan sensor world has figured out how to run routing protocols on = tiny, tiny, devices. CeroWRT has been running routing protocols for = years. When I look around, the routing protocol pessimism seems to be a = rather localized one.=20 Ultimately, I think we should be guided by what is technically correct, = balanced with what we can find interoperable, preferably open source, = implementations of. - Mark >=20 > What's different or special about home networks? > There's millions or billions of them. They usually use cheap routers = with limited resources. And I don't think that is going to change = anywhere in the near future. So while technically a full-blown routing = protocol or even using more enterprisey routing is probably superior = there are IMO other factors that limit the practically of it. >=20 > I'm just saying that a DHCPv6-PD based solution - maybe with some of = the most concerning issues fixed / circumvented - could have a much = better chance of being adopted widely. I mean in the end defining = standards that are never going to get used makes little sense as well. >=20 > I know it's just one perspective and it's not even technical but I = think nevertheless it should at least be considered. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From Ray.Bellis@nominet.org.uk Wed Jun 19 03:09:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8DB21F9F9E for ; Wed, 19 Jun 2013 03:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDVDlX9NmcPO for ; Wed, 19 Jun 2013 03:09:09 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id E7EFF21F9F9A for ; Wed, 19 Jun 2013 03:09:08 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV: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=zFe28gLcRrzXXAhuAQx7XgeflfMqFo8O8J91fBKLEJONk9n8zidybtDh t8e34wlWe/PBZ0uyQxDWCdOQhmPmxxe//irW01oDbJF4EMx+4yvHUIp9H Jjz+wsWbEPnwMyT; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1371636548; x=1403172548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tmprd/4x1c6L/j7ZXLJNmJaEiu4fjNkDxkPsQtgpfqg=; b=kD1/KzdrW0UQ5E4ZbK5UlndCqL7T52OZ87ycK0CEKawKFd23cVh2tX0h O9e+2wARgyKwA1KnxLfcajtu6VoqmhlZ6puKqqdqyRfFQXwDOLP2aM49u i4+8IBtqaOtittN; X-IronPort-AV: E=Sophos;i="4.87,895,1363132800"; d="scan'208";a="1512945" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 19 Jun 2013 11:08:53 +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%17]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 11:08:53 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk5WxuAgAB0toCAAAbRgIAAASiAgAACkQCAAg9DgIAAENsAgAAOqYCAAM9cgA== Date: Wed, 19 Jun 2013 10:08:53 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDC2960@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87vc5b2it8.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: <7DD1171C6CDF0F4CA1085E0B679D9C86@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:09:15 -0000 On 18 Jun 2013, at 22:46, Juliusz Chroboczek wrote: > I think we can take it asa given that OSPF will be chosen for Homenet, wh= ether some of us like it or not. Actually I don't think that's a given at all. It happens that the initial efforts by some participants have focused on OS= PF, but I hear there's quite a few people now thinking that IS-IS would be = a better choice. Lack of open source implementations is a potential impediment, of course, a= lthough it's expected that BIRD (from cz.nic) will have IS-IS support some = time pretty soon. Ray From tjc@ecs.soton.ac.uk Wed Jun 19 03:37:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0CF21F9590 for ; Wed, 19 Jun 2013 03:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5uBbHRX-z0X for ; Wed, 19 Jun 2013 03:37:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08721F94D3 for ; Wed, 19 Jun 2013 03:37:10 -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 r5JAb9UX004207 for ; Wed, 19 Jun 2013 11:37:09 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5JAb9UX004207 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1371638229; bh=hu0md1WV2ExNBINw8/JvGF6aXpI=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=QL52CEW0JnMR6tB7GReCKUcLP0UCsjHYd7qLrPewqwqVMfq/KLv5MZ98ie99vd4ZB OGaeV9hD22LYrz0G9TnsGz1BOUXFHR06WyZwm1QNKF1GvIS7IircmcYOybMXRDkc1X 1uQDlOrXrXguN10IhRq2skYv0XozPKojqlGmoZwc= 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 p5IBb90430658030j1 ret-id none; Wed, 19 Jun 2013 11:37:09 +0100 Received: from dhcp-205-24.wireless.soton.ac.uk (dhcp-205-24.wireless.soton.ac.uk [152.78.205.24]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r5JAb55M022588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Jun 2013 11:37:05 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDC2960@wds-exc1.okna.nominet.org.uk> Date: Wed, 19 Jun 2013 11:37:11 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDC2960@wds-exc1.okna.nominet.org.uk> <7E3451B2-FFF2-45C4-AD43-44142377067D@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5IBb9043065803000; tid=p5IBb90430658030j1; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r5JAb9UX004207 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:37:11 -0000 On 19 Jun 2013, at 11:08, Ray Bellis wrote: > On 18 Jun 2013, at 22:46, Juliusz Chroboczek = wrote: >=20 >> I think we can take it asa given that OSPF will be chosen for = Homenet, whether some of us like it or not. >=20 > Actually I don't think that's a given at all. >=20 > It happens that the initial efforts by some participants have focused = on OSPF, but I hear there's quite a few people now thinking that IS-IS = would be a better choice. >=20 > Lack of open source implementations is a potential impediment, of = course, although it's expected that BIRD (from cz.nic) will have IS-IS = support some time pretty soon. So we've seen some examples of the zeroconf prefix = assignment/configuration in action through implementations of = draft-arkko-homenet-prefix-assignment-04 and = draft-ietf-ospf-ospfv3-autoconfig-02. These have used Bird and Quagga. = While obviously just proof of concept, these were deployed on commodity = devices. The Bird implementation went further, supporting src&dst based = routing, which was demonstrated at the previous two IETFs. It would be interesting to see the equivalent solution based on IS-IS. = I'm not sure who the "quite a few people" are, but it would be a good = time for them to put something more tangible forward. Prior discussions have also proposed other routing protocols for = homenet. As someone else mentioned, the prefix and routing information could be = passed in ND/RAs, or that function could potentially be part of any = extended naming/SD protocols that emerge from the "mdnsext" BoF and = subsequent work. What the homenet-arch text needs to capture is the = general principles/requirements. I think with the changes suggested by = Ole, which are fairly minor, it will do so. Tim From teco@inf-net.nl Wed Jun 19 03:47:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D93921F9AAF for ; Wed, 19 Jun 2013 03:47:19 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oDOUO7weZ0d for ; Wed, 19 Jun 2013 03:47:18 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70E21F9AA0 for ; Wed, 19 Jun 2013 03:47:17 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so493455wiv.5 for ; Wed, 19 Jun 2013 03:47:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=kwxvlUd2nVm5K326xnL2t32PMWEQDjQUXcL/c2V5F74=; b=XK4PeDvzkoGUPYPbGaS4gjdYix/Xz3l2dxqXWNW1oUq5ZQD1ssbYSaot1MUajDkBc4 36ou+enmyzqWaSrVvUNR+W3wG12Ne8prFBe14HI6KbFiN+eVT1Pc4oj91ZNyYJ5FjiL0 WbWOiuU/rkDYFr5mIT2cBACxlQhMUaykKQRHq4oCXRTIvr5A9atjDHB3fRMofHbpngmU 8JoACWL8zpJ9PuJJepGGqo3NXSBZSMxkmz/WAs3nA0L+CnEgRXqp80PCEUK+rIkMNGse JaxJbDaJvHrkP3n74SSDT3+rsvR1G5QZYtfDtiu71yug4Fs0IyC4+qn5w8NmtfXrHsgJ ETvA== X-Received: by 10.194.179.233 with SMTP id dj9mr1719381wjc.46.1371638837085; Wed, 19 Jun 2013 03:47:17 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id fs8sm8386236wib.0.2013.06.19.03.47.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 03:47:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDC2960@wds-exc1.okna.nominet.org.uk> Date: Wed, 19 Jun 2013 12:47:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11E0A41F-11B5-4559-A37E-AD2F3676D112@inf-net.nl> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDC2960@wds-exc1.okna.nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmPZkuQRjIDgPIwugidJOHTS/Lf2JTJhQzfVouQgbcldCqVaNsa7+GAaXUxeXynS6QrMKck Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:47:19 -0000 Quite some time ago (25nov2011) I suggested to consider IS-IS and TRILL. It happens to be I manage my own small home network. I have 2 WiFi APs = with same SSIDs. I have to use single access subnet, WiFi stacks make = such assumption. How can I subnet my homenet without breaking my WiFi = service?=20 Teco Op 19 jun. 2013, om 12:08 heeft Ray Bellis = het volgende geschreven: >=20 > On 18 Jun 2013, at 22:46, Juliusz Chroboczek = wrote: >=20 >=20 >> I think we can take it asa given that OSPF will be chosen for = Homenet, whether some of us like it or not. >=20 > Actually I don't think that's a given at all. >=20 > It happens that the initial efforts by some participants have focused = on OSPF, but I hear there's quite a few people now thinking that IS-IS = would be a better choice. >=20 > Lack of open source implementations is a potential impediment, of = course, although it's expected that BIRD (from cz.nic) will have IS-IS = support some time pretty soon. >=20 > Ray >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From cyrus@openwrt.org Wed Jun 19 03:47:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D49A21F9A8D for ; Wed, 19 Jun 2013 03:47:59 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-ZO7GeTSGJL for ; Wed, 19 Jun 2013 03:47:59 -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 C7D3B21F8F7B for ; Wed, 19 Jun 2013 03:47:58 -0700 (PDT) Received: from [100.72.216.93] (tmo-110-221.customers.d1-online.com [80.187.110.221]) by chi.subsignal.org (Postfix) with ESMTPSA id A65FA12618C; Wed, 19 Jun 2013 12:48:50 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <13E7BF83-A1E6-468C-83E9-CF51C99B18C6@townsley.net> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> <51C17D0F.8090709@openwrt.org> <13E7BF83-A1E6-468C-83E9-CF51C99B18C6@townsley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Steven Barth Date: Wed, 19 Jun 2013 12:47:51 +0200 To: Mark Townsley Message-ID: <12b18035-bd67-480e-bd84-fd6b626e81c6@email.android.com> Cc: Ole Troan , Juliusz Chroboczek , Dave Taht , Ray Bellis , tjc@ecs.soton.ac.uk, "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:47:59 -0000 Mark Townsley wrote: >I understand your pessimism. That said, based on what we saw presented >at the last IETF, even the IEEE seems to be headed towards using IS-IS >in the home. Imagine the Irony of not having a routing protocol at L3 >in the IETF, while having one defined in the IEEE for use at L2. The >6lowpan sensor world has figured out how to run routing protocols on >tiny, tiny, devices. CeroWRT has been running routing protocols for >years. When I look around, the routing protocol pessimism seems to be a >rather localized one. > >Ultimately, I think we should be guided by what is technically correct, >balanced with what we can find interoperable, preferably open source, >implementations of. Well I guess the compromise would be something lightweight then. I find ospf - as proposed - too heavy-duty for that. Maybe something based on IS-IS if you already mentioned it? Maybe having a small lightweight open source daemon -preferrably outside of bird / quagga? - that can be easily integrated into the native firmware source policy based routing without carrying too much unnecessary bloat. -Steven From prvs=288224811f=acee.lindem@ericsson.com Wed Jun 19 05:48:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914AE21F938E for ; Wed, 19 Jun 2013 05:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPNc1H5WRikq for ; Wed, 19 Jun 2013 05:48:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 120F021F91A5 for ; Wed, 19 Jun 2013 05:48:14 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-99-51c1a88ecbba Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 2E.A3.17537.E88A1C15; Wed, 19 Jun 2013 14:48:14 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 08:48:13 -0400 From: Acee Lindem To: Steven Barth Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOaxZOD2/n0Jq0ZEK+oRQ4rPdZUJk6DjWAgAAG0YCAAAEngIAAApEAgAIPRICAABDaAIAABywAgAC44wCAAAFxAIAAFTGAgAAEywCAAA1tgIAAIaAA Date: Wed, 19 Jun 2013 12:48:13 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE471805C2@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> <51C17D0F.8090709@openwrt.org> <13E7BF83-A1E6-468C-83E9-CF51C99B18C6@townsley.net> <12b18035-bd67-480e-bd84-fd6b626e81c6@email.android.com> In-Reply-To: <12b18035-bd67-480e-bd84-fd6b626e81c6@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E7AEB01EEBFBD45B352959176B6F669@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXRPiG7fioOBBrv+K1qcO7yJyWLPxpMs Fu8XHWKx+PzpH6vFtAMPmCwmt61gs/jU9ZzV4tCe52wOHB5/17l6HDz2kdFj56y77B5Llvxk 8jgxdx6Tx5bFGR4Xd79j9Lg/bSJTAEcUt01SYklZcGZ6nr5dAndGx9+VTAXtAhWTNi1gbWBs 5u1i5OSQEDCReHjnEQuELSZx4d56NhBbSOAoo0TrIpEuRi4gezmjxMKb05hAEmwCOhLPH/1j BrFFBFQkOi8cZwMpYhZYwSRxf90UdpCEsICnxP/3N5ggirwkZh/sAisSEWhilGg6vogVJMEi oCrR0PEazOYV8JZ4tWMhO8S6l6wSv652gU3iFHCVuLiuDWwdI9B930+tAZvKLCAucevJfCaI uwUkluw5zwxhi0q8fPyPFcJWlljyZD8LRL2OxILdn9ggbGuJt7PboeLaEssWvmaGOEJQ4uTM JywTGMVnIVkxC0n7LCTts5C0z0LSvoCRdRUjR2lxalluupHBJkZgRB+TYNPdwbjnpeUhRmkO FiVx3pendgUKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjG6P98S7xJoaNSxRZe49lb+H s8T4yY6Pr0InXu4t65Xcwbln3XuW7z2r0l6YOe/7nrNixbvrs5Yfm1PIvYtp7e7wVJ0uz+C7 GxcpPvWVsq2xuTxpfdDVhq1uvRLpV5Z3xugF5KxYO1XIq87TUaqIw6PnxZ0p7f/esTLMlAt5 c9tkr0fDfRWZq0osxRmJhlrMRcWJACyvwvG7AgAA Cc: Juliusz Chroboczek , Mark Townsley , Dave Taht , Ray Bellis , Ole Troan , "" , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:48:20 -0000 On Jun 19, 2013, at 6:47 AM, Steven Barth wrote: >=20 >=20 > Mark Townsley wrote: >> I understand your pessimism. That said, based on what we saw presented >> at the last IETF, even the IEEE seems to be headed towards using IS-IS >> in the home. Imagine the Irony of not having a routing protocol at L3 >> in the IETF, while having one defined in the IEEE for use at L2. The >> 6lowpan sensor world has figured out how to run routing protocols on >> tiny, tiny, devices. CeroWRT has been running routing protocols for >> years. When I look around, the routing protocol pessimism seems to be a >> rather localized one.=20 >>=20 >> Ultimately, I think we should be guided by what is technically correct, >> balanced with what we can find interoperable, preferably open source, >> implementations of. >=20 > Well I guess the compromise would be something lightweight then. I find o= spf - as proposed - too heavy-duty for that. Maybe something based on IS-IS= if you already mentioned it? It has been my experience that ISIS and OSPF without accoutrements are simi= lar in code size and complexity. Both these protocols have experienced deca= des of extensions to meet the requirements of service provider and, to some= extent, large enterprise networks. Many of these extensions are not needed= in home nets.=20 If you add layer 3 transparency on top of the routing protocol, e.g., TRILL= or SPB, that is another layer of complexity. However, if the technology is= mature and better meets the requirements, I'm not sure that complexity or = code size should be the primary concern.=20 Acee=20 >=20 > Maybe having a small lightweight open source daemon -preferrably outside = of bird / quagga? - that can be easily integrated into the native firmware = source policy based routing without carrying too much unnecessary bloat. >=20 > -Steven > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Wed Jun 19 05:57:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F73C21F9BD3 for ; Wed, 19 Jun 2013 05:57:47 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyKoP2piBxxF for ; Wed, 19 Jun 2013 05:57:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 75B5421F9BA7 for ; Wed, 19 Jun 2013 05:57:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F09F2017D; Wed, 19 Jun 2013 10:01:25 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D2711A9028; Wed, 19 Jun 2013 08:56:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BAFCDB9081; Wed, 19 Jun 2013 08:56:43 -0400 (EDT) From: Michael Richardson To: Steven Barth In-Reply-To: <51C1789E.2050203@openwrt.org> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@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 Cc: "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:57:47 -0000 --=-=-= Steven Barth wrote: sb> Right I agree. Especially that users do and will chain routers. Maybe sb> even non-ethernet/WiFi at some point. This is a must for homenet but sb> this is also what chained DHCPv6-PD / a hipnet-like solution can do. it can deal with tree-like topologies with a single ISP. It can not deal with loops: I see them regularly in people's small offices, and given wifi, it's really easy even for experts to create. sb> I'd just like to avoid a solution which adds much complexity and sb> provides more features than actually needed today just because it sb> could be useful in a later future where we don't even know if today's sb> solution is even relevant for what we need because e.g. as you said sb> sensors might need totally different routing. The solution that has been demoed appears pretty light weight. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcGqiIqHRg3pndX9AQL6uwP/QYFPcyJOP5xMNm65dmkTx0B3P+RCC67n zpWyNh5f9Za/DrhWE09FQT72DVplnQheeDbdk3NOFicJHVC+8JgOqTyxQ3dkyJGx qbnBb6RkKIqKmiK7/Jak3ZVqne3bPSVTRPpeWWayjZ05ZyPSY09S1Kls6DQvuTbQ XlUDJkbk97o= =ZLvH -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Jun 19 07:37:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A4921F9C97 for ; Wed, 19 Jun 2013 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5drNKwEC-OWl for ; Wed, 19 Jun 2013 07:37:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 330D621F9CC4 for ; Wed, 19 Jun 2013 07:37:40 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 430C62017D; Wed, 19 Jun 2013 11:41:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2A769A9028; Wed, 19 Jun 2013 10:36:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 12BF8B9081; Wed, 19 Jun 2013 10:36:41 -0400 (EDT) From: Michael Richardson To: Ray Hunter In-Reply-To: <51C151A7.2070304@globis.net> References: <51C151A7.2070304@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 Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:37:46 -0000 --=-=-= Ray Hunter wrote: ray> Although ULA prefixes are recommended to be filtered at the site ray> boundary (Section 4.3 RFC4193) they also may be used for inter-site ray> VPN's (section 4.7 RFC4193). 1) is anyone actually doing this now? 2) the RIRs need to be pushed by the IETF to make some Non-Connected Network (aka "ULA-Central") space available at very minimal cost to Enterprises. 3) ULAs across sites would piss me, and anyone else off who had to debug. You need reverse DNS and whois in a big enterprise. The proliferation and confusion as a result of RFC1918 in enterprises proves this. So, maybe we can push back here at 6man, and suggest that section 4.7 of 4193 should be deprecated. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcHB9oqHRg3pndX9AQKu6gP6A+ykGTfGivLdLNPrOYNvuVWd74EZ42c5 WqlidnJCwVlZnqWl6LGj4DIub4D4mav0FMo7rSrsVMbsfoSia2hwy/Vmo8q2HGPv OLSCsrN5cTeZ8bru7s+V01bdWqDw6RQt4J1WXZk9smcgX0PvgAiYRfdI4ppnl7of Fv/iEnEcXV8= =LRvL -----END PGP SIGNATURE----- --=-=-=-- From mike@mtcc.com Wed Jun 19 07:49:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2A21F9C57 for ; Wed, 19 Jun 2013 07:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmxCUQdMFnYm for ; Wed, 19 Jun 2013 07:48:54 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id CAA3421F9CC8 for ; Wed, 19 Jun 2013 07:48:51 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5JEmKgh012095 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 07:48:21 -0700 Message-ID: <51C1C4B4.2040206@mtcc.com> Date: Wed, 19 Jun 2013 07:48:20 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> In-Reply-To: <5706.1371652601@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1144; t=1371653301; x=1372517301; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20draft-ietf-homenet-arch=20c omments |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ULhjSbWeV1079yTSjkTv1o6XBu6u8Xgsdo3O5bTWWkY=; b=FVtKKKPn5sEx4f6n0Q5mskn6YShaCZuU82p3zYEFoueTvDhHG3lp4YPCbc upwbIZX421MKVEPe9/bhNun3501RY57/8kYrOdLxFJHACefpgQMwWtNdLMXX FSt2xXrWGU+LH+4EJmEpPz/qQuoYGeEZY30cNODlCgg9pplNligwE=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Hunter , Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:49:00 -0000 On 06/19/2013 07:36 AM, Michael Richardson wrote: > Ray Hunter wrote: > ray> Although ULA prefixes are recommended to be filtered at the site > ray> boundary (Section 4.3 RFC4193) they also may be used for inter-site > ray> VPN's (section 4.7 RFC4193). > > 1) is anyone actually doing this now? > > 2) the RIRs need to be pushed by the IETF to make some Non-Connected Network (aka > "ULA-Central") space available at very minimal cost to Enterprises. > > 3) ULAs across sites would piss me, and anyone else off who had to debug. > You need reverse DNS and whois in a big enterprise. The proliferation > and confusion as a result of RFC1918 in enterprises proves this. > The corpro-IT types typically think of your laptop as being part of their site, not your home. So getting a corpro ula would probably seem right to them. In either case though: just being attached by vpn may make getting corpro ula's inevitable regardless of desire: autoconfiguring them is what the host wants to do, so any bit of config oops will land them there. Tunnels are strange beasts. Mike From v6ops@globis.net Wed Jun 19 08:42:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6693E21F9D4F for ; Wed, 19 Jun 2013 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, DIET_1=0.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF+YkBMeK9hd for ; Wed, 19 Jun 2013 08:42:20 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6C21F9D4E for ; Wed, 19 Jun 2013 08:42:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 563438700E7; Wed, 19 Jun 2013 17:42: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 k2yNWjqdqooY; Wed, 19 Jun 2013 17:42:04 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 2D0318700CD; Wed, 19 Jun 2013 17:42:04 +0200 (CEST) Message-ID: <51C1D145.6070200@globis.net> Date: Wed, 19 Jun 2013 17:41:57 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Michael Richardson References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> In-Reply-To: <5706.1371652601@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:42:21 -0000 > Michael Richardson > 19 June 2013 16:36 > Ray Hunter wrote: > ray> Although ULA prefixes are recommended to be filtered at the site > ray> boundary (Section 4.3 RFC4193) they also may be used for inter-site > ray> VPN's (section 4.7 RFC4193). > > 1) is anyone actually doing this now? I don't know anyone who's actually doing it already , but I've certainly seen plenty of evidence of people thinking of doing it. People are talking Internet centric. So a deployment model of an automatically configured tunnel network running over public Internet for private enterprise traffic, plus a number of NPTv6 gateways breaking out to the public Internet makes perfect sense to them. There are a number of products that do this already for IPv4 e.g. Meraki, and it wouldn't be rocket science to extend the concept to IPv6. Using ULA means you don't even have to pay for PI space for small remote offices, and you also "fix" your intercontinental multi-homing problems. [not that I necessarily agree that this is the best deployment model, but it is certainly valid and does not require deploying anything more than existing IETF standards documents] An awful lot of people work from home, or on small sales sites, where they tunnel back into the corporate network, or even simultaneously to a 3rd party's machines for some collaboration. That VPN can terminate either on your laptops' VPN driver, or a homenet router. Relying on address class to determine security context is a non-starter IMHO. > 2) the RIRs need to be pushed by the IETF to make some Non-Connected > Network (aka > "ULA-Central") space available at very minimal cost to Enterprises. > Not sure that's related or how it would help.. > 3) ULAs across sites would piss me, and anyone else off who had to debug. > You need reverse DNS and whois in a big enterprise. The proliferation > and confusion as a result of RFC1918 in enterprises proves this. Yes. You'll probably also need split DNS. Hence my comments. > > So, maybe we can push back here at 6man, and suggest that section 4.7 > of 4193 > should be deprecated. > Too late IMHO. I think it might be more constructive to initially treat the requirements for a corporate VPN link as "just another ISP uplink" > -- > Michael Richardson , Sandelman Software Works > > > Ray Hunter > 19 June 2013 08:37 > Ole Troan wrote: >> I've battled through the whole document again. I'm quite happy to see this document proceed as is. >> some nits and comments below. note I'm also a co-author although I haven't held the pen for a while. >> >> cheers, >> Ole >> >> ----- >> >> >> this document could benefit from some weight loss throughout. the text is riddled with excess, just in the abstract alone >> you can cut: increasingly, general, associated, briefly, suggests, can be employed (are used), >> >> s/pro-active management/active management >> >> s/CER/CE router/? >> how many names do we need for a CPE, Home Gateway, Residential Gateway, CE, CE Router, pick one of the existing ones >> >> section 2.2 on global addressablity - include a paragraph stating that the network is exposed to ISP renumbering the network >> to a much larger degree than before. NAT isolated the user against ISP renumbering to some extent. >> >> section 2.4 ULA >> paragraph on security by restricting reachability. ULAs can be used by default for devices that without configuration >> only should offer services to the internal network. e.g. a printer could only accept incoming connections on a ULA, >> until configured to be globally reachable. > > This is a good example of why I am concerned about ULA. > > ULA may be preferred over GUA [assuming we either take action on 6724 to > inject additional /48's into the policy table or older nodes are present > that still run 3484 or something else.] > > Although ULA prefixes are recommended to be filtered at the site > boundary (Section 4.3 RFC4193) > they also may be used for inter-site VPN's (section 4.7 RFC4193). > > Making additional/ unnecessary assumptions about reachability and > security is IMHO yet another .local / RFC1918 problem waiting to strike. > > If you want security, the device providing the security needs to > understand the topology e.g. where the site border is in relation to the > endpoints of the connection request. Merely relying on addressing > schemes is insufficient IMHO. > > >> section 3.3.2 largest possible subnets. >> this seems to say, if something can be bridged together do so. is that what we want to recommend? >> I don't know enough about bridging wired to wireless, versus routing wired to wireless, but someone >> seemed to indicate that there were problems with bridging interfaces of greatly differing speeds. >> anyone who can provide insight? >> >> remove this paragraph from section 3.4.1 >> There are reports that some CER equipment does not support receipt of >> a prefix bigger than /64, but the homenet architecture is designed >> for future IPv6 home networks, and we assume that such restricted >> equipment will become rarer over time. >> >> the sentence: "It is expected that ISPs will deliver a relatively stable prefix" is repeated at least twice if not three times >> >> section 3.4.1 with regards to flash renumbering. it might be noted that while the network can support flash renumbering, it will have adverse effects on applications. >> >> section 3.4.3 s/internal prefix delegation/internal prefix assignment/ alternatively prefix configuration >> >> "However, where ULAs are used, most likely but not necessarily in parallel with global prefixes," >> remove "but not necessarily" >> >> section 3.4.3 remove references to possible solution drafts >> >> section 3.4.4 shouldn't it say something more about distribution of other configuration information? >> >> >> >> >> > ------------------------------------------------------------------------ From mellon@fugue.com Wed Jun 19 10:40:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3E21F9D16 for ; Wed, 19 Jun 2013 10:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNRj90YQ3UPm for ; Wed, 19 Jun 2013 10:39:55 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D605A21F9CE8 for ; Wed, 19 Jun 2013 10:39:54 -0700 (PDT) Received: from [IPv6:2001:470:88a3::68c0:e8ba:fa67:f768] (unknown [IPv6:2001:470:88a3:0:68c0:e8ba:fa67:f768]) by toccata.fugue.com (Postfix) with ESMTPSA id 84F782381687; Wed, 19 Jun 2013 13:39:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> Date: Wed, 19 Jun 2013 13:39:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:40:00 -0000 On Jun 17, 2013, at 4:13 PM, Ralph Droms wrote: > The document makes no mention of *how* a largest practical subnet = architecture might be achieved. There should be some requirement that = devices be capable of acting as either a bridge or a router (or a mix of = both), and that devices should bridge unless routing is determined = necessary. I find this text in the document a bit problematic too. I don't think = it's actually reasonably practical to do any such determination. The = only practical source of subnet sizing is the size of the smallest = prefix we got from an ISP. I guess there are some ideas we could = suggest, but they look more like solutions than architecture to me. For instance, we could say that for any given router, all non-edge = interfaces on that router that are of the same media type should be = bridged together into a single subnet. CeroWRT makes each one its own = subnet, which drives me nuts. This would have the effect that if you = plugged a Wifi router's ethernet port into the ethernet port of a CER, = the WiFi router's ethernet port would be on the same subnet as the CER's = ethernet ports, but the Wifi network would be on its own subnet; hence, = routed, not bridged, which I think is desirable. But does this belong = in the architecture document? Furthermore, it's complicated by the fact that we'd really prefer to = avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite = possible that people will plug such interfaces together. So we may = need to decide very dynamically which interfaces are bridged and which = are routed. Maybe we will have virtual bridged networks on each = homenet router for each media type and speed that the router supports, = and dynamically connect interfaces that are running at that speed to = those bridges, and hope that this works. I don't think we've visited this issue thoroughly enough to make = statements about it in the architecture document. > Acknowledging the desire to avoid constraining future networks, I = think the document would benefit from some discussion of scaling goals: = how many subnets, how many ISP connections, etc. also, some text about = how much and what user configuration is acceptable should be added. As = a specific example, network devices can't know, without user input, = whether s guest network us desired and how devices should be guided to = attach to the guest network. I think that these are all reasonable things to want to describe; the = question is, does the working group want to describe them, particularly = in the current rev of the architecture document. My impression is that = at the moment the working group is willing to leave these things out of = the architecture document. The document at the moment assumes the ability to support multihoming = for N connections, where N can definitely be 2, and possibly an = arbitrarily large number greater than two, but probably not. I think = it would indeed be worth making this explicit in the architecture = document. If we don't, I think some people will tend to read the = architecture document as really only requiring support for a maximum of = two CERs and two ISP connections. How many subnets is determined by the size of the prefix we are given. = If we get a /64, the whole homenet is going to have to be a single = subnet, like it or not. If we get a /48, we can have a subnet for = every device, which would be pretty silly. This leads to a separate question that is also interesting: what if we = are multihomed, and one ISP gives us lots of prefix, and the other ISP = gives us a /64? Do we bridge, to accommodate the chintzy ISP? Do we = route, and just ignore the second ISP? Do we just subnet the /64 down, = and run those micro-prefixes as managed prefixes using DHCPv6? I think none of these options works well, if at all, and this scenario = is a very realistic possibility, e.g. in the case of a dual-homed home = that's connected to a wireline ISP that provides a /56, and a wireless = ISP that provides a /64. If Comcast ever gets me a native IPv6 = connection, that will in fact be my home network environment. The = current architecture document does not discuss this scenario, although = it grazes frustratingly close to doing so in section 3.4.3. 3.3.3 does talk about guest realms, which I think is adequate. Talking = about UI is probably unnecessary, since it's implicit that some UI is = needed, and since the text in 3.3.3 isn't nearly sufficient to implement = guest realms; a document describing how this works on a homenet will be = necessary, and if the working group (which includes you!) decides to = talk about UI in that document, then we'll cover it there; otherwise = not. The beginning of 3.3 talks about user interaction in the sense that it = says there shouldn't need to be any. We have in the past talked about = how to make that work, since at the very minimum, the arrangement of = ethernet ports on a router and the labeling of these connectors = constitutes a user interface. 3.3 also talks about a shared key, but = doesn't say how that's provided. We talked about this during the early = discussions about the architecture document, and I don't think we came = to any kind of consensus about how that would work, although I think it = was clear to everybody that we needed to figure out some way to identify = friend and stranger when it comes to bridging over Wifi. Some ideas = for how to do this were discussed, and sounded good at least to me, so I = don't think that's the end of the discussion, but the lack of consensus = makes it hard to say anything more in the architecture document. The bottom line, wearing my working group participant hat, not my AD = hat, is that this is going to be an evolutionary process, and things = that are unclear now will become clearer later, and can be added to a = new version of the architecture document then. Much as we might wish = for it to be the case that the architecture document as written could be = the final, perfect version, I don't think we are in a position to = achieve that yet. From jch@pps.univ-paris-diderot.fr Wed Jun 19 10:44:39 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C5B21F9D92 for ; Wed, 19 Jun 2013 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M59u95jNdeQ for ; Wed, 19 Jun 2013 10:44:34 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1D21F9D5D for ; Wed, 19 Jun 2013 10:44:31 -0700 (PDT) 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/38117) with ESMTP id r5JHiTO8004465; Wed, 19 Jun 2013 19:44: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 73F524EA0B; Wed, 19 Jun 2013 19:44: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 7FPGS2Gu_TXE; Wed, 19 Jun 2013 19:44:28 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 528AB4E9DF; Wed, 19 Jun 2013 19:44:28 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UpMQl-0007zi-RW; Wed, 19 Jun 2013 19:44:27 +0200 Date: Wed, 19 Jun 2013 19:44:27 +0200 Message-ID: <87sj0evvus.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Teco Boot In-Reply-To: <11E0A41F-11B5-4559-A37E-AD2F3676D112@inf-net.nl> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDC2960@wds-exc1.okna.nominet.org.uk> <11E0A41F-11B5-4559-A37E-AD2F3676D112@inf-net.nl> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 19 Jun 2013 19:44:29 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:44:40 -0000 > I suggested to consider [...] TRILL. (giggle) -- Juliusz From mellon@fugue.com Wed Jun 19 11:07:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0421E21F9E3C for ; Wed, 19 Jun 2013 11:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrF6fgRnjBS8 for ; Wed, 19 Jun 2013 11:06:55 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 44BCD21F9E34 for ; Wed, 19 Jun 2013 11:06:45 -0700 (PDT) Received: from [IPv6:2001:470:88a3::cdbd:4df5:1265:653d] (unknown [IPv6:2001:470:88a3:0:cdbd:4df5:1265:653d]) by toccata.fugue.com (Postfix) with ESMTPSA id EE6A523817D0; Wed, 19 Jun 2013 14:06:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <87sj0evvus.wl%jch@pps.univ-paris-diderot.fr> Date: Wed, 19 Jun 2013 14:06:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1126E7A1-A4B3-414D-AFC2-411857E0BFAE@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDC2960@wds-exc1.okna.nominet.org.uk> <11E0A41F-11B5-4559-A37E-AD2F3676D112@inf-net.nl> <87sj0evvus.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" , Teco Boot Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:07:00 -0000 On Jun 19, 2013, at 1:44 PM, Juliusz Chroboczek = wrote: >> I suggested to consider [...] TRILL. > (giggle) He's not the only person to think of it. If not to use it directly, to = consider its use of IS-IS. From mbaugher@cisco.com Wed Jun 19 11:39:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E8E21F9DC0 for ; Wed, 19 Jun 2013 11:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpCwo-mhyX9K for ; Wed, 19 Jun 2013 11:39:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C69D721F9AE2 for ; Wed, 19 Jun 2013 11:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=440; q=dns/txt; s=iport; t=1371667186; x=1372876786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4xMprpOHwwJZzmF1siQA+Kl7bbjYIQpPZydvE5sNJkE=; b=IL2LFy4Htd37nCh36MP0p6rN2DJaxGsbBSVcXyrnDjXjxWAVhQ/P1nAz PzA2x8qopapwTZcouu3TtzhJLiGds95ftY0O4RTRuFMxceEFH5sE/BlZo M2mZlc6hW3iwhu7Il39rZCEkCznUorjvBJV9n30OJVf1lCg1FBo40EeSR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsOAO35wVGtJXG+/2dsb2JhbABagwl6gju8WQQCAYEAFnSCIwEBAQMBHR0/BQsCAQgOFBQQMiUCBA4FCIgABrtljw8CMQeDAGEDqQWDD4Io X-IronPort-AV: E=Sophos;i="4.87,899,1363132800"; d="scan'208";a="224722278" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 19 Jun 2013 18:39:46 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5JIdkGp002538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 18:39:46 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 13:39:45 -0500 From: "Mark Baugher (mbaugher)" To: Mikael Abrahamsson Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk5v7CAgAB0toCAAAbSgIAAASeAgAACkQCAAg9EgIAAENoAgAAHLACAALjiAP//+XGAgACzQ4A= Date: Wed, 19 Jun 2013 18:39:45 +0000 Message-ID: <9C2FF8548CD17F4AB32FC8B311470DFA15282ABB@xmb-aln-x10.cisco.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.205] Content-Type: text/plain; charset="us-ascii" Content-ID: <9172381A339D0E40A11DFA513759D107@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:39:52 -0000 On Jun 19, 2013, at 12:58 AM, Mikael Abrahamsson wrote: > There are a lot of use-cases where it would be beneficial to have things = work well regardless of topology for devices being connected.=20 And some where it is not: A security service might not place sensors or act= uators on the common home LAN owing to common threats like malware, visitor= s, etc. This is a routable homenet use case. Mark= From mbaugher@cisco.com Wed Jun 19 11:49:02 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8121F9BF1 for ; Wed, 19 Jun 2013 11:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOmB3w-527tX for ; Wed, 19 Jun 2013 11:48:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5B221F9E34 for ; Wed, 19 Jun 2013 11:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1371667737; x=1372877337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zk3cJmYgoASAlPwOX8ASbr4zrW8tHECkSG+5Mv6rO8Y=; b=Y/I8VmqsdEtGiZ1GRgDObpIIf96EZR2fhvpbCrTTqP6DY0vaJ85Btr7R LNZSdzptji4GV04JskGY8yfeuW1LJbwxMkhzBw6p5dBkN7eCuEJwOLygd asCCuPIbYpG1vkI7ZUXMUDLSLB3wj5/zrEQKTnnLBF89Zex+vAPzUjGKl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAEX8wVGtJV2b/2dsb2JhbABagwkxSb8bgQAWdIIjAQEBAwEBAQEaHTQLBQsCAQgOCgoUECcLJQIEDgUIE4dtBgy7XQSOCgGBBAIxB4MAYQOpBYMPgWgBHyA X-IronPort-AV: E=Sophos;i="4.87,899,1363132800"; d="scan'208";a="224727282" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 19 Jun 2013 18:48:57 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5JImvmU021694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 18:48:57 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 13:48:56 -0500 From: "Mark Baugher (mbaugher)" To: Steven Barth Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk5v7CAgAB0toCAAAbSgIAAASeAgAACkQCAAg9EgIAAENoAgAAHLACAALjiAIAAAXIAgAAVMYCAAJiggA== Date: Wed, 19 Jun 2013 18:48:56 +0000 Message-ID: <9C2FF8548CD17F4AB32FC8B311470DFA15282B5B@xmb-aln-x10.cisco.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> <51C17D0F.8090709@openwrt.org> In-Reply-To: <51C17D0F.8090709@openwrt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.205] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BE6B067D2C2944F99B638863A94580F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Juliusz Chroboczek , "" , Dave Taht , Ray Bellis , Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:49:02 -0000 On Jun 19, 2013, at 2:42 AM, Steven Barth wrote: > On 19.06.2013 10:26, Ole Troan wrote: >> what's special about the home network? we have been running routing prot= ocols in networks for decades. why should we only put lobotomised schemes i= n the home? > Well honestly from a technical perspective I wholeheartedly agree with yo= u. > I'm just pessimistic about it getting anywhere deployed widely. Depends on how IoT applications and other new services appear on the home n= etwork or don't appear - in which case there may be little need for routing= . But today's bridged home network (SSID+ethernet ports) is not well suite= d to services that need network separation. After all, why are we introducing multiple routers in the home anyway? In = my case its because I have a teleworking service, others may have a securit= y service or smart meter, etc. =20 >=20 > What's different or special about home networks? > There's millions or billions of them. They usually use cheap routers with= limited resources. And I don't think that is going to change anywhere in t= he near future. So while technically a full-blown routing protocol or even = using more enterprisey routing is probably superior there are IMO other fac= tors that limit the practically of it. Home routers are subject to Moore's law and they will continue to grow in s= peed and memory that can increasingly support routing, VPN, 802.1x and othe= r services. Mark >=20 > I'm just saying that a DHCPv6-PD based solution - maybe with some of the = most concerning issues fixed / circumvented - could have a much better chan= ce of being adopted widely. I mean in the end defining standards that are n= ever going to get used makes little sense as well. >=20 > I know it's just one perspective and it's not even technical but I think = nevertheless it should at least be considered. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Wed Jun 19 13:41:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF0221F9FF1 for ; Wed, 19 Jun 2013 13:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, DIET_1=0.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN6esPWYRAo4 for ; Wed, 19 Jun 2013 13:41:48 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99321F9F9D for ; Wed, 19 Jun 2013 13:41:48 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so5487502pdi.30 for ; Wed, 19 Jun 2013 13:41:48 -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=h25Xtx8sHHwxraX/ropcJ+tKkws8g5zSI7wu2mUWNjI=; b=QrVy7dj3MfbdJIyiWARQdX2AfatsqhyX67N2NX5SGniRVZTr1bma0lgTQ2Jp0PBBqG roZwVLDs0+QETshSWetSG5rUkhoX4bsHyiQFxKhavWlXEmrYXnGLtCeF2d1F9GrvtqbU TJtMYe/b4Rn5gOqi6pVveO5BnPdGJKJjp2kl1Ds1LDfDUd86gc0aO9B9FBwJjNRcgamQ EUSdotny1zYxY0hYQQpYfBmIc0K/fJEO9EvURoQ9W1QjOKRC9FrjhvK2kHyGCEELEjTj E0VyfNaJIeZgAjfdxl0SohjVKFoFNJ5+I7GmB+H6qOAMskWUHj+eLZVNJjh5CNM2cXgR JzAw== X-Received: by 10.68.219.70 with SMTP id pm6mr4445273pbc.154.1371674508147; Wed, 19 Jun 2013 13:41:48 -0700 (PDT) Received: from [192.168.178.20] (36.200.69.111.dynamic.snap.net.nz. [111.69.200.36]) by mx.google.com with ESMTPSA id fn9sm26261884pab.2.2013.06.19.13.41.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 13:41:47 -0700 (PDT) Message-ID: <51C2178F.40004@gmail.com> Date: Thu, 20 Jun 2013 08:41:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> In-Reply-To: <51C1D145.6070200@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 20:41:53 -0000 On 20/06/2013 03:41, Ray Hunter wrote: >> Michael Richardson >> 19 June 2013 16:36 >> Ray Hunter wrote: >> ray> Although ULA prefixes are recommended to be filtered at the site >> ray> boundary (Section 4.3 RFC4193) they also may be used for inter-site >> ray> VPN's (section 4.7 RFC4193). >> >> 1) is anyone actually doing this now? > > I don't know anyone who's actually doing it already , but I've certainly > seen plenty of evidence of people thinking of doing it. > > People are talking Internet centric. So a deployment model of an > automatically configured tunnel network running over public Internet for > private enterprise traffic, plus a number of NPTv6 gateways breaking out > to the public Internet makes perfect sense to them. There are a number > of products that do this already for IPv4 e.g. Meraki, and it wouldn't > be rocket science to extend the concept to IPv6. Using ULA means you > don't even have to pay for PI space for small remote offices, and you > also "fix" your intercontinental multi-homing problems. [not that I > necessarily agree that this is the best deployment model, but it is > certainly valid and does not require deploying anything more than > existing IETF standards documents] > > An awful lot of people work from home, or on small sales sites, where > they tunnel back into the corporate network, or even simultaneously to a > 3rd party's machines for some collaboration. That VPN can terminate > either on your laptops' VPN driver, or a homenet router. > > Relying on address class to determine security context is a non-starter > IMHO. > > >> 2) the RIRs need to be pushed by the IETF to make some Non-Connected >> Network (aka >> "ULA-Central") space available at very minimal cost to Enterprises. >> > Not sure that's related or how it would help.. And it's way out of scope for homenets; typical home users will not be going off to register a ULA prefix to avoid a minute chance of collision. > >> 3) ULAs across sites would piss me, and anyone else off who had to debug. >> You need reverse DNS and whois in a big enterprise. The proliferation >> and confusion as a result of RFC1918 in enterprises proves this. > > Yes. You'll probably also need split DNS. Which is of course standard practice in thousands of enterprise networks. > Hence my comments. >> So, maybe we can push back here at 6man, and suggest that section 4.7 >> of 4193 >> should be deprecated. >> > Too late IMHO. I think it might be more constructive to initially treat > the requirements for a corporate VPN link as "just another ISP uplink" In the sense that a "foreign" ULA prefix is just another global prefix, with tailored routing rules, that's exactly right and fully consistent with existing practice in large corporates. ULAs are a simplification compared with de-aggregating GUA prefixes for the same purpose. Brian > >> -- >> Michael Richardson , Sandelman Software Works >> > >> Ray Hunter >> 19 June 2013 08:37 >> Ole Troan wrote: >>> I've battled through the whole document again. I'm quite happy to see this document proceed as is. >>> some nits and comments below. note I'm also a co-author although I haven't held the pen for a while. >>> >>> cheers, >>> Ole >>> >>> ----- >>> >>> >>> this document could benefit from some weight loss throughout. the text is riddled with excess, just in the abstract alone >>> you can cut: increasingly, general, associated, briefly, suggests, can be employed (are used), >>> >>> s/pro-active management/active management >>> >>> s/CER/CE router/? >>> how many names do we need for a CPE, Home Gateway, Residential Gateway, CE, CE Router, pick one of the existing ones >>> >>> section 2.2 on global addressablity - include a paragraph stating that the network is exposed to ISP renumbering the network >>> to a much larger degree than before. NAT isolated the user against ISP renumbering to some extent. >>> >>> section 2.4 ULA >>> paragraph on security by restricting reachability. ULAs can be used by default for devices that without configuration >>> only should offer services to the internal network. e.g. a printer could only accept incoming connections on a ULA, >>> until configured to be globally reachable. >> This is a good example of why I am concerned about ULA. >> >> ULA may be preferred over GUA [assuming we either take action on 6724 to >> inject additional /48's into the policy table or older nodes are present >> that still run 3484 or something else.] >> >> Although ULA prefixes are recommended to be filtered at the site >> boundary (Section 4.3 RFC4193) >> they also may be used for inter-site VPN's (section 4.7 RFC4193). >> >> Making additional/ unnecessary assumptions about reachability and >> security is IMHO yet another .local / RFC1918 problem waiting to strike. >> >> If you want security, the device providing the security needs to >> understand the topology e.g. where the site border is in relation to the >> endpoints of the connection request. Merely relying on addressing >> schemes is insufficient IMHO. >> >> >>> section 3.3.2 largest possible subnets. >>> this seems to say, if something can be bridged together do so. is that what we want to recommend? >>> I don't know enough about bridging wired to wireless, versus routing wired to wireless, but someone >>> seemed to indicate that there were problems with bridging interfaces of greatly differing speeds. >>> anyone who can provide insight? >>> >>> remove this paragraph from section 3.4.1 >>> There are reports that some CER equipment does not support receipt of >>> a prefix bigger than /64, but the homenet architecture is designed >>> for future IPv6 home networks, and we assume that such restricted >>> equipment will become rarer over time. >>> >>> the sentence: "It is expected that ISPs will deliver a relatively stable prefix" is repeated at least twice if not three times >>> >>> section 3.4.1 with regards to flash renumbering. it might be noted that while the network can support flash renumbering, it will have adverse effects on applications. >>> >>> section 3.4.3 s/internal prefix delegation/internal prefix assignment/ alternatively prefix configuration >>> >>> "However, where ULAs are used, most likely but not necessarily in parallel with global prefixes," >>> remove "but not necessarily" >>> >>> section 3.4.3 remove references to possible solution drafts >>> >>> section 3.4.4 shouldn't it say something more about distribution of other configuration information? >>> >>> >>> >>> >>> >> ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From marka@isc.org Wed Jun 19 18:01:43 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB59921F9EFC for ; Wed, 19 Jun 2013 18:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYMtb7e9R5Qa for ; Wed, 19 Jun 2013 18:01:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A622421F9EBD for ; Wed, 19 Jun 2013 18:01:34 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BBE7CC94C9; Thu, 20 Jun 2013 01:01:27 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371690093; bh=i+V+OBV3Ps2IxE1uOjk4Sp/+CTQYvoe0TJqjyAJ8gbI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=TND9vfZssTqMJrQuG78otPSKmC+8mRFc2Y23kjtITaTxT53ANelCLSwhnVUljSsC8 rYeDKxFdGQYgZpUl0MpVDMFAsk1mxodyjCYbwMXQBFzHgWtTB/ZYIKp/zfzG07/dUj DyWkyiKQ1lus/lVepWq+qHOXrzpTkhpxLzYI5KwE= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 20 Jun 2013 01:01:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 607F616006D; Thu, 20 Jun 2013 01:02:11 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WFjmooU9R4Bz; Thu, 20 Jun 2013 01:02:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8B6B4160079; Thu, 20 Jun 2013 01:02:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a62juZk3g6oV; Thu, 20 Jun 2013 01:02:10 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 2EC96160078; Thu, 20 Jun 2013 01:02:10 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id B1B033613B86; Thu, 20 Jun 2013 11:01:17 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> <51C2178F.40004@gmail.com> In-reply-to: Your message of "Thu, 20 Jun 2013 08:41:51 +1200." <51C2178F.40004@gmail.com> Date: Thu, 20 Jun 2013 11:01:16 +1000 Message-Id: <20130620010117.B1B033613B86@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Ray Hunter , Ole Troan , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 01:01:43 -0000 In terms of ULA address and the DNS, IPv6 needs a scoped type in the DNS to hold IPv6 addresses. This would help with both ULA and Link-Local scoped addresses. It also needs to be able to advertise whether a address is deprecated or not. Where indicates the address is deprecated (1) so that this address sorted to the end of the potential addresses. Where is a domain name and should be choosen to be globally unique for the space. "." is the global namespace. RA's would advertise which namespaces are valid for the link. There would also be DHCP options (4 and 6) which specify which spaces are valid for the relevent address family. I have 3 non-temporary address on currently one of my interfaces. inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf fe80::6233:4bff:fe01:7585 0 link1.dv.isv.org. fd92:7065:b8e::6233:4bff:fe01:7585 0 dv.isv.org. 2001:470:1f00:820:6233:4bff:fe01:7585 0 . The RA/DHCP would say that "wireless.dv.isv.org", "dv.isv.org" and "." are valid for this link and getaddrinfo() would filter addresses ( controllable via a flag) based on that information and fill in the scopeid field appropriately for the linklocal address. This interface also has a RFC 1918 address inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 and this would also be in the RRset as a mapped address giving fe80::6233:4bff:fe01:7585 0 link1.dv.isv.org. fd92:7065:b8e::6233:4bff:fe01:7585 0 dv.isv.org. 2001:470:1f00:820:6233:4bff:fe01:7585 0 . ::ffff:192.168.191.223 0 dv.isv.org. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mellon@fugue.com Wed Jun 19 18:36:03 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B10121F9AE5 for ; Wed, 19 Jun 2013 18:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfjb68lVZWgD for ; Wed, 19 Jun 2013 18:35:58 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0287D21F9AE3 for ; Wed, 19 Jun 2013 18:35:58 -0700 (PDT) Received: from [IPv6:2001:470:88a3::1188:c7d7:f03e:45e5] (unknown [IPv6:2001:470:88a3:0:1188:c7d7:f03e:45e5]) by toccata.fugue.com (Postfix) with ESMTPSA id 0A117238059C; Wed, 19 Jun 2013 21:35:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <20130620010117.B1B033613B86@drugs.dv.isc.org> Date: Wed, 19 Jun 2013 21:35:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com> References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> <51C2178F.40004@gmail.com> <20130620010117.B1B033613B86@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) Cc: Ray Hunter , Ole Troan , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 01:36:03 -0000 On Jun 19, 2013, at 9:01 PM, Mark Andrews wrote: > Where indicates the address is deprecated (1) so that > this address sorted to the end of the potential addresses. Why would you even publish a deprecated address? If you're = renumbering, a connection from a deprecated address to a new address = ought to work, so there's no reason to have the deprecated addresses in = the DNS at all. From swmike@swm.pp.se Wed Jun 19 19:23:18 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598E721F9FC1 for ; Wed, 19 Jun 2013 19:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMTNMbemSS9t for ; Wed, 19 Jun 2013 19:23:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 510E821F9F43 for ; Wed, 19 Jun 2013 19:23:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6DC1F9C; Thu, 20 Jun 2013 04:23:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 64F419A; Thu, 20 Jun 2013 04:23:14 +0200 (CEST) Date: Thu, 20 Jun 2013 04:23:14 +0200 (CEST) From: Mikael Abrahamsson To: "Mark Baugher (mbaugher)" In-Reply-To: <9C2FF8548CD17F4AB32FC8B311470DFA15282ABB@xmb-aln-x10.cisco.com> Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <9C2FF8548CD17F4AB32FC8B311470DFA15282ABB@xmb-aln-x10.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 02:23:18 -0000 On Wed, 19 Jun 2013, Mark Baugher (mbaugher) wrote: > And some where it is not: A security service might not place sensors or > actuators on the common home LAN owing to common threats like malware, > visitors, etc. This is a routable homenet use case. Hm, I don't know if I'm misunderstanding you, but just to be clear, I am very much *pro* a routed home and this is what I am advocating for. But anyhow, isn't the correct approach for a sensor manufacturer to make sure only devices authorized to talk to it, can talk to it? By means of using IPSEC or similar mechanism? Then again, I realise a sensors isn't in a great position to handle a few megabits of small packets from Internet. Can perhaps something like 802.1x be used to be placed the device into different vlans and/or different secured routing domains within the home (or a configurable firewall policy in the homenet router depending on some criteria that is configurable). I need to think about this, it's an interesting question. -- Mikael Abrahamsson email: swmike@swm.pp.se From marka@isc.org Wed Jun 19 20:15:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D022E21F9A5C for ; Wed, 19 Jun 2013 20:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTQdvoZwuyif for ; Wed, 19 Jun 2013 20:15:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F062711E80CC for ; Wed, 19 Jun 2013 20:15:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7E18CC9425; Thu, 20 Jun 2013 03:15:39 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371698146; bh=c0lWFhx0nYTBKcKqPp1j4dauzlNVijs5hEUGfwKF05U=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=YQM7LPqFkO2wfeG1qfE1LAn13bqZitA22NZf0NRiZ1WnYnYz4WzWNuBRbHYL85Im7 ikPQQpfLAtU8RnQHmyuYp5J4iWDk7SZySWUZrsPS8YMMhJL0/RAPfen6JvtvQ8mq1p bIYW3HlJjmYOHfufiZWGlPcBF2Igv+ZsOBXuQFR8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 20 Jun 2013 03:15:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ADFB4160075; Thu, 20 Jun 2013 03:16:23 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lejh3oJaiEPb; Thu, 20 Jun 2013 03:16:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1CAB516006D; Thu, 20 Jun 2013 03:16:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TbCFhqo8s_Hv; Thu, 20 Jun 2013 03:16:23 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id A4E7B16003D; Thu, 20 Jun 2013 03:16:22 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E631F3614104; Thu, 20 Jun 2013 13:15:32 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> <51C2178F.40004@gmail.com> <20130620010117.B1B033613B86@drugs.dv.isc.org> <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com> In-reply-to: Your message of "Wed, 19 Jun 2013 21:35:54 -0400." <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com> Date: Thu, 20 Jun 2013 13:15:32 +1000 Message-Id: <20130620031532.E631F3614104@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Ray Hunter , Ole Troan , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:15:51 -0000 In message <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com>, Ted Lemon writes: > On Jun 19, 2013, at 9:01 PM, Mark Andrews wrote: > > Where indicates the address is deprecated (1) so that > > this address sorted to the end of the potential addresses. > > Why would you even publish a deprecated address? If you're renumbering, > a connection from a deprecated address to a new address ought to work, so > there's no reason to have the deprecated addresses in the DNS at all. Well for one thing you need it for address -> PTR -> AAAA checking. For a second thing you can have routing issues with one prefix and not the other. The address is "deprecated" not "gone". At the moment you have to remove the AAAA too early or risk a deprecated address being used in preference to a non deprecated address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Wed Jun 19 20:19:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A01211E80E0 for ; Wed, 19 Jun 2013 20:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWCndZYulDj3 for ; Wed, 19 Jun 2013 20:19:36 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4871821E805F for ; Wed, 19 Jun 2013 20:19:36 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id 14so5691584pdj.40 for ; Wed, 19 Jun 2013 20:19:36 -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=v/4sWBMt3BW2RLUPB3LB7wonXJ+je/8YX2O/JZJ5fRY=; b=woHtvdZXbYZ/v7BFc085xEdsEx9pO7+MWl82HOluOm33XlNVheZHTv//L08LjxzXpb uu5kIM2uhDalojaWAed/RTS3HrgL4Z8S9NCSd7SqK6ih9WHjzTQNcaBVrqn9CJII5zBo Jg3FBvkh4GfYImDQhqIGDW/5zCCYnvDoKsYALqJ1irVtIPZn23sKNCZKJKqDVVEnMMDB aTnPxWft7znwG9SvQMx2KQ9uR0AcWlCnmnovzjwkwvHnOHuHcdG/DqVJZJBuimk5wEqI nqAmbjEtNAGICGl0AamnVr3lQxkYpnDwLpZ4fxHYjTNEsNwKDkcWmqBlG9eqb7r75e3W 88gw== X-Received: by 10.66.136.76 with SMTP id py12mr9398783pab.192.1371698375961; Wed, 19 Jun 2013 20:19:35 -0700 (PDT) Received: from [192.168.178.20] (36.200.69.111.dynamic.snap.net.nz. [111.69.200.36]) by mx.google.com with ESMTPSA id cq1sm25736110pbc.13.2013.06.19.20.19.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 20:19:35 -0700 (PDT) Message-ID: <51C274CB.4060302@gmail.com> Date: Thu, 20 Jun 2013 15:19:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> <51C2178F.40004@gmail.com> <20130620010117.B1B033613B86@drugs.dv.isc.org> <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com> <20130620031532.E631F3614104@drugs.dv.isc.org> In-Reply-To: <20130620031532.E631F3614104@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , Ole Troan , Ted Lemon , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:19:42 -0000 On 20/06/2013 15:15, Mark Andrews wrote: ... > Well for one thing you need it for address -> PTR -> AAAA checking. Maybe we could deprecate that check first. > For a second thing you can have routing issues with one prefix and So why wouldn't you publish the deprecated *prefix* rather than a large bunch of /128s? Brian From marka@isc.org Wed Jun 19 20:37:34 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74AB11E80F3 for ; Wed, 19 Jun 2013 20:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k31hsEpeywzQ for ; Wed, 19 Jun 2013 20:37:29 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE911E80F0 for ; Wed, 19 Jun 2013 20:37:29 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B7CE6C9425; Thu, 20 Jun 2013 03:37:22 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371699448; bh=Z0XTN/0Rg/dxp9ejJnJFSJd+Beg4PgSmOTDSaFoKFo8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=AU/8eBR7kl6kc2DcHdwVw9Kmg76qGsfOoVoRZFV+GWkbNQXRb7IafiZRbkUXxlXnj 3tnx71GSXnBFjCIUSmPAwMFeMr9E3yb3WYD6vIrkja9ad07aNkh71gNkaAPVSG1FZf +dPXSJDsr7RfHCaQ0BON/7IX3RC4pTY2HkWWAEgY= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 20 Jun 2013 03:37:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E3D71160078; Thu, 20 Jun 2013 03:38:06 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SOl6Cb09DzlJ; Thu, 20 Jun 2013 03:38:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6EC48160077; Thu, 20 Jun 2013 03:38:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qkOL4dsqRuH5; Thu, 20 Jun 2013 03:38:06 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 0057D160076; Thu, 20 Jun 2013 03:38:05 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id A1F0E361443C; Thu, 20 Jun 2013 13:37:17 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> <51C2178F.40004@gmail.com> <20130620010117.B1B033613B86@drugs.dv.isc.org> <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com> <20130620031532.E631F3614104@drugs.dv.isc.org> <51C274CB.4060302@gmail.com> In-reply-to: Your message of "Thu, 20 Jun 2013 15:19:39 +1200." <51C274CB.4060302@gmail.com> Date: Thu, 20 Jun 2013 13:37:17 +1000 Message-Id: <20130620033717.A1F0E361443C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Ray Hunter , Ole Troan , Ted Lemon , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:37:34 -0000 In message <51C274CB.4060302@gmail.com>, Brian E Carpenter writes: > On 20/06/2013 15:15, Mark Andrews wrote: > ... > > Well for one thing you need it for address -> PTR -> AAAA checking. > > Maybe we could deprecate that check first. What's wrong with a sanity check? > > For a second thing you can have routing issues with one prefix and > > So why wouldn't you publish the deprecated *prefix* rather than > a large bunch of /128s? Who was talking about /128's vs short prefixes? > Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jch@pps.univ-paris-diderot.fr Thu Jun 20 05:38:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0109621F9C35 for ; Thu, 20 Jun 2013 05:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr47aV-ozuxO for ; Thu, 20 Jun 2013 05:38:13 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6038621F9C4D for ; Thu, 20 Jun 2013 05:38:10 -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/38117) with ESMTP id r5KCc6cW010142; Thu, 20 Jun 2013 14:38:06 +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 89BEA4EB34; Thu, 20 Jun 2013 14:38:06 +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 Xrc5pauOPBVM; Thu, 20 Jun 2013 14:38:05 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 31F7F4EB33; Thu, 20 Jun 2013 14:38:05 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Upe7o-00015t-TF; Thu, 20 Jun 2013 14:38:04 +0200 Date: Thu, 20 Jun 2013 14:38:04 +0200 Message-ID: <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Michael Richardson In-Reply-To: <7761.1371646603@sandelman.ca> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 20 Jun 2013 14:38:07 +0200 (CEST) Cc: Steven Barth , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 12:38:29 -0000 > sb> this is also what chained DHCPv6-PD / a hipnet-like solution can do. > It can not deal with loops: I see them regularly in people's small offices, > and given wifi, it's really easy even for experts to create. Could you please explain that? I was under the impression that a prefix subdelegation is always for a longer prefix than the one it was delegated from, so at each hop the prefix gets longer. A loop would imply that a prefix is strictly longer than itself. (Of course we want a proper routing protocol, whether DHCP-PD can handle routing topologies or not, but I'd hope that DHCP-PD is at least as good as STP.) -- Juliusz From mellon@fugue.com Thu Jun 20 06:01:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A436621F9A63 for ; Thu, 20 Jun 2013 06:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XKYt31lV8wn for ; Thu, 20 Jun 2013 06:01:42 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4321F9A76 for ; Thu, 20 Jun 2013 06:01:42 -0700 (PDT) Received: from [IPv6:2001:470:88a3::1188:c7d7:f03e:45e5] (unknown [IPv6:2001:470:88a3:0:1188:c7d7:f03e:45e5]) by toccata.fugue.com (Postfix) with ESMTPSA id 9F5C823808CB; Thu, 20 Jun 2013 09:01:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> Date: Thu, 20 Jun 2013 09:01:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: Michael Richardson , Steven Barth , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:01:47 -0000 On Jun 20, 2013, at 8:38 AM, Juliusz Chroboczek = wrote: > I was under the impression that a prefix subdelegation is always for > a longer prefix than the one it was delegated from, so at each hop the > prefix gets longer. A loop would imply that a prefix is strictly > longer than itself. >=20 > (Of course we want a proper routing protocol, whether DHCP-PD can > handle routing topologies or not, but I'd hope that DHCP-PD is at > least as good as STP.) The correct way to do PD in a homenet, if you want to do PD, is to have = a single router doing delegation, and all the other routers on the = network relaying to that router if they are not directly connected to a = link to which that router is also connected. So while what you say = above is true, it doesn't mean what you think it means, because all = delegations are coming from a single source. How a routing loop happens in this model is another question, of course. = Suppose I connect my network up like this: -D-- V V A->B->C ^-----V A knows how to get to the outside world directly. B knows how to get = to the outside world through A or C or D. C knows how to get to the = outside world through B or through A or D. D knows how to get to the = outside world through B or C. So now you can have a case where if = routing decisions are deterministic, and happen the wrong way, you can = have a packet looping through D until the TTL runs out, for instance. Of course, it would be straightforward to detect this situation, and we = could invent a new mechanism to do it, but we already have mechanisms = for doing it (e.g., IS-IS), so why not use them?= From jch@pps.univ-paris-diderot.fr Thu Jun 20 06:11:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32B721F99FB for ; Thu, 20 Jun 2013 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zG2NutDRQLY for ; Thu, 20 Jun 2013 06:11:08 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 947B421F9A4A for ; Thu, 20 Jun 2013 06:11:08 -0700 (PDT) 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/38117) with ESMTP id r5KDB1Px031611; Thu, 20 Jun 2013 15:11:01 +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 149824EACA; Thu, 20 Jun 2013 15:11:01 +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 OYwXXLNouquJ; Thu, 20 Jun 2013 15:10:59 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9D5B04EB39; Thu, 20 Jun 2013 15:10:59 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Upedf-00018m-7g; Thu, 20 Jun 2013 15:10:59 +0200 Date: Thu, 20 Jun 2013 15:10:59 +0200 Message-ID: <87ppvhuduk.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 20 Jun 2013 15:11:01 +0200 (CEST) Cc: Michael Richardson , Steven Barth , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Loops in DHCP-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:11:14 -0000 > -D-- > V V > A->B->C > ^-----V > A knows how to get to the outside world directly. B knows how to > get to the outside world through A or C or D. You've lost me here. B got its prefix delegation from A, so B's default route points at A, no? > Of course, it would be straightforward to detect this situation, and > we could invent a new mechanism to do it, but we already have > mechanisms for doing it (e.g., IS-IS), so why not use them? I think everyone here is convinced that it's a good idea to be using a real routing protocol to communicate between routers, but that's quite orthogonal to the (purely theoretical) question of whether a DHCP-PD-based topology causes persistent routing loops. -- Juliusz From tjc@ecs.soton.ac.uk Thu Jun 20 06:12:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB37821F9C21 for ; Thu, 20 Jun 2013 06:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1XK3MP2Z0Ea for ; Thu, 20 Jun 2013 06:12:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id EE01621F9A4A for ; Thu, 20 Jun 2013 06:12:25 -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 r5KDCM8K012707 for ; Thu, 20 Jun 2013 14:12:22 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5KDCM8K012707 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1371733942; bh=G7nWV+m2KQOA8gSPtTvUB5X0MlA=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=VZhhyAzZzXjwqbt2DMtK+2QYRjHcBHlIDI43ok8XNkDK7FSbQ34YhdtFOi/CLHSHa p8xEiJOZ3oPDMDpI028yMW+Y9ttADBDjn0TmtldvsVdg1ueKj/9jYCFch2skNOLmdM HDMTnRykb4FLkAGzLDsGWhgW4m7PknZnHrJvz1co= 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 p5JECM0544500229jj ret-id none; Thu, 20 Jun 2013 14:12:22 +0100 Received: from dhcp-200-189.wireless.soton.ac.uk (dhcp-200-189.wireless.soton.ac.uk [152.78.200.189]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r5KDCIpC010187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Jun 2013 14:12:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <20130620033717.A1F0E361443C@drugs.dv.isc.org> Date: Thu, 20 Jun 2013 14:12:18 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> <51C2178F.40004@gmail.com> <20130620010117.B1B033613B86@drugs.dv.isc.org> <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com> <20130620031532.E631F3614104@drugs.dv.isc.org> <51C274CB.4060302@gmail.com> <20130620033717.A1F0E361443C@drugs.dv.isc.org> <65C6A9C8-53BC-4180-B5B4-75D75F7C80C1@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5JECM054450022900; tid=p5JECM0544500229jj; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r5KDCM8K012707 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:12:27 -0000 On 20 Jun 2013, at 04:37, Mark Andrews wrote: > In message <51C274CB.4060302@gmail.com>, Brian E Carpenter writes: >> On 20/06/2013 15:15, Mark Andrews wrote: >> ... >>> Well for one thing you need it for address -> PTR -> AAAA checking. >>=20 >> Maybe we could deprecate that check first. >=20 > What's wrong with a sanity check? >=20 >>> For a second thing you can have routing issues with one prefix and >>=20 >> So why wouldn't you publish the deprecated *prefix* rather than >> a large bunch of /128s? >=20 > Who was talking about /128's vs short prefixes? While discussion is fine, it would be very useful if the focus was on = specific suggested changes to text for the -08 arch text. Tim= From tjc@ecs.soton.ac.uk Thu Jun 20 06:24:32 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12DA21F9C2B for ; Thu, 20 Jun 2013 06:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwf6d1c+drvO for ; Thu, 20 Jun 2013 06:24:32 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E445C21F9BCF for ; Thu, 20 Jun 2013 06:24:20 -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 r5KDOJaY016733 for ; Thu, 20 Jun 2013 14:24:19 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5KDOJaY016733 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1371734659; bh=/zZGynHu4XxyO31OlBx7LWZqOG0=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=ajj8xx45xv4AuBeazF9IkAdBRH99IDDmT2F1fqJkqjpTfomPQ0wmdKsPiyE62ia4X V85kEgtgmTtBX+e79cBbwixh/aeXYVtbS9bo73V+uOWZ0bUeZMIOUIG/FRpFEQ5ozo W20/tGl4rLGWr2QJF9IMkqovE5CS9vlVUxwAO8P0= 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 p5JEOJ0544500403Re ret-id none; Thu, 20 Jun 2013 14:24:19 +0100 Received: from dhcp-200-189.wireless.soton.ac.uk (dhcp-200-189.wireless.soton.ac.uk [152.78.200.189]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r5KDOG50013478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Jun 2013 14:24:16 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <87ppvhuduk.wl%jch@pps.univ-paris-diderot.fr> Date: Thu, 20 Jun 2013 14:24:16 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> <87ppvhuduk.wl%jch@pps.univ-paris-diderot.fr> <46F29B7C-168B-4EC3-A927-616B7C23DF20@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5JEOJ054450040300; tid=p5JEOJ0544500403Re; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r5KDOJaY016733 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] Loops in DHCP-PD X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:24:33 -0000 On 20 Jun 2013, at 14:10, Juliusz Chroboczek = wrote: >> -D-- >> V V >> A->B->C >> ^-----V >=20 >> A knows how to get to the outside world directly. B knows how to >> get to the outside world through A or C or D. >=20 > You've lost me here. B got its prefix delegation from A, so B's > default route points at A, no? >=20 >> Of course, it would be straightforward to detect this situation, and >> we could invent a new mechanism to do it, but we already have >> mechanisms for doing it (e.g., IS-IS), so why not use them? >=20 > I think everyone here is convinced that it's a good idea to be using > a real routing protocol to communicate between routers, but that's > quite orthogonal to the (purely theoretical) question of whether > a DHCP-PD-based topology causes persistent routing loops. So the homenet-arch text splits out the routing functionality (which = doesn't strictly require a routing protocol) from the prefix assignment = functionality. In hipnet, there is no routing protocol, you have = cascaded DHCP-PD with default route up, more specifics down. In zOSPF, = prefixes are assigned as per draft-arkko-homenet-prefix-assignment-04.=20= My question is whether there is any specific text suggested for = homenet-arch from this discussion. The previous suggestions from Ole are = already noted. Tim= From alexandru.petrescu@gmail.com Thu Jun 20 06:25:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A5221F9C2F for ; Thu, 20 Jun 2013 06:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBoJzZLI1IRy for ; Thu, 20 Jun 2013 06:25:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A755821F9C52 for ; Thu, 20 Jun 2013 06:25:35 -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 r5KDPYqC025401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Jun 2013 15:25:34 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5KDPX36006558 for ; Thu, 20 Jun 2013 15:25:34 +0200 (envelope-from alexandru.petrescu@gmail.com) 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 r5KDPUcT017431 for ; Thu, 20 Jun 2013 15:25:33 +0200 Message-ID: <51C302CA.3080304@gmail.com> Date: Thu, 20 Jun 2013 15:25:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: homenet@ietf.org References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:25:41 -0000 Le 20/06/2013 14:38, Juliusz Chroboczek a écrit : >> sb> this is also what chained DHCPv6-PD / a hipnet-like solution >> can do. > >> It can not deal with loops: I see them regularly in people's small >> offices, and given wifi, it's really easy even for experts to >> create. > > Could you please explain that? > > I was under the impression that a prefix subdelegation is always for > a longer prefix than the one it was delegated from, Not necessarily. It is possible to configure DHCPv6 PD such that to delegate whatever prefix compared to already owned, or compared to other delegated prefix: equal, longer, shorter or completely different. It is however important that when DHCPv6 delegates something, the routes in the routing table entries of intermediate machines be set up accordingly. Loops appear in the route set up phase (which is a different software than what typically DHCPv6 PD software does). 'Loops' is what one cries about when noticing (1) circling packets after delegation and route setup, or (2) same prefix delegated to different places, or (3) packet storms. Hop Limit is a field in each IP packet decremented at each forwarding step, and dropped when 0 - a good tool helping not fear loops. Other tools exist. One would need however a good interface between the DHCPv6-PD software and that other dynamic routing protocol. > so at each hop the prefix gets longer. A loop would imply that a > prefix is strictly longer than itself. > > (Of course we want a proper routing protocol, whether DHCP-PD can > handle routing topologies or not, but I'd hope that DHCP-PD is at > least as good as STP.) I am not sure what is STP. Last time I checked long ago DHCPv6-PD would not do any routing table management (not insert nor remove entries). This is an operation that is needed at least at Relay, upon delegation (insert an entry for the delegated prefix, and remove it when no longer delegated). Alex > > -- Juliusz _______________________________________________ homenet > mailing list homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > From teco@inf-net.nl Thu Jun 20 07:30:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D707121F9CAD for ; Thu, 20 Jun 2013 07:30:20 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0vr5omOesI8 for ; Thu, 20 Jun 2013 07:30:20 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1323521F9C97 for ; Thu, 20 Jun 2013 07:30:19 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so2950494bkc.10 for ; Thu, 20 Jun 2013 07:30:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DcJVC85Z9HtEDRhYiBPExHttdosp9x3zVeQd7og7Jhg=; b=cjhyAF44NGnqGbR+V+eJBOf7IVavE5IbLJjjHANePursOTZ14Vm9+NGngCrUmk5txO UxHc17Tk2o1ZroJpJDTFgnSUlBSgHxzGWqcRrRoPAQCaWtShDPRsU7h5oTK83u7i1W6M wWDG5V7PD4T9XUM3Z2oqDF0QtoLBAxkQqHh40Un8eyPsxYd3oiubckittSATE42bHvVk ovYiP8JpAmBrxq93iShsfgHO1OZYs2GUPXg7RqMWBEiiSgk+l1PxXZ20bYzL/lqbvk2U /vxM4vG+Pf2BZ9oug9pDtfEKaimZmV7HMB8ckjJXZNtl7E2EcELPxE+ghW9RfOTHxqgl y4sw== X-Received: by 10.204.191.72 with SMTP id dl8mr1159614bkb.56.1371738618181; Thu, 20 Jun 2013 07:30:18 -0700 (PDT) Received: from [10.87.16.152] ([88.128.80.4]) by mx.google.com with ESMTPSA id lb14sm330051bkb.6.2013.06.20.07.29.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 07:30:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> Date: Thu, 20 Jun 2013 16:29:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <617B4914-32B7-4CD9-9653-9E5FDFEA2837@inf-net.nl> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkIP7ie/TTb9Cnlj7+KPuy/vQcsv9tVxI+dSH/Zwn823ay5uaFevG0qDvmcn05bEWlIfQix Cc: Michael Richardson , Steven Barth , Mikael Abrahamsson , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 14:30:20 -0000 Op 20 jun. 2013, om 15:01 heeft Ted Lemon het = volgende geschreven: >=20 > The correct way to do PD in a homenet, if you want to do PD, is to = have a single router doing delegation, and all the other routers on the = network relaying to that router if they are not directly connected to a = link to which that router is also connected.=20 Better: a single router doing delegation for a prefix_delegated_by_ISP. = In practice, it would be the router with the link to the ISP. Teco= From mellon@fugue.com Thu Jun 20 07:37:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F8421F9CF6 for ; Thu, 20 Jun 2013 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLU6uN2sM279 for ; Thu, 20 Jun 2013 07:37:19 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E0CF421F9CE8 for ; Thu, 20 Jun 2013 07:37:19 -0700 (PDT) Received: from [IPv6:2001:470:88a3::1188:c7d7:f03e:45e5] (unknown [IPv6:2001:470:88a3:0:1188:c7d7:f03e:45e5]) by toccata.fugue.com (Postfix) with ESMTPSA id 9EB7623808CB; Thu, 20 Jun 2013 10:37:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <617B4914-32B7-4CD9-9653-9E5FDFEA2837@inf-net.nl> Date: Thu, 20 Jun 2013 10:37:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66F880AE-C0E0-4D55-99EE-B61204D113E1@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> <617B4914-32B7-4CD9-9653-9E5FDFEA2837@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1508) Cc: Michael Richardson , Steven Barth , Juliusz Chroboczek , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 14:37:25 -0000 On Jun 20, 2013, at 10:29 AM, Teco Boot wrote: > Op 20 jun. 2013, om 15:01 heeft Ted Lemon het = volgende geschreven: >>=20 >> The correct way to do PD in a homenet, if you want to do PD, is to = have a single router doing delegation, and all the other routers on the = network relaying to that router if they are not directly connected to a = link to which that router is also connected.=20 >=20 > Better: a single router doing delegation for a = prefix_delegated_by_ISP. In practice, it would be the router with the = link to the ISP. I don't see a difference between what you said and what I said, so I = think we are in violent agreement. If you were trying to say something = different than what you understood me to be saying, could you try again? = :} From ot@cisco.com Thu Jun 20 07:43:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFC421F9C6C for ; Thu, 20 Jun 2013 07:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqZROzTu13Pu for ; Thu, 20 Jun 2013 07:43:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 91DDD21F9C59 for ; Thu, 20 Jun 2013 07:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1318; q=dns/txt; s=iport; t=1371739411; x=1372949011; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=beSsp4mGD2CnM8CbsjHP2dbOmm45kIb/QKsny8p6bkE=; b=LMQkggQ4+tWGzWkgC8snUtR+u7OMX1GfRE6rQ4t9hczf/ejhOSGi/Amb TDxbVJaqM6TrB/Va5Vm1e3MCBZJwfuqYPrOV/nfCXNojNyqWN/zEzvNAN y9+ATlmCyGVFt1ifSa4B10DYdBbOwU1bwCbnYCCfPj46VbGsoodLoLbpf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAFABcUw1GQ/khM/2dsb2JhbABbgwnAJHwWdIIjAQEBAwE6PxALDjhXBogbBrttjw8zB4MAYQOXQZFEgxE6 X-IronPort-AV: E=Sophos;i="4.87,905,1363132800"; d="scan'208";a="155574476" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2013 14:43:27 +0000 Received: from dhcp-10-61-109-218.cisco.com (dhcp-10-61-109-218.cisco.com [10.61.109.218]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5KEhOoc001454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Jun 2013 14:43:25 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <66F880AE-C0E0-4D55-99EE-B61204D113E1@fugue.com> Date: Thu, 20 Jun 2013 16:43:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C124E68-069A-4C43-A1EB-51DC5FA09D85@cisco.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> <617B4914-32B7-4CD9-9653-9E5FDFEA2837@inf-net.nl> <66F880AE-C0E0-4D55-99EE-B61204D113E1@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: Teco Boot , Juliusz Chroboczek , Michael Richardson , Steven Barth , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 14:43:37 -0000 >>> The correct way to do PD in a homenet, if you want to do PD, is to = have a single router doing delegation, and all the other routers on the = network relaying to that router if they are not directly connected to a = link to which that router is also connected.=20 >>=20 >> Better: a single router doing delegation for a = prefix_delegated_by_ISP. In practice, it would be the router with the = link to the ISP. >=20 > I don't see a difference between what you said and what I said, so I = think we are in violent agreement. If you were trying to say something = different than what you understood me to be saying, could you try again? = :} Teco's case you would have multiple routers delegated prefixes, one for = each ISP in the multi-homed case. if I understand your suggestion correctly, you would have one router = elected to do the delegation. you'd still need to build a spanning tree of DHCP relays in the network. = and preferably you'd need to integrate the PD server with the routing protocol topology database to avoid = duplicate assignments on shared links. in Teco's case DHCP has to be changed to deal with multiple sources of = information. in your case you'd need some sort of protocol between edge = routers to collate the information to delegate. cheers, Ole= From mbaugher@cisco.com Thu Jun 20 08:02:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8959021F9D9F for ; Thu, 20 Jun 2013 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KcESZN9tqw7 for ; Thu, 20 Jun 2013 08:01:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 150D221F9A86 for ; Thu, 20 Jun 2013 08:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1662; q=dns/txt; s=iport; t=1371740487; x=1372950087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JDLHy3kocdMbinUhgltt+stv+ISEwsX9duThqsvz2kY=; b=J8KCnoA00IT7WXqwCDeiMRt/PyAvUDdmW8AD3xc45pXwc80iX4QiDQOV inTrIF5H3JVGmQ9zeTgGQEvUefxl2ZLHoHcOOyAuRVunQJ8Ek2CaXqf1r bdN6p2Srwf8OGT8perfj6VvgD8fzPkUYhmqiRX/UibZgwDyd9qDs+yvN+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIEYw1GtJXHB/2dsb2JhbABbgwl6vzZ8FnSCIwEBAQMBHR0/BQsCAQgOCgoUEDIlAgQOBQiIAAa7co4HgQ8CMQeDAGEDqQeDD4FxNw X-IronPort-AV: E=Sophos;i="4.87,905,1363132800"; d="scan'208";a="225366104" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jun 2013 15:01:07 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5KF16Zb001844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 15:01:06 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 10:01:06 -0500 From: "Mark Baugher (mbaugher)" To: Mikael Abrahamsson Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk5v7CAgAB0toCAAAbSgIAAASeAgAACkQCAAg9EgIAAENoAgAAHLACAALjiAP//+XGAgACzQ4CAAIF+AIAA078A Date: Thu, 20 Jun 2013 15:01:06 +0000 Message-ID: <9C2FF8548CD17F4AB32FC8B311470DFA15284B5D@xmb-aln-x10.cisco.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <9C2FF8548CD17F4AB32FC8B311470DFA15282ABB@xmb-aln-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.24.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <9F2393122373E44395BE4FB270984C0D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:02:05 -0000 On Jun 19, 2013, at 7:23 PM, Mikael Abrahamsson wrote: > On Wed, 19 Jun 2013, Mark Baugher (mbaugher) wrote: >=20 >> And some where it is not: A security service might not place sensors or = actuators on the common home LAN owing to common threats like malware, visi= tors, etc. This is a routable homenet use case. >=20 > Hm, I don't know if I'm misunderstanding you, but just to be clear, I am = very much *pro* a routed home and this is what I am advocating for. Sorry, I am agreeing with you and adding that there are some use cases wher= e apps are sensitive to topology, like home security. >=20 > But anyhow, isn't the correct approach for a sensor manufacturer to make = sure only devices authorized to talk to it, can talk to it? By means of usi= ng IPSEC or similar mechanism? Then again, I realise a sensors isn't in a g= reat position to handle a few megabits of small packets from Internet. I have seen retail home monitoring applications that plug into the home LAN= . Layer 3-7 security could be added and probably should be, but it would b= e better not to have critical flows on the common home network. >=20 > Can perhaps something like 802.1x be used to be placed the device into di= fferent vlans and/or different secured routing domains within the home (or = a configurable firewall policy in the homenet router depending on some crit= eria that is configurable). I need to think about this, it's an interesting= question. Yes, but we are not longer in the auto-configured, DIY case for home servic= es. Mark >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From mellon@fugue.com Thu Jun 20 09:33:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8AA21F9CE9 for ; Thu, 20 Jun 2013 09:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJCT9lSySTIS for ; Thu, 20 Jun 2013 09:33:01 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2AED821F9D01 for ; Thu, 20 Jun 2013 09:33:01 -0700 (PDT) Received: from [IPv6:2001:470:88a3::1188:c7d7:f03e:45e5] (unknown [IPv6:2001:470:88a3:0:1188:c7d7:f03e:45e5]) by toccata.fugue.com (Postfix) with ESMTPSA id A865023808CB; Thu, 20 Jun 2013 12:32:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <7C124E68-069A-4C43-A1EB-51DC5FA09D85@cisco.com> Date: Thu, 20 Jun 2013 12:32:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> <617B4914-32B7-4CD9-9653-9E5FDFEA2837@inf-net.nl> <66F880AE-C0E0-4D55-99EE-B61204D113E1@fugue.com> <7C124E68-069A-4C43-A1EB-51DC5FA09D85@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1508) Cc: Teco Boot , Juliusz Chroboczek , Michael Richardson , Steven Barth , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:33:06 -0000 On Jun 20, 2013, at 10:43 AM, Ole Troan wrote: > Teco's case you would have multiple routers delegated prefixes, one = for each ISP in the multi-homed case. > if I understand your suggestion correctly, you would have one router = elected to do the delegation. No, I meant the same thing. From lorenzo@google.com Thu Jun 20 09:40:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357FF21F9EB0 for ; Thu, 20 Jun 2013 09:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynGupvFur7Ly for ; Thu, 20 Jun 2013 09:40:04 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6B52321F9EA2 for ; Thu, 20 Jun 2013 09:40:04 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id jw11so5262462veb.32 for ; Thu, 20 Jun 2013 09:40:03 -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=ilLO89amCbqQgb4CbDkiRDBKqPlHAbxrMZVcCakqAew=; b=IrcNGIGtHN3oq+CT9Fj5VgE0cvzLHqJFb8e8bj5LXCKqz0k6J7L3MDRLGZBBhNVnwv m/Raxzhofg4Rqu3ERGkRNs5BtjPjVjmXnW4LodaTslpPz/JNVZOYDvTMbQq7LScJ5LOH bbEbx8/XqqBFQLNY24hISg0sffF7nuH9R8/tRfMc27I1UlBJEssxDk/CLcYoOm676oM6 wXykBbXrXKZ6smUcbRPEuKsuMB7zhSelfcWj7lc9ce2GxX3BztFT5Afpbq+psPJUqDsx Ih8SPBuV1iPYgii+jQ36dbLVQkFKTQOpu/ERl6LytKk5FZKy/qp3BD0mVYMfu3A2uy+I hhFQ== X-Google-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:x-gm-message-state; bh=ilLO89amCbqQgb4CbDkiRDBKqPlHAbxrMZVcCakqAew=; b=NA0GsSB++hWYemvCv/vIvkFLTX9YHmU6bpqsJKuLrVUMe6C237WculhmtHLzEJioEz N89NIDQfAECbrx6dmsZIELysTHCFcrG7DgRP1L7RPCDv693OorYsJVH6nU7i/KWmD6G4 L7gDTCQPdREixdLyFFcwBHninug4WEIKeHlg1koIz0bFYkseG/GcBrM19sxQ7jz9/+Pt 1xGkK/L3bam9Dm25WW8xjFURz5TrwSaeGxY+dr4eDWEn3ZIjgAwnKkgKQzzcSazK/F8o mdzmhX9QehJvL4klQmlsnpRmUnzJtIocYMbY/y98bpyi/Id9kpPjRY6ZcoHa6iFMbhiA zmFg== X-Received: by 10.58.76.34 with SMTP id h2mr3477981vew.93.1371746403706; Thu, 20 Jun 2013 09:40:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.172.66 with HTTP; Thu, 20 Jun 2013 09:39:43 -0700 (PDT) In-Reply-To: <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> From: Lorenzo Colitti Date: Thu, 20 Jun 2013 09:39:43 -0700 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b3437e41d979204df98995b X-Gm-Message-State: ALoCoQkvVkGdMcg6XkOnHsvpc36BFefS+0CbHjEIfxS3eVgEXgREn3nalUFQukkQDdy0IZLwfEBiCA4jwVq0hlAykMKVcDfowS7fwpGhZ8pq4ZfNQKaLc06w/kMy0rrG9R8qgcta4GjwA3O86kPdXcAzxrO1MrzIIRrxDJbJWGQzDHnQYDfTq34MeEvwjErkVLdcICHmNhZo Cc: Michael Richardson , Steven Barth , Mikael Abrahamsson , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:40:06 -0000 --047d7b3437e41d979204df98995b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 6:01 AM, Ted Lemon wrote: > The correct way to do PD in a homenet > There is no correct way to do PD in a homenet if you want to be able to change the topology. Specifically, if the One Router acting as a DHCPv6 server is unplugged or crashes, everything breaks. --047d7b3437e41d979204df98995b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 20, 2013 at 6:01 AM, Ted Lemon <mellon@fugue.c= om> wrote:
The correct way to do= PD in a homenet

There i= s no correct way to do PD in a homenet if you want to be able to change the= topology. Specifically, if the One Router acting as a DHCPv6 server is unp= lugged or crashes, everything breaks.=A0
--047d7b3437e41d979204df98995b-- From mike@mtcc.com Thu Jun 20 12:35:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F1111E8127 for ; Thu, 20 Jun 2013 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTlhVzmyBulH for ; Thu, 20 Jun 2013 12:35:25 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id AA7F711E8124 for ; Thu, 20 Jun 2013 12:35:25 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5KJYnwI010063 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 12:34:50 -0700 Message-ID: <51C35959.30307@mtcc.com> Date: Thu, 20 Jun 2013 12:34:49 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Tim Chown References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> <3307C836-FBDE-4EE9-BEA4-94726BF94BC0@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=418; t=1371756890; x=1372620890; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Tim=20Chown=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=U/+wxfrLdjlUPYYuESKO9KK0FVbaZjcckcjr5+qpSXE=; b=gtx/pWKlhSC9xTDDLc0KL3S6v4dobEFREEubsNo9UbmwyRTeH458qDN2QY XjicJ/Dj2amrF+ekxskSJ9iFhi19xA/1B+DfY/QK7amOFYDWx2NUo5cuH3Mu fVT3JrHMOmRlh8vh7LZoE+t/OB64fVmrJpN5RVu6YKOYyNZfyS5a8=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:35:30 -0000 On 06/18/2013 03:57 PM, Tim Chown wrote: > - the firewall text appears appropriate, though some could be pruned without changing the tone/balance > Wait a minute: it is an extraordinary claim that the current practice of putting hosts on home network behind firewalls is obsolete. There needs to be justification for that claim and I haven't heard it here, and it most certainly isn't in the document. Mike From mbaugher@cisco.com Thu Jun 20 12:51:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0283421F9D48 for ; Thu, 20 Jun 2013 12:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0+Q5TJjzttx for ; Thu, 20 Jun 2013 12:50:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B122121E804D for ; Thu, 20 Jun 2013 12:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=880; q=dns/txt; s=iport; t=1371757844; x=1372967444; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=U5qKi88P2kkr2TtKPJxeBTOovk8nD5g+WPHQMS4af0U=; b=H/Z3iNeFlfl0CRySO/eUL3Q0dTZeLWViwQZ4FWlkvaa3gqzZzZq5tAcW OmlERspFqqHSefY7i5StCZj+4GRjE142g/0QqhaBTfZPOzGyNdFFZUoYj pc4E3Uejsaz+GEbA1+3mnqDW+2+BU17wto6oMjzMcrSoQeAPG/YNUE3Rk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAIFcw1GtJXHA/2dsb2JhbABbgwkxSYI8vHp+FnSCIwEBAQMBAQEBCw8dKwkLBQsCAQgOCgoUECcLJQIEDgUIiAAGDLwnBI8WAjEHgwBhA6kHgw+CKA X-IronPort-AV: E=Sophos;i="4.87,907,1363132800"; d="scan'208";a="225563067" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jun 2013 19:50:43 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5KJohr2016779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 19:50:43 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 14:50:43 -0500 From: "Mark Baugher (mbaugher)" To: Michael Thomas Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk5v7CAgAB0toCAAAbSgIAAASeAgAACkQCAAg9EgIAAENoAgAAOqoCAAAEZgIAAEpeAgALsH4CAAARwAA== Date: Thu, 20 Jun 2013 19:50:42 +0000 Message-ID: <9C2FF8548CD17F4AB32FC8B311470DFA15285419@xmb-aln-x10.cisco.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> <3307C836-FBDE-4EE9-BEA4-94726BF94BC0@ecs.soton.ac.uk> <51C35959.30307@mtcc.com> In-Reply-To: <51C35959.30307@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.24.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <5EE02B2DAAC83C4E882628539AC79AAE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:51:12 -0000 On Jun 20, 2013, at 12:34 PM, Michael Thomas wrote: > On 06/18/2013 03:57 PM, Tim Chown wrote: >> - the firewall text appears appropriate, though some could be pruned wit= hout changing the tone/balance >>=20 >=20 > Wait a minute: it is an extraordinary claim that the current practice of = putting > hosts on home network behind firewalls is obsolete. Here's what the I-D says: "The use of firewalls today, whether a good pract= ice or not, is common practice and whatever protection afforded, even if ma= rginally effective, should not be lost." Mark > There needs to be justification > for that claim and I haven't heard it here, and it most certainly isn't i= n the document. >=20 > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Thu Jun 20 12:59:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA9D11E8114 for ; Thu, 20 Jun 2013 12:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch8BWaMawTMS for ; Thu, 20 Jun 2013 12:59:02 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2339811E80A5 for ; Thu, 20 Jun 2013 12:59:02 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5KJwUfx017990 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 12:58:31 -0700 Message-ID: <51C35EE6.70503@mtcc.com> Date: Thu, 20 Jun 2013 12:58:30 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "Mark Baugher (mbaugher)" References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> <3307C836-FBDE-4EE9-BEA4-94726BF94BC0@ecs.soton.ac.uk> <51C35959.30307@mtcc.com> <9C2FF8548CD17F4AB32FC8B311470DFA15285419@xmb-aln-x10.cisco.com> In-Reply-To: <9C2FF8548CD17F4AB32FC8B311470DFA15285419@xmb-aln-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1053; t=1371758311; x=1372622311; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20=22Mark=20Baugher=20(mbaugher)=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ESfLFltA6lLHHcJ5Wwx7ENjnbCPu6s/4gGEvNzZ3jRk=; b=rmLf646rMYvxUgW32qSxaKqczCWkbejXxPAJhs5Z5jeRgxk3RNKCnGDREv NHPokG6m8veukyJh2QyrKvi/wbW5h6miF7x3Kq8lLCoDpGUwFZiDpi0+QY2V bqyo67qyDVPbuofIBe9C3ScoAPOUTrlwwGKg/9Y7N/ZZZm+7tUG8o=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:59:11 -0000 On 06/20/2013 12:50 PM, Mark Baugher (mbaugher) wrote: > On Jun 20, 2013, at 12:34 PM, Michael Thomas > wrote: > >> On 06/18/2013 03:57 PM, Tim Chown wrote: >>> - the firewall text appears appropriate, though some could be pruned without changing the tone/balance >>> >> Wait a minute: it is an extraordinary claim that the current practice of putting >> hosts on home network behind firewalls is obsolete. > Here's what the I-D says: "The use of firewalls today, whether a good practice or not, is common practice and whatever protection afforded, even if marginally effective, should not be lost." > Ok, it's the wording that's extremely awkward. This entire section should just be deleted because it's not furthering any goal, and seems to just be editorializing somebody's distaste for firewalls without actually saying something needs to be done. If it's not deleted it should just say: "homenet arch recommends that the current practice of putting firewalls on CPE remain." and leave it at that. Mike From brian.e.carpenter@gmail.com Thu Jun 20 13:20:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2A21E80EB for ; Thu, 20 Jun 2013 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQD1rWWmTh1L for ; Thu, 20 Jun 2013 13:20:36 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BB90221E80EA for ; Thu, 20 Jun 2013 13:20:36 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so6703680pab.34 for ; Thu, 20 Jun 2013 13:20:36 -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=qE12ppJeLs2cKW9Fqw/JvJzFx0VUpJnrVZRrIKCDqHw=; b=cfIy4XgxadbBgcPPItzS/ugtbrSEDUN3+y0W2MsC6qSf7rdzIXNZfN9cJzFsZrpenT hmqsr/8S9bceAzggAew58aMBsTTc72duiuZgfltverkCsVwqSG3wdw/EPHHUqiGXO+64 h5XyEAE6JPNeisihIzDDTUBxD+rQr/mI9xXYvyio2xRYDEGrIG8BGOM+pSgslBeN6CCZ Fo6pLtNKixyOb9DSneoTlw6IbEpWgQlIqNUuQxVGopVvn/SOYmzvJ969tp+5TQFIC1q/ TZ3/kAKF4Y6nM8+GCbFKhfeG9JjzDqzsO4CiyHeCResAn/26F/7/IkaX+KTolEMyoLy5 k03Q== X-Received: by 10.68.169.97 with SMTP id ad1mr7873823pbc.84.1371759636444; Thu, 20 Jun 2013 13:20:36 -0700 (PDT) Received: from [192.168.178.20] (36.200.69.111.dynamic.snap.net.nz. [111.69.200.36]) by mx.google.com with ESMTPSA id pe9sm1506070pbc.35.2013.06.20.13.20.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 13:20:35 -0700 (PDT) Message-ID: <51C3641B.3050102@gmail.com> Date: Fri, 21 Jun 2013 08:20:43 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> <3307C836-FBDE-4EE9-BEA4-94726BF94BC0@ecs.soton.ac.uk> <51C35959.30307@mtcc.com> <9C2FF8548CD17F4AB32FC8B311470DFA15285419@xmb-aln-x10.cisco.com> <51C35EE6.70503@mtcc.com> In-Reply-To: <51C35EE6.70503@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , "homenet@ietf.org Group" , "Mark Baugher \(mbaugher\)" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:20:37 -0000 On 21/06/2013 07:58, Michael Thomas wrote: > "homenet arch recommends that the current practice of putting firewalls > on CPE remain." > > and leave it at that. The problem with that is that in IPv4 homenets, many people equate "firewall" with "NAT" and we don't want that to carry over. Also there is a whole other discussion that we surely don't want in *this* draft about the best split in firewall functions between perimeter defence and individual host defences. Something like "Clearly all hosts in a homenet must be adequately protected by built-in security functions, but it is also assumed that all CPEs will continue to provide appropriate perimeter defence functions [rfc6204bis]." Brian From mike@mtcc.com Thu Jun 20 13:23:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D394A21F9E06 for ; Thu, 20 Jun 2013 13:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnFpLXvigRYL for ; Thu, 20 Jun 2013 13:23:37 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1765D21F9E99 for ; Thu, 20 Jun 2013 13:23:37 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5KKMq1W026206 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 13:22:52 -0700 Message-ID: <51C3649C.8040704@mtcc.com> Date: Thu, 20 Jun 2013 13:22:52 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <87vc5b2it8.wl%jch@pps.univ-paris-diderot.fr> <87ehbzccls.wl%jch@pps.univ-paris-diderot.fr> <3307C836-FBDE-4EE9-BEA4-94726BF94BC0@ecs.soton.ac.uk> <51C35959.30307@mtcc.com> <9C2FF8548CD17F4AB32FC8B311470DFA15285419@xmb-aln-x10.cisco.com> <51C35EE6.70503@mtcc.com> <51C3641B.3050102@gmail.com> In-Reply-To: <51C3641B.3050102@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=831; t=1371759772; x=1372623772; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Brian=20E=20Carpenter=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=rfg6WK3eU5fjQg037B7W01S/bOBrlL0/OZ5tirtp7AI=; b=QvCcmTtuY3OOOpsdYdpR1oJ+Vtf+1docpojmQDRJ+ITlWZ+aj1F3Tjo2TW 5KqdYt9ghZDruFXReGHoz5bpewxG+P98/Z6gE23Kk5K6lmChx/uyV3fZDZZb LFmVQU0HQjPnoPvV/de1HyZQnzUKbsH7wwMRxrO4wXbxu6q6xbotI=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Tim Chown , "homenet@ietf.org Group" , "Mark Baugher \(mbaugher\)" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:23:48 -0000 On 06/20/2013 01:20 PM, Brian E Carpenter wrote: > On 21/06/2013 07:58, Michael Thomas wrote: > >> "homenet arch recommends that the current practice of putting firewalls >> on CPE remain." >> >> and leave it at that. > The problem with that is that in IPv4 homenets, many people equate > "firewall" with "NAT" and we don't want that to carry over. > > Also there is a whole other discussion that we surely don't want in > *this* draft about the best split in firewall functions between > perimeter defence and individual host defences. > > Something like > > "Clearly all hosts in a homenet must be adequately protected by > built-in security functions, but it is also assumed that all CPEs > will continue to provide appropriate perimeter defence functions > [rfc6204bis]." > That works for me. Mike From jch@pps.univ-paris-diderot.fr Thu Jun 20 15:38:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B5B21E80B9 for ; Thu, 20 Jun 2013 15:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBIkcLY6UfT0 for ; Thu, 20 Jun 2013 15:38:40 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1BD11E80E1 for ; Thu, 20 Jun 2013 15:38:39 -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/38117) with ESMTP id r5KMcahr016747; Fri, 21 Jun 2013 00:38:36 +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 82E0A4EBB9; Fri, 21 Jun 2013 00:38:36 +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 tQRVmN4Fpcor; Fri, 21 Jun 2013 00:38:35 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 72E084EBB4; Fri, 21 Jun 2013 00:38:35 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UpnUx-00011V-2F; Fri, 21 Jun 2013 00:38:35 +0200 Date: Fri, 21 Jun 2013 00:38:35 +0200 Message-ID: <87zjuk8l1w.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Steven Barth In-Reply-To: <51C17D0F.8090709@openwrt.org> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> <51C17D0F.8090709@openwrt.org> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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]); Fri, 21 Jun 2013 00:38:36 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:38:46 -0000 > They usually use cheap routers with limited resources. Steven, The following is run on a WNDR3700v2, which cost €70 when we bought it. It is running babeld, ahcpd, the OpenWRT web interface, OpenVPN, the full NTP daemon, and is streaming topology data to a remote BabelWeb instance: root@omicron:~# free total used free shared buffers Mem: 61708 24152 37556 0 0 -/+ buffers: 24152 37556 Swap: 0 0 0 root@omicron:~# df -h / Filesystem Size Used Available Use% Mounted on rootfs 14.6M 5.5M 9.0M 38% / root@omicron:~# uptime 00:26:18 up 9 days, 10:13, load average: 0.00, 0.03, 0.04 As you can see, resource limitations are simply not an issue any more, even in fairly cheap routers. -- Juliusz From jch@pps.univ-paris-diderot.fr Thu Jun 20 15:54:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C70721E80C0 for ; Thu, 20 Jun 2013 15:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJZ6lSQxVhHg for ; Thu, 20 Jun 2013 15:54:40 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD3B21E80A9 for ; Thu, 20 Jun 2013 15:54:39 -0700 (PDT) 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/38117) with ESMTP id r5KMsRjt009184; Fri, 21 Jun 2013 00:54:28 +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 AE8684EBB9; Fri, 21 Jun 2013 00:54:27 +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 AUr531cFDNiR; Fri, 21 Jun 2013 00:54:26 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9F17D4EBB4; Fri, 21 Jun 2013 00:54:26 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UpnkI-00011k-8I; Fri, 21 Jun 2013 00:54:26 +0200 Date: Fri, 21 Jun 2013 00:54:26 +0200 Message-ID: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ole Troan In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 21 Jun 2013 00:54:28 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:54:48 -0000 I don't see any mention of the need to handle topologies with links of widely varying speed (except for the incidental mention in 3.2.3). A typical home network grows organically, and combines different generations of technlogies. In a typical home today, you'll find Gigabit Ethernet as well as the 1Mbit/s wifi link to the shack in the garden. That's four orders of magnitude difference, and I expect this difference to get worse with time. This has some important consequences, notably the fact that it's possibly hazardous to implement multicast by flooding. -- Juliusz From jch@pps.univ-paris-diderot.fr Thu Jun 20 16:24:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB3E21E80AD for ; Thu, 20 Jun 2013 16:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q49BkOT7q0ei for ; Thu, 20 Jun 2013 16:24:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 25B2321E80D4 for ; Thu, 20 Jun 2013 16:24:41 -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/38117) with ESMTP id r5KNOcKG024858; Fri, 21 Jun 2013 01:24:38 +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 873694EBC2; Fri, 21 Jun 2013 01:24:38 +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 7twLEXvCqI4k; Fri, 21 Jun 2013 01:24:37 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7CDB14EBC1; Fri, 21 Jun 2013 01:24:37 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UpoDV-00013Z-3E; Fri, 21 Jun 2013 01:24:37 +0200 Date: Fri, 21 Jun 2013 01:24:37 +0200 Message-ID: <87li648ix6.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Steven Barth In-Reply-To: <51C16A12.3030205@openwrt.org> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 21 Jun 2013 01:24:38 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 23:24:48 -0000 > However a whole separate OSPF or so daemon + routing stack with 100s > of KB and all the inherent logic just for a few very advanced > usecases? $ size babeld text data bss dec hex filename 82262 1288 1408 84958 14bde babeld $ ps l $(cat /var/run/babeld.pid) F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 5 0 5953 1 20 0 8396 576 poll_s Ss ? 0:19 babeld -D - That's 50 kB of flash (after compression) and half a meg of RAM. I'm pretty sure a well-done implementation of OSPFv3 can be within an order of magnitude of that. -- Juliusz From mcr@sandelman.ca Thu Jun 20 17:10:35 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8EC21E80E2 for ; Thu, 20 Jun 2013 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJkDp6GMNXrm for ; Thu, 20 Jun 2013 17:10:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id D05C621E80E1 for ; Thu, 20 Jun 2013 17:10:30 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C68020261 for ; Thu, 20 Jun 2013 21:14:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E6DD4A9028; Thu, 20 Jun 2013 20:09:28 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CFF66B9081 for ; Thu, 20 Jun 2013 20:09:28 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org Group" In-Reply-To: <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.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 Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 00:10:35 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Juliusz Chroboczek wrote: sb> this is also what chained DHCPv6-PD / a hipnet-like solution can do. mcr> It can not deal with loops: I see them regularly in people's small mcr> offices, and given wifi, it's really easy even for experts to crea= te. juliusz> Could you please explain that? juliusz> I was under the impression that a prefix subdelegation is alwa= ys juliusz> for a longer prefix than the one it was delegated from, so at juliusz> each hop the prefix gets longer. A loop would imply that a juliusz> prefix is strictly longer than itself. Given the scenario: ISP1 ISP2 \ / CPE1 CPE2___ \ / \ ~~~~~~~ wifi \WIRE | | CPE3 | | | \------------ PD will have CPE3 get a prefix from...? CPE1? CPE2 (via WIFI) and CPE3 (via= wired). If you look at the wires, it looks like CPE3 is simply plugged into CPE2. B= ut the wires you can't see help too. Why did you buy CPE3?=20=20 Well, how about so that you'd have wifi coverage in the upstairs. (CPE3 can easily see CPE2 and CPE1, but a tablet in your bed can't) In order for CableLabsHome to be augmented to support multiple ISPs, CPE3 h= as to get PDs from all possible "uplinks".=20=20=20 Should CPE1 now also ask for a prefix (from ISP2) from CPE3, which now looks like an uplink to it as well. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcOZtIqHRg3pndX9AQIkmwQAg/h046DCgSiWMMhPT3nvZMI7apQP+/A0 U5szpSVI0vOEAUCxhd8xTkLrH2AJKpIxJkxoOk58r5VST1+vm+eOqSMJ3k3Z8HAe xQQndbSg98aD9bDiQhIoulLT3rdct0qK0saXCe2HKtHGd6hG4uTOGKAnyMpnaXA0 yyr4mDb36ts= =GXVD -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Jun 20 17:13:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DEA21E80E6 for ; Thu, 20 Jun 2013 17:13:49 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLeYD1oMAQ3R for ; Thu, 20 Jun 2013 17:13:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3D621E80E5 for ; Thu, 20 Jun 2013 17:13:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 591C420261 for ; Thu, 20 Jun 2013 21:17:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9EBC8A9028; Thu, 20 Jun 2013 20:12:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 84CC4B9081 for ; Thu, 20 Jun 2013 20:12:46 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org Group" In-Reply-To: <9C2FF8548CD17F4AB32FC8B311470DFA15282ABB@xmb-aln-x10.cisco.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <9C2FF8548CD17F4AB32FC8B311470DFA15282ABB@xmb-aln-x10.cisco.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 Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 00:13:49 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Mark Baugher (mbaugher) wrote: >> There are a lot of use-cases where it would be beneficial to have >> things work well regardless of topology for devices being connected. > And some where it is not: A security service might not place sensors = or > actuators on the common home LAN owing to common threats like malware, > visitors, etc. This is a routable homenet use case. You don't need to invoke malware... 1) The sensor network doesn't have the bandwidth to support the amount of multicast traffic that occurs on the LAN. 2) the sensor network was created before the home owner bought the home, and signed up for an ISP. ... =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcOafIqHRg3pndX9AQKzLwP/ej7c1JK5rO9DbmHqNv5wT74miCQt11Pw tAhdSK2tk2XdCnYzuHUYRahX6CkjYhqvgX+pWZbvuyQ6C+S4bspTPgULrgytMvBC K3/j8F5pr6SUTooQbGLFrHjkrzhk7E1KqkOb7dYuLvlVg6KUVYu4dLZcln20VvlC bfqzj+IHdP0= =GNLp -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Thu Jun 20 17:31:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27C221F9B07 for ; Thu, 20 Jun 2013 17:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+X1otpiQ9j1 for ; Thu, 20 Jun 2013 17:31:17 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id DCA8621F99CE for ; Thu, 20 Jun 2013 17:31:16 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d9e6:651c:7692:a716] (unknown [IPv6:2001:470:88a3:0:d9e6:651c:7692:a716]) by toccata.fugue.com (Postfix) with ESMTPSA id D89FD23808CB; Thu, 20 Jun 2013 20:31:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <31343.1371773368@sandelman.ca> Date: Thu, 20 Jun 2013 20:17:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66BD076D-D8BC-4F30-8DCD-44095D1475E5@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <31343.1371773368@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 00:31:23 -0000 On Jun 20, 2013, at 8:09 PM, Michael Richardson = wrote: > Should CPE1 now also ask for a prefix (from ISP2) from CPE3, which now = looks > like an uplink to it as well. Yes. From mike@mtcc.com Thu Jun 20 17:37:17 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FA811E8136 for ; Thu, 20 Jun 2013 17:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPAhVJ+3Epmv for ; Thu, 20 Jun 2013 17:37:12 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id AF84411E8132 for ; Thu, 20 Jun 2013 17:37:12 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5L0bAK8014117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 17:37:11 -0700 Message-ID: <51C3A036.2040200@mtcc.com> Date: Thu, 20 Jun 2013 17:37:10 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <6A0D8953-A9F9-4B8B-AF02-E206B705A86A@employees.org> <51C17D0F.8090709@openwrt.org> <87zjuk8l1w.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87zjuk8l1w.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1405; t=1371775032; x=1372639032; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=202nd=20Working=20Group=20Las t=20Call=20for=20draft-homenet-arch |Sender:=20 |To:=20Juliusz=20Chroboczek=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=Q+faG+bpf4sbxJPUU95UBxhbIQKtrLOhhy8m+q6R42U=; b=AX36hgP/y7BK7wDmnlFEa/QBbRSZcBsTqAAurh3BMwIRF6O65Lla7WGpg7 0tQbNQQIcwwMRJBc6fYFyZqsOZ6Kwbz8RMSHZWHPpSWOcPZ48mhRNR5liAZH W0WJ0I7/tfatHwH+wCFjCYHJWbfd7pgqTc+vEbEFo7J4WqQxNrjQs=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Steven Barth , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 00:37:17 -0000 On 06/20/2013 03:38 PM, Juliusz Chroboczek wrote: >> They usually use cheap routers with limited resources. > Steven, > > The following is run on a WNDR3700v2, which cost €70 when we bought > it. It is running babeld, ahcpd, the OpenWRT web interface, OpenVPN, > the full NTP daemon, and is streaming topology data to a remote > BabelWeb instance: > > root@omicron:~# free > total used free shared buffers > Mem: 61708 24152 37556 0 0 > -/+ buffers: 24152 37556 > Swap: 0 0 0 > root@omicron:~# df -h / > Filesystem Size Used Available Use% Mounted on > rootfs 14.6M 5.5M 9.0M 38% / > root@omicron:~# uptime > 00:26:18 up 9 days, 10:13, load average: 0.00, 0.03, 0.04 > > As you can see, resource limitations are simply not an issue any more, > even in fairly cheap routers. > I think probably too many of us here were traumatized by the bad old days when we were sneered at for wasting a whole 128kb of ram. What I really want is my router(s) to be the always-on-therefore-lets-make-use-of-it hub for my house that does all kinds of other non-routing related chores. In fact, I want it to look like this: http://headlessandroid.blogspot.com/ Mike From john_leddy@cable.comcast.com Thu Jun 20 18:04:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D71421F9A61 for ; Thu, 20 Jun 2013 18:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36DCzYheSCFM for ; Thu, 20 Jun 2013 18:04:53 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 28F7721F9A5E for ; Thu, 20 Jun 2013 18:04:52 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78493607; Thu, 20 Jun 2013 19:04:12 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 20 Jun 2013 21:04:50 -0400 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.141]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Thu, 20 Jun 2013 21:04:49 -0400 From: "Leddy, John" To: Michael Richardson , "homenet@ietf.org Group" Thread-Topic: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] Thread-Index: AQHObhPFG/CY4of1S0eK9OvW2VI66Jk/Wn2A Date: Fri, 21 Jun 2013 01:04:49 +0000 Message-ID: <9FB60CE5849B194190DC0CDAD4825AEC3F41F592@PACDCEXMB13.cable.comcast.com> In-Reply-To: <31343.1371773368@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <3ACC18C53BBCBF408C8A849C8D3F6C12@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 01:04:59 -0000 My personal opinion is that HipNet or PD delegation does not work in an arbitrary topology with multiple service providers. I also find it hard to believe that you can't build a tree out of a mesh infrastructure, though, yes there will be wasted connectivity. I thought this was what HomeNet was supposed to figure out? There is the issue of the normal home (getting more complex) and issues of multiple NAT's in V4. Providers are putting more services and GW boxes into homes, having them work well with CE devices would be good as more services run over them. I see HipNet as an IPV4 solution using IPV6, rather than an IPV6 solution. I'm all for HomeNet, go. My fear is that we will end up with a flat L2 home, and when HomeNet shows up, it will be a massive change to think about sub netting. There is also the thread of thought that everything goes to the "cloud", virtual CPE, which almost requires L2 flat homes. A solution to this conflict would be to include V4 into HomeNet or embrace HipNet as a transition technology. John On 6/20/13 8:09 PM, "Michael Richardson" wrote: > >Juliusz Chroboczek wrote: > sb> this is also what chained DHCPv6-PD / a hipnet-like solution can >do. > > mcr> It can not deal with loops: I see them regularly in people's >small > mcr> offices, and given wifi, it's really easy even for experts to >create. > > juliusz> Could you please explain that? > > juliusz> I was under the impression that a prefix subdelegation is >always > juliusz> for a longer prefix than the one it was delegated from, so at > juliusz> each hop the prefix gets longer. A loop would imply that a > juliusz> prefix is strictly longer than itself. > >Given the scenario: > >ISP1 ISP2 > \ / > CPE1 CPE2___ > \ / \ > ~~~~~~~ wifi \WIRE > | | > CPE3 | > | | > \------------ > > >PD will have CPE3 get a prefix from...? CPE1? CPE2 (via WIFI) and CPE3 >(via wired). >If you look at the wires, it looks like CPE3 is simply plugged into CPE2. >But >the wires you can't see help too. Why did you buy CPE3? > >Well, how about so that you'd have wifi coverage in the upstairs. >(CPE3 can easily see CPE2 and CPE1, but a tablet in your bed can't) > >In order for CableLabsHome to be augmented to support multiple ISPs, CPE3 >has >to get PDs from all possible "uplinks". > >Should CPE1 now also ask for a prefix (from ISP2) from CPE3, which now >looks >like an uplink to it as well. > >--=20 >] Never tell me the odds! | ipv6 mesh >networks [=20 >] Michael Richardson, Sandelman Software Works | network >architect [=20 >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [=20 >=09 > > > > From brian.e.carpenter@gmail.com Thu Jun 20 20:53:43 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8818021F9CA2 for ; Thu, 20 Jun 2013 20:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwaGSvwMHBJb for ; Thu, 20 Jun 2013 20:53:43 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1544321F9CA1 for ; Thu, 20 Jun 2013 20:53:43 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so7202306pad.4 for ; Thu, 20 Jun 2013 20:53:42 -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=vNNCdYooFz4wywM5hE6LYW0a/OXlTCGtpXN6xE5LB7w=; b=lBuO5ONPP6WowiW+CL+4htfJ72DSDEGGTy3y4icKAP4syjS4GBw7czhKIUvnmk+ViG EhINmemxKvnp8EZoAYtGyEYjGT7BOlbhfSK4ewdBmZ+aOkcqKdcGmup1To6Hxx22WyRL UkYE6LBXSU4kRxB5uGw7PS4UazfOJFoDWsx5ieftm07oZjNUueCGp83aSy5ddamnybH9 MxJrdcqeBP9Sb1IWnTWn7YWZcZ5D/eZnmk9uzJ/pwj0UCgUg5wUoQmKxQnc41nj2EoWO WZ7c2aUSz2NlriqfrGu2x5k4XgitELzbrabMnq8LHIPOm+QM0wCNTPQA6PXZkcwVRYD5 3CoQ== X-Received: by 10.66.251.202 with SMTP id zm10mr14436582pac.53.1371786822779; Thu, 20 Jun 2013 20:53:42 -0700 (PDT) Received: from [192.168.178.20] (36.200.69.111.dynamic.snap.net.nz. [111.69.200.36]) by mx.google.com with ESMTPSA id xn5sm3717335pab.0.2013.06.20.20.53.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 20:53:41 -0700 (PDT) Message-ID: <51C3CE4C.8010307@gmail.com> Date: Fri, 21 Jun 2013 15:53:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews References: <51C151A7.2070304@globis.net> <5706.1371652601@sandelman.ca> <51C1D145.6070200@globis.net> <51C2178F.40004@gmail.com> <20130620010117.B1B033613B86@drugs.dv.isc.org> <81AD9CE3-B508-4706-9EBB-53593FB21371@fugue.com> <20130620031532.E631F3614104@drugs.dv.isc.org> <51C274CB.4060302@gmail.com> <20130620033717.A1F0E361443C@drugs.dv.isc.org> In-Reply-To: <20130620033717.A1F0E361443C@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , Ole Troan , Ted Lemon , "homenet@ietf.org Group" , Michael Richardson Subject: [homenet] RRs for deprecated prefixes [was: draft-ietf-homenet-arch comments] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 03:53:43 -0000 On 20/06/2013 15:37, Mark Andrews wrote: > In message <51C274CB.4060302@gmail.com>, Brian E Carpenter writes: >> On 20/06/2013 15:15, Mark Andrews wrote: >> ... >>> Well for one thing you need it for address -> PTR -> AAAA checking. >> Maybe we could deprecate that check first. > > What's wrong with a sanity check? I've never believed that that's a check worth doing, since its success might be due to an accomplished fraudster (unless, I guess, DNSSEC is universal) and its failure might be due to somebody who sees no particular reason to create PTR records. >>> For a second thing you can have routing issues with one prefix and >> So why wouldn't you publish the deprecated *prefix* rather than >> a large bunch of /128s? > > Who was talking about /128's vs short prefixes? I thought you were suggesting an additional RR for every /128 in a deprecated state. It seems to me that a single RR for each prefix in a deprecated state would be more economical. (In fact I can see a positive value for it during a renumbering event, but that is a further digression.) Brian From teco@inf-net.nl Thu Jun 20 23:24:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5F311E80FE for ; Thu, 20 Jun 2013 23:24:47 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt+RYZTRqyW9 for ; Thu, 20 Jun 2013 23:24:47 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5246921F9F63 for ; Thu, 20 Jun 2013 23:24:43 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g15so4412755eak.32 for ; Thu, 20 Jun 2013 23:24:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4JRX1v58iz6pXls2ZnQKnFyh7ebyGaTRRQiN9hVVIjU=; b=WmE0z7TZEubonvI3Qm5/zcmin6673uzsgQygLpgjj/16CqavPiColnGZQuEidi7lFd HBcQHkdHygY2vP3JQsBVGT4vCmuBqINcFsTzoeimaChXukIJn1fJTvuhKt2sdqjkZsP4 kPVYGpT3MzYPGDQNzRnacxIjl1Iq+tAEBdqJc2uQkQr4iRUlLvoTvkliP0tAgMo1aeG9 vdCw0+CWkJh9ureSMbs0XiL7jzpsla8OzrcnM4oXIxrHYCBoJEUWajmp0dDM98WjhnI7 PDXCmqQrGzoH6Y1ROsobrovBzBA7UsTKxJMJ90auPZDjfyAcDSf2Fzz0lRNW9ZZMKdG4 zLtA== X-Received: by 10.15.42.129 with SMTP id u1mr10938862eev.116.1371795882584; Thu, 20 Jun 2013 23:24:42 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id n42sm5279072eeh.15.2013.06.20.23.24.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 23:24:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Fri, 21 Jun 2013 08:24:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> <617B4914-32B7-4CD9-9653-9E5FDFEA2837@inf-net.nl> <66F880AE-C0E0-4D55-99EE-B61204D113E1@fugue.com> <7C124E68-069A-4C43-A1EB-51DC5FA09D85@cisco.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQlJOh6FAET0pRuOCGJQ1d4HD+eK4sGwkl3UN+QoJltqi0IlBD5PEiFbDQpptSwElXB4Ddge Cc: Ole Troan , Juliusz Chroboczek , Michael Richardson , Steven Barth , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 06:24:47 -0000 Op 20 jun. 2013, om 18:32 heeft Ted Lemon het = volgende geschreven: > On Jun 20, 2013, at 10:43 AM, Ole Troan wrote: >> Teco's case you would have multiple routers delegated prefixes, one = for each ISP in the multi-homed case. >> if I understand your suggestion correctly, you would have one router = elected to do the delegation. >=20 > No, I meant the same thing. Great. Thanks, Teco From teco@inf-net.nl Thu Jun 20 23:43:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7435C11E80F8 for ; Thu, 20 Jun 2013 23:43:50 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndP1x1jXzPnU for ; Thu, 20 Jun 2013 23:43:50 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADDF21E808F for ; Thu, 20 Jun 2013 23:43:46 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id m14so4432826eaj.2 for ; Thu, 20 Jun 2013 23:43:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=om2cfNmz0vqnJjR+kTksg1T+USB/5SgDiTFh3IRFifc=; b=NkKnILm+Ola6EOpNRLIPnF5giPZcpaXgN33HP+C1lXCESvmQ+OxreId7K6P+S5txTg eee2AFhSHocPAXtYllk1Tymq/EB/fl2uwbAZAX3E4zBEQ8UuGj7LxHIq7dFQ1pIbG0YW cz2jjh2Cn2mFjccHTKJvsYRihfD/y87UqoOcsWaFzr0QQc1yGO5glBPVZIGyN19oc0aX aB2ToUu0vy70Yv1Qy+mPwDkiXbZmlEDWqBeGBuvohOi/hL+Z5gZIjzjbUlF0JmVaRmr9 gNTAf4QFfaoDDwLr8itCnoKeeoDrKMmhuz4Sudw496SiPjzFfSQ3wHRvINp6gxacdk7K SMJQ== X-Received: by 10.14.206.196 with SMTP id l44mr8650811eeo.142.1371797025762; Thu, 20 Jun 2013 23:43:45 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id c44sm5457209eeb.8.2013.06.20.23.43.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 23:43:44 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Fri, 21 Jun 2013 08:43:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <13C89B82-768C-4F83-A05B-63274117251A@fugue.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQlPLU1NVu2RscMRIN6jnDW9+u/DE88eJVdqgRnEheexQKJKd2mD7AIqFyZ2ffOMPVMjbn4j Cc: Juliusz Chroboczek , Michael Richardson , Ted Lemon , Steven Barth , "homenet@ietf.org Group" , Mikael Abrahamsson Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 06:43:50 -0000 Op 20 jun. 2013, om 18:39 heeft Lorenzo Colitti het = volgende geschreven: > On Thu, Jun 20, 2013 at 6:01 AM, Ted Lemon wrote: > The correct way to do PD in a homenet >=20 > There is no correct way to do PD in a homenet if you want to be able = to change the topology. Specifically, if the One Router acting as a = DHCPv6 server is unplugged or crashes, everything breaks.=20 Only the DHCPv6 service for delegated prefix for that ISP breaks. = Network should inform nodes the gateway for that prefix is down. So = almost all continues to work fine. ULA is a special case. Each ULA Global ID would be served by One Router. = I see a need for a ULA DHCP server election mechanism. A router would = stand up if no other router serving ULA is in place. Preferable a single = ULA serving router and single Global ID. If more ULA Global IDs, nothing = should break. Teco=20 From otroan@employees.org Fri Jun 21 01:10:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C22721F9EE7 for ; Fri, 21 Jun 2013 01:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76wfkt-iJfXH for ; Fri, 21 Jun 2013 01:10:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6891011E8167 for ; Fri, 21 Jun 2013 01:10:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADwJxFGQ/khN/2dsb2JhbABbgwnAL38WdIIjAQEEATo/BQsLDjhXBogbBrxQjxYzB4MAYQOpB4MROg X-IronPort-AV: E=Sophos;i="4.87,911,1363132800"; d="scan'208";a="155605346" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2013 08:10:06 +0000 Received: from dhcp-lys01-vla250-10-147-112-135.cisco.com (dhcp-lys01-vla250-10-147-112-135.cisco.com [10.147.112.135]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5L8A3bZ017247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Jun 2013 08:10:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> Date: Fri, 21 Jun 2013 10:10:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:10:29 -0000 Juliusz, > I don't see any mention of the need to handle topologies with links of > widely varying speed (except for the incidental mention in 3.2.3). >=20 > A typical home network grows organically, and combines different > generations of technlogies. In a typical home today, you'll find > Gigabit Ethernet as well as the 1Mbit/s wifi link to the shack in the > garden. That's four orders of magnitude difference, and I expect this > difference to get worse with time. >=20 > This has some important consequences, notably the fact that it's > possibly hazardous to implement multicast by flooding. do you have any references that could be included or would you mind = proposing some text? if it turns out to be multicast specific it could go in 3.5.1. if there are more general issues to consider then perhaps a new = sub-section? cheers, Ole= From rdroms.ietf@gmail.com Fri Jun 21 05:11:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FA421F9F3D for ; Fri, 21 Jun 2013 05:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VgAMnmdzn4A for ; Fri, 21 Jun 2013 05:11:52 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB1021F9F38 for ; Fri, 21 Jun 2013 05:11:52 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id d13so481713qak.16 for ; Fri, 21 Jun 2013 05:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=l4en8JPWpj5AMFodIVHEgQX++Pz2lst+wq4MFq2IqDM=; b=MYaC71o91hTzh5N+YF1N9J6mfU/qhKSqDYMR65WLqFMt7W1TnR2Dp4Kwee6Iqd02O0 iX7nCaMg1cDqHf2nnV5of/I3SXocf39kepl03s224mUY6/x1OIqmBOV3LqyfKgvqJ+gx FJq+OHkx3c7r///F8cFlIlXiIpq80PLECViqb2CWGaVuBECKFpH4hPHDMWTeez9wbkDE OgAeVpS2Hqvipps5Q/P4L5uC5fqux20Ia3fc2d/lDhWZFh26efWt7kEXXqOpY1B9W5Np Bcp04G1cbv/rMxDetJll68EyanjC/GUNqkycc9+JidDS8B8UsUAeQePG8C05VqWSoRBm 6Bag== X-Received: by 10.49.35.180 with SMTP id i20mr14287675qej.61.1371816712000; Fri, 21 Jun 2013 05:11:52 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:f463:9e2b:73c2:422c? ([2001:420:2481:20:f463:9e2b:73c2:422c]) by mx.google.com with ESMTPSA id j5sm6058324qan.7.2013.06.21.05.11.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 05:11:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> Date: Fri, 21 Jun 2013 08:11:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 12:11:53 -0000 On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon wrote: > On Jun 17, 2013, at 4:13 PM, Ralph Droms = wrote: >> The document makes no mention of *how* a largest practical subnet = architecture might be achieved. There should be some requirement that = devices be capable of acting as either a bridge or a router (or a mix of = both), and that devices should bridge unless routing is determined = necessary. >=20 > I find this text in the document a bit problematic too. I don't = think it's actually reasonably practical to do any such determination. Perhaps it should be explicitly called out as an open question in the = architecture document? > The only practical source of subnet sizing is the size of the = smallest prefix we got from an ISP. I guess there are some ideas we = could suggest, but they look more like solutions than architecture to = me. The delegated prefixes only provide an upper bound. My concern is that = we're assuming routing in the homenet comes from three sources: 1) explicitly desired for a specific goal like privacy or traffic = management 2) hardware requirements like unbridgeable L2s or where bridging is for = some reason undesirable 3) random placement of devices 1) requires some sort of explicit management while 3) may incur = unnecessary complexity. 2) might deserve a little more text in the = architecture document so the WG can have a discussion about what can be = supported as "undesirable". >=20 > For instance, we could say that for any given router, all non-edge = interfaces on that router that are of the same media type should be = bridged together into a single subnet. But here's where routing for a desired property and management comes in = ... suppose one of the router ports is to be configured as a separate = link for the "office" subnet? That configuration can't be inferred, I = don't think. > CeroWRT makes each one its own subnet, which drives me nuts. This = would have the effect that if you plugged a Wifi router's ethernet port = into the ethernet port of a CER, the WiFi router's ethernet port would = be on the same subnet as the CER's ethernet ports, but the Wifi network = would be on its own subnet; hence, routed, not bridged, which I think is = desirable. But does this belong in the architecture document? I think there needs to be more careful distinction among the three cases = I mentioned earlier. Here, I think you're talking about case 2). I agree that goals, requirements and problem statements belong in the = architecture document, but (mostly) not solutions.=20 >=20 > Furthermore, it's complicated by the fact that we'd really prefer to = avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite = possible that people will plug such interfaces together. > So we may need to decide very dynamically which interfaces are = bridged and which are routed. Maybe we will have virtual bridged = networks on each homenet router for each media type and speed that the = router supports, and dynamically connect interfaces that are running at = that speed to those bridges, and hope that this works. >=20 > I don't think we've visited this issue thoroughly enough to make = statements about it in the architecture document. Maybe it needs to be cited as an open question? I'll re-read the = document; statements like "we'd really prefer to avoid briding between = 10mbps, 100mbps and 1Mbps internet" ought to be made explicit and = justified. >=20 >> Acknowledging the desire to avoid constraining future networks, I = think the document would benefit from some discussion of scaling goals: = how many subnets, how many ISP connections, etc. also, some text about = how much and what user configuration is acceptable should be added. As = a specific example, network devices can't know, without user input, = whether s guest network us desired and how devices should be guided to = attach to the guest network. >=20 > I think that these are all reasonable things to want to describe; the = question is, does the working group want to describe them, particularly = in the current rev of the architecture document. My impression is that = at the moment the working group is willing to leave these things out of = the architecture document. >=20 > The document at the moment assumes the ability to support multihoming = for N connections, where N can definitely be 2, and possibly an = arbitrarily large number greater than two, but probably not. I think = it would indeed be worth making this explicit in the architecture = document. If we don't, I think some people will tend to read the = architecture document as really only requiring support for a maximum of = two CERs and two ISP connections. >=20 > How many subnets is determined by the size of the prefix we are given. = If we get a /64, the whole homenet is going to have to be a single = subnet, like it or not. If we get a /48, we can have a subnet for = every device, which would be pretty silly. There are other considerations beyond the upper limit imposed by the = delegated prefix. Where do we draw the "silly" line? > This leads to a separate question that is also interesting: what if we = are multihomed, and one ISP gives us lots of prefix, and the other ISP = gives us a /64? Do we bridge, to accommodate the chintzy ISP? Do we = route, and just ignore the second ISP? Do we just subnet the /64 down, = and run those micro-prefixes as managed prefixes using DHCPv6? >=20 > I think none of these options works well, if at all, and this scenario = is a very realistic possibility, e.g. in the case of a dual-homed home = that's connected to a wireline ISP that provides a /56, and a wireless = ISP that provides a /64. If Comcast ever gets me a native IPv6 = connection, that will in fact be my home network environment. The = current architecture document does not discuss this scenario, although = it grazes frustratingly close to doing so in section 3.4.3. >=20 > 3.3.3 does talk about guest realms, which I think is adequate. = Talking about UI is probably unnecessary, since it's implicit that some = UI is needed, and since the text in 3.3.3 isn't nearly sufficient to = implement guest realms; a document describing how this works on a = homenet will be necessary, and if the working group (which includes = you!) decides to talk about UI in that document, then we'll cover it = there; otherwise not. I'm not suggesting the architecture document needs to describe a UI. I = think more clarity is needed about what is expected to be automated and = what requires some form of management intervention (See below for more). >=20 > The beginning of 3.3 talks about user interaction in the sense that it = says there shouldn't need to be any. We have in the past talked about = how to make that work, since at the very minimum, the arrangement of = ethernet ports on a router and the labeling of these connectors = constitutes a user interface. Yup. Can it be left as an open question? Something to the effect of = "there is a tension between autonomous operation and control of the = network deployment to meet user requirements"? > 3.3 also talks about a shared key, but doesn't say how that's = provided. We talked about this during the early discussions about the = architecture document, and I don't think we came to any kind of = consensus about how that would work, although I think it was clear to = everybody that we needed to figure out some way to identify friend and = stranger when it comes to bridging over Wifi. And I don't see any discussion of how sorting of devices by type into = the network topology actually works. That is, the logical topology = doesn't necessarily match the physical topology, and I don't see any = acknowledgment of that issue in the document. > Some ideas for how to do this were discussed, and sounded good at = least to me, so I don't think that's the end of the discussion, but the = lack of consensus makes it hard to say anything more in the architecture = document. >=20 > The bottom line, wearing my working group participant hat, not my AD = hat, is that this is going to be an evolutionary process, and things = that are unclear now will become clearer later, and can be added to a = new version of the architecture document then. I absolutely agree, and I thought Curtis Villamizar made an interesting = suggestion about a wiki summary, which evolves as the WG develops = specific technologies. If there is interest, I'll volunteer to extract = an initial summary out of the architecture document. > Much as we might wish for it to be the case that the architecture = document as written could be the final, perfect version, I don't think = we are in a position to achieve that yet. >=20 I agree that perfect is the enemy of the good, and = draft-ietf-homenet-arch-08 is a good document. In my opinion, the = document would benefit from some more specificity around= From jch@pps.univ-paris-diderot.fr Fri Jun 21 05:28:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABA821E810C for ; Fri, 21 Jun 2013 05:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM+HEH0LphAO for ; Fri, 21 Jun 2013 05:28:21 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F3121E810B for ; Fri, 21 Jun 2013 05:28:20 -0700 (PDT) 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/38117) with ESMTP id r5LCSCfv009067; Fri, 21 Jun 2013 14:28:13 +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 C042A4EC47; Fri, 21 Jun 2013 14:28: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 ndWervuUaYNA; Fri, 21 Jun 2013 14:28:11 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8168C4EC48; Fri, 21 Jun 2013 14:28:11 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Uq0Rn-00015H-2w; Fri, 21 Jun 2013 14:28:11 +0200 Date: Fri, 21 Jun 2013 14:28:11 +0200 Message-ID: <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ole Troan In-Reply-To: References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 21 Jun 2013 14:28:14 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 12:28:26 -0000 > if it turns out to be multicast specific it could go in 3.5.1. > if there are more general issues to consider then perhaps a new sub-section? No, I think it's more general. What about something like the following: Homenets tend to grow organically over many years, and a homenet will typically be built over link-layer technologies from different generations. Current homenets typically use links ranging from 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed discrepancy. We expect this discrepancy to get worse as both high-speed and low-power technogies are deployed. Homenet protocols should be designed to deal well with interconnecting links of very different speeds. In particular, flows local to a link should not be flooded throughout the homenet, even when sent over multicast, and, whenever possible, the homenet protocols should be able to choose the faster links and avoid the slower ones. If you wish, I can add a sentence saying "This implies that a link-state protocol must be used in the homenet" ;-) -- Juliusz From rdroms.ietf@gmail.com Fri Jun 21 06:54:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF4F21E811A for ; Fri, 21 Jun 2013 06:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtm1uQx4IQ2v for ; Fri, 21 Jun 2013 06:54:40 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D68E711E818A for ; Fri, 21 Jun 2013 06:54:39 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so557042qab.7 for ; Fri, 21 Jun 2013 06:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=V9gRRS06RwwnlqJx3bE4mGJylETRFfkVOesy++Kwm+I=; b=WiA2Ji9GQvHa4+oOsL6wG9q0lQRBXYtc4l/Hf6JajCIq/nGlVdI9baNUF1cpTi6417 Imxp2OxPvbeXcguPQPAmKtPPAr4MqEauzK1sf9tcJjNtqkHg1DTvLI6Pdk6rQntcgDil iSMsAGfdSjV3KEEfjiyd2ZSpYLB2yrscntzc/pl9zATzqVuSfvjMtFPE4tYABbKFd4p8 SZ8IET4i3afXlZWgRkuS3I54lTraeg1XN8c51sMCpnTijz8IQZxzC7bRFZPHRrjXGxH8 +qb69PXcqYlKGxRvroASCleO3XBIzSb/XQTiyYyiKxQ8iB7/PA0C0Wg1UFr3Nssi5iHO oxgQ== X-Received: by 10.224.74.1 with SMTP id s1mr11239938qaj.25.1371822879131; Fri, 21 Jun 2013 06:54:39 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:bd33:7c3c:a8e9:6b95? ([2001:420:2481:20:bd33:7c3c:a8e9:6b95]) by mx.google.com with ESMTPSA id 11sm6070104qek.1.2013.06.21.06.54.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 06:54:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <31343.1371773368@sandelman.ca> Date: Fri, 21 Jun 2013 09:54:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <31343.1371773368@sandelman.ca> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1508) Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:54:41 -0000 On Jun 20, 2013, at 8:09 PM 6/20/13, Michael Richardson = wrote: >=20 > Juliusz Chroboczek wrote: > sb> this is also what chained DHCPv6-PD / a hipnet-like solution = can do. >=20 > mcr> It can not deal with loops: I see them regularly in people's = small > mcr> offices, and given wifi, it's really easy even for experts to = create. >=20 > juliusz> Could you please explain that? >=20 > juliusz> I was under the impression that a prefix subdelegation is = always > juliusz> for a longer prefix than the one it was delegated from, so = at > juliusz> each hop the prefix gets longer. A loop would imply that = a > juliusz> prefix is strictly longer than itself. >=20 > Given the scenario: >=20 > ISP1 ISP2 > \ / > CPE1 CPE2___ > \ / \ > ~~~~~~~ wifi \WIRE > | | > CPE3 | > | | > \------------ >=20 >=20 > PD will have CPE3 get a prefix from...? I'm not sure whether you're asking about hierarchical PD (HIPnet) or = centralized PD (draft-baker-homenet-prefix-assignment-01). Section 3..1.2.2 of the latter addresses this issue. The idea is that = CPE3 detects RAs on wifi and WIRE and concludes it does not need to make = any PD requests. Here are three issues to be refined in = draft-baker-homenet-prefix-assignment-01 (not all related to the = question Michael raises), if there is interest in further development of = the specification. 1) What happens if the CPE(s) don't come up in the "correct" order; = e.g., suppose CPE3 comes up before CPE1 and CPE2. 2) How does an interior router (in this example, CPE3) in a multi-homed = network detect that it needs some but not all prefixes? =46rom this = example, suppose CPE1 has assigned a prefix to wifi but CPE2 has not = (for some reason). How would CPE3 determine it needs a prefix from CPE2 = for wifi but not from CPE1? 3) Do CPE1 and CPE2 each do PD for their respective ISPs (requiring = changes to the DHCPv6 protocol to allow multiple sources of PD) or do = CPE1 and CPE2 agree that CPE1 will hand out all prefixes, and CPE2 = delegates all of its prefixes from ISP2 to CPE1? - Ralph > CPE1? CPE2 (via WIFI) and CPE3 (via wired). > If you look at the wires, it looks like CPE3 is simply plugged into = CPE2. But > the wires you can't see help too. Why did you buy CPE3? =20 >=20 > Well, how about so that you'd have wifi coverage in the upstairs. > (CPE3 can easily see CPE2 and CPE1, but a tablet in your bed can't) >=20 > In order for CableLabsHome to be augmented to support multiple ISPs, = CPE3 has > to get PDs from all possible "uplinks". =20 >=20 > Should CPE1 now also ask for a prefix (from ISP2) from CPE3, which now = looks > like an uplink to it as well. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 >=20 >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Fri Jun 21 07:40:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B816411E8193 for ; Fri, 21 Jun 2013 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itx73HVDNShy for ; Fri, 21 Jun 2013 07:40:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8529621E8124 for ; Fri, 21 Jun 2013 07:40:26 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id C0F4B20266; Fri, 21 Jun 2013 11:44:14 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 88535A902A; Fri, 21 Jun 2013 10:39:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 707EFB9083; Fri, 21 Jun 2013 10:39:24 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: <66BD076D-D8BC-4F30-8DCD-44095D1475E5@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <87zjunnqjw.wl%jch@pps.univ-paris-diderot.fr> <51C16A12.3030205@openwrt.org> <51C1789E.2050203@openwrt.org> <7761.1371646603@sandelman.ca> <87vc59ufdf.wl%jch@pps.univ-paris-diderot.fr> <31343.1371773368@sandelman.ca> <66BD076D-D8BC-4F30-8DCD-44095D1475E5@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 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:40:31 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable mcr> Should CPE1 now also ask for a prefix (from ISP2) from CPE3, which mcr> now looks like an uplink to it as well. Ted Lemon wrote: tl> Yes. and now we definitely have a forwarding loop. This is why chained PD does n= ot solve the problem, and I think is a cul-de-sac architecture. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcRlmIqHRg3pndX9AQK+6AQAg1KQ94A85nkevwN7tx9E+CaJNg6tbKm4 EPQtV8yay/A8WRYe2ktsw8HqC4RMyL4W3c2yG9UaFXw8V+DmZDbCtNON2ZFh9am2 3nQnbtl6VBFiVpnWrAoDkjwq2lGILzznFroYaormpBu9uGSE4vZVmeT7g1ELX+xM 0FwLYW86f7A= =Q9vY -----END PGP SIGNATURE----- --=-=-=-- From curtis@ipv6.occnc.com Fri Jun 21 14:00:07 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF8021F9E33 for ; Fri, 21 Jun 2013 14:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUm9qO3ecvT0 for ; Fri, 21 Jun 2013 14:00:03 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 265AE21F9E2A for ; Fri, 21 Jun 2013 14:00:02 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r5LKsMLN015796; Fri, 21 Jun 2013 16:54:23 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201306212054.r5LKsMLN015796@gateway1.orleans.occnc.com> To: Juliusz Chroboczek From: Curtis Villamizar In-reply-to: Your message of "Mon, 17 Jun 2013 14:13:27 +0200." <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> Date: Fri, 21 Jun 2013 16:54:22 -0400 Cc: Ray Bellis , Ole Troan , "homenet@ietf.org Group" , tjc@ecs.soton.ac.uk Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:00:07 -0000 In message <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> Juliusz Chroboczek writes: > Hi Ole, > > > > This would seem to imply that only link-state protocols can "give > > > a consistent view of the network", and that only link-state protocols > > > can "pass around more than just routing information". I'm pretty sure > > > BGP and EIGRP experts would disagree with that. > > > why would BGP and EIGRP experts disagree with that? > > BGP has an extensive attributes mechanism that allows it to "pass > around more than just routing information". > > EIGRP has a number of mechanisms (reliable transport, active phase) > that ensure that it provides a "consistent view of the network" at all > times (arguably more so than multi-area OSPF). > > The implication that only link-state protocols can have these > properties is incorrect. This is completely orthogonal to the issue > of whether the Homenet group wishes to promote the use of OSPF. > > -- Juliusz > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet EIGRP is a proprietary protocol, protected by a patent and implemented by a single vendor (AFAIK). RIP2 is patent free but nearly dead. EIGRP, RIP2, and BGP are distance vector (BGP is actually path vector) and therefore do not give a consistent view of the topology. BGP doesn't yield any view at all of a network's internal topology. BGP is not an appropriate protocol for use as an Interior Gateway Protocol (IGP). Deployments which use BGP rely on an IGP to provide internal topology and reachability. The IGP in all major providers is a link state protocol (OSPF or ISIS). A tiny number of providers that are foolish enough to lock themselves into a single vendor may use EIGRP as their IGP (but its zero among the big boys). Use of RIP2 among providers is zero AFAIK. I would say that not only would BGP experts object to the statement above that started this thread, but anyone with a clue about how BGP is used would object. Lets leave the text as-is. It is accurate given that the obvious context is an interior routing protocol. We need not consider homenets running BGP at all. Networks carrying global routes would need to run BGP, but not as their IGP, and these networks would not be homenets or sohos or small business. Curtis From dave.taht@gmail.com Fri Jun 21 14:24:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3F521F9E37 for ; Fri, 21 Jun 2013 14:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9hzKwuuiOaA for ; Fri, 21 Jun 2013 14:24:12 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AF6A321F9E16 for ; Fri, 21 Jun 2013 14:24:12 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so59259vcb.34 for ; Fri, 21 Jun 2013 14:24:11 -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=36PPv/eaXmususuYME0tXcM6FiYSm/ZyDRPTj7oaL3s=; b=mWkSfyIfS06uRxBcfb0Et41CKsrSs79fcolto1NNLpxKGtnHdX5BhBNIks55uRuWBO VsaoBnSOieCE0TtT0noLZUeeonrCTmzDoslW8YUeK0GTBgtQZaHT048/jSYDj1sd0z94 zH+vgQ1TGgABCqtMT9T6N2Zg9QWhH0SEcFwgG7H2XfexwFGR2HQowqdVajguUME4AZc4 gw6jLl2dPcv+8mGvLPRMs3mD1hwsBjQ6E1BlHkwYtKWBJnS3zaV0AZv/40BaqK1Pc2Rh JV20YlFOBKVDnlAoN+sVkdVkXH0l3lSCEhzRkWa2lqFV88cxgik4Of3WNj7BXw2czzj+ juqg== MIME-Version: 1.0 X-Received: by 10.52.16.172 with SMTP id h12mr5580806vdd.47.1371849851796; Fri, 21 Jun 2013 14:24:11 -0700 (PDT) Received: by 10.58.28.129 with HTTP; Fri, 21 Jun 2013 14:24:11 -0700 (PDT) In-Reply-To: <201306212054.r5LKsMLN015796@gateway1.orleans.occnc.com> References: <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <201306212054.r5LKsMLN015796@gateway1.orleans.occnc.com> Date: Fri, 21 Jun 2013 14:24:11 -0700 Message-ID: From: Dave Taht To: curtis@ipv6.occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Juliusz Chroboczek , Henning Rogge , tjc@ecs.soton.ac.uk, Ray Bellis , Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:24:15 -0000 On Fri, Jun 21, 2013 at 1:54 PM, Curtis Villamizar wrote: > > In message <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> > Juliusz Chroboczek writes: > >> Hi Ole, >> >> > > This would seem to imply that only link-state protocols can "give >> > > a consistent view of the network", and that only link-state protocol= s >> > > can "pass around more than just routing information". I'm pretty su= re >> > > BGP and EIGRP experts would disagree with that. >> >> > why would BGP and EIGRP experts disagree with that? >> >> BGP has an extensive attributes mechanism that allows it to "pass >> around more than just routing information". >> >> EIGRP has a number of mechanisms (reliable transport, active phase) >> that ensure that it provides a "consistent view of the network" at all >> times (arguably more so than multi-area OSPF). >> >> The implication that only link-state protocols can have these >> properties is incorrect. This is completely orthogonal to the issue >> of whether the Homenet group wishes to promote the use of OSPF. >> >> -- Juliusz >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > EIGRP is a proprietary protocol, protected by a patent and implemented > by a single vendor (AFAIK). RIP2 is patent free but nearly dead. > > EIGRP, RIP2, and BGP are distance vector (BGP is actually path vector) > and therefore do not give a consistent view of the topology. I take it nobody here is paying any attention to olsr v2, which at least has hope as towards a viable metric for wireless. http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ and also nobody here is paying attention to batman-adv which is both deployed and available in the linux kernel... both of these have a consistent view of the topology for some values of consistent. There aint nothing wrong with a hybrid approach either, towards announcing that "I need prefixes" - there is very little stopping any routing protocol of any sort from announcing that, and getting it, if that's what you want. With sufficient spare prefixes a network can have a large degree of "inconsistency" towards its outlook towards gaining prefixes. >BGP > doesn't yield any view at all of a network's internal topology. > > BGP is not an appropriate protocol for use as an Interior Gateway > Protocol (IGP). Deployments which use BGP rely on an IGP to provide > internal topology and reachability. The IGP in all major providers is > a link state protocol (OSPF or ISIS). A tiny number of providers that > are foolish enough to lock themselves into a single vendor may use > EIGRP as their IGP (but its zero among the big boys). Use of RIP2 > among providers is zero AFAIK. This is generally not a discussion about what providers use. A discussion about what small business uses might be relevant. My own objections are largely rooted in the need for a viable protocol over wireless networks. Period. Prove you have a routing viable protocol for wireless networks and embed a prefix distribution mechanism in it if you like. Dragging in an entire routing protocol in, in support of the prefix mechanism problem is the wrong way 'round. aside: Most older protocols treat ipv6 and ipv4 separately, often with separate daemons, and packet types. I'm not particularly fond of that approach. > I would say that not only would BGP experts object to the statement > above that started this thread, but anyone with a clue about how BGP > is used would object. > > Lets leave the text as-is. It is accurate given that the obvious > context is an interior routing protocol. I've kind of lost in this thread what text you are referring to now. > We need not consider homenets running BGP at all. Networks carrying > global routes would need to run BGP, but not as their IGP, and these > networks would not be homenets or sohos or small business. I would rather like multihoming to work in soho and small business. > > Curtis > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From dave.taht@gmail.com Fri Jun 21 15:04:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5D721F9E68 for ; Fri, 21 Jun 2013 15:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpTl50JbytZt for ; Fri, 21 Jun 2013 15:04:57 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BC4D321F9E53 for ; Fri, 21 Jun 2013 15:04:57 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so20678924iec.33 for ; Fri, 21 Jun 2013 15:04:57 -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=ya/qVRJy0K+M4j04vbczuhBzk+ZXIAdcohigAANOd6M=; b=Kn7/0tRiYTtgbjuX1SRH3lRtmhNWeT/XRiJ++3LuHmqa+e/KpGcs3Dwfu/FhaRHZNa TeolbiBkgj6c8BilMiXMYhekdlkvwnznGD8NvwYNscM3SURfms48za7aljotnpWQ330P naqhRZ2nbFLlKzsTzWWlIO3Q37zw6OJERiWrhDCtCYw/iIcWKsWi6zOuxKVBUurnz+7i lfiy1eAnghqNmg8DSxDYdcfCe4wjd22AMF7F9COZnISCPDFO4WI0n86TI05MqVh8Ot/N oFai9RaqAa5ggcIw0n0fTrkpE9jQX4BSM2xxVteSq13xPK31Hq7dlO4OGEnPGTeeqaK9 m8aA== MIME-Version: 1.0 X-Received: by 10.50.23.8 with SMTP id i8mr80423igf.42.1371852297248; Fri, 21 Jun 2013 15:04:57 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Fri, 21 Jun 2013 15:04:56 -0700 (PDT) In-Reply-To: <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> Date: Fri, 21 Jun 2013 15:04:56 -0700 Message-ID: From: Dave Taht To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 22:04:59 -0000 On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms wrote: > > On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon wrote: > >> On Jun 17, 2013, at 4:13 PM, Ralph Droms wrote: >>> The document makes no mention of *how* a largest practical subnet archi= tecture might be achieved. There should be some requirement that devices b= e capable of acting as either a bridge or a router (or a mix of both), and = that devices should bridge unless routing is determined necessary. >> >> I find this text in the document a bit problematic too. I don't think = it's actually reasonably practical to do any such determination. > > Perhaps it should be explicitly called out as an open question in the arc= hitecture document? > >> The only practical source of subnet sizing is the size of the smallest = prefix we got from an ISP. I guess there are some ideas we could suggest,= but they look more like solutions than architecture to me. > > The delegated prefixes only provide an upper bound. My concern is that w= e're assuming routing in the homenet comes from three sources: > > 1) explicitly desired for a specific goal like privacy or traffic managem= ent > 2) hardware requirements like unbridgeable L2s or where bridging is for s= ome reason undesirable > 3) random placement of devices > 1) requires some sort of explicit management while 3) may incur unnecessa= ry complexity. 2) might deserve a little more text in the architecture doc= ument so the WG can have a discussion about what can be supported as "undes= irable". > >> >> For instance, we could say that for any given router, all non-edge inter= faces on that router that are of the same media type should be bridged toge= ther into a single subnet. My definition of media type would treat 2.4ghz and 5.x ghz wireless differently. does yours? > > But here's where routing for a desired property and management comes in .= .. suppose one of the router ports is to be configured as a separate link f= or the "office" subnet? That configuration can't be inferred, I don't thin= k. Happens all the time. > >> CeroWRT makes each one its own subnet, which drives me nuts. Not clear to me which part of that drives you nuts. In part CeroWrt's purpose is to expose problems with ideas by putting them out there annoyingly. :) (The original reason for routing rather than bridging networks in cero was that we wanted to be able to analyze the effects of routing vs bridging on wireless. The results of bridging gigE to 2.4ghz are generally pretty dismal. IPv6 also uses much more multicast than ipv4.) Along the way we gained insight into problems with commonly used protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of which have been solved, some of which have fixes in progress, others are unsolvable, all are documented publicly on the mailing list, wiki and issues database. Security is also a problem. Etc. If this group would like the reality based list, I can create a rather large list of hyperlinks at this point. The most recent example is the one with problems with windows filesharing induced by routing: https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html and successful resolution: https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html It certainly would be nice for people here to setup more homenet-like setups to get a grip for common protocols that have issues in routed environments. I don't setup networks like the yurtlab (86 prefixes) http://pastebin.com/K8g5TyXS out of any innate love for S&M. The thing that drives me nuts here is not the prefix distribution problem (which is 2 sed commands away per router, once, assuming stable prefixes) but the the naming problems. I'd like to be able to get to the printer at the office... but there's now a separate group for solving that. >This would have the effect that if you plugged a Wifi router's ethernet po= rt into the ethernet port of a CER, the WiFi router's ethernet port would b= e on the same subnet as the CER's ethernet ports, but the Wifi network woul= d be on its own subnet; hence, routed, not bridged, which I think is desira= ble. But does this belong in the architecture document? I like the "directionless" feature of hipnet. I'd like it very much if there was a way to distinguish between a master and slave router out of the box for both ipv4 and ivp6. If you plug two routers together on their bridge, they end up competing, if you plug the uplink of one into the other, you get nat, and either way, if they are both on 192.168.1.1, weird things happen. > I think there needs to be more careful distinction among the three cases = I mentioned earlier. Here, I think you're talking about case 2). > > I agree that goals, requirements and problem statements belong in the arc= hitecture document, but (mostly) not solutions. > >> >> Furthermore, it's complicated by the fact that we'd really prefer to avo= id briding between 10mbps, 100mbps and 1Mbps internet, and it's quite possi= ble that people will plug such interfaces together. wireless issue noted above. Am I the only one in this group that actually has the vast majority of devices in home and office wireless? Is there anybody here that doesn't think that the vast majority of devices in the home will be wireless? >> So we may need to decide very dynamically which interfaces are bridged= and which are routed. Maybe we will have virtual bridged networks on eac= h homenet router for each media type and speed that the router supports, an= d dynamically connect interfaces that are running at that speed to those br= idges, and hope that this works. >> >> I don't think we've visited this issue thoroughly enough to make stateme= nts about it in the architecture document. > > Maybe it needs to be cited as an open question? I'll re-read the documen= t; statements like "we'd really prefer to avoid briding between 10mbps, 100= mbps and 1Mbps internet" ought to be made explicit and justified. see above. > >> >>> Acknowledging the desire to avoid constraining future networks, I think= the document would benefit from some discussion of scaling goals: how many= subnets, how many ISP connections, etc. also, some text about how much an= d what user configuration is acceptable should be added. As a specific exa= mple, network devices can't know, without user input, whether s guest netwo= rk us desired and how devices should be guided to attach to the guest netwo= rk. >> >> I think that these are all reasonable things to want to describe; the qu= estion is, does the working group want to describe them, particularly in th= e current rev of the architecture document. My impression is that at the = moment the working group is willing to leave these things out of the archit= ecture document. >> >> The document at the moment assumes the ability to support multihoming fo= r N connections, where N can definitely be 2, and possibly an arbitrarily l= arge number greater than two, but probably not. I think it would indeed b= e worth making this explicit in the architecture document. If we don't, I= think some people will tend to read the architecture document as really on= ly requiring support for a maximum of two CERs and two ISP connections. >> >> How many subnets is determined by the size of the prefix we are given. = If we get a /64, the whole homenet is going to have to be a single subnet,= like it or not. If we get a /48, we can have a subnet for every device, = which would be pretty silly. > > There are other considerations beyond the upper limit imposed by the dele= gated prefix. Where do we draw the "silly" line? > >> This leads to a separate question that is also interesting: what if we a= re multihomed, and one ISP gives us lots of prefix, and the other ISP gives= us a /64? Do we bridge, to accommodate the chintzy ISP? Do we route, a= nd just ignore the second ISP? Do we just subnet the /64 down, and run th= ose micro-prefixes as managed prefixes using DHCPv6? I note that openwrt merely gives up and relays ips off a single /64 if it has to. >> >> I think none of these options works well, if at all, and this scenario i= s a very realistic possibility, e.g. in the case of a dual-homed home that'= s connected to a wireline ISP that provides a /56, and a wireless ISP that = provides a /64. If Comcast ever gets me a native IPv6 connection, that wi= ll in fact be my home network environment. The current architecture docum= ent does not discuss this scenario, although it grazes frustratingly close = to doing so in section 3.4.3. >> >> 3.3.3 does talk about guest realms, which I think is adequate. Talking= about UI is probably unnecessary, since it's implicit that some UI is need= ed, and since the text in 3.3.3 isn't nearly sufficient to implement guest = realms; a document describing how this works on a homenet will be necessary= , and if the working group (which includes you!) decides to talk about UI i= n that document, then we'll cover it there; otherwise not. > > I'm not suggesting the architecture document needs to describe a UI. I t= hink more clarity is needed about what is expected to be automated and what= requires some form of management intervention (See below for more). > >> >> The beginning of 3.3 talks about user interaction in the sense that it s= ays there shouldn't need to be any. We have in the past talked about how = to make that work, since at the very minimum, the arrangement of ethernet p= orts on a router and the labeling of these connectors constitutes a user in= terface. > > Yup. Can it be left as an open question? Something to the effect of "th= ere is a tension between autonomous operation and control of the network de= ployment to meet user requirements"? > >> 3.3 also talks about a shared key, but doesn't say how that's provided= . We talked about this during the early discussions about the architectur= e document, and I don't think we came to any kind of consensus about how th= at would work, although I think it was clear to everybody that we needed to= figure out some way to identify friend and stranger when it comes to bridg= ing over Wifi. > > And I don't see any discussion of how sorting of devices by type into the= network topology actually works. That is, the logical topology doesn't ne= cessarily match the physical topology, and I don't see any acknowledgment o= f that issue in the document. > >> Some ideas for how to do this were discussed, and sounded good at leas= t to me, so I don't think that's the end of the discussion, but the lack of= consensus makes it hard to say anything more in the architecture document. >> >> The bottom line, wearing my working group participant hat, not my AD hat= , is that this is going to be an evolutionary process, and things that are = unclear now will become clearer later, and can be added to a new version of= the architecture document then. > > I absolutely agree, and I thought Curtis Villamizar made an interesting s= uggestion about a wiki summary, which evolves as the WG develops specific t= echnologies. If there is interest, I'll volunteer to extract an initial su= mmary out of the architecture document. > >> Much as we might wish for it to be the case that the architecture docu= ment as written could be the final, perfect version, I don't think we are i= n a position to achieve that yet. >> > > > I agree that perfect is the enemy of the good, and draft-ietf-homenet-arc= h-08 is a good document. In my opinion, the document would benefit from so= me more specificity around > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From mark@townsley.net Sat Jun 22 04:28:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D47D21F9FCD for ; Sat, 22 Jun 2013 04:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tuey5AG8Ix2z for ; Sat, 22 Jun 2013 04:28:35 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8121F9F5F for ; Sat, 22 Jun 2013 04:28:35 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so7236205wgh.30 for ; Sat, 22 Jun 2013 04:28:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=52AbIimCWV5nvUAQ+qCMmAzNGx9OqWwGHMdlKFZaMGk=; b=ExJGC7nKRiMpwsc6YOIQrgMfJMCPwli4SMKbVU+sb3pliB4e5685XMSr4ABB/RuaSa sBVxIK8lGBiC5wZz9qnANEJ9bIslTAJ6h0DMl2CVkqVMaS5T+gRhfZNfa1UWqFdd45Eh Hc06gX4MlXOX+iOHvmGbTL8TWa9sOeTJyQ4KOANyjoED/fFsTSeDMCK7YlXgcHPcbp0U Uv1vmeihLUiq+DeipcHh9ZndM0C9dGAySk+PTotc2Sa3HQPt5H/Mz7GT8HqFewc4PCXJ fQBzOZ6nDJx9Q+Y6zhwxIm0fld8oiEaa6mkLZ1ShScG0EuddbLtn2HGN0v8Tkl9+2l5B i3Zg== X-Received: by 10.180.74.162 with SMTP id u2mr1380232wiv.36.1371900514645; Sat, 22 Jun 2013 04:28:34 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id f8sm3304440wiv.0.2013.06.22.04.28.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Jun 2013 04:28:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <9FB60CE5849B194190DC0CDAD4825AEC3F41F592@PACDCEXMB13.cable.comcast.com> Date: Sat, 22 Jun 2013 13:28:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B957673-0B0D-4586-9BCF-1C8AF20BBDFA@townsley.net> References: <9FB60CE5849B194190DC0CDAD4825AEC3F41F592@PACDCEXMB13.cable.comcast.com> To: "Leddy, John" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQl9qaJqt9vUNT6lVNd5NYFBCejjW2yaz9PMngYz1/sIVXq83YNS7dcgR53zC6HU7VvTfHl1 Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] Loops in DHCP-PD [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 11:28:36 -0000 Hi John, nice to hear from you. With my chair hat on, I'd like to = clarify one thing here. On Jun 21, 2013, at 3:04 AM, Leddy, John wrote: > A solution to this conflict would be to include V4 into HomeNet or = embrace > HipNet as a transition technology. "IP Version Agnostic" work is (and has always been) within scope of the = WG. Meaning, we are chartered to define solutions that could work in = IPv4 and IPv6 whenever possible, as long as we are not making = compromises in IPv6 due to the existing state of IPv4 (as an extreme = example, we wouldn't include IPv6 NAPT just because IPv4 has it). That's = another way of saying work MUST be incremental to the ultimate IPv6 = solution, and SHOULD be applicable to IPv4. For homenet to embrace hipnet as a transition technology, it needs to = show that it does in fact provide transition rather than a stumbling = block to the full IPv6 solution. Ray has asked for that from the authors = already. But in terms of your first option (including IPv4 in Homenet), = as long as IPv4 is not holding up the ultimate IPv6 design, it's already = in scope in for Homenet today. - Mark= From v6ops@globis.net Sat Jun 22 10:15:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ADE11E810B for ; Sat, 22 Jun 2013 10:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOJwQhe+6otl for ; Sat, 22 Jun 2013 10:15:14 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76E21F9F48 for ; Sat, 22 Jun 2013 10:15:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 814298700E6; Sat, 22 Jun 2013 19:14:58 +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 r-NuJ8ZAZ605; Sat, 22 Jun 2013 19:14:58 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 61FBE8700DA; Sat, 22 Jun 2013 19:14:58 +0200 (CEST) Message-ID: <51C5DB8C.1070104@globis.net> Date: Sat, 22 Jun 2013 19:14:52 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Dave Taht References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Ted Lemon , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 17:15:15 -0000 Dave Taht wrote: > On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms wrote: >> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon wrote: >> >>> On Jun 17, 2013, at 4:13 PM, Ralph Droms wrote: >>>> The document makes no mention of *how* a largest practical subnet architecture might be achieved. There should be some requirement that devices be capable of acting as either a bridge or a router (or a mix of both), and that devices should bridge unless routing is determined necessary. >>> I find this text in the document a bit problematic too. I don't think it's actually reasonably practical to do any such determination. >> Perhaps it should be explicitly called out as an open question in the architecture document? >> >>> The only practical source of subnet sizing is the size of the smallest prefix we got from an ISP. I guess there are some ideas we could suggest, but they look more like solutions than architecture to me. >> The delegated prefixes only provide an upper bound. My concern is that we're assuming routing in the homenet comes from three sources: >> >> 1) explicitly desired for a specific goal like privacy or traffic management >> 2) hardware requirements like unbridgeable L2s or where bridging is for some reason undesirable >> 3) random placement of devices >> 1) requires some sort of explicit management while 3) may incur unnecessary complexity. 2) might deserve a little more text in the architecture document so the WG can have a discussion about what can be supported as "undesirable". >> >>> For instance, we could say that for any given router, all non-edge interfaces on that router that are of the same media type should be bridged together into a single subnet. > My definition of media type would treat 2.4ghz and 5.x ghz wireless > differently. does yours? Bridging between the two could be problematic, yes. >> But here's where routing for a desired property and management comes in ... suppose one of the router ports is to be configured as a separate link for the "office" subnet? That configuration can't be inferred, I don't think. > Happens all the time. > >>> CeroWRT makes each one its own subnet, which drives me nuts. > Not clear to me which part of that drives you nuts. In part CeroWrt's > purpose is to expose problems with ideas by putting them out there > annoyingly. > > (The original reason for routing rather than bridging networks in cero > was that we wanted to be able to analyze the effects of routing vs > bridging on wireless. The results of bridging gigE to 2.4ghz are > generally pretty dismal. IPv6 also uses much more multicast than > ipv4.) > > Along the way we gained insight into problems with commonly used > protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of > which have been solved, some of which have fixes in progress, others > are unsolvable, all are documented publicly on the mailing list, wiki > and issues database. Security is also a problem. Etc. > > If this group would like the reality based list, I can create a rather > large list of hyperlinks at this point. > > The most recent example is the one with problems with windows > filesharing induced by routing: > https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html > and successful resolution: > > https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html > > It certainly would be nice for people here to setup more homenet-like > setups to get a grip for common protocols that have issues in routed > environments. I don't setup networks like the yurtlab (86 prefixes) > > http://pastebin.com/K8g5TyXS > > out of any innate love for S&M. > > The thing that drives me nuts here is not the prefix distribution > problem (which is 2 sed commands away per router, once, assuming > stable prefixes) but the the naming problems. I'd like to be able to > get to the printer at the office... but there's now a separate group > for solving that. Agreed. Namespace (and service discovery) will likely remain a significant challenge with competing architectures, never mind implementations. >> This would have the effect that if you plugged a Wifi router's ethernet port into the ethernet port of a CER, the WiFi router's ethernet port would be on the same subnet as the CER's ethernet ports, but the Wifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable. But does this belong in the architecture document? > I like the "directionless" feature of hipnet. > > I'd like it very much if there was a way to distinguish between a > master and slave router out of the box for both ipv4 and ivp6. If you > plug two routers together on their bridge, they end up competing, if > you plug the uplink of one into the other, you get nat, and either > way, if they are both on 192.168.1.1, weird things happen. > >> I think there needs to be more careful distinction among the three cases I mentioned earlier. Here, I think you're talking about case 2). >> >> I agree that goals, requirements and problem statements belong in the architecture document, but (mostly) not solutions. >> >>> Furthermore, it's complicated by the fact that we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite possible that people will plug such interfaces together. > wireless issue noted above. I agree. AFAIK we do NOT have large scale reference deployments of common IGP's where wireless is used as a connector between multiple routers. Selecting Designated Router and Backup Designated Router in OSPF and Designated Intermediate System in IS-IS is NOT trivial especially when not all of the routers are within radio range of a common router. In fact I think we may well be missing a trick here, and we may need some form of mesh under network, at least between the routers connected via a common wireless link but where they are not all mutually within range of each other. Wireless to wireless bridging / repeating also seems to be highly proprietary and problematic. > Am I the only one in this group that > actually has the vast majority of devices in home and office wireless? No. > Is there anybody here that doesn't think that the vast majority of > devices in the home will be wireless? Not me. >>> So we may need to decide very dynamically which interfaces are bridged and which are routed. Maybe we will have virtual bridged networks on each homenet router for each media type and speed that the router supports, and dynamically connect interfaces that are running at that speed to those bridges, and hope that this works. >>> >>> I don't think we've visited this issue thoroughly enough to make statements about it in the architecture document. >> Maybe it needs to be cited as an open question? I'll re-read the document; statements like "we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet" ought to be made explicit and justified. > see above. > > From acee.lindem@ericsson.com Sat Jun 22 12:30:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF73721F9E9D for ; Sat, 22 Jun 2013 12:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKb4mOArYdoH for ; Sat, 22 Jun 2013 12:30:20 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 441BA21F9EAE for ; Sat, 22 Jun 2013 12:30:20 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-64-51c5fb4a2dde Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6D.59.17537.A4BF5C15; Sat, 22 Jun 2013 21:30:18 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Sat, 22 Jun 2013 15:30:18 -0400 From: Acee Lindem To: Ray Hunter Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAXEzICAAvmhgIACyQCAgAClugCAAUFJAIAAJdSA Date: Sat, 22 Jun 2013 19:30:17 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> In-Reply-To: <51C5DB8C.1070104@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A1D6231EC2D0749B92B79E38D277B1F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn67X76OBBiubrSz2bDzJYvF+0SEW izdrjjBZNF7rY7XYc7XegdWj6cIydo8nZ6+zeeycdZfdY8mSn0wBLFFcNimpOZllqUX6dglc GWefvWIrWOBYsff0G5YGxnsmXYwcHBICJhJPn1h2MXICmWISF+6tZwOxhQSOMkr8b8rqYuQC spczStxses0MkmAT0JF4/ugfmC0ioCgx/d8XJpAiZoHpjBIHn11jB0kIC3hK/H9/gwmiyEti 9sEuNgg7SuL+ydtgcRYBVYlpm34zgti8At4SrxY1MENsnssscedRHIjNKaAlcfb3a1YQmxHo uu+n1oD1MguIS9x6Mp8J4moBiSV7zjND2KISLx//Y4WwlSWWPNnPAlGvI7Fg9yc2CNta4uvW TVBxbYllCyEe4xUQlDg58wnLBEbxWUhWzELSPgtJ+ywk7bOQtC9gZF3FyFFanFqWm25ksIkR GIXHJNh0dzDueWl5iFGag0VJnPflqV2BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgDazc5 fDuazm4mYyX6TurH3G+K2ywZmR4rbvOQmzBNWUdP6DOrccDy6xxb/Z0UtmUnMDye6WN24MqM CRaK2/+s3FGv2t59xd3fyuDyi7uC3od8rTUM+8WlvzSnOxRJCz+6oC/KXCNaL9ZxNsxwlb+M TN7bS++kxT4zh3j4Xb5leGF52kLjYCWW4oxEQy3mouJEAB3TCGSQAgAA Cc: "homenet@ietf.org Group" , Ted Lemon , Dave Taht , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 19:30:26 -0000 There seems to be a fundamental disagreement here in terms of requirements.= With respect to wireless, we all agree that the home will include a large = number of wireless devices. However, I do not believe all these devices wil= l participate in the routing topology. Rather, there will be a small finite= number of routers with fixed and wireless connectivity that form the home = routing infrastructure. I do not believe the requirement is for a MANET net= work while those active in the MANET WG take this as given. Until we agree = or agree to disagree on this requirement, we will have wildly divergent opi= nions on the architecture with respect to routing.=20 Thanks Acee=20 On Jun 22, 2013, at 1:14 PM, Ray Hunter wrote: > Dave Taht wrote: >> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms wro= te: >>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon wrote= : >>>=20 >>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms wrote= : >>>>> The document makes no mention of *how* a largest practical subnet arc= hitecture might be achieved. There should be some requirement that devices= be capable of acting as either a bridge or a router (or a mix of both), an= d that devices should bridge unless routing is determined necessary. >>>> I find this text in the document a bit problematic too. I don't thin= k it's actually reasonably practical to do any such determination. >>> Perhaps it should be explicitly called out as an open question in the a= rchitecture document? >>>=20 >>>> The only practical source of subnet sizing is the size of the smallest= prefix we got from an ISP. I guess there are some ideas we could suggest= , but they look more like solutions than architecture to me. >>> The delegated prefixes only provide an upper bound. My concern is that= we're assuming routing in the homenet comes from three sources: >>>=20 >>> 1) explicitly desired for a specific goal like privacy or traffic manag= ement >>> 2) hardware requirements like unbridgeable L2s or where bridging is for= some reason undesirable >>> 3) random placement of devices >>> 1) requires some sort of explicit management while 3) may incur unneces= sary complexity. 2) might deserve a little more text in the architecture d= ocument so the WG can have a discussion about what can be supported as "und= esirable". >>>=20 >>>> For instance, we could say that for any given router, all non-edge int= erfaces on that router that are of the same media type should be bridged to= gether into a single subnet. >> My definition of media type would treat 2.4ghz and 5.x ghz wireless >> differently. does yours? > Bridging between the two could be problematic, yes. >=20 >>> But here's where routing for a desired property and management comes in= ... suppose one of the router ports is to be configured as a separate link= for the "office" subnet? That configuration can't be inferred, I don't th= ink. >> Happens all the time. >>=20 >>>> CeroWRT makes each one its own subnet, which drives me nuts. >> Not clear to me which part of that drives you nuts. In part CeroWrt's >> purpose is to expose problems with ideas by putting them out there >> annoyingly.=20 >>=20 >> (The original reason for routing rather than bridging networks in cero >> was that we wanted to be able to analyze the effects of routing vs >> bridging on wireless. The results of bridging gigE to 2.4ghz are >> generally pretty dismal. IPv6 also uses much more multicast than >> ipv4.) >>=20 >> Along the way we gained insight into problems with commonly used >> protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of >> which have been solved, some of which have fixes in progress, others >> are unsolvable, all are documented publicly on the mailing list, wiki >> and issues database. Security is also a problem. Etc. >>=20 >> If this group would like the reality based list, I can create a rather >> large list of hyperlinks at this point. >>=20 >> The most recent example is the one with problems with windows >> filesharing induced by routing: >> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html >> and successful resolution: >>=20 >> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.h= tml >>=20 >> It certainly would be nice for people here to setup more homenet-like >> setups to get a grip for common protocols that have issues in routed >> environments. I don't setup networks like the yurtlab (86 prefixes) >>=20 >> http://pastebin.com/K8g5TyXS >>=20 >> out of any innate love for S&M. >>=20 >> The thing that drives me nuts here is not the prefix distribution >> problem (which is 2 sed commands away per router, once, assuming >> stable prefixes) but the the naming problems. I'd like to be able to >> get to the printer at the office... but there's now a separate group >> for solving that. > Agreed. Namespace (and service discovery) will likely remain a > significant challenge with competing architectures, never mind > implementations. >=20 >=20 >>> This would have the effect that if you plugged a Wifi router's ethernet= port into the ethernet port of a CER, the WiFi router's ethernet port woul= d be on the same subnet as the CER's ethernet ports, but the Wifi network w= ould be on its own subnet; hence, routed, not bridged, which I think is des= irable. But does this belong in the architecture document? >> I like the "directionless" feature of hipnet. >>=20 >> I'd like it very much if there was a way to distinguish between a >> master and slave router out of the box for both ipv4 and ivp6. If you >> plug two routers together on their bridge, they end up competing, if >> you plug the uplink of one into the other, you get nat, and either >> way, if they are both on 192.168.1.1, weird things happen. >>=20 >>> I think there needs to be more careful distinction among the three case= s I mentioned earlier. Here, I think you're talking about case 2). >>>=20 >>> I agree that goals, requirements and problem statements belong in the a= rchitecture document, but (mostly) not solutions. >>>=20 >>>> Furthermore, it's complicated by the fact that we'd really prefer to a= void briding between 10mbps, 100mbps and 1Mbps internet, and it's quite pos= sible that people will plug such interfaces together. >> wireless issue noted above. > I agree. AFAIK we do NOT have large scale reference deployments of > common IGP's where wireless is used as a connector between multiple route= rs. >=20 > Selecting Designated Router and Backup Designated Router in OSPF and > Designated Intermediate System in IS-IS is NOT trivial especially when > not all of the routers are within radio range of a common router. In > fact I think we may well be missing a trick here, and we may need some > form of mesh under network, at least between the routers connected via a > common wireless link but where they are not all mutually within range of > each other. Wireless to wireless bridging / repeating also seems to be > highly proprietary and problematic. >=20 >=20 >> Am I the only one in this group that >> actually has the vast majority of devices in home and office wireless? > No. >=20 >> Is there anybody here that doesn't think that the vast majority of >> devices in the home will be wireless? > Not me. >=20 >>>> So we may need to decide very dynamically which interfaces are bridge= d and which are routed. Maybe we will have virtual bridged networks on ea= ch homenet router for each media type and speed that the router supports, a= nd dynamically connect interfaces that are running at that speed to those b= ridges, and hope that this works. >>>>=20 >>>> I don't think we've visited this issue thoroughly enough to make state= ments about it in the architecture document. >>> Maybe it needs to be cited as an open question? I'll re-read the docum= ent; statements like "we'd really prefer to avoid briding between 10mbps, 1= 00mbps and 1Mbps internet" ought to be made explicit and justified. >> see above. >>=20 >> >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From v6ops@globis.net Sat Jun 22 13:05:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9386421F9FB7 for ; Sat, 22 Jun 2013 13:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kratSl801fJ0 for ; Sat, 22 Jun 2013 13:05:58 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5313021F9FA4 for ; Sat, 22 Jun 2013 13:05:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 81D6287007C; Sat, 22 Jun 2013 22:05: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 E0gAMfB-kxpp; Sat, 22 Jun 2013 22:05:41 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 4AF8B87005E; Sat, 22 Jun 2013 22:05:41 +0200 (CEST) Message-ID: <51C6038F.2050500@globis.net> Date: Sat, 22 Jun 2013 22:05:35 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Acee Lindem References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Ted Lemon , Dave Taht , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:05:59 -0000 > Acee Lindem > 22 June 2013 21:30 > There seems to be a fundamental disagreement here in terms of > requirements. possibly. > With respect to wireless, we all agree that the home will include a > large number of wireless devices. agree. > However, I do not believe all these devices will participate in the > routing topology. agreed, almost certainly not all. Especially not static sensors. > Rather, there will be a small finite number of routers with fixed and > wireless connectivity that form the home routing infrastructure. Right. But even if you have 4 or 5 routers (one per room or per floor) there's a strong chance that they won't all be in mutual radio contact. So then you probably cannot assume all 4 or 5 of them are on a single shared subnet using the traditional OSPF or IS IS designated router to distribute routing information to all the on-link neighbors. Add to that scenario auto-prefix distribution. How do you establish and manage neighbor adjacencies versus subnets/ prefixes? Or do you presume that the homenet routers will be contiguously connected via wires, and there's no wireless router-router connections? > I do not believe the requirement is for a MANET network while those > active in the MANET WG take this as given. I never said there'd be a MANET, but we might need to consider that there'll be point to point wireless links that act as active adjacencies between 2 routers and that there'll be no alternative wired link between these routers, whilst at the same time those wireless interfaces are serving local end nodes within range. RFC 5820 could be of help in that situation to maintain router-router adjacencies as point to point links (without necessarily invoking all of MANET requirements for an ad hoc network of many mobile nodes). I don't know of any IS IS equivalent. Otherwise I think we might very well get into problems with repeaters and packet loss. > Until we agree or agree to disagree on this requirement, we will have > wildly divergent opinions on the architecture with respect to routing. > Thanks > Acee > > Ray Hunter > 22 June 2013 19:14 > Dave Taht wrote: >> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms wrote: >>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon wrote: >>> >>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms wrote: >>>>> The document makes no mention of *how* a largest practical subnet architecture might be achieved. There should be some requirement that devices be capable of acting as either a bridge or a router (or a mix of both), and that devices should bridge unless routing is determined necessary. >>>> I find this text in the document a bit problematic too. I don't think it's actually reasonably practical to do any such determination. >>> Perhaps it should be explicitly called out as an open question in the architecture document? >>> >>>> The only practical source of subnet sizing is the size of the smallest prefix we got from an ISP. I guess there are some ideas we could suggest, but they look more like solutions than architecture to me. >>> The delegated prefixes only provide an upper bound. My concern is that we're assuming routing in the homenet comes from three sources: >>> >>> 1) explicitly desired for a specific goal like privacy or traffic management >>> 2) hardware requirements like unbridgeable L2s or where bridging is for some reason undesirable >>> 3) random placement of devices >>> 1) requires some sort of explicit management while 3) may incur unnecessary complexity. 2) might deserve a little more text in the architecture document so the WG can have a discussion about what can be supported as "undesirable". >>> >>>> For instance, we could say that for any given router, all non-edge interfaces on that router that are of the same media type should be bridged together into a single subnet. >> My definition of media type would treat 2.4ghz and 5.x ghz wireless >> differently. does yours? > Bridging between the two could be problematic, yes. > >>> But here's where routing for a desired property and management comes in ... suppose one of the router ports is to be configured as a separate link for the "office" subnet? That configuration can't be inferred, I don't think. >> Happens all the time. >> >>>> CeroWRT makes each one its own subnet, which drives me nuts. >> Not clear to me which part of that drives you nuts. In part CeroWrt's >> purpose is to expose problems with ideas by putting them out there >> annoyingly. >> >> (The original reason for routing rather than bridging networks in cero >> was that we wanted to be able to analyze the effects of routing vs >> bridging on wireless. The results of bridging gigE to 2.4ghz are >> generally pretty dismal. IPv6 also uses much more multicast than >> ipv4.) >> >> Along the way we gained insight into problems with commonly used >> protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of >> which have been solved, some of which have fixes in progress, others >> are unsolvable, all are documented publicly on the mailing list, wiki >> and issues database. Security is also a problem. Etc. >> >> If this group would like the reality based list, I can create a rather >> large list of hyperlinks at this point. >> >> The most recent example is the one with problems with windows >> filesharing induced by routing: >> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html >> and successful resolution: >> >> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html >> >> It certainly would be nice for people here to setup more homenet-like >> setups to get a grip for common protocols that have issues in routed >> environments. I don't setup networks like the yurtlab (86 prefixes) >> >> http://pastebin.com/K8g5TyXS >> >> out of any innate love for S&M. >> >> The thing that drives me nuts here is not the prefix distribution >> problem (which is 2 sed commands away per router, once, assuming >> stable prefixes) but the the naming problems. I'd like to be able to >> get to the printer at the office... but there's now a separate group >> for solving that. > Agreed. Namespace (and service discovery) will likely remain a > significant challenge with competing architectures, never mind > implementations. > > >>> This would have the effect that if you plugged a Wifi router's ethernet port into the ethernet port of a CER, the WiFi router's ethernet port would be on the same subnet as the CER's ethernet ports, but the Wifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable. But does this belong in the architecture document? >> I like the "directionless" feature of hipnet. >> >> I'd like it very much if there was a way to distinguish between a >> master and slave router out of the box for both ipv4 and ivp6. If you >> plug two routers together on their bridge, they end up competing, if >> you plug the uplink of one into the other, you get nat, and either >> way, if they are both on 192.168.1.1, weird things happen. >> >>> I think there needs to be more careful distinction among the three cases I mentioned earlier. Here, I think you're talking about case 2). >>> >>> I agree that goals, requirements and problem statements belong in the architecture document, but (mostly) not solutions. >>> >>>> Furthermore, it's complicated by the fact that we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite possible that people will plug such interfaces together. >> wireless issue noted above. > I agree. AFAIK we do NOT have large scale reference deployments of > common IGP's where wireless is used as a connector between multiple routers. > > Selecting Designated Router and Backup Designated Router in OSPF and > Designated Intermediate System in IS-IS is NOT trivial especially when > not all of the routers are within radio range of a common router. In > fact I think we may well be missing a trick here, and we may need some > form of mesh under network, at least between the routers connected via a > common wireless link but where they are not all mutually within range of > each other. Wireless to wireless bridging / repeating also seems to be > highly proprietary and problematic. > > >> Am I the only one in this group that >> actually has the vast majority of devices in home and office wireless? > No. > >> Is there anybody here that doesn't think that the vast majority of >> devices in the home will be wireless? > Not me. > >>>> So we may need to decide very dynamically which interfaces are bridged and which are routed. Maybe we will have virtual bridged networks on each homenet router for each media type and speed that the router supports, and dynamically connect interfaces that are running at that speed to those bridges, and hope that this works. >>>> >>>> I don't think we've visited this issue thoroughly enough to make statements about it in the architecture document. >>> Maybe it needs to be cited as an open question? I'll re-read the document; statements like "we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet" ought to be made explicit and justified. >> see above. >> >> > > ------------------------------------------------------------------------ From jch@pps.univ-paris-diderot.fr Sat Jun 22 13:24:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FE021F9F10 for ; Sat, 22 Jun 2013 13:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibE2m-nzp3Xu for ; Sat, 22 Jun 2013 13:24:04 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id D641821F9F0E for ; Sat, 22 Jun 2013 13:24:03 -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/38117) with ESMTP id r5MKNxgH017677; Sat, 22 Jun 2013 22:23:59 +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 617404ED4E; Sat, 22 Jun 2013 22:23:59 +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 4W9uOnTGg2ri; Sat, 22 Jun 2013 22:23:58 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 650E54ED4C; Sat, 22 Jun 2013 22:23:58 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UqULl-0003un-JA; Sat, 22 Jun 2013 22:23:57 +0200 Date: Sat, 22 Jun 2013 22:23:57 +0200 Message-ID: <8761x5yjvm.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Acee Lindem In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 22 Jun 2013 22:23:59 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:24:10 -0000 > There seems to be a fundamental disagreement here in terms of > requirements. With respect to wireless, we all agree that the home > will include a large number of wireless devices. However, I do not > believe all these devices will participate in the routing > topology. AFAICT, nobody on this list has suggested otherwise. I'm confused. Whose statement exactly are you reacting to? -- Juliusz From acee.lindem@ericsson.com Sat Jun 22 14:20:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1085621F9E57 for ; Sat, 22 Jun 2013 14:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsBPF1eRNXe9 for ; Sat, 22 Jun 2013 14:20:53 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 437FC21F9E1D for ; Sat, 22 Jun 2013 14:20:53 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-fb-51c6152df42b Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 23.38.05617.D2516C15; Sat, 22 Jun 2013 23:20:45 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Sat, 22 Jun 2013 17:20:44 -0400 From: Acee Lindem To: Ray Hunter Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAXEzICAAvmhgIACyQCAgAClugCAAUFJAIAAJdSAgAAJ34CAABT+gA== Date: Sat, 22 Jun 2013 21:20:43 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> In-Reply-To: <51C6038F.2050500@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <9232C59F82EA044BBC5AC53EA9C2B306@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonVldX9FigwbIL0hZ7Np5ksXi/6BCL xZs1R5gsGq/1sVrsuVrvwOrRdGEZu8eTs9fZPHbOusvusWTJT6YAligum5TUnMyy1CJ9uwSu jI1L7rIXNIRVdP8/z9rAeM61i5GTQ0LARKJ59i52CFtM4sK99WxdjFwcQgJHGSU+duyDcpYz SpxeNZsVpIpNQEfi+aN/zCC2iICixPR/X5hAipgFpjJKXP61jAUkISzgKfH//Q0miCIvidkH u9gg7CyJVedOgQ1iEVCVOLvjC5jNK+AtcXD2AVaIbf+ZJZ5MPAO2gVNAS+Lp35eMIDYj0H3f T60BG8osIC5x68l8Joi7BSSW7DnPDGGLSrx8/I8VwlaWWPJkPwtEvY7Egt2f2CBsa4n7q64z Q9jaEssWvmaGOEJQ4uTMJywTGMVnIVkxC0n7LCTts5C0z0LSvoCRdRUjR2lxalluupHhJkZg LB6TYHPcwbjgk+UhRmkOFiVx3vendgUKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGwwKl8W +ulbr+bzg9/vfTeT2qBxITAzl2mBpv3fTL1ZWd8D1zvkm61v37o84HxY0apFnFPSUlPOLb5/ W3Tj7F8yjHN/55x4f+lhXr6d5uF1PJFT98Y8LSvdu/zbUZWVi3osBCMCPVcW2NWJOSuGJu7+ KHfrgpSm3WLWSBOhpKQg4RtqHq8P/1RiKc5INNRiLipOBAAG8aYbkwIAAA== Cc: "homenet@ietf.org Group" , Ted Lemon , Dave Taht , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 21:20:58 -0000 On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote: >> Acee Lindem >> 22 June 2013 21:30 >> There seems to be a fundamental disagreement here in terms of >> requirements. > possibly. >=20 >> With respect to wireless, we all agree that the home will include a >> large number of wireless devices. > agree. >> However, I do not believe all these devices will participate in the >> routing topology. > agreed, almost certainly not all. Especially not static sensors. >=20 >> Rather, there will be a small finite number of routers with fixed and >> wireless connectivity that form the home routing infrastructure. >=20 > Right. But even if you have 4 or 5 routers (one per room or per floor) > there's a strong chance that they won't all be in mutual radio contact. >=20 > So then you probably cannot assume all 4 or 5 of them are on a single > shared subnet using the traditional OSPF or IS IS designated router to > distribute routing information to all the on-link neighbors. >=20 > Add to that scenario auto-prefix distribution. How do you establish and > manage neighbor adjacencies versus subnets/ prefixes? >=20 > Or do you presume that the homenet routers will be contiguously > connected via wires, and there's no wireless router-router connections? I'd envision that all home network routers would be connected via wires or = wireless but for topology changes to be infrequent. I don't envision a home= network having the same dynamics as a MANET.=20 With respect to wireless router-to-router connections, if you cannot assume= mutual radio contact on the same wireless network, we could use P2MP as th= e default topology to solve the router-to-router problem. However, this ass= umption would break the broadcast model as well for hosts since basic proto= cols like ND and ARP assume a broadcast network.=20 >=20 >=20 >> I do not believe the requirement is for a MANET network while those >> active in the MANET WG take this as given. >=20 > I never said there'd be a MANET, but we might need to consider that > there'll be point to point wireless links that act as active adjacencies > between 2 routers and that there'll be no alternative wired link between > these routers, whilst at the same time those wireless interfaces are > serving local end nodes within range. Okay.=20 >=20 > RFC 5820 could be of help in that situation to maintain router-router > adjacencies as point to point links (without necessarily invoking all of > MANET requirements for an ad hoc network of many mobile nodes). I don't > know of any IS IS equivalent. Otherwise I think we might very well get > into problems with repeaters and packet loss. RFC 5820 is specifically to deal with the dynamic topologies and flooding s= cale challenges associated with a MANET network. I don't see it as being ap= plicable to the home network.=20 Thanks, Acee >=20 >=20 >=20 >> Until we agree or agree to disagree on this requirement, we will have >> wildly divergent opinions on the architecture with respect to routing. >> Thanks >> Acee >>=20 >> Ray Hunter >> 22 June 2013 19:14 >> Dave Taht wrote: >>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms wr= ote: >>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon wrot= e: >>>>=20 >>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms wrot= e: >>>>>> The document makes no mention of *how* a largest practical subnet ar= chitecture might be achieved. There should be some requirement that device= s be capable of acting as either a bridge or a router (or a mix of both), a= nd that devices should bridge unless routing is determined necessary. >>>>> I find this text in the document a bit problematic too. I don't thi= nk it's actually reasonably practical to do any such determination. >>>> Perhaps it should be explicitly called out as an open question in the = architecture document? >>>>=20 >>>>> The only practical source of subnet sizing is the size of the smalles= t prefix we got from an ISP. I guess there are some ideas we could sugges= t, but they look more like solutions than architecture to me. >>>> The delegated prefixes only provide an upper bound. My concern is tha= t we're assuming routing in the homenet comes from three sources: >>>>=20 >>>> 1) explicitly desired for a specific goal like privacy or traffic mana= gement >>>> 2) hardware requirements like unbridgeable L2s or where bridging is fo= r some reason undesirable >>>> 3) random placement of devices >>>> 1) requires some sort of explicit management while 3) may incur unnece= ssary complexity. 2) might deserve a little more text in the architecture = document so the WG can have a discussion about what can be supported as "un= desirable". >>>>=20 >>>>> For instance, we could say that for any given router, all non-edge in= terfaces on that router that are of the same media type should be bridged t= ogether into a single subnet. >>> My definition of media type would treat 2.4ghz and 5.x ghz wireless >>> differently. does yours? >> Bridging between the two could be problematic, yes. >>=20 >>>> But here's where routing for a desired property and management comes i= n ... suppose one of the router ports is to be configured as a separate lin= k for the "office" subnet? That configuration can't be inferred, I don't t= hink. >>> Happens all the time. >>>=20 >>>>> CeroWRT makes each one its own subnet, which drives me nuts. >>> Not clear to me which part of that drives you nuts. In part CeroWrt's >>> purpose is to expose problems with ideas by putting them out there >>> annoyingly.=20 >>>=20 >>> (The original reason for routing rather than bridging networks in cero >>> was that we wanted to be able to analyze the effects of routing vs >>> bridging on wireless. The results of bridging gigE to 2.4ghz are >>> generally pretty dismal. IPv6 also uses much more multicast than >>> ipv4.) >>>=20 >>> Along the way we gained insight into problems with commonly used >>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of >>> which have been solved, some of which have fixes in progress, others >>> are unsolvable, all are documented publicly on the mailing list, wiki >>> and issues database. Security is also a problem. Etc. >>>=20 >>> If this group would like the reality based list, I can create a rather >>> large list of hyperlinks at this point. >>>=20 >>> The most recent example is the one with problems with windows >>> filesharing induced by routing: >>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html >>> and successful resolution: >>>=20 >>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.= html >>>=20 >>> It certainly would be nice for people here to setup more homenet-like >>> setups to get a grip for common protocols that have issues in routed >>> environments. I don't setup networks like the yurtlab (86 prefixes) >>>=20 >>> http://pastebin.com/K8g5TyXS >>>=20 >>> out of any innate love for S&M. >>>=20 >>> The thing that drives me nuts here is not the prefix distribution >>> problem (which is 2 sed commands away per router, once, assuming >>> stable prefixes) but the the naming problems. I'd like to be able to >>> get to the printer at the office... but there's now a separate group >>> for solving that. >> Agreed. Namespace (and service discovery) will likely remain a >> significant challenge with competing architectures, never mind >> implementations. >>=20 >>=20 >>>> This would have the effect that if you plugged a Wifi router's etherne= t port into the ethernet port of a CER, the WiFi router's ethernet port wou= ld be on the same subnet as the CER's ethernet ports, but the Wifi network = would be on its own subnet; hence, routed, not bridged, which I think is de= sirable. But does this belong in the architecture document? >>> I like the "directionless" feature of hipnet. >>>=20 >>> I'd like it very much if there was a way to distinguish between a >>> master and slave router out of the box for both ipv4 and ivp6. If you >>> plug two routers together on their bridge, they end up competing, if >>> you plug the uplink of one into the other, you get nat, and either >>> way, if they are both on 192.168.1.1, weird things happen. >>>=20 >>>> I think there needs to be more careful distinction among the three cas= es I mentioned earlier. Here, I think you're talking about case 2). >>>>=20 >>>> I agree that goals, requirements and problem statements belong in the = architecture document, but (mostly) not solutions. >>>>=20 >>>>> Furthermore, it's complicated by the fact that we'd really prefer to = avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite po= ssible that people will plug such interfaces together. >>> wireless issue noted above. >> I agree. AFAIK we do NOT have large scale reference deployments of >> common IGP's where wireless is used as a connector between multiple rout= ers. >>=20 >> Selecting Designated Router and Backup Designated Router in OSPF and >> Designated Intermediate System in IS-IS is NOT trivial especially when >> not all of the routers are within radio range of a common router. In >> fact I think we may well be missing a trick here, and we may need some >> form of mesh under network, at least between the routers connected via a >> common wireless link but where they are not all mutually within range of >> each other. Wireless to wireless bridging / repeating also seems to be >> highly proprietary and problematic. >>=20 >>=20 >>> Am I the only one in this group that >>> actually has the vast majority of devices in home and office wireless? >> No. >>=20 >>> Is there anybody here that doesn't think that the vast majority of >>> devices in the home will be wireless? >> Not me. >>=20 >>>>> So we may need to decide very dynamically which interfaces are bridg= ed and which are routed. Maybe we will have virtual bridged networks on e= ach homenet router for each media type and speed that the router supports, = and dynamically connect interfaces that are running at that speed to those = bridges, and hope that this works. >>>>>=20 >>>>> I don't think we've visited this issue thoroughly enough to make stat= ements about it in the architecture document. >>>> Maybe it needs to be cited as an open question? I'll re-read the docu= ment; statements like "we'd really prefer to avoid briding between 10mbps, = 100mbps and 1Mbps internet" ought to be made explicit and justified. >>> see above. >>>=20 >>> >>=20 >> ------------------------------------------------------------------------ >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From andrewmcgr@gmail.com Sat Jun 22 22:07:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3994021E808C for ; Sat, 22 Jun 2013 22:07:52 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhuHC6bxZuuY for ; Sat, 22 Jun 2013 22:07:50 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C56B111E80AE for ; Sat, 22 Jun 2013 22:07:39 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fq12so8928044lab.38 for ; Sat, 22 Jun 2013 22:07:38 -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; bh=qXEyABIx/YUsLOTwdx418mD0YUOp38fcOEwDlxx0Eus=; b=p+rTnSA7KC4j0A9aQls0OXlH0r8f28cVLrMgUKlFe7bsg2zCvsdEblVGxFfpNBG2dp 3VJdsjly52C7jtP9oyzV5Rm2/9B+XM2psDTKZbkQ0Xlv/K0Cqrzozzj3AUi4LtX2CZxj CN64VekXSrLeycfFXy3wzjiNI9Wpwnn7G8szB92sqhAfmc5ymQ2Gk3jeHievv4w9VHSb 8gUmk+UNcC/ckXW2DWkhg2eAdv+homgqMdtFCb6MFUhy8iWFzpZLMcTyXXZ7ER1Jns6t GHXKZ4J/tDUT/iszYXEkUM6fGAu1gyotHXW/jsiF70QSK3FRpMHVaybjKJpcYUS2rL2P VAeg== MIME-Version: 1.0 X-Received: by 10.152.27.40 with SMTP id q8mr8816074lag.75.1371964058705; Sat, 22 Jun 2013 22:07:38 -0700 (PDT) Received: by 10.112.51.41 with HTTP; Sat, 22 Jun 2013 22:07:38 -0700 (PDT) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> Date: Sun, 23 Jun 2013 15:07:38 +1000 Message-ID: From: Andrew McGregor To: Acee Lindem Content-Type: multipart/alternative; boundary=089e0158c5aa5d255f04dfcb4626 Cc: Ray Hunter , "homenet@ietf.org Group" , Ted Lemon , Dave Taht , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 05:07:52 -0000 --089e0158c5aa5d255f04dfcb4626 Content-Type: text/plain; charset=ISO-8859-1 I actually think that some MANET technologies are applicable here... I don't recall what happened to its standardisation process, but wOSPF has a lot of nice properties here, not least being that we have homenet considering an OSPF based solution, and wOSPF provides the necessary mechanics to deal with a wireless mesh. This is also a positive for BABEL, it being primarily intended for mesh. Bear in mind that topology updates in fixed wireless mesh mostly come from statistics; you are never going to have 100% reachability probability for your HELLOs (much less than that if they are multicast), and therefore every now and again there will be false unreachability detections. Secondly, wireless channels, even fixed ones, are subject to time variability due to moving reflective objects in the environment; homenet really ought to work on wireless even when there's a street right outside the window, no? This implies taking the wireless mesh case as the default; the protocols will definitely work on wired, and will tend to continue to work even on badly degraded wired links. On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem wrote: > > On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote: > > >> Acee Lindem > >> 22 June 2013 21:30 > >> There seems to be a fundamental disagreement here in terms of > >> requirements. > > possibly. > > > >> With respect to wireless, we all agree that the home will include a > >> large number of wireless devices. > > agree. > >> However, I do not believe all these devices will participate in the > >> routing topology. > > agreed, almost certainly not all. Especially not static sensors. > > > >> Rather, there will be a small finite number of routers with fixed and > >> wireless connectivity that form the home routing infrastructure. > > > > Right. But even if you have 4 or 5 routers (one per room or per floor) > > there's a strong chance that they won't all be in mutual radio contact. > > > > So then you probably cannot assume all 4 or 5 of them are on a single > > shared subnet using the traditional OSPF or IS IS designated router to > > distribute routing information to all the on-link neighbors. > > > > Add to that scenario auto-prefix distribution. How do you establish and > > manage neighbor adjacencies versus subnets/ prefixes? > > > > Or do you presume that the homenet routers will be contiguously > > connected via wires, and there's no wireless router-router connections? > > I'd envision that all home network routers would be connected via wires or > wireless but for topology changes to be infrequent. I don't envision a home > network having the same dynamics as a MANET. > With respect to wireless router-to-router connections, if you cannot > assume mutual radio contact on the same wireless network, we could use P2MP > as the default topology to solve the router-to-router problem. However, > this assumption would break the broadcast model as well for hosts since > basic protocols like ND and ARP assume a broadcast network. > > > > > > > >> I do not believe the requirement is for a MANET network while those > >> active in the MANET WG take this as given. > > > > I never said there'd be a MANET, but we might need to consider that > > there'll be point to point wireless links that act as active adjacencies > > between 2 routers and that there'll be no alternative wired link between > > these routers, whilst at the same time those wireless interfaces are > > serving local end nodes within range. > > Okay. > > > > > > RFC 5820 could be of help in that situation to maintain router-router > > adjacencies as point to point links (without necessarily invoking all of > > MANET requirements for an ad hoc network of many mobile nodes). I don't > > know of any IS IS equivalent. Otherwise I think we might very well get > > into problems with repeaters and packet loss. > > RFC 5820 is specifically to deal with the dynamic topologies and flooding > scale challenges associated with a MANET network. I don't see it as being > applicable to the home network. > > Thanks, > Acee > > > > > > > > > >> Until we agree or agree to disagree on this requirement, we will have > >> wildly divergent opinions on the architecture with respect to routing. > >> Thanks > >> Acee > >> > >> Ray Hunter > >> 22 June 2013 19:14 > >> Dave Taht wrote: > >>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms > wrote: > >>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon > wrote: > >>>> > >>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms > wrote: > >>>>>> The document makes no mention of *how* a largest practical subnet > architecture might be achieved. There should be some requirement that > devices be capable of acting as either a bridge or a router (or a mix of > both), and that devices should bridge unless routing is determined > necessary. > >>>>> I find this text in the document a bit problematic too. I don't > think it's actually reasonably practical to do any such determination. > >>>> Perhaps it should be explicitly called out as an open question in the > architecture document? > >>>> > >>>>> The only practical source of subnet sizing is the size of the > smallest prefix we got from an ISP. I guess there are some ideas we could > suggest, but they look more like solutions than architecture to me. > >>>> The delegated prefixes only provide an upper bound. My concern is > that we're assuming routing in the homenet comes from three sources: > >>>> > >>>> 1) explicitly desired for a specific goal like privacy or traffic > management > >>>> 2) hardware requirements like unbridgeable L2s or where bridging is > for some reason undesirable > >>>> 3) random placement of devices > >>>> 1) requires some sort of explicit management while 3) may incur > unnecessary complexity. 2) might deserve a little more text in the > architecture document so the WG can have a discussion about what can be > supported as "undesirable". > >>>> > >>>>> For instance, we could say that for any given router, all non-edge > interfaces on that router that are of the same media type should be bridged > together into a single subnet. > >>> My definition of media type would treat 2.4ghz and 5.x ghz wireless > >>> differently. does yours? > >> Bridging between the two could be problematic, yes. > >> > >>>> But here's where routing for a desired property and management comes > in ... suppose one of the router ports is to be configured as a separate > link for the "office" subnet? That configuration can't be inferred, I > don't think. > >>> Happens all the time. > >>> > >>>>> CeroWRT makes each one its own subnet, which drives me nuts. > >>> Not clear to me which part of that drives you nuts. In part CeroWrt's > >>> purpose is to expose problems with ideas by putting them out there > >>> annoyingly. > >>> > >>> (The original reason for routing rather than bridging networks in cero > >>> was that we wanted to be able to analyze the effects of routing vs > >>> bridging on wireless. The results of bridging gigE to 2.4ghz are > >>> generally pretty dismal. IPv6 also uses much more multicast than > >>> ipv4.) > >>> > >>> Along the way we gained insight into problems with commonly used > >>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of > >>> which have been solved, some of which have fixes in progress, others > >>> are unsolvable, all are documented publicly on the mailing list, wiki > >>> and issues database. Security is also a problem. Etc. > >>> > >>> If this group would like the reality based list, I can create a rather > >>> large list of hyperlinks at this point. > >>> > >>> The most recent example is the one with problems with windows > >>> filesharing induced by routing: > >>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html > >>> and successful resolution: > >>> > >>> > https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html > >>> > >>> It certainly would be nice for people here to setup more homenet-like > >>> setups to get a grip for common protocols that have issues in routed > >>> environments. I don't setup networks like the yurtlab (86 prefixes) > >>> > >>> http://pastebin.com/K8g5TyXS > >>> > >>> out of any innate love for S&M. > >>> > >>> The thing that drives me nuts here is not the prefix distribution > >>> problem (which is 2 sed commands away per router, once, assuming > >>> stable prefixes) but the the naming problems. I'd like to be able to > >>> get to the printer at the office... but there's now a separate group > >>> for solving that. > >> Agreed. Namespace (and service discovery) will likely remain a > >> significant challenge with competing architectures, never mind > >> implementations. > >> > >> > >>>> This would have the effect that if you plugged a Wifi router's > ethernet port into the ethernet port of a CER, the WiFi router's ethernet > port would be on the same subnet as the CER's ethernet ports, but the Wifi > network would be on its own subnet; hence, routed, not bridged, which I > think is desirable. But does this belong in the architecture document? > >>> I like the "directionless" feature of hipnet. > >>> > >>> I'd like it very much if there was a way to distinguish between a > >>> master and slave router out of the box for both ipv4 and ivp6. If you > >>> plug two routers together on their bridge, they end up competing, if > >>> you plug the uplink of one into the other, you get nat, and either > >>> way, if they are both on 192.168.1.1, weird things happen. > >>> > >>>> I think there needs to be more careful distinction among the three > cases I mentioned earlier. Here, I think you're talking about case 2). > >>>> > >>>> I agree that goals, requirements and problem statements belong in the > architecture document, but (mostly) not solutions. > >>>> > >>>>> Furthermore, it's complicated by the fact that we'd really prefer to > avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite > possible that people will plug such interfaces together. > >>> wireless issue noted above. > >> I agree. AFAIK we do NOT have large scale reference deployments of > >> common IGP's where wireless is used as a connector between multiple > routers. > >> > >> Selecting Designated Router and Backup Designated Router in OSPF and > >> Designated Intermediate System in IS-IS is NOT trivial especially when > >> not all of the routers are within radio range of a common router. In > >> fact I think we may well be missing a trick here, and we may need some > >> form of mesh under network, at least between the routers connected via a > >> common wireless link but where they are not all mutually within range of > >> each other. Wireless to wireless bridging / repeating also seems to be > >> highly proprietary and problematic. > >> > >> > >>> Am I the only one in this group that > >>> actually has the vast majority of devices in home and office wireless? > >> No. > >> > >>> Is there anybody here that doesn't think that the vast majority of > >>> devices in the home will be wireless? > >> Not me. > >> > >>>>> So we may need to decide very dynamically which interfaces are > bridged and which are routed. Maybe we will have virtual bridged networks > on each homenet router for each media type and speed that the router > supports, and dynamically connect interfaces that are running at that speed > to those bridges, and hope that this works. > >>>>> > >>>>> I don't think we've visited this issue thoroughly enough to make > statements about it in the architecture document. > >>>> Maybe it needs to be cited as an open question? I'll re-read the > document; statements like "we'd really prefer to avoid briding between > 10mbps, 100mbps and 1Mbps internet" ought to be made explicit and justified. > >>> see above. > >>> > >>> > >> > >> ------------------------------------------------------------------------ > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --089e0158c5aa5d255f04dfcb4626 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I actually think that some MANET technologies are applicab= le here... I don't recall what happened to its standardisation process,= but wOSPF has a lot of nice properties here, not least being that we have = homenet considering an OSPF based solution, and wOSPF provides the necessar= y mechanics to deal with a wireless mesh. =A0This is also a positive for BA= BEL, it being primarily intended for mesh.

Bear in mind that topology updates in fixed wireless mesh mo= stly come from statistics; you are never going to have 100% reachability pr= obability for your HELLOs (much less than that if they are multicast), and = therefore every now and again there will be false unreachability detections= . =A0Secondly, wireless channels, even fixed ones, are subject to time vari= ability due to moving reflective objects in the environment; homenet really= ought to work on wireless even when there's a street right outside the= window, no? =A0This implies taking the wireless mesh case as the default; = the protocols will definitely work on wired, and will tend to continue to w= ork even on badly degraded wired links.


On Sun,= Jun 23, 2013 at 7:20 AM, Acee Lindem <acee.lindem@ericsson.com= > wrote:

On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote:

>> Acee Lindem <mailto:acee.lindem@ericsson.com>
>> 22 June 2013 21:30
>> There seems to be a fundamental disagreement here in terms of
>> requirements.
> possibly.
>
>> With respect to wireless, we all agree that the home will include = a
>> large number of wireless devices.
> agree.
>> However, I do not believe all these devices will participate in th= e
>> routing topology.
> agreed, almost certainly not all. Especially not static sensors.
>
>> Rather, there will be a small finite number of routers with fixed = and
>> wireless connectivity that form the home routing infrastructure. >
> Right. But even if you have 4 or 5 routers (one per room or per floor)=
> there's a strong chance that they won't all be in mutual radio= contact.
>
> So then you probably cannot assume all 4 or 5 of them are on a single<= br> > shared subnet using the traditional OSPF or IS IS designated router to=
> distribute routing information to all the on-link neighbors.
>
> Add to that scenario auto-prefix distribution. How do you establish an= d
> manage neighbor adjacencies versus subnets/ prefixes?
>
> Or do you presume that the homenet routers will be contiguously
> connected via wires, and there's no wireless router-router connect= ions?

I'd envision that all home network routers would be connected via= wires or wireless but for topology changes to be infrequent. I don't e= nvision a home network having the same dynamics as a MANET.
With respect to wireless router-to-router connections, if you cannot assume= mutual radio contact on the same wireless network, we could use P2MP as th= e default topology to solve the router-to-router problem. However, this ass= umption would break the broadcast model as well for hosts since basic proto= cols like ND and ARP assume a broadcast network.


>
>
>> I do not believe the requirement is for a MANET network while thos= e
>> active in the MANET WG take this as given.
>
> I never said there'd be a MANET, but we might need to consider tha= t
> there'll be point to point wireless links that act as active adjac= encies
> between 2 routers and that there'll be no alternative wired link b= etween
> these routers, whilst at the same time those wireless interfaces are > serving local end nodes within range.

Okay.


>
> RFC 5820 could be of help in that situation to maintain router-router<= br> > adjacencies as point to point links (without necessarily invoking all = of
> MANET requirements for an ad hoc network of many mobile nodes). I don&= #39;t
> know of any IS IS equivalent. Otherwise I think we might very well get=
> into problems with repeaters and packet loss.

RFC 5820 is specifically to deal with the dynamic topologies and floo= ding scale challenges associated with a MANET network. I don't see it a= s being applicable to the home network.

Thanks,
Acee


>
>
>
>> Until we agree or agree to disagree on this requirement, we will h= ave
>> wildly divergent opinions on the architecture with respect to rout= ing.
>> Thanks
>> Acee
>>
>> Ray Hunter <mailto:v6ops@gl= obis.net>
>> 22 June 2013 19:14
>> Dave Taht wrote:
>>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon <mellon@fugue.com> wrote:
>>>>
>>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>>>>>> The document makes no mention of *how* a largest p= ractical subnet architecture might be achieved. =A0There should be some req= uirement that devices be capable of acting as either a bridge or a router (= or a mix of both), and that devices should bridge unless routing is determi= ned necessary.
>>>>> I find this text in the document a bit problematic too= . =A0 I don't think it's actually reasonably practical to do any su= ch determination.
>>>> Perhaps it should be explicitly called out as an open ques= tion in the architecture document?
>>>>
>>>>> The only practical source of subnet sizing is the size= of the smallest prefix we got from an ISP. =A0 I guess there are some idea= s we could suggest, but they look more like solutions than architecture to = me.
>>>> The delegated prefixes only provide an upper bound. =A0My = concern is that we're assuming routing in the homenet comes from three = sources:
>>>>
>>>> 1) explicitly desired for a specific goal like privacy or = traffic management
>>>> 2) hardware requirements like unbridgeable L2s or where br= idging is for some reason undesirable
>>>> 3) random placement of devices
>>>> 1) requires some sort of explicit management while 3) may = incur unnecessary complexity. =A02) might deserve a little more text in the= architecture document so the WG can have a discussion about what can be su= pported as "undesirable".
>>>>
>>>>> For instance, we could say that for any given router, = all non-edge interfaces on that router that are of the same media type shou= ld be bridged together into a single subnet.
>>> My definition of media type would treat 2.4ghz and 5.x ghz wir= eless
>>> differently. does yours?
>> Bridging between the two could be problematic, yes.
>>
>>>> But here's where routing for a desired property and ma= nagement comes in ... suppose one of the router ports is to be configured a= s a separate link for the "office" subnet? =A0That configuration = can't be inferred, I don't think.
>>> Happens all the time.
>>>
>>>>> =A0CeroWRT makes each one its own subnet, which drives= me nuts.
>>> Not clear to me which part of that drives you nuts. In part Ce= roWrt's
>>> purpose is to expose problems with ideas by putting them out t= here
>>> annoyingly.
>>>
>>> (The original reason for routing rather than bridging networks= in cero
>>> was that we wanted to be able to analyze the effects of routin= g vs
>>> bridging on wireless. The results of bridging gigE to 2.4ghz a= re
>>> generally pretty dismal. IPv6 also uses much more multicast th= an
>>> ipv4.)
>>>
>>> Along the way we gained insight into problems with commonly us= ed
>>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. S= ome of
>>> which have been solved, some of which have fixes in progress, = others
>>> are unsolvable, all are documented publicly on the mailing lis= t, wiki
>>> and issues database. Security is also a problem. Etc.
>>>
>>> If this group would like the reality based list, I can create = a rather
>>> large list of hyperlinks at this point.
>>>
>>> The most recent example is the one with problems with windows<= br> >>> filesharing induced by routing:
>>> https://lists.bufferbloat.net/pipermail= /bloat/2013-June/001577.html
>>> and successful resolution:
>>>
>>> https://lists.bufferbloat.net/p= ipermail/cerowrt-devel/2013-June/001321.html
>>>
>>> It certainly would be nice for people here to setup more homen= et-like
>>> setups to get a grip for common protocols that have issues in = routed
>>> environments. I don't setup networks like the yurtlab (86 = prefixes)
>>>
>>> htt= p://pastebin.com/K8g5TyXS
>>>
>>> out of any innate love for S&M.
>>>
>>> The thing that drives me nuts here is not the prefix distribut= ion
>>> problem (which is 2 sed commands away per router, once, assumi= ng
>>> stable prefixes) but the the naming problems. I'd like to = be able to
>>> get to the printer at the office... but there's now a sepa= rate group
>>> for solving that.
>> Agreed. Namespace (and service discovery) will likely remain a
>> significant challenge with competing architectures, never mind
>> implementations.
>>
>>
>>>> This would have the effect that if you plugged a Wifi rout= er's ethernet port into the ethernet port of a CER, the WiFi router'= ;s ethernet port would be on the same subnet as the CER's ethernet port= s, but the Wifi network would be on its own subnet; hence, routed, not brid= ged, which I think is desirable. =A0 But does this belong in the architectu= re document?
>>> I like the "directionless" feature of hipnet.
>>>
>>> I'd like it very much if there was a way to distinguish be= tween a
>>> master and slave router out of the box for both ipv4 and ivp6.= If you
>>> plug two routers together on their bridge, they end up competi= ng, if
>>> you plug the uplink of one into the other, you get nat, and ei= ther
>>> way, if they are both on 192.168.1.1, weird things happen.
>>>
>>>> I think there needs to be more careful distinction among t= he three cases I mentioned earlier. =A0Here, I think you're talking abo= ut case 2).
>>>>
>>>> I agree that goals, requirements and problem statements be= long in the architecture document, but (mostly) not solutions.
>>>>
>>>>> Furthermore, it's complicated by the fact that we&= #39;d really prefer to avoid briding between 10mbps, 100mbps and 1Mbps inte= rnet, and it's quite possible that people will plug such interfaces tog= ether.
>>> wireless issue noted above.
>> I agree. AFAIK we do NOT have large scale reference deployments of=
>> common IGP's where wireless is used as a connector between mul= tiple routers.
>>
>> Selecting Designated Router and Backup Designated Router in OSPF a= nd
>> Designated Intermediate System in IS-IS is NOT trivial especially = when
>> not all of the routers are within radio range of a common router. = In
>> fact I think we may well be missing a trick here, and we may need = some
>> form of mesh under network, at least between the routers connected= via a
>> common wireless link but where they are not all mutually within ra= nge of
>> each other. Wireless to wireless bridging / repeating also seems t= o be
>> highly proprietary and problematic.
>>
>>
>>> Am I the only one in this group that
>>> actually has the vast majority of devices in home and office w= ireless?
>> No.
>>
>>> Is there anybody here that doesn't think that the vast maj= ority of
>>> devices in the home will be wireless?
>> Not me.
>>
>>>>> =A0So we may need to decide very dynamically which int= erfaces are bridged and which are routed. =A0 Maybe we will have virtual br= idged networks on each homenet router for each media type and speed that th= e router supports, and dynamically connect interfaces that are running at t= hat speed to those bridges, and hope that this works.
>>>>>
>>>>> I don't think we've visited this issue thoroug= hly enough to make statements about it in the architecture document.
>>>> Maybe it needs to be cited as an open question? =A0I'l= l re-read the document; statements like "we'd really prefer to avo= id briding between 10mbps, 100mbps and 1Mbps internet" ought to be mad= e explicit and justified.
>>> see above.
>>>
>>> <snip>
>>
>> ------------------------------------------------------------------= ------
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

--089e0158c5aa5d255f04dfcb4626-- From hrogge@googlemail.com Sun Jun 23 01:20:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BC521F9ED4 for ; Sun, 23 Jun 2013 01:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyncIFjmXWWx for ; Sun, 23 Jun 2013 01:20:19 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E321F9E17 for ; Sun, 23 Jun 2013 01:20:18 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so5554073qcv.23 for ; Sun, 23 Jun 2013 01:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1V2nRR93mhImSpo4y6tEcVWI73inMw1rYYq6fC/++sI=; b=Fe3keVzVfpysAEMeh4BOJvO9AJ1srlwGvmqBFobsdhG4eZltbvO8NuPPxcq1QF3QtC o2fsYyXE74zhCikQVVWwtx8K9n94y7o/TelUAj5zdEa3VLlUiviHo4zgCBSdVqyuumGT 02dPYSdOUdDuHtRAviQWzPQG44UDB6mDlPinc51jIOJlp1JMIygOMY21nPXIFRIl0geF pcmqJFkN7k7Na6vzwcw2e6vKIgmOvKTMZ9+Jxa6IrxQX43GwHcS+JKoPsBOTWWRham42 nGHw+9DSaPEWQmZd2pDonhgwJs6uT9gnwWderwc88qhbOX0z/E8HkVIzF20744JLe9Q3 Sg3Q== X-Received: by 10.224.51.7 with SMTP id b7mr21899377qag.8.1371975616678; Sun, 23 Jun 2013 01:20:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.82 with HTTP; Sun, 23 Jun 2013 01:19:56 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> From: Henning Rogge Date: Sun, 23 Jun 2013 10:19:56 +0200 Message-ID: To: Andrew McGregor Content-Type: text/plain; charset=ISO-8859-1 Cc: Ted Lemon , Dave Taht , Ray Hunter , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 08:20:19 -0000 On Sun, Jun 23, 2013 at 7:07 AM, Andrew McGregor wrote: > I actually think that some MANET technologies are applicable here... I don't > recall what happened to its standardisation process, but wOSPF has a lot of > nice properties here, not least being that we have homenet considering an > OSPF based solution, and wOSPF provides the necessary mechanics to deal with > a wireless mesh. This is also a positive for BABEL, it being primarily > intended for mesh. Is there a reason not to consider using OLSRv2 as the routing protocol if you are running a mesh? Henning Rogge ---- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From acee.lindem@ericsson.com Sun Jun 23 03:38:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A669C21F9A62 for ; Sun, 23 Jun 2013 03:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3xqEJV1jZRh for ; Sun, 23 Jun 2013 03:37:56 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C6B3C21F9A5E for ; Sun, 23 Jun 2013 03:37:55 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-5a-51c6d002d044 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 65.3D.05617.200D6C15; Sun, 23 Jun 2013 12:37:54 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 06:37:53 -0400 From: Acee Lindem To: Andrew McGregor Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAXEzICAAvmhgIACyQCAgAClugCAAUFJAIAAJdSAgAAJ34CAABT+gIAAgnQAgABcQ4A= Date: Sun, 23 Jun 2013 10:37:52 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47186532eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPiC7ThWOBBte3Slvs7Dew2LPxJIvF +0WHWCzerDnCZNF4rY/VYs/Vegc2j6YLy9g9npy9zuaxc9Zddo8lS34yBbBEcdmkpOZklqUW 6dslcGXcvLWfteDUe8aKR037GBsYDx5j7GLk5JAQMJH4cuwzG4QtJnHh3nogm4tDSOAoo8TP VQsYIZzljBIzl39gBaliE9CReP7oHzOILSKgJTH3220WkCJmgW2MEtMvfWUHSQgLeEr8f3+D CaLIS2L2wS42CLtMouv8MzCbRUBVYtepGSwgNq+At8T8bc+htnWwSix5OA3sPk6BQInP7xvB GhiB7vt+ag3YUGYBcYlbT+YzQdwtILFkz3lmCFtU4uXjf6wQtrLEkif7WSDq8yV61u1ih1gm KHFy5hOWCYyis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPIbqtZY4NvcXipoFjByr GDlKi1PLctONDDcxAuP1mASb4w7GBZ8sDzFKc7AoifO+P7UrUEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVANj0Xfvn9G3zxRnHujWubq88Wy5FMOr7GknHFgLdr742xJQ9X+X93npm/1bH7v6 L912PdPHXcMt4bPMDTuvtjUFt3X63PnWO7Hsnhdkt8rMksP5++r9axb6/wvJmxdRHH9N43n6 7/raqdm6S5mkZi+4LdX3T9Aq7oftGSaRH1m/vjj/Yy/WEjRWYinOSDTUYi4qTgQAPsoEyaUC AAA= Cc: Ray Hunter , "homenet@ietf.org Group" , Ted Lemon , Dave Taht , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:38:00 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47186532eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 23, 2013, at 1:07 AM, Andrew McGregor wrote: I actually think that some MANET technologies are applicable here... I don'= t recall what happened to its standardisation process, but wOSPF has a lot = of nice properties here, not least being that we have homenet considering a= n OSPF based solution, and wOSPF provides the necessary mechanics to deal w= ith a wireless mesh. This is also a positive for BABEL, it being primarily= intended for mesh. By wOSPF, I guess you mean the OSPF MANET options. I believe RFC 5820 and R= FC 5614 have seen some usage. Bear in mind that topology updates in fixed wireless mesh mostly come from = statistics; you are never going to have 100% reachability probability for y= our HELLOs (much less than that if they are multicast), and therefore every= now and again there will be false unreachability detections. Secondly, wi= reless channels, even fixed ones, are subject to time variability due to mo= ving reflective objects in the environment; homenet really ought to work on= wireless even when there's a street right outside the window, no? This im= plies taking the wireless mesh case as the default; the protocols will defi= nitely work on wired, and will tend to continue to work even on badly degra= ded wired links. The problem with using a mesh topology by default is that it doesn't handle= the non-routers very well unless they also participate in the mesh and hav= e their host addresses advertised independently like the routers. At least = this is the case for OSPF P2MP and the OSPF MANET variants - the assumption= is that all devices connecting to the mesh form routing protocol adjacenci= es. Thanks, Acee On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem > wrote: On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote: >> Acee Lindem > >> 22 June 2013 21:30 >> There seems to be a fundamental disagreement here in terms of >> requirements. > possibly. > >> With respect to wireless, we all agree that the home will include a >> large number of wireless devices. > agree. >> However, I do not believe all these devices will participate in the >> routing topology. > agreed, almost certainly not all. Especially not static sensors. > >> Rather, there will be a small finite number of routers with fixed and >> wireless connectivity that form the home routing infrastructure. > > Right. But even if you have 4 or 5 routers (one per room or per floor) > there's a strong chance that they won't all be in mutual radio contact. > > So then you probably cannot assume all 4 or 5 of them are on a single > shared subnet using the traditional OSPF or IS IS designated router to > distribute routing information to all the on-link neighbors. > > Add to that scenario auto-prefix distribution. How do you establish and > manage neighbor adjacencies versus subnets/ prefixes? > > Or do you presume that the homenet routers will be contiguously > connected via wires, and there's no wireless router-router connections? I'd envision that all home network routers would be connected via wires or = wireless but for topology changes to be infrequent. I don't envision a home= network having the same dynamics as a MANET. With respect to wireless router-to-router connections, if you cannot assume= mutual radio contact on the same wireless network, we could use P2MP as th= e default topology to solve the router-to-router problem. However, this ass= umption would break the broadcast model as well for hosts since basic proto= cols like ND and ARP assume a broadcast network. > > >> I do not believe the requirement is for a MANET network while those >> active in the MANET WG take this as given. > > I never said there'd be a MANET, but we might need to consider that > there'll be point to point wireless links that act as active adjacencies > between 2 routers and that there'll be no alternative wired link between > these routers, whilst at the same time those wireless interfaces are > serving local end nodes within range. Okay. > > RFC 5820 could be of help in that situation to maintain router-router > adjacencies as point to point links (without necessarily invoking all of > MANET requirements for an ad hoc network of many mobile nodes). I don't > know of any IS IS equivalent. Otherwise I think we might very well get > into problems with repeaters and packet loss. RFC 5820 is specifically to deal with the dynamic topologies and flooding s= cale challenges associated with a MANET network. I don't see it as being ap= plicable to the home network. Thanks, Acee > > > >> Until we agree or agree to disagree on this requirement, we will have >> wildly divergent opinions on the architecture with respect to routing. >> Thanks >> Acee >> >> Ray Hunter > >> 22 June 2013 19:14 >> Dave Taht wrote: >>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms > wrote: >>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon > wrote: >>>> >>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms > wrote: >>>>>> The document makes no mention of *how* a largest practical subnet ar= chitecture might be achieved. There should be some requirement that device= s be capable of acting as either a bridge or a router (or a mix of both), a= nd that devices should bridge unless routing is determined necessary. >>>>> I find this text in the document a bit problematic too. I don't thi= nk it's actually reasonably practical to do any such determination. >>>> Perhaps it should be explicitly called out as an open question in the = architecture document? >>>> >>>>> The only practical source of subnet sizing is the size of the smalles= t prefix we got from an ISP. I guess there are some ideas we could sugges= t, but they look more like solutions than architecture to me. >>>> The delegated prefixes only provide an upper bound. My concern is tha= t we're assuming routing in the homenet comes from three sources: >>>> >>>> 1) explicitly desired for a specific goal like privacy or traffic mana= gement >>>> 2) hardware requirements like unbridgeable L2s or where bridging is fo= r some reason undesirable >>>> 3) random placement of devices >>>> 1) requires some sort of explicit management while 3) may incur unnece= ssary complexity. 2) might deserve a little more text in the architecture = document so the WG can have a discussion about what can be supported as "un= desirable". >>>> >>>>> For instance, we could say that for any given router, all non-edge in= terfaces on that router that are of the same media type should be bridged t= ogether into a single subnet. >>> My definition of media type would treat 2.4ghz and 5.x ghz wireless >>> differently. does yours? >> Bridging between the two could be problematic, yes. >> >>>> But here's where routing for a desired property and management comes i= n ... suppose one of the router ports is to be configured as a separate lin= k for the "office" subnet? That configuration can't be inferred, I don't t= hink. >>> Happens all the time. >>> >>>>> CeroWRT makes each one its own subnet, which drives me nuts. >>> Not clear to me which part of that drives you nuts. In part CeroWrt's >>> purpose is to expose problems with ideas by putting them out there >>> annoyingly. >>> >>> (The original reason for routing rather than bridging networks in cero >>> was that we wanted to be able to analyze the effects of routing vs >>> bridging on wireless. The results of bridging gigE to 2.4ghz are >>> generally pretty dismal. IPv6 also uses much more multicast than >>> ipv4.) >>> >>> Along the way we gained insight into problems with commonly used >>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of >>> which have been solved, some of which have fixes in progress, others >>> are unsolvable, all are documented publicly on the mailing list, wiki >>> and issues database. Security is also a problem. Etc. >>> >>> If this group would like the reality based list, I can create a rather >>> large list of hyperlinks at this point. >>> >>> The most recent example is the one with problems with windows >>> filesharing induced by routing: >>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html >>> and successful resolution: >>> >>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.= html >>> >>> It certainly would be nice for people here to setup more homenet-like >>> setups to get a grip for common protocols that have issues in routed >>> environments. I don't setup networks like the yurtlab (86 prefixes) >>> >>> http://pastebin.com/K8g5TyXS >>> >>> out of any innate love for S&M. >>> >>> The thing that drives me nuts here is not the prefix distribution >>> problem (which is 2 sed commands away per router, once, assuming >>> stable prefixes) but the the naming problems. I'd like to be able to >>> get to the printer at the office... but there's now a separate group >>> for solving that. >> Agreed. Namespace (and service discovery) will likely remain a >> significant challenge with competing architectures, never mind >> implementations. >> >> >>>> This would have the effect that if you plugged a Wifi router's etherne= t port into the ethernet port of a CER, the WiFi router's ethernet port wou= ld be on the same subnet as the CER's ethernet ports, but the Wifi network = would be on its own subnet; hence, routed, not bridged, which I think is de= sirable. But does this belong in the architecture document? >>> I like the "directionless" feature of hipnet. >>> >>> I'd like it very much if there was a way to distinguish between a >>> master and slave router out of the box for both ipv4 and ivp6. If you >>> plug two routers together on their bridge, they end up competing, if >>> you plug the uplink of one into the other, you get nat, and either >>> way, if they are both on 192.168.1.1, weird things happen. >>> >>>> I think there needs to be more careful distinction among the three cas= es I mentioned earlier. Here, I think you're talking about case 2). >>>> >>>> I agree that goals, requirements and problem statements belong in the = architecture document, but (mostly) not solutions. >>>> >>>>> Furthermore, it's complicated by the fact that we'd really prefer to = avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite po= ssible that people will plug such interfaces together. >>> wireless issue noted above. >> I agree. AFAIK we do NOT have large scale reference deployments of >> common IGP's where wireless is used as a connector between multiple rout= ers. >> >> Selecting Designated Router and Backup Designated Router in OSPF and >> Designated Intermediate System in IS-IS is NOT trivial especially when >> not all of the routers are within radio range of a common router. In >> fact I think we may well be missing a trick here, and we may need some >> form of mesh under network, at least between the routers connected via a >> common wireless link but where they are not all mutually within range of >> each other. Wireless to wireless bridging / repeating also seems to be >> highly proprietary and problematic. >> >> >>> Am I the only one in this group that >>> actually has the vast majority of devices in home and office wireless? >> No. >> >>> Is there anybody here that doesn't think that the vast majority of >>> devices in the home will be wireless? >> Not me. >> >>>>> So we may need to decide very dynamically which interfaces are bridg= ed and which are routed. Maybe we will have virtual bridged networks on e= ach homenet router for each media type and speed that the router supports, = and dynamically connect interfaces that are running at that speed to those = bridges, and hope that this works. >>>>> >>>>> I don't think we've visited this issue thoroughly enough to make stat= ements about it in the architecture document. >>>> Maybe it needs to be cited as an open question? I'll re-read the docu= ment; statements like "we'd really prefer to avoid briding between 10mbps, = 100mbps and 1Mbps internet" ought to be made explicit and justified. >>> see above. >>> >>> >> >> ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --_000_94A203EA12AECE4BA92D42DBFFE0AE47186532eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 23, 2013, at 1:07 AM, Andrew McGregor wrote:

I actually think that some MANET technologies are applicab= le here... I don't recall what happened to its standardisation process, but= wOSPF has a lot of nice properties here, not least being that we have home= net considering an OSPF based solution, and wOSPF provides the necessary mechanics to deal with a wireless mesh. &= nbsp;This is also a positive for BABEL, it being primarily intended for mes= h.

By wOSPF, I guess you mean the OSPF MANET options. I believe RFC 5820 = and RFC 5614 have seen some usage. 


Bear in mind that topology updates in fixed wireless mesh mostly come = from statistics; you are never going to have 100% reachability probability = for your HELLOs (much less than that if they are multicast), and therefore = every now and again there will be false unreachability detections.  Secondly, wireless channels, even f= ixed ones, are subject to time variability due to moving reflective objects= in the environment; homenet really ought to work on wireless even when the= re's a street right outside the window, no?  This implies taking the wireless mesh case as the default; the p= rotocols will definitely work on wired, and will tend to continue to work e= ven on badly degraded wired links.

The problem with using a mesh topology by default is that it doesn't h= andle the non-routers very well unless they also participate in the mesh an= d have their host addresses advertised independently like the routers. At l= east this is the case for OSPF P2MP and the OSPF MANET variants - the assumption is that all devices connectin= g to the mesh form routing protocol adjacencies. 

Thanks,
Acee 





On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem <acee.lind= em@ericsson.com> wrote:

On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote:

>> Acee Lindem <mailto:acee.lindem@ericsson.com>
>> 22 June 2013 21:30
>> There seems to be a fundamental disagreement here in terms of
>> requirements.
> possibly.
>
>> With respect to wireless, we all agree that the home will include = a
>> large number of wireless devices.
> agree.
>> However, I do not believe all these devices will participate in th= e
>> routing topology.
> agreed, almost certainly not all. Especially not static sensors.
>
>> Rather, there will be a small finite number of routers with fixed = and
>> wireless connectivity that form the home routing infrastructure. >
> Right. But even if you have 4 or 5 routers (one per room or per floor)=
> there's a strong chance that they won't all be in mutual radio contact= .
>
> So then you probably cannot assume all 4 or 5 of them are on a single<= br> > shared subnet using the traditional OSPF or IS IS designated router to=
> distribute routing information to all the on-link neighbors.
>
> Add to that scenario auto-prefix distribution. How do you establish an= d
> manage neighbor adjacencies versus subnets/ prefixes?
>
> Or do you presume that the homenet routers will be contiguously
> connected via wires, and there's no wireless router-router connections= ?

I'd envision that all home network routers would be connected via wires or = wireless but for topology changes to be infrequent. I don't envision a home= network having the same dynamics as a MANET.
With respect to wireless router-to-router connections, if you cannot assume= mutual radio contact on the same wireless network, we could use P2MP as th= e default topology to solve the router-to-router problem. However, this ass= umption would break the broadcast model as well for hosts since basic protocols like ND and ARP assume a bro= adcast network.


>
>
>> I do not believe the requirement is for a MANET network while thos= e
>> active in the MANET WG take this as given.
>
> I never said there'd be a MANET, but we might need to consider that > there'll be point to point wireless links that act as active adjacenci= es
> between 2 routers and that there'll be no alternative wired link betwe= en
> these routers, whilst at the same time those wireless interfaces are > serving local end nodes within range.

Okay.


>
> RFC 5820 could be of help in that situation to maintain router-router<= br> > adjacencies as point to point links (without necessarily invoking all = of
> MANET requirements for an ad hoc network of many mobile nodes). I don'= t
> know of any IS IS equivalent. Otherwise I think we might very well get=
> into problems with repeaters and packet loss.

RFC 5820 is specifically to deal with the dynamic topologies and flooding s= cale challenges associated with a MANET network. I don't see it as being ap= plicable to the home network.

Thanks,
Acee


>
>
>
>> Until we agree or agree to disagree on this requirement, we will h= ave
>> wildly divergent opinions on the architecture with respect to rout= ing.
>> Thanks
>> Acee
>>
>> Ray Hunter <mailto:v6ops@gl= obis.net>
>> 22 June 2013 19:14
>> Dave Taht wrote:
>>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon <mellon@fugue.com> wrote:
>>>>
>>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>>>>>> The document makes no mention of *how* a largest p= ractical subnet architecture might be achieved.  There should be some = requirement that devices be capable of acting as either a bridge or a route= r (or a mix of both), and that devices should bridge unless routing is determined necessary.
>>>>> I find this text in the document a bit problematic too= .   I don't think it's actually reasonably practical to do any such de= termination.
>>>> Perhaps it should be explicitly called out as an open ques= tion in the architecture document?
>>>>
>>>>> The only practical source of subnet sizing is the size= of the smallest prefix we got from an ISP.   I guess there are some i= deas we could suggest, but they look more like solutions than architecture = to me.
>>>> The delegated prefixes only provide an upper bound.  = My concern is that we're assuming routing in the homenet comes from three s= ources:
>>>>
>>>> 1) explicitly desired for a specific goal like privacy or = traffic management
>>>> 2) hardware requirements like unbridgeable L2s or where br= idging is for some reason undesirable
>>>> 3) random placement of devices
>>>> 1) requires some sort of explicit management while 3) may = incur unnecessary complexity.  2) might deserve a little more text in = the architecture document so the WG can have a discussion about what can be= supported as "undesirable".
>>>>
>>>>> For instance, we could say that for any given router, = all non-edge interfaces on that router that are of the same media type shou= ld be bridged together into a single subnet.
>>> My definition of media type would treat 2.4ghz and 5.x ghz wir= eless
>>> differently. does yours?
>> Bridging between the two could be problematic, yes.
>>
>>>> But here's where routing for a desired property and manage= ment comes in ... suppose one of the router ports is to be configured as a = separate link for the "office" subnet?  That configuration c= an't be inferred, I don't think.
>>> Happens all the time.
>>>
>>>>>  CeroWRT makes each one its own subnet, which dri= ves me nuts.
>>> Not clear to me which part of that drives you nuts. In part Ce= roWrt's
>>> purpose is to expose problems with ideas by putting them out t= here
>>> annoyingly.
>>>
>>> (The original reason for routing rather than bridging networks= in cero
>>> was that we wanted to be able to analyze the effects of routin= g vs
>>> bridging on wireless. The results of bridging gigE to 2.4ghz a= re
>>> generally pretty dismal. IPv6 also uses much more multicast th= an
>>> ipv4.)
>>>
>>> Along the way we gained insight into problems with commonly us= ed
>>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. S= ome of
>>> which have been solved, some of which have fixes in progress, = others
>>> are unsolvable, all are documented publicly on the mailing lis= t, wiki
>>> and issues database. Security is also a problem. Etc.
>>>
>>> If this group would like the reality based list, I can create = a rather
>>> large list of hyperlinks at this point.
>>>
>>> The most recent example is the one with problems with windows<= br> >>> filesharing induced by routing:
>>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html
>>> and successful resolution:
>>>
>>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html=
>>>
>>> It certainly would be nice for people here to setup more homen= et-like
>>> setups to get a grip for common protocols that have issues in = routed
>>> environments. I don't setup networks like the yurtlab (86 pref= ixes)
>>>
>>> htt= p://pastebin.com/K8g5TyXS
>>>
>>> out of any innate love for S&M.
>>>
>>> The thing that drives me nuts here is not the prefix distribut= ion
>>> problem (which is 2 sed commands away per router, once, assumi= ng
>>> stable prefixes) but the the naming problems. I'd like to be a= ble to
>>> get to the printer at the office... but there's now a separate= group
>>> for solving that.
>> Agreed. Namespace (and service discovery) will likely remain a
>> significant challenge with competing architectures, never mind
>> implementations.
>>
>>
>>>> This would have the effect that if you plugged a Wifi rout= er's ethernet port into the ethernet port of a CER, the WiFi router's ether= net port would be on the same subnet as the CER's ethernet ports, but the W= ifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable.   But does this belo= ng in the architecture document?
>>> I like the "directionless" feature of hipnet.
>>>
>>> I'd like it very much if there was a way to distinguish betwee= n a
>>> master and slave router out of the box for both ipv4 and ivp6.= If you
>>> plug two routers together on their bridge, they end up competi= ng, if
>>> you plug the uplink of one into the other, you get nat, and ei= ther
>>> way, if they are both on 192.168.1.1, weird things happen.
>>>
>>>> I think there needs to be more careful distinction among t= he three cases I mentioned earlier.  Here, I think you're talking abou= t case 2).
>>>>
>>>> I agree that goals, requirements and problem statements be= long in the architecture document, but (mostly) not solutions.
>>>>
>>>>> Furthermore, it's complicated by the fact that we'd re= ally prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet, an= d it's quite possible that people will plug such interfaces together.
>>> wireless issue noted above.
>> I agree. AFAIK we do NOT have large scale reference deployments of=
>> common IGP's where wireless is used as a connector between multipl= e routers.
>>
>> Selecting Designated Router and Backup Designated Router in OSPF a= nd
>> Designated Intermediate System in IS-IS is NOT trivial especially = when
>> not all of the routers are within radio range of a common router. = In
>> fact I think we may well be missing a trick here, and we may need = some
>> form of mesh under network, at least between the routers connected= via a
>> common wireless link but where they are not all mutually within ra= nge of
>> each other. Wireless to wireless bridging / repeating also seems t= o be
>> highly proprietary and problematic.
>>
>>
>>> Am I the only one in this group that
>>> actually has the vast majority of devices in home and office w= ireless?
>> No.
>>
>>> Is there anybody here that doesn't think that the vast majorit= y of
>>> devices in the home will be wireless?
>> Not me.
>>
>>>>>  So we may need to decide very dynamically which = interfaces are bridged and which are routed.   Maybe we will have virt= ual bridged networks on each homenet router for each media type and speed t= hat the router supports, and dynamically connect interfaces that are running at that speed to those bridges, and hope that this works.=
>>>>>
>>>>> I don't think we've visited this issue thoroughly enou= gh to make statements about it in the architecture document.
>>>> Maybe it needs to be cited as an open question?  I'll= re-read the document; statements like "we'd really prefer to avoid br= iding between 10mbps, 100mbps and 1Mbps internet" ought to be made exp= licit and justified.
>>> see above.
>>>
>>> <snip>
>>
>> ------------------------------------------------------------------= ------
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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


--_000_94A203EA12AECE4BA92D42DBFFE0AE47186532eusaamb101ericsso_-- From andrewmcgr@gmail.com Sun Jun 23 04:24:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDE821F9C96 for ; Sun, 23 Jun 2013 04:24:31 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfr9R2TiaEq5 for ; Sun, 23 Jun 2013 04:24:29 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7205C21F915B for ; Sun, 23 Jun 2013 04:24:28 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fo12so9184890lab.39 for ; Sun, 23 Jun 2013 04:24:27 -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; bh=qNtehCe7Z3i9GSmk6nu2f7M1BVl4AD3H/BbzCK888EY=; b=ZweY+jHykuAUWOBYeWq0V0XwETDevct0i/J4WOpW2wCByyanpvi8U/nlbkBA30LxUI 4BtCSnqBbBmRcT4EGiecL0WxE2XDcNwPVUbHZnP1S8jP0rubF1dEC5utO3CHgNZf8VEI 2lUTK3d1eQIUb91HfG0zIKiyn50szJolD0BX7WqzBbVNjGKpfC3cfZNVlnnFtf+q6MWN ZLA8UUv30yiX9G8s10pS9x02R1bLZQGBYAU6fEBjjc6SSIBvIooiiv3e53GDcGJFjKpW kMrEFx7M7cNe3jOgvT8zJOAluYNv9HNhLnQcaOzitjai08ZJ3mNxKiCgPhY4WFVGb3S3 RlwA== MIME-Version: 1.0 X-Received: by 10.152.170.162 with SMTP id an2mr9328941lac.3.1371986667116; Sun, 23 Jun 2013 04:24:27 -0700 (PDT) Received: by 10.112.51.41 with HTTP; Sun, 23 Jun 2013 04:24:26 -0700 (PDT) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> Date: Sun, 23 Jun 2013 21:24:26 +1000 Message-ID: From: Andrew McGregor To: Acee Lindem Content-Type: multipart/alternative; boundary=089e011615e4ee205d04dfd0899a Cc: Ray Hunter , "homenet@ietf.org Group" , Ted Lemon , Dave Taht , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 11:24:31 -0000 --089e011615e4ee205d04dfd0899a Content-Type: text/plain; charset=ISO-8859-1 So, I believe you could do this: use one SSID for meshing routers and a different one for clients (possibly hiding the mesh from the clients to avoid end-user confusion). On Sun, Jun 23, 2013 at 8:37 PM, Acee Lindem wrote: > > On Jun 23, 2013, at 1:07 AM, Andrew McGregor wrote: > > I actually think that some MANET technologies are applicable here... I > don't recall what happened to its standardisation process, but wOSPF has a > lot of nice properties here, not least being that we have homenet > considering an OSPF based solution, and wOSPF provides the necessary > mechanics to deal with a wireless mesh. This is also a positive for BABEL, > it being primarily intended for mesh. > > > By wOSPF, I guess you mean the OSPF MANET options. I believe RFC 5820 > and RFC 5614 have seen some usage. > > > Bear in mind that topology updates in fixed wireless mesh mostly come > from statistics; you are never going to have 100% reachability probability > for your HELLOs (much less than that if they are multicast), and therefore > every now and again there will be false unreachability detections. > Secondly, wireless channels, even fixed ones, are subject to time > variability due to moving reflective objects in the environment; homenet > really ought to work on wireless even when there's a street right outside > the window, no? This implies taking the wireless mesh case as the default; > the protocols will definitely work on wired, and will tend to continue to > work even on badly degraded wired links. > > > The problem with using a mesh topology by default is that it doesn't > handle the non-routers very well unless they also participate in the mesh > and have their host addresses advertised independently like the routers. At > least this is the case for OSPF P2MP and the OSPF MANET variants - the > assumption is that all devices connecting to the mesh form routing protocol > adjacencies. > > Thanks, > Acee > > > > > > On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem wrote: > >> >> On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote: >> >> >> Acee Lindem >> >> 22 June 2013 21:30 >> >> There seems to be a fundamental disagreement here in terms of >> >> requirements. >> > possibly. >> > >> >> With respect to wireless, we all agree that the home will include a >> >> large number of wireless devices. >> > agree. >> >> However, I do not believe all these devices will participate in the >> >> routing topology. >> > agreed, almost certainly not all. Especially not static sensors. >> > >> >> Rather, there will be a small finite number of routers with fixed and >> >> wireless connectivity that form the home routing infrastructure. >> > >> > Right. But even if you have 4 or 5 routers (one per room or per floor) >> > there's a strong chance that they won't all be in mutual radio contact. >> > >> > So then you probably cannot assume all 4 or 5 of them are on a single >> > shared subnet using the traditional OSPF or IS IS designated router to >> > distribute routing information to all the on-link neighbors. >> > >> > Add to that scenario auto-prefix distribution. How do you establish and >> > manage neighbor adjacencies versus subnets/ prefixes? >> > >> > Or do you presume that the homenet routers will be contiguously >> > connected via wires, and there's no wireless router-router connections? >> >> I'd envision that all home network routers would be connected via wires >> or wireless but for topology changes to be infrequent. I don't envision a >> home network having the same dynamics as a MANET. >> With respect to wireless router-to-router connections, if you cannot >> assume mutual radio contact on the same wireless network, we could use P2MP >> as the default topology to solve the router-to-router problem. However, >> this assumption would break the broadcast model as well for hosts since >> basic protocols like ND and ARP assume a broadcast network. >> >> >> > >> > >> >> I do not believe the requirement is for a MANET network while those >> >> active in the MANET WG take this as given. >> > >> > I never said there'd be a MANET, but we might need to consider that >> > there'll be point to point wireless links that act as active adjacencies >> > between 2 routers and that there'll be no alternative wired link between >> > these routers, whilst at the same time those wireless interfaces are >> > serving local end nodes within range. >> >> Okay. >> >> >> > >> > RFC 5820 could be of help in that situation to maintain router-router >> > adjacencies as point to point links (without necessarily invoking all of >> > MANET requirements for an ad hoc network of many mobile nodes). I don't >> > know of any IS IS equivalent. Otherwise I think we might very well get >> > into problems with repeaters and packet loss. >> >> RFC 5820 is specifically to deal with the dynamic topologies and >> flooding scale challenges associated with a MANET network. I don't see it >> as being applicable to the home network. >> >> Thanks, >> Acee >> >> >> > >> > >> > >> >> Until we agree or agree to disagree on this requirement, we will have >> >> wildly divergent opinions on the architecture with respect to routing. >> >> Thanks >> >> Acee >> >> >> >> Ray Hunter >> >> 22 June 2013 19:14 >> >> Dave Taht wrote: >> >>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms >> wrote: >> >>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon >> wrote: >> >>>> >> >>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms >> wrote: >> >>>>>> The document makes no mention of *how* a largest practical subnet >> architecture might be achieved. There should be some requirement that >> devices be capable of acting as either a bridge or a router (or a mix of >> both), and that devices should bridge unless routing is determined >> necessary. >> >>>>> I find this text in the document a bit problematic too. I don't >> think it's actually reasonably practical to do any such determination. >> >>>> Perhaps it should be explicitly called out as an open question in >> the architecture document? >> >>>> >> >>>>> The only practical source of subnet sizing is the size of the >> smallest prefix we got from an ISP. I guess there are some ideas we could >> suggest, but they look more like solutions than architecture to me. >> >>>> The delegated prefixes only provide an upper bound. My concern is >> that we're assuming routing in the homenet comes from three sources: >> >>>> >> >>>> 1) explicitly desired for a specific goal like privacy or traffic >> management >> >>>> 2) hardware requirements like unbridgeable L2s or where bridging is >> for some reason undesirable >> >>>> 3) random placement of devices >> >>>> 1) requires some sort of explicit management while 3) may incur >> unnecessary complexity. 2) might deserve a little more text in the >> architecture document so the WG can have a discussion about what can be >> supported as "undesirable". >> >>>> >> >>>>> For instance, we could say that for any given router, all non-edge >> interfaces on that router that are of the same media type should be bridged >> together into a single subnet. >> >>> My definition of media type would treat 2.4ghz and 5.x ghz wireless >> >>> differently. does yours? >> >> Bridging between the two could be problematic, yes. >> >> >> >>>> But here's where routing for a desired property and management comes >> in ... suppose one of the router ports is to be configured as a separate >> link for the "office" subnet? That configuration can't be inferred, I >> don't think. >> >>> Happens all the time. >> >>> >> >>>>> CeroWRT makes each one its own subnet, which drives me nuts. >> >>> Not clear to me which part of that drives you nuts. In part CeroWrt's >> >>> purpose is to expose problems with ideas by putting them out there >> >>> annoyingly. >> >>> >> >>> (The original reason for routing rather than bridging networks in cero >> >>> was that we wanted to be able to analyze the effects of routing vs >> >>> bridging on wireless. The results of bridging gigE to 2.4ghz are >> >>> generally pretty dismal. IPv6 also uses much more multicast than >> >>> ipv4.) >> >>> >> >>> Along the way we gained insight into problems with commonly used >> >>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of >> >>> which have been solved, some of which have fixes in progress, others >> >>> are unsolvable, all are documented publicly on the mailing list, wiki >> >>> and issues database. Security is also a problem. Etc. >> >>> >> >>> If this group would like the reality based list, I can create a rather >> >>> large list of hyperlinks at this point. >> >>> >> >>> The most recent example is the one with problems with windows >> >>> filesharing induced by routing: >> >>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html >> >>> and successful resolution: >> >>> >> >>> >> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html >> >>> >> >>> It certainly would be nice for people here to setup more homenet-like >> >>> setups to get a grip for common protocols that have issues in routed >> >>> environments. I don't setup networks like the yurtlab (86 prefixes) >> >>> >> >>> http://pastebin.com/K8g5TyXS >> >>> >> >>> out of any innate love for S&M. >> >>> >> >>> The thing that drives me nuts here is not the prefix distribution >> >>> problem (which is 2 sed commands away per router, once, assuming >> >>> stable prefixes) but the the naming problems. I'd like to be able to >> >>> get to the printer at the office... but there's now a separate group >> >>> for solving that. >> >> Agreed. Namespace (and service discovery) will likely remain a >> >> significant challenge with competing architectures, never mind >> >> implementations. >> >> >> >> >> >>>> This would have the effect that if you plugged a Wifi router's >> ethernet port into the ethernet port of a CER, the WiFi router's ethernet >> port would be on the same subnet as the CER's ethernet ports, but the Wifi >> network would be on its own subnet; hence, routed, not bridged, which I >> think is desirable. But does this belong in the architecture document? >> >>> I like the "directionless" feature of hipnet. >> >>> >> >>> I'd like it very much if there was a way to distinguish between a >> >>> master and slave router out of the box for both ipv4 and ivp6. If you >> >>> plug two routers together on their bridge, they end up competing, if >> >>> you plug the uplink of one into the other, you get nat, and either >> >>> way, if they are both on 192.168.1.1, weird things happen. >> >>> >> >>>> I think there needs to be more careful distinction among the three >> cases I mentioned earlier. Here, I think you're talking about case 2). >> >>>> >> >>>> I agree that goals, requirements and problem statements belong in >> the architecture document, but (mostly) not solutions. >> >>>> >> >>>>> Furthermore, it's complicated by the fact that we'd really prefer >> to avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite >> possible that people will plug such interfaces together. >> >>> wireless issue noted above. >> >> I agree. AFAIK we do NOT have large scale reference deployments of >> >> common IGP's where wireless is used as a connector between multiple >> routers. >> >> >> >> Selecting Designated Router and Backup Designated Router in OSPF and >> >> Designated Intermediate System in IS-IS is NOT trivial especially when >> >> not all of the routers are within radio range of a common router. In >> >> fact I think we may well be missing a trick here, and we may need some >> >> form of mesh under network, at least between the routers connected via >> a >> >> common wireless link but where they are not all mutually within range >> of >> >> each other. Wireless to wireless bridging / repeating also seems to be >> >> highly proprietary and problematic. >> >> >> >> >> >>> Am I the only one in this group that >> >>> actually has the vast majority of devices in home and office wireless? >> >> No. >> >> >> >>> Is there anybody here that doesn't think that the vast majority of >> >>> devices in the home will be wireless? >> >> Not me. >> >> >> >>>>> So we may need to decide very dynamically which interfaces are >> bridged and which are routed. Maybe we will have virtual bridged networks >> on each homenet router for each media type and speed that the router >> supports, and dynamically connect interfaces that are running at that speed >> to those bridges, and hope that this works. >> >>>>> >> >>>>> I don't think we've visited this issue thoroughly enough to make >> statements about it in the architecture document. >> >>>> Maybe it needs to be cited as an open question? I'll re-read the >> document; statements like "we'd really prefer to avoid briding between >> 10mbps, 100mbps and 1Mbps internet" ought to be made explicit and justified. >> >>> see above. >> >>> >> >>> >> >> >> >> >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > homenet mailing list >> > homenet@ietf.org >> > https://www.ietf.org/mailman/listinfo/homenet >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > --089e011615e4ee205d04dfd0899a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So, I believe you could do this: use one SSID for meshing = routers and a different one for clients (possibly hiding the mesh from the = clients to avoid end-user confusion).

<= br>
On Sun, Jun 23, 2013 at 8:37 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:

On Jun 23, 2013, at 1:07 AM, Andrew McGregor wrote:

I actually think that some MANET technologies are applicab= le here... I don't recall what happened to its standardisation process,= but wOSPF has a lot of nice properties here, not least being that we have = homenet considering an OSPF based solution, and wOSPF provides the necessary mechanics to deal with a wireless mesh. = =A0This is also a positive for BABEL, it being primarily intended for mesh.=

By wOSPF, I guess you mean the OSPF MANET options. I believe RFC= 5820 and RFC 5614 have seen some usage.=A0


Bear in mind that topology updates in fixed wireless mesh mostly come = from statistics; you are never going to have 100% reachability probability = for your HELLOs (much less than that if they are multicast), and therefore = every now and again there will be false unreachability detections. =A0Secondly, wireless channels, even fixe= d ones, are subject to time variability due to moving reflective objects in= the environment; homenet really ought to work on wireless even when there&= #39;s a street right outside the window, no? =A0This implies taking the wireless mesh case as the default; the prot= ocols will definitely work on wired, and will tend to continue to work even= on badly degraded wired links.

The problem with using a mesh topology by default is that it doe= sn't handle the non-routers very well unless they also participate in t= he mesh and have their host addresses advertised independently like the rou= ters. At least this is the case for OSPF P2MP and the OSPF MANET variants - the assumption is that all devices connectin= g to the mesh form routing protocol adjacencies.=A0

Thanks,
Acee=A0





On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem <acee.lind= em@ericsson.com> wrote:

On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote:

>> Acee Lindem <mailto:acee.lindem@ericsson.com>
>> 22 June 2013 21:30
>> There seems to be a fundamental disagreement here in terms of
>> requirements.
> possibly.
>
>> With respect to wireless, we all agree that the home will include = a
>> large number of wireless devices.
> agree.
>> However, I do not believe all these devices will participate in th= e
>> routing topology.
> agreed, almost certainly not all. Especially not static sensors.
>
>> Rather, there will be a small finite number of routers with fixed = and
>> wireless connectivity that form the home routing infrastructure. >
> Right. But even if you have 4 or 5 routers (one per room or per floor)=
> there's a strong chance that they won't all be in mutual radio= contact.
>
> So then you probably cannot assume all 4 or 5 of them are on a single<= br> > shared subnet using the traditional OSPF or IS IS designated router to=
> distribute routing information to all the on-link neighbors.
>
> Add to that scenario auto-prefix distribution. How do you establish an= d
> manage neighbor adjacencies versus subnets/ prefixes?
>
> Or do you presume that the homenet routers will be contiguously
> connected via wires, and there's no wireless router-router connect= ions?

I'd envision that all home network routers would be connected via wires= or wireless but for topology changes to be infrequent. I don't envisio= n a home network having the same dynamics as a MANET.
With respect to wireless router-to-router connections, if you cannot assume= mutual radio contact on the same wireless network, we could use P2MP as th= e default topology to solve the router-to-router problem. However, this ass= umption would break the broadcast model as well for hosts since basic protocols like ND and ARP assume a bro= adcast network.


>
>
>> I do not believe the requirement is for a MANET network while thos= e
>> active in the MANET WG take this as given.
>
> I never said there'd be a MANET, but we might need to consider tha= t
> there'll be point to point wireless links that act as active adjac= encies
> between 2 routers and that there'll be no alternative wired link b= etween
> these routers, whilst at the same time those wireless interfaces are > serving local end nodes within range.

Okay.


>
> RFC 5820 could be of help in that situation to maintain router-router<= br> > adjacencies as point to point links (without necessarily invoking all = of
> MANET requirements for an ad hoc network of many mobile nodes). I don&= #39;t
> know of any IS IS equivalent. Otherwise I think we might very well get=
> into problems with repeaters and packet loss.

RFC 5820 is specifically to deal with the dynamic topologies and flooding s= cale challenges associated with a MANET network. I don't see it as bein= g applicable to the home network.

Thanks,
Acee


>
>
>
>> Until we agree or agree to disagree on this requirement, we will h= ave
>> wildly divergent opinions on the architecture with respect to rout= ing.
>> Thanks
>> Acee
>>
>> Ray Hunter <mailto:v6ops@globis.net>
>> 22 June 2013 19:14
>> Dave Taht wrote:
>>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms <rdroms.ietf@gmail.com>= wrote:
>>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon <mellon@fugue.com> wro= te:
>>>>
>>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>>>>>> The document makes no mention of *how* a largest p= ractical subnet architecture might be achieved. =A0There should be some req= uirement that devices be capable of acting as either a bridge or a router (= or a mix of both), and that devices should bridge unless routing is determined necessary.
>>>>> I find this text in the document a bit problematic too= . =A0 I don't think it's actually reasonably practical to do any su= ch determination.
>>>> Perhaps it should be explicitly called out as an open ques= tion in the architecture document?
>>>>
>>>>> The only practical source of subnet sizing is the size= of the smallest prefix we got from an ISP. =A0 I guess there are some idea= s we could suggest, but they look more like solutions than architecture to = me.
>>>> The delegated prefixes only provide an upper bound. =A0My = concern is that we're assuming routing in the homenet comes from three = sources:
>>>>
>>>> 1) explicitly desired for a specific goal like privacy or = traffic management
>>>> 2) hardware requirements like unbridgeable L2s or where br= idging is for some reason undesirable
>>>> 3) random placement of devices
>>>> 1) requires some sort of explicit management while 3) may = incur unnecessary complexity. =A02) might deserve a little more text in the= architecture document so the WG can have a discussion about what can be su= pported as "undesirable".
>>>>
>>>>> For instance, we could say that for any given router, = all non-edge interfaces on that router that are of the same media type shou= ld be bridged together into a single subnet.
>>> My definition of media type would treat 2.4ghz and 5.x ghz wir= eless
>>> differently. does yours?
>> Bridging between the two could be problematic, yes.
>>
>>>> But here's where routing for a desired property and ma= nagement comes in ... suppose one of the router ports is to be configured a= s a separate link for the "office" subnet? =A0That configuration = can't be inferred, I don't think.
>>> Happens all the time.
>>>
>>>>> =A0CeroWRT makes each one its own subnet, which drives= me nuts.
>>> Not clear to me which part of that drives you nuts. In part Ce= roWrt's
>>> purpose is to expose problems with ideas by putting them out t= here
>>> annoyingly.
>>>
>>> (The original reason for routing rather than bridging networks= in cero
>>> was that we wanted to be able to analyze the effects of routin= g vs
>>> bridging on wireless. The results of bridging gigE to 2.4ghz a= re
>>> generally pretty dismal. IPv6 also uses much more multicast th= an
>>> ipv4.)
>>>
>>> Along the way we gained insight into problems with commonly us= ed
>>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. S= ome of
>>> which have been solved, some of which have fixes in progress, = others
>>> are unsolvable, all are documented publicly on the mailing lis= t, wiki
>>> and issues database. Security is also a problem. Etc.
>>>
>>> If this group would like the reality based list, I can create = a rather
>>> large list of hyperlinks at this point.
>>>
>>> The most recent example is the one with problems with windows<= br> >>> filesharing induced by routing:
>>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html
>>> and successful resolution:
>>>
>>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html=
>>>
>>> It certainly would be nice for people here to setup more homen= et-like
>>> setups to get a grip for common protocols that have issues in = routed
>>> environments. I don't setup networks like the yurtlab (86 = prefixes)
>>>
>>> htt= p://pastebin.com/K8g5TyXS
>>>
>>> out of any innate love for S&M.
>>>
>>> The thing that drives me nuts here is not the prefix distribut= ion
>>> problem (which is 2 sed commands away per router, once, assumi= ng
>>> stable prefixes) but the the naming problems. I'd like to = be able to
>>> get to the printer at the office... but there's now a sepa= rate group
>>> for solving that.
>> Agreed. Namespace (and service discovery) will likely remain a
>> significant challenge with competing architectures, never mind
>> implementations.
>>
>>
>>>> This would have the effect that if you plugged a Wifi rout= er's ethernet port into the ethernet port of a CER, the WiFi router'= ;s ethernet port would be on the same subnet as the CER's ethernet port= s, but the Wifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable. =A0 But does this belong = in the architecture document?
>>> I like the "directionless" feature of hipnet.
>>>
>>> I'd like it very much if there was a way to distinguish be= tween a
>>> master and slave router out of the box for both ipv4 and ivp6.= If you
>>> plug two routers together on their bridge, they end up competi= ng, if
>>> you plug the uplink of one into the other, you get nat, and ei= ther
>>> way, if they are both on 192.168.1.1, weird things happen.
>>>
>>>> I think there needs to be more careful distinction among t= he three cases I mentioned earlier. =A0Here, I think you're talking abo= ut case 2).
>>>>
>>>> I agree that goals, requirements and problem statements be= long in the architecture document, but (mostly) not solutions.
>>>>
>>>>> Furthermore, it's complicated by the fact that we&= #39;d really prefer to avoid briding between 10mbps, 100mbps and 1Mbps inte= rnet, and it's quite possible that people will plug such interfaces tog= ether.
>>> wireless issue noted above.
>> I agree. AFAIK we do NOT have large scale reference deployments of=
>> common IGP's where wireless is used as a connector between mul= tiple routers.
>>
>> Selecting Designated Router and Backup Designated Router in OSPF a= nd
>> Designated Intermediate System in IS-IS is NOT trivial especially = when
>> not all of the routers are within radio range of a common router. = In
>> fact I think we may well be missing a trick here, and we may need = some
>> form of mesh under network, at least between the routers connected= via a
>> common wireless link but where they are not all mutually within ra= nge of
>> each other. Wireless to wireless bridging / repeating also seems t= o be
>> highly proprietary and problematic.
>>
>>
>>> Am I the only one in this group that
>>> actually has the vast majority of devices in home and office w= ireless?
>> No.
>>
>>> Is there anybody here that doesn't think that the vast maj= ority of
>>> devices in the home will be wireless?
>> Not me.
>>
>>>>> =A0So we may need to decide very dynamically which int= erfaces are bridged and which are routed. =A0 Maybe we will have virtual br= idged networks on each homenet router for each media type and speed that th= e router supports, and dynamically connect interfaces that are running at that speed to those bridges, and hope that this works.=
>>>>>
>>>>> I don't think we've visited this issue thoroug= hly enough to make statements about it in the architecture document.
>>>> Maybe it needs to be cited as an open question? =A0I'l= l re-read the document; statements like "we'd really prefer to avo= id briding between 10mbps, 100mbps and 1Mbps internet" ought to be mad= e explicit and justified.
>>> see above.
>>>
>>> <snip>
>>
>> ------------------------------------------------------------------= ------
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org=
> https://www.ietf.org/mailman/listinfo/homenet

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



--089e011615e4ee205d04dfd0899a-- From acee.lindem@ericsson.com Sun Jun 23 08:38:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C2D21F9A3F for ; Sun, 23 Jun 2013 08:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txUhLy4VunMr for ; Sun, 23 Jun 2013 08:38:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 73DCC21F9302 for ; Sun, 23 Jun 2013 08:38:30 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-6a-51c71673a346 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 57.5F.05617.37617C15; Sun, 23 Jun 2013 17:38:27 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 11:38:27 -0400 From: Acee Lindem To: Andrew McGregor Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAXEzICAAvmhgIACyQCAgAClugCAAUFJAIAAJdSAgAAJ34CAABT+gIAAgnQAgABcQ4CAAA0EAIAARvaA Date: Sun, 23 Jun 2013 15:38:26 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE471868ABeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXSPt26x2PFAg5/LbCx29htY7Nl4ksXi /aJDLBZv1hxhsmi81sdqsedqvQObR9OFZeweT85eZ/PYOesuu8eSJT+ZAliiuGxSUnMyy1KL 9O0SuDLOvnzDXLDjH2PFhz8LmRsYn19i7GLk5JAQMJGYcXUelC0mceHeerYuRi4OIYGjjBKz Tm5nh3CWM0ocXXyfDaSKTUBH4vmjf8wgtoiAlsTcb7dZQIqYBbYxSky/9JUdJCEs4Cnx//0N JogiL4nZB7vAxooINDFKHPj+HGwSi4CqxLenf1lAbF4Bb4mjBzczQaybyCbRfqoLLMEpECix 538b2DpGoAO/n1oDNpVZQFzi1pP5TBCHC0gs2XOeGcIWlXj5+B8rhK0sseTJfhaI+nyJTRf3 QS0TlDg58wnLBEbRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHkP1Wks8fzefFVnN AkaOVYwcpcWpZbnpRoabGIERe0yCzXEH44JPlocYpTlYlMR535/aFSgkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qB0SbdLHcOy/E3TTEX36XVduuKOR8MfHjg2O8PPDrhImEqp8U+Tr84M4Y5 2Wn3vjns5eEns1a1OVuwMcrsyOifVK6/4WHn1sgSRaOmUM1Wi8isupoa/6vKD77Zxe6+dXnx kc8hXmE5i1Z9/lWb9ISPZ76Zx8JFsw4HO13bMNdjzlMGL7Pb9hPvKLEUZyQaajEXFScCAFfx 8SKmAgAA Cc: Ray Hunter , "homenet@ietf.org Group" , Ted Lemon , Dave Taht , Ralph Droms Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 15:38:36 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE471868ABeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is room for innovation here and I agree that one could come up with a= model to support this. However, I'm not ready to take it as a requirement = for an auto-configured homenet since the Wi-Fi broadcast network model has = heretofore served us quite well. Acee On Jun 23, 2013, at 7:24 AM, Andrew McGregor wrote: So, I believe you could do this: use one SSID for meshing routers and a dif= ferent one for clients (possibly hiding the mesh from the clients to avoid = end-user confusion). On Sun, Jun 23, 2013 at 8:37 PM, Acee Lindem > wrote: On Jun 23, 2013, at 1:07 AM, Andrew McGregor wrote: I actually think that some MANET technologies are applicable here... I don'= t recall what happened to its standardisation process, but wOSPF has a lot = of nice properties here, not least being that we have homenet considering a= n OSPF based solution, and wOSPF provides the necessary mechanics to deal w= ith a wireless mesh. This is also a positive for BABEL, it being primarily= intended for mesh. By wOSPF, I guess you mean the OSPF MANET options. I believe RFC 5820 and R= FC 5614 have seen some usage. Bear in mind that topology updates in fixed wireless mesh mostly come from = statistics; you are never going to have 100% reachability probability for y= our HELLOs (much less than that if they are multicast), and therefore every= now and again there will be false unreachability detections. Secondly, wi= reless channels, even fixed ones, are subject to time variability due to mo= ving reflective objects in the environment; homenet really ought to work on= wireless even when there's a street right outside the window, no? This im= plies taking the wireless mesh case as the default; the protocols will defi= nitely work on wired, and will tend to continue to work even on badly degra= ded wired links. The problem with using a mesh topology by default is that it doesn't handle= the non-routers very well unless they also participate in the mesh and hav= e their host addresses advertised independently like the routers. At least = this is the case for OSPF P2MP and the OSPF MANET variants - the assumption= is that all devices connecting to the mesh form routing protocol adjacenci= es. Thanks, Acee On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem > wrote: On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote: >> Acee Lindem > >> 22 June 2013 21:30 >> There seems to be a fundamental disagreement here in terms of >> requirements. > possibly. > >> With respect to wireless, we all agree that the home will include a >> large number of wireless devices. > agree. >> However, I do not believe all these devices will participate in the >> routing topology. > agreed, almost certainly not all. Especially not static sensors. > >> Rather, there will be a small finite number of routers with fixed and >> wireless connectivity that form the home routing infrastructure. > > Right. But even if you have 4 or 5 routers (one per room or per floor) > there's a strong chance that they won't all be in mutual radio contact. > > So then you probably cannot assume all 4 or 5 of them are on a single > shared subnet using the traditional OSPF or IS IS designated router to > distribute routing information to all the on-link neighbors. > > Add to that scenario auto-prefix distribution. How do you establish and > manage neighbor adjacencies versus subnets/ prefixes? > > Or do you presume that the homenet routers will be contiguously > connected via wires, and there's no wireless router-router connections? I'd envision that all home network routers would be connected via wires or = wireless but for topology changes to be infrequent. I don't envision a home= network having the same dynamics as a MANET. With respect to wireless router-to-router connections, if you cannot assume= mutual radio contact on the same wireless network, we could use P2MP as th= e default topology to solve the router-to-router problem. However, this ass= umption would break the broadcast model as well for hosts since basic proto= cols like ND and ARP assume a broadcast network. > > >> I do not believe the requirement is for a MANET network while those >> active in the MANET WG take this as given. > > I never said there'd be a MANET, but we might need to consider that > there'll be point to point wireless links that act as active adjacencies > between 2 routers and that there'll be no alternative wired link between > these routers, whilst at the same time those wireless interfaces are > serving local end nodes within range. Okay. > > RFC 5820 could be of help in that situation to maintain router-router > adjacencies as point to point links (without necessarily invoking all of > MANET requirements for an ad hoc network of many mobile nodes). I don't > know of any IS IS equivalent. Otherwise I think we might very well get > into problems with repeaters and packet loss. RFC 5820 is specifically to deal with the dynamic topologies and flooding s= cale challenges associated with a MANET network. I don't see it as being ap= plicable to the home network. Thanks, Acee > > > >> Until we agree or agree to disagree on this requirement, we will have >> wildly divergent opinions on the architecture with respect to routing. >> Thanks >> Acee >> >> Ray Hunter > >> 22 June 2013 19:14 >> Dave Taht wrote: >>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms > wrote: >>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon > wrote: >>>> >>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms > wrote: >>>>>> The document makes no mention of *how* a largest practical subnet ar= chitecture might be achieved. There should be some requirement that device= s be capable of acting as either a bridge or a router (or a mix of both), a= nd that devices should bridge unless routing is determined necessary. >>>>> I find this text in the document a bit problematic too. I don't thi= nk it's actually reasonably practical to do any such determination. >>>> Perhaps it should be explicitly called out as an open question in the = architecture document? >>>> >>>>> The only practical source of subnet sizing is the size of the smalles= t prefix we got from an ISP. I guess there are some ideas we could sugges= t, but they look more like solutions than architecture to me. >>>> The delegated prefixes only provide an upper bound. My concern is tha= t we're assuming routing in the homenet comes from three sources: >>>> >>>> 1) explicitly desired for a specific goal like privacy or traffic mana= gement >>>> 2) hardware requirements like unbridgeable L2s or where bridging is fo= r some reason undesirable >>>> 3) random placement of devices >>>> 1) requires some sort of explicit management while 3) may incur unnece= ssary complexity. 2) might deserve a little more text in the architecture = document so the WG can have a discussion about what can be supported as "un= desirable". >>>> >>>>> For instance, we could say that for any given router, all non-edge in= terfaces on that router that are of the same media type should be bridged t= ogether into a single subnet. >>> My definition of media type would treat 2.4ghz and 5.x ghz wireless >>> differently. does yours? >> Bridging between the two could be problematic, yes. >> >>>> But here's where routing for a desired property and management comes i= n ... suppose one of the router ports is to be configured as a separate lin= k for the "office" subnet? That configuration can't be inferred, I don't t= hink. >>> Happens all the time. >>> >>>>> CeroWRT makes each one its own subnet, which drives me nuts. >>> Not clear to me which part of that drives you nuts. In part CeroWrt's >>> purpose is to expose problems with ideas by putting them out there >>> annoyingly. >>> >>> (The original reason for routing rather than bridging networks in cero >>> was that we wanted to be able to analyze the effects of routing vs >>> bridging on wireless. The results of bridging gigE to 2.4ghz are >>> generally pretty dismal. IPv6 also uses much more multicast than >>> ipv4.) >>> >>> Along the way we gained insight into problems with commonly used >>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of >>> which have been solved, some of which have fixes in progress, others >>> are unsolvable, all are documented publicly on the mailing list, wiki >>> and issues database. Security is also a problem. Etc. >>> >>> If this group would like the reality based list, I can create a rather >>> large list of hyperlinks at this point. >>> >>> The most recent example is the one with problems with windows >>> filesharing induced by routing: >>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html >>> and successful resolution: >>> >>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.= html >>> >>> It certainly would be nice for people here to setup more homenet-like >>> setups to get a grip for common protocols that have issues in routed >>> environments. I don't setup networks like the yurtlab (86 prefixes) >>> >>> http://pastebin.com/K8g5TyXS >>> >>> out of any innate love for S&M. >>> >>> The thing that drives me nuts here is not the prefix distribution >>> problem (which is 2 sed commands away per router, once, assuming >>> stable prefixes) but the the naming problems. I'd like to be able to >>> get to the printer at the office... but there's now a separate group >>> for solving that. >> Agreed. Namespace (and service discovery) will likely remain a >> significant challenge with competing architectures, never mind >> implementations. >> >> >>>> This would have the effect that if you plugged a Wifi router's etherne= t port into the ethernet port of a CER, the WiFi router's ethernet port wou= ld be on the same subnet as the CER's ethernet ports, but the Wifi network = would be on its own subnet; hence, routed, not bridged, which I think is de= sirable. But does this belong in the architecture document? >>> I like the "directionless" feature of hipnet. >>> >>> I'd like it very much if there was a way to distinguish between a >>> master and slave router out of the box for both ipv4 and ivp6. If you >>> plug two routers together on their bridge, they end up competing, if >>> you plug the uplink of one into the other, you get nat, and either >>> way, if they are both on 192.168.1.1, weird things happen. >>> >>>> I think there needs to be more careful distinction among the three cas= es I mentioned earlier. Here, I think you're talking about case 2). >>>> >>>> I agree that goals, requirements and problem statements belong in the = architecture document, but (mostly) not solutions. >>>> >>>>> Furthermore, it's complicated by the fact that we'd really prefer to = avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite po= ssible that people will plug such interfaces together. >>> wireless issue noted above. >> I agree. AFAIK we do NOT have large scale reference deployments of >> common IGP's where wireless is used as a connector between multiple rout= ers. >> >> Selecting Designated Router and Backup Designated Router in OSPF and >> Designated Intermediate System in IS-IS is NOT trivial especially when >> not all of the routers are within radio range of a common router. In >> fact I think we may well be missing a trick here, and we may need some >> form of mesh under network, at least between the routers connected via a >> common wireless link but where they are not all mutually within range of >> each other. Wireless to wireless bridging / repeating also seems to be >> highly proprietary and problematic. >> >> >>> Am I the only one in this group that >>> actually has the vast majority of devices in home and office wireless? >> No. >> >>> Is there anybody here that doesn't think that the vast majority of >>> devices in the home will be wireless? >> Not me. >> >>>>> So we may need to decide very dynamically which interfaces are bridg= ed and which are routed. Maybe we will have virtual bridged networks on e= ach homenet router for each media type and speed that the router supports, = and dynamically connect interfaces that are running at that speed to those = bridges, and hope that this works. >>>>> >>>>> I don't think we've visited this issue thoroughly enough to make stat= ements about it in the architecture document. >>>> Maybe it needs to be cited as an open question? I'll re-read the docu= ment; statements like "we'd really prefer to avoid briding between 10mbps, = 100mbps and 1Mbps internet" ought to be made explicit and justified. >>> see above. >>> >>> >> >> ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --_000_94A203EA12AECE4BA92D42DBFFE0AE471868ABeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <2BF60D286CDF95449AFDA7FF5184F5F3@ericsson.com> Content-Transfer-Encoding: quoted-printable There is room for innovation here and I agree that one could come up with a= model to support this. However, I'm not ready to take it as a requirement = for an auto-configured homenet since the Wi-Fi broadcast network model has = heretofore served us quite well. 
Acee 
On Jun 23, 2013, at 7:24 AM, Andrew McGregor wrote:

So, I believe you could do this: use one SSID for meshing = routers and a different one for clients (possibly hiding the mesh from the = clients to avoid end-user confusion).


On Sun, Jun 23, 2013 at 8:37 PM, Acee Lindem <acee.lind= em@ericsson.com> wrote:

On Jun 23, 2013, at 1:07 AM, Andrew McGregor wrote:

I actually think that some MANET technologies are applicab= le here... I don't recall what happened to its standardisation process, but= wOSPF has a lot of nice properties here, not least being that we have home= net considering an OSPF based solution, and wOSPF provides the necessary mechanics to deal with a wireless mesh. &= nbsp;This is also a positive for BABEL, it being primarily intended for mes= h.

By wOSPF, I guess you mean the OSPF MANET options. I believe RFC 5820 = and RFC 5614 have seen some usage. 


Bear in mind that topology updates in fixed wireless mesh mostly come = from statistics; you are never going to have 100% reachability probability = for your HELLOs (much less than that if they are multicast), and therefore = every now and again there will be false unreachability detections.  Secondly, wireless channels, even f= ixed ones, are subject to time variability due to moving reflective objects= in the environment; homenet really ought to work on wireless even when the= re's a street right outside the window, no?  This implies taking the wireless mesh case as the default; the p= rotocols will definitely work on wired, and will tend to continue to work e= ven on badly degraded wired links.

The problem with using a mesh topology by default is that it doesn't h= andle the non-routers very well unless they also participate in the mesh an= d have their host addresses advertised independently like the routers. At l= east this is the case for OSPF P2MP and the OSPF MANET variants - the assumption is that all devices connectin= g to the mesh form routing protocol adjacencies. 

Thanks,
Acee 





On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem <acee.lind= em@ericsson.com> wrote:

On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote:

>> Acee Lindem <mailto:acee.lindem@ericsson.com>
>> 22 June 2013 21:30
>> There seems to be a fundamental disagreement here in terms of
>> requirements.
> possibly.
>
>> With respect to wireless, we all agree that the home will include = a
>> large number of wireless devices.
> agree.
>> However, I do not believe all these devices will participate in th= e
>> routing topology.
> agreed, almost certainly not all. Especially not static sensors.
>
>> Rather, there will be a small finite number of routers with fixed = and
>> wireless connectivity that form the home routing infrastructure. >
> Right. But even if you have 4 or 5 routers (one per room or per floor)=
> there's a strong chance that they won't all be in mutual radio contact= .
>
> So then you probably cannot assume all 4 or 5 of them are on a single<= br> > shared subnet using the traditional OSPF or IS IS designated router to=
> distribute routing information to all the on-link neighbors.
>
> Add to that scenario auto-prefix distribution. How do you establish an= d
> manage neighbor adjacencies versus subnets/ prefixes?
>
> Or do you presume that the homenet routers will be contiguously
> connected via wires, and there's no wireless router-router connections= ?

I'd envision that all home network routers would be connected via wires or = wireless but for topology changes to be infrequent. I don't envision a home= network having the same dynamics as a MANET.
With respect to wireless router-to-router connections, if you cannot assume= mutual radio contact on the same wireless network, we could use P2MP as th= e default topology to solve the router-to-router problem. However, this ass= umption would break the broadcast model as well for hosts since basic protocols like ND and ARP assume a bro= adcast network.


>
>
>> I do not believe the requirement is for a MANET network while thos= e
>> active in the MANET WG take this as given.
>
> I never said there'd be a MANET, but we might need to consider that > there'll be point to point wireless links that act as active adjacenci= es
> between 2 routers and that there'll be no alternative wired link betwe= en
> these routers, whilst at the same time those wireless interfaces are > serving local end nodes within range.

Okay.


>
> RFC 5820 could be of help in that situation to maintain router-router<= br> > adjacencies as point to point links (without necessarily invoking all = of
> MANET requirements for an ad hoc network of many mobile nodes). I don'= t
> know of any IS IS equivalent. Otherwise I think we might very well get=
> into problems with repeaters and packet loss.

RFC 5820 is specifically to deal with the dynamic topologies and flooding s= cale challenges associated with a MANET network. I don't see it as being ap= plicable to the home network.

Thanks,
Acee


>
>
>
>> Until we agree or agree to disagree on this requirement, we will h= ave
>> wildly divergent opinions on the architecture with respect to rout= ing.
>> Thanks
>> Acee
>>
>> Ray Hunter <mailto:v6ops@globis.net>
>> 22 June 2013 19:14
>> Dave Taht wrote:
>>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms <rdroms.ietf@gmail.com>= wrote:
>>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon <mellon@fugue.com> wro= te:
>>>>
>>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>>>>>> The document makes no mention of *how* a largest p= ractical subnet architecture might be achieved.  There should be some = requirement that devices be capable of acting as either a bridge or a route= r (or a mix of both), and that devices should bridge unless routing is determined necessary.
>>>>> I find this text in the document a bit problematic too= .   I don't think it's actually reasonably practical to do any such de= termination.
>>>> Perhaps it should be explicitly called out as an open ques= tion in the architecture document?
>>>>
>>>>> The only practical source of subnet sizing is the size= of the smallest prefix we got from an ISP.   I guess there are some i= deas we could suggest, but they look more like solutions than architecture = to me.
>>>> The delegated prefixes only provide an upper bound.  = My concern is that we're assuming routing in the homenet comes from three s= ources:
>>>>
>>>> 1) explicitly desired for a specific goal like privacy or = traffic management
>>>> 2) hardware requirements like unbridgeable L2s or where br= idging is for some reason undesirable
>>>> 3) random placement of devices
>>>> 1) requires some sort of explicit management while 3) may = incur unnecessary complexity.  2) might deserve a little more text in = the architecture document so the WG can have a discussion about what can be= supported as "undesirable".
>>>>
>>>>> For instance, we could say that for any given router, = all non-edge interfaces on that router that are of the same media type shou= ld be bridged together into a single subnet.
>>> My definition of media type would treat 2.4ghz and 5.x ghz wir= eless
>>> differently. does yours?
>> Bridging between the two could be problematic, yes.
>>
>>>> But here's where routing for a desired property and manage= ment comes in ... suppose one of the router ports is to be configured as a = separate link for the "office" subnet?  That configuration c= an't be inferred, I don't think.
>>> Happens all the time.
>>>
>>>>>  CeroWRT makes each one its own subnet, which dri= ves me nuts.
>>> Not clear to me which part of that drives you nuts. In part Ce= roWrt's
>>> purpose is to expose problems with ideas by putting them out t= here
>>> annoyingly.
>>>
>>> (The original reason for routing rather than bridging networks= in cero
>>> was that we wanted to be able to analyze the effects of routin= g vs
>>> bridging on wireless. The results of bridging gigE to 2.4ghz a= re
>>> generally pretty dismal. IPv6 also uses much more multicast th= an
>>> ipv4.)
>>>
>>> Along the way we gained insight into problems with commonly us= ed
>>> protocols like mdns, upnp, dnssdd, windows filesharing, etc. S= ome of
>>> which have been solved, some of which have fixes in progress, = others
>>> are unsolvable, all are documented publicly on the mailing lis= t, wiki
>>> and issues database. Security is also a problem. Etc.
>>>
>>> If this group would like the reality based list, I can create = a rather
>>> large list of hyperlinks at this point.
>>>
>>> The most recent example is the one with problems with windows<= br> >>> filesharing induced by routing:
>>> https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html
>>> and successful resolution:
>>>
>>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html=
>>>
>>> It certainly would be nice for people here to setup more homen= et-like
>>> setups to get a grip for common protocols that have issues in = routed
>>> environments. I don't setup networks like the yurtlab (86 pref= ixes)
>>>
>>> htt= p://pastebin.com/K8g5TyXS
>>>
>>> out of any innate love for S&M.
>>>
>>> The thing that drives me nuts here is not the prefix distribut= ion
>>> problem (which is 2 sed commands away per router, once, assumi= ng
>>> stable prefixes) but the the naming problems. I'd like to be a= ble to
>>> get to the printer at the office... but there's now a separate= group
>>> for solving that.
>> Agreed. Namespace (and service discovery) will likely remain a
>> significant challenge with competing architectures, never mind
>> implementations.
>>
>>
>>>> This would have the effect that if you plugged a Wifi rout= er's ethernet port into the ethernet port of a CER, the WiFi router's ether= net port would be on the same subnet as the CER's ethernet ports, but the W= ifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable.   But does this belo= ng in the architecture document?
>>> I like the "directionless" feature of hipnet.
>>>
>>> I'd like it very much if there was a way to distinguish betwee= n a
>>> master and slave router out of the box for both ipv4 and ivp6.= If you
>>> plug two routers together on their bridge, they end up competi= ng, if
>>> you plug the uplink of one into the other, you get nat, and ei= ther
>>> way, if they are both on 192.168.1.1, weird things happen.
>>>
>>>> I think there needs to be more careful distinction among t= he three cases I mentioned earlier.  Here, I think you're talking abou= t case 2).
>>>>
>>>> I agree that goals, requirements and problem statements be= long in the architecture document, but (mostly) not solutions.
>>>>
>>>>> Furthermore, it's complicated by the fact that we'd re= ally prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet, an= d it's quite possible that people will plug such interfaces together.
>>> wireless issue noted above.
>> I agree. AFAIK we do NOT have large scale reference deployments of=
>> common IGP's where wireless is used as a connector between multipl= e routers.
>>
>> Selecting Designated Router and Backup Designated Router in OSPF a= nd
>> Designated Intermediate System in IS-IS is NOT trivial especially = when
>> not all of the routers are within radio range of a common router. = In
>> fact I think we may well be missing a trick here, and we may need = some
>> form of mesh under network, at least between the routers connected= via a
>> common wireless link but where they are not all mutually within ra= nge of
>> each other. Wireless to wireless bridging / repeating also seems t= o be
>> highly proprietary and problematic.
>>
>>
>>> Am I the only one in this group that
>>> actually has the vast majority of devices in home and office w= ireless?
>> No.
>>
>>> Is there anybody here that doesn't think that the vast majorit= y of
>>> devices in the home will be wireless?
>> Not me.
>>
>>>>>  So we may need to decide very dynamically which = interfaces are bridged and which are routed.   Maybe we will have virt= ual bridged networks on each homenet router for each media type and speed t= hat the router supports, and dynamically connect interfaces that are running at that speed to those bridges, and hope that this works.=
>>>>>
>>>>> I don't think we've visited this issue thoroughly enou= gh to make statements about it in the architecture document.
>>>> Maybe it needs to be cited as an open question?  I'll= re-read the document; statements like "we'd really prefer to avoid br= iding between 10mbps, 100mbps and 1Mbps internet" ought to be made exp= licit and justified.
>>> see above.
>>>
>>> <snip>
>>
>> ------------------------------------------------------------------= ------
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org=
> https://www.ietf.org/mailman/listinfo/homenet

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




--_000_94A203EA12AECE4BA92D42DBFFE0AE471868ABeusaamb101ericsso_-- From mellon@fugue.com Sun Jun 23 09:18:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1221F9D9D for ; Sun, 23 Jun 2013 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MipNoH+K8qC7 for ; Sun, 23 Jun 2013 09:18:48 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id AF24821F9E05 for ; Sun, 23 Jun 2013 09:18:48 -0700 (PDT) Received: from [IPv6:2001:470:88a3::c9c2:2c34:d702:a5a8] (unknown [IPv6:2001:470:88a3:0:c9c2:2c34:d702:a5a8]) by toccata.fugue.com (Postfix) with ESMTPSA id 0EF5B2380986; Sun, 23 Jun 2013 12:18:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> Date: Sun, 23 Jun 2013 12:18:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1508) Cc: Ray Hunter , "homenet@ietf.org Group" , Ralph Droms , Dave Taht , Andrew McGregor Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 16:18:54 -0000 There's been brief mention of the WiFi infrastructure problem for the = homenet during this post-last-call conversation, but I don't think we = drew a conclusion, and indeed some of what was said seems to suggest = that we aren't addressing the issue. Let's consider the following scenario: I have a wired infrastructure = that connects my home and garage. The home and garage can't all be = served by the same Wifi AP. I want to set up WiFi APs so that I can = wander around between the various parts of my home, as well as outdoors, = and have good WiFi connectivity in all of these locations, without = expensive handoffs and without changing subnets (which would break = connections, e.g. SIP calls, ssh sessions, etc). There are a variety of ways of addressing this problem, and you and = Andrew and Ray have touched on them a bit, but I didn't see a clear = requirement stated, and I'd like to. I don't see one in the = architecture document either. The first question is, is this a use case that the Homenet architecture = wants to address? I think the answer is yes, but I don't get the sense = that everybody agrees with that, which is why I am asking the question = directly. Second, _can_ we address it, given other assumptions we're making in the = architecture, and how? I've mentioned the wired backbone/wireless AP = model, but of course a lot of home environments won't have the luxury of = a wired backbone, so we will probably have to do air-to-air = infrastructure links to make it work. What does this look like? One way to make this work, which someone jokingly alluded to before, = would be to have all the APs coexist in a TRILL layer 2. I'm sure I = will attract some rotten tomatoes for that suggestion, but it _would_ = work. Subnetting wouldn't work=97it would break connections every time = I changed APs. I am not convinced that making the whole homenet one = big bridge is a good answer, but that would work, in the sense of = addressing the specific use case I am describing. Mobile IP would also = work, but I don't think it would be practical to set up a Mobile IP = infrastructure on a homenet. It can also be argued that nobody needs this functionality. Sorry for lobbing this question into an otherwise interesting and = related WiFi mesh discussion, but is anybody else thinking about this = and/or concerned about this?= From acee.lindem@ericsson.com Sun Jun 23 11:19:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE121F9C1E for ; Sun, 23 Jun 2013 11:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiHJ21A6woX5 for ; Sun, 23 Jun 2013 11:18:59 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC321F9BF2 for ; Sun, 23 Jun 2013 11:18:58 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-1e-51c73c112885 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0C.F2.17537.11C37C15; Sun, 23 Jun 2013 20:18:58 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 14:18:57 -0400 From: Acee Lindem To: Ted Lemon Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAXEzICAAvmhgIACyQCAgAClugCAAUFJAIAAJdSAgAAJ34CAABT+gIAAgnQAgABcQ4CAAA0EAIAARvaAgAALRACAACGVAA== Date: Sun, 23 Jun 2013 18:18:56 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47186AC3@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> In-Reply-To: <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLrHT1fI5nigweoOFoud/QYWezaeZLF4 v+gQi8WbNUeYLBqv9bFa7Lla78Dm0XRhGbvHk7PX2Tx2zrrL7rFkyU+mAJYoLpuU1JzMstQi fbsEroy2e0tZCprEKuZ2f2ZvYNwr2MXIwSEhYCKxs4+ri5ETyBSTuHBvPVsXIxeHkMBRRom9 V28xQTjLGSVOv+xjAaliE9CReP7oHzOILSKgIDH3zBqwImaBA4wSW27/B0sIC3hK/H9/gwmi yEti9sEuNgh7EqPExlesIDaLgKrE9Ftb2UFsXgFviW2tnxhBbCGBNnaJ6x9SQGxOAVuJpQta wOoZgc77fmoN2ExmAXGJW0/mM0GcLSCxZM95ZghbVOLl43+sELayxJIn+1kg6g0k3p+bzwxh W0tsutbIDmFrSyxb+JoZ4gZBiZMzn7BMYBSfhWTFLCTts5C0z0LSPgtJ+wJG1lWMHKXFqWW5 6UYGmxiB8XhMgk13B+Oel5aHGKU5WJTEeV+e2hUoJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gTF4qt3PR+I6X1zazWvUsyf8+FLI4v6lM79obu5CaQ6jrP9Hnf2vBj3yPth5UvuAlmnhBd3m +E+PFm3ySL/IP2X9i48rS2ID3aU6mE7PS7841cx/2kOPh81xE7YVsTdNvf8gXH+uYGVIyzHm Zim+q++akrw/LnqX8mxKeAHL39cbtnaf8M+pZ1NiKc5INNRiLipOBACnCOeilQIAAA== Cc: Ray Hunter , "homenet@ietf.org Group" , Ralph Droms , Dave Taht , Andrew McGregor Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 18:19:05 -0000 Ted,=20 For this particular problem, I don't think there is a simple solution at la= yer 3. I think layer 2 bridging is the most straightforward approach to ext= end the wireless LAN without requiring additional function in every device = that connects (e.g., MIP6). =20 Thanks, Acee=20 On Jun 23, 2013, at 12:18 PM, Ted Lemon wrote: > There's been brief mention of the WiFi infrastructure problem for the hom= enet during this post-last-call conversation, but I don't think we drew a c= onclusion, and indeed some of what was said seems to suggest that we aren't= addressing the issue. >=20 > Let's consider the following scenario: I have a wired infrastructure that= connects my home and garage. The home and garage can't all be served by = the same Wifi AP. I want to set up WiFi APs so that I can wander around b= etween the various parts of my home, as well as outdoors, and have good WiF= i connectivity in all of these locations, without expensive handoffs and wi= thout changing subnets (which would break connections, e.g. SIP calls, ssh = sessions, etc). >=20 > There are a variety of ways of addressing this problem, and you and Andre= w and Ray have touched on them a bit, but I didn't see a clear requirement = stated, and I'd like to. I don't see one in the architecture document eit= her. >=20 > The first question is, is this a use case that the Homenet architecture w= ants to address? I think the answer is yes, but I don't get the sense tha= t everybody agrees with that, which is why I am asking the question directl= y. >=20 > Second, _can_ we address it, given other assumptions we're making in the = architecture, and how? I've mentioned the wired backbone/wireless AP mode= l, but of course a lot of home environments won't have the luxury of a wire= d backbone, so we will probably have to do air-to-air infrastructure links = to make it work. What does this look like? >=20 > One way to make this work, which someone jokingly alluded to before, woul= d be to have all the APs coexist in a TRILL layer 2. I'm sure I will attr= act some rotten tomatoes for that suggestion, but it _would_ work. Subnet= ting wouldn't work=97it would break connections every time I changed APs. = I am not convinced that making the whole homenet one big bridge is a good = answer, but that would work, in the sense of addressing the specific use ca= se I am describing. Mobile IP would also work, but I don't think it would= be practical to set up a Mobile IP infrastructure on a homenet. >=20 > It can also be argued that nobody needs this functionality. >=20 > Sorry for lobbing this question into an otherwise interesting and related= WiFi mesh discussion, but is anybody else thinking about this and/or conce= rned about this? From v6ops@globis.net Sun Jun 23 11:21:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CAB21F99AF for ; Sun, 23 Jun 2013 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlWbi8Bgv-2L for ; Sun, 23 Jun 2013 11:21:55 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D47721F99A0 for ; Sun, 23 Jun 2013 11:21:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 58BAF8700D0; Sun, 23 Jun 2013 20:21:33 +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 0C88haB-LUEu; Sun, 23 Jun 2013 20:21:33 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 2A75C8700AC; Sun, 23 Jun 2013 20:21:33 +0200 (CEST) Message-ID: <51C73CA6.8060802@globis.net> Date: Sun, 23 Jun 2013 20:21:26 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Ted Lemon References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> In-Reply-To: <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Dave Taht , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" , Andrew McGregor Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 18:21:56 -0000 > Ted Lemon > 23 June 2013 18:18 > There's been brief mention of the WiFi infrastructure problem for the > homenet during this post-last-call conversation, but I don't think we > drew a conclusion, and indeed some of what was said seems to suggest > that we aren't addressing the issue. > > Let's consider the following scenario: I have a wired infrastructure > that connects my home and garage. The home and garage can't all be > served by the same Wifi AP. I want to set up WiFi APs so that I can > wander around between the various parts of my home, as well as > outdoors, and have good WiFi connectivity in all of these locations, > without expensive handoffs and without changing subnets (which would > break connections, e.g. SIP calls, ssh sessions, etc). > > There are a variety of ways of addressing this problem, and you and > Andrew and Ray have touched on them a bit, but I didn't see a clear > requirement stated, and I'd like to. I don't see one in the > architecture document either. > Sounds like a clear requirement for simple end node to router handoff over wireless, with session survivability when the end node device connects via another radio device. That could be expressed in the architecture without moving on to the "how". > The first question is, is this a use case that the Homenet > architecture wants to address? I think the answer is yes, but I don't > get the sense that everybody agrees with that, which is why I am > asking the question directly. Yes. I agree with the requirement (regardless of how it's implemented) > Second, _can_ we address it, given other assumptions we're making in > the architecture, and how? There's a whole load of options: wireless repeating where there's one AP + wireless extenders to create a single flat wireless LAN (WDS) = how most home networks work today. Another would be layer 2 bridging over the entire homenet backbone + multiple AP's advertising the same SSID on different channels (generally how most office wifi works today). Pure routing and disjoint subnets + renumbering the end node would probably break sessions, and would not work as desired as you rightly point out. Another would be carrying a common VLAN for wireless throughout the homenet over a routed homenet backbone (Integrated Routing and Bridging in Cisco speak) or bridging over GRE/ other tunnel or other fancy L2/L3 combo that allows a single subnet to remain contiguous when spanning routed links. Mobile IP. MANET. Mobile end nodes to source / sink sessions from a software loopback interface and route individual /128's around the Homenet. Tunnel from the mobile end node to a central router over a point to point link (like LTE) Plenty of things to explore, and with varying degrees of end node involvement, complexity, and survivability. e.g. sessions over mobile IP requires significant complexity and end node involvement, but would survive a move between different wireless technologies. Bridging requires no end node involvement, is simple within one media type but problematic between types, and sessions would almost certainly not survive a move to a different radio technology . Repeating requires no end node involvement, is generally proprietary, and sessions would not survive a move to a different radio technology. > I've mentioned the wired backbone/wireless AP model, but of course a > lot of home environments won't have the luxury of a wired backbone, so > we will probably have to do air-to-air infrastructure links to make it > work. What does this look like? That to me is a second requirement for wireless, and where we get into a potential conflict with your first requirement. For end node - homenet it's only important that you can connect to at least one device from a set of devices advertising your SSID, and the end node will generally select the channel with the strongest signal if there's more than one. It's not relevant that you can simultaneously reach ALL devices advertising the SSID. For router - router communication, mutual visibility is very relevant, as having all routers in a flat LAN will almost certainly seriously impact common routing protocols being touted. As mentioned previously, the quality of wireless links will vary substantially over time, as will adjacencies, even without moving the routers. > > One way to make this work, which someone jokingly alluded to before, > would be to have all the APs coexist in a TRILL layer 2. I'm sure I > will attract some rotten tomatoes for that suggestion, but it _would_ > work. Subnetting wouldn't work—it would break connections every time I > changed APs. I am not convinced that making the whole homenet one big > bridge is a good answer, but that would work, in the sense of > addressing the specific use case I am describing. Mobile IP would also > work, but I don't think it would be practical to set up a Mobile IP > infrastructure on a homenet. > > It can also be argued that nobody needs this functionality. > > Sorry for lobbing this question into an otherwise interesting and > related WiFi mesh discussion, but is anybody else thinking about this > and/or concerned about this? You've brought up the two wireless use cases that triggered my original comments, so yes I am concerned that we are neglecting documenting requirements. Speaking as someone who lives in a reinforced concrete box, I also think that router to router connectivity over wireless is a requirement. regards, RayH > Acee Lindem > 23 June 2013 17:38 > There is room for innovation here and I agree that one could come up > with a model to support this. However, I'm not ready to take it as a > requirement for an auto-configured homenet since the Wi-Fi broadcast > network model has heretofore served us quite well. > Acee > On Jun 23, 2013, at 7:24 AM, Andrew McGregor wrote: > > From mellon@fugue.com Sun Jun 23 11:58:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E428021F9D96 for ; Sun, 23 Jun 2013 11:58:40 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjalGGkx04OW for ; Sun, 23 Jun 2013 11:58:35 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0E021F9EE0 for ; Sun, 23 Jun 2013 11:58:35 -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 0F4232380423; Sun, 23 Jun 2013 14:58:31 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47186AC3@eusaamb101.ericsson.se> Date: Sun, 23 Jun 2013 14:58:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <94A203EA12AECE4BA92D42DBFFE0AE47186AC3@eusaamb101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1508) Cc: Ray Hunter , "homenet@ietf.org Group" , Andrew McGregor , Ralph Droms , Dave Taht Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 18:58:41 -0000 On Jun 23, 2013, at 2:18 PM, Acee Lindem = wrote: > For this particular problem, I don't think there is a simple solution = at layer 3. I think layer 2 bridging is the most straightforward = approach to extend the wireless LAN without requiring additional = function in every device that connects (e.g., MIP6). =20 I think you are right, but it points out an issue with the homenet = architecture, because the homenet architecture currently assumes a lot = of subnetting, and I think for good reason. And yet we have what seems = to me to be a clear and contradictory requirement for bridging in the = case of Wifi infrastructure. How do we get both? From jch@pps.univ-paris-diderot.fr Sun Jun 23 14:52:03 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BF621F9CDB for ; Sun, 23 Jun 2013 14:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZmcctNcJ371 for ; Sun, 23 Jun 2013 14:51:57 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 839DD21F9CC7 for ; Sun, 23 Jun 2013 14:51:55 -0700 (PDT) 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/38117) with ESMTP id r5NLpmwT022029; Sun, 23 Jun 2013 23:51:49 +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 426AB4EE2B; Sun, 23 Jun 2013 23:51:48 +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 6zQOAiKZEUsr; Sun, 23 Jun 2013 23:51:47 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2897D4EE26; Sun, 23 Jun 2013 23:51:47 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UqsCJ-0001Jr-FY; Sun, 23 Jun 2013 23:51:47 +0200 Date: Sun, 23 Jun 2013 23:51:47 +0200 Message-ID: <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 23 Jun 2013 23:51:49 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 21:52:03 -0000 > One way to make this work, which someone jokingly alluded to before, > would be to have all the APs coexist in a TRILL layer 2. I'm sure > I will attract some rotten tomatoes for that suggestion, but it > _would_ work. I'm starting to be seriously fed up with the TRILL propaganda. Has anyone actually made the above to work with TRILL? With single-radio wireless routers serving as relays? Without the silly topology restrictions required by WDS? You must realise that we, in the mesh networking community, have been doing all of the above (and more) for a decade now. We have a number of protocols that have been demonstrated, on multiple occasions and by independent researchers, to work satisfactorily (OLSR-ETX, Babel, BATMAN). We spend our copious free time organising regular meetings to check that this is still the case. It is difficult not to be annoyed when our work is summarily dismissed by people who have never flashed a router in their life, but have the gall to say that running IS-IS at layer 2 with a bunch of tunnels will actually solve more problems than it will introduce. Please do refrain from promoting TRILL for this kind of application until you can provide us with experimental data. Getting wireless meshes to work with acceptable efficiency is a little more difficult than you seem to realise. -- Juliusz From mellon@fugue.com Sun Jun 23 15:36:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213D521F9F68 for ; Sun, 23 Jun 2013 15:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fq4MOKW4gPh for ; Sun, 23 Jun 2013 15:36:06 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 13F5321F9F4C for ; Sun, 23 Jun 2013 15:36:06 -0700 (PDT) Received: from [IPv6:2001:470:88a3::3596:9549:789d:ec38] (unknown [IPv6:2001:470:88a3:0:3596:9549:789d:ec38]) by toccata.fugue.com (Postfix) with ESMTPSA id CB72E2380986; Sun, 23 Jun 2013 18:36:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> Date: Sun, 23 Jun 2013 18:36:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 22:36:11 -0000 On Jun 23, 2013, at 5:51 PM, Juliusz Chroboczek = wrote: > I'm starting to be seriously fed up with the TRILL propaganda. Excuse me? Well, I guess I did predict rotten tomatoes, but you = apparently have a very low bar for what qualifies as propaganda. > Has anyone actually made the above to work with TRILL? I've never done anything with TRILL except review some documents. I'm = just trying to figure out how to solve the problem, and TRILL does solve = the problem, at least on paper. If there is a better solution, I'm all = ears. > You must realise that we, in the mesh networking community, have been > doing all of the above (and more) for a decade now. We have a number > of protocols that have been demonstrated, on multiple occasions and by > independent researchers, to work satisfactorily (OLSR-ETX, Babel, > BATMAN). We spend our copious free time organising regular meetings > to check that this is still the case. Well then make your case. How does what you have done solve the = problem I asked about in the homenet architecture? I am not asking how = it works in a wide-area mesh network; I am asking how it works in a = homenet. > It is difficult not to be annoyed when our work is summarily dismissed > by people who have never flashed a router in their life, but have the > gall to say that running IS-IS at layer 2 with a bunch of tunnels will > actually solve more problems than it will introduce. Your work is not summarily dismissed. It is simply not being included = in the discussion, because the people who know about it are busy = accusing me of propagandizing rather than explaining why their idea is = better! > Please do refrain from promoting TRILL for this kind of application > until you can provide us with experimental data. Getting wireless > meshes to work with acceptable efficiency is a little more difficult > than you seem to realise. I didn't propose using TRILL in a wireless mesh. I proposed using it = to connect wireless APs using a wired backbone. If you think I will = get better performance in this scenario by connecting my APs using a = wireless mesh, I am interested in hearing how. But I think this will = actually be more difficult than using a wired backbone, because I live = in a Passivhaus, and the insulation on the house is foil-backed, so it's = very difficult to get radio signals through it; the only = radio-transparent part of the house is the bank of windows on the south = wall, and the garage is to the east. And I already have a bunch of cat = 6e shielded wires going from the house to the garage, so it's hard to = see how any wireless solution you could propose would be easier than = using one of them. Of course this is not a general scenario, but do you see my point? I'm = trying to solve a problem that I don't think is easily solved with = wireless, and that I think is relevant to homenet, and that is not = currently discussed in the homenet architecture document. It's quite = likely that some sort of layer 2 wireless mesh would work in a different = scenario.= From jch@pps.univ-paris-diderot.fr Sun Jun 23 16:56:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCAF21F925A for ; Sun, 23 Jun 2013 16:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Us+QPdEiev for ; Sun, 23 Jun 2013 16:56:39 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF0321F9978 for ; Sun, 23 Jun 2013 16:56:35 -0700 (PDT) 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/38117) with ESMTP id r5NNuTep014263; Mon, 24 Jun 2013 01:56:30 +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 E2A724EE42; Mon, 24 Jun 2013 01:56: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 lUzG_KPNlqhv; Mon, 24 Jun 2013 01:56:28 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 342024EE39; Mon, 24 Jun 2013 01:56:28 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Uqu8y-0001VI-7Y; Mon, 24 Jun 2013 01:56:28 +0200 Date: Mon, 24 Jun 2013 01:56:28 +0200 Message-ID: <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 24 Jun 2013 01:56:32 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 23:56:49 -0000 >> I'm starting to be seriously fed up with the TRILL propaganda. > Excuse me? My apologies, Ted. The tone of my reply was not called for. > you apparently have a very low bar for what qualifies as propaganda. > > Has anyone actually made the above to work with TRILL? > I've never done anything with TRILL except review some documents. Sorry for the terminology. By "propaganda" I meant "repeatedly claiming that TRILL solves the problem without providing any operational evidence". (You know, working code and all that.) Ted, I really think we should be extremely cautious when evaluating solutions based on the Ruby Goldberg device known as TRILL. > I didn't propose using TRILL in a wireless mesh. I proposed using > it to connect wireless APs using a wired backbone. You do that using a routing protocol. I have trouble believing that moving your routing protocol to layer 2 and hiding it beneath a layer of tunnelling is going to lead to a robust solution. > If you think I will get better performance in this scenario by > connecting my APs using a wireless mesh, I am interested in hearing > how. But I think this will actually be more difficult than using > a wired backbone, because I live in a Passivhaus, and the > insulation on the house is foil-backed, Ah, I see the misunderstanding, and it's due to sloppy terminology on my part. What we usually call "wireless meshes" are actually hybrid -- they consist of both wired and wireless links, just like you'd expect. The topologies are usually more complex than what you envision (there are multiple diconnected wired backbones rather than just one), but we use wired links extensively, either to save radio spectrum where laying cables is easy, or to cross obstacles. A wired link with just two nodes on it is a common way of crossing a wall. (Babel has explicit provisions for efficient usage of wired links. In OSLR-ETX and BATMAN, wired links work, but are not particularly optimised for.) > How does what you have done solve the problem I asked about in the > homenet architecture? You have a bunch of routers. You run a routing protocol on all of them. Every router announces one or more /64 for its connected links. You run normal RAs, so that unmodified nodes can connect to the network. (Reminder to anyone who forgot -- routers ignore RAs.) If you don't care about compatibility with normal devices, you run the routing protocol on each mobile node, but have it filter any routes except for announcing its own /128 (this is described in RFC 6126 Appendix C). In effect, you have two kinds of nodes: "legacy" nodes that use normal routing practices for hosts (RAs, on-link routing using ND), and mesh nodes, that participate in the routing protocol although they are not routers. Legacy nodes must renumber whenever they roam, while mesh nodes can roam seamlessly at the cost of introducing an extra /128 into your routing domain and going through a router in order to reach on-link legacy nodes. If you want legacy devices to roam seamlessly, it's a little more messy. Whenever neighbour discovery (or link sensing?) indicates that your node has roamed, you have your routers inject a /128 into the routing domain. That's going to be slightly less robust (since the roaming node is not beaconing HELLO packets, so link quality cannot be estimated). At a basic level, this will work with any routing protocol as long as it allows /128 routes. Of course, if you want the kind of topologies that we use in mesh networks (forwarding by single-radio nodes, usage of marginal links when no good links are available), you'll want a protocol that has the ability to use such topologies, but that's strictly optional. I'd like to stress that, except for the hack described in the next-to-last paragraph, we have implemented and tested the above. -- Juliusz From brian.e.carpenter@gmail.com Sun Jun 23 19:22:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55FE21E808D for ; Sun, 23 Jun 2013 19:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJu4IRI1oEff for ; Sun, 23 Jun 2013 19:22:04 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF3421E8085 for ; Sun, 23 Jun 2013 19:22:04 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rl6so10354167pac.15 for ; Sun, 23 Jun 2013 19:22:04 -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=CS1+Gh8RXxYCQFfac/0g55FmzWAlLve0ahsvLaKaKuw=; b=l1GhZ+BNv+lqiVomyHVpO0y1br//254LJxHmL+twf67NAtxzzlZXRE8Exodz9Z+qiB WzocuiMvr1mAnztLFrKvs5RnMG8RY4zBark4UjugqyF1iq+At6jfnIjg00tgW6lE7Bog gLEgAKswFXTR0yn2EBElLMpqD1uNChxOsGCfpQqg3Xl5HPOZ0R1fWntzLgHfoavuJpWd d2iYne4ZWRc1GJGtJZ7e/L9TArd5cc979ruDPS8VJkpoSn6frwBFZpuXLb3dP28kyhfw pDdOeI3ytnThtO5oypB9jTXJIK1B/0Zxj5+m4M/uPHlHDyKclkmU83pifUcmuRdJDw6X iGsg== X-Received: by 10.68.170.193 with SMTP id ao1mr21827025pbc.18.1372040524101; Sun, 23 Jun 2013 19:22:04 -0700 (PDT) Received: from [192.168.178.22] (91.198.69.111.dynamic.snap.net.nz. [111.69.198.91]) by mx.google.com with ESMTPSA id re16sm17267641pac.16.2013.06.23.19.22.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Jun 2013 19:22:03 -0700 (PDT) Message-ID: <51C7AD48.3060302@gmail.com> Date: Mon, 24 Jun 2013 14:22:00 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <51C151A7.2070304@globis.net> In-Reply-To: <51C151A7.2070304@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 02:22:05 -0000 On 19/06/2013 18:37, Ray Hunter wrote: ... > Although ULA prefixes are recommended to be filtered at the site > boundary (Section 4.3 RFC4193) > they also may be used for inter-site VPN's (section 4.7 RFC4193). > > Making additional/ unnecessary assumptions about reachability and > security is IMHO yet another .local / RFC1918 problem waiting to strike. > > If you want security, the device providing the security needs to > understand the topology e.g. where the site border is in relation to the > endpoints of the connection request. Merely relying on addressing > schemes is insufficient IMHO. Absolutely. You are certainly correct that "ULA safe, GUA dangerous" is not always true. But is this different from a case where a GUA prefix is leaked to a friend via a VPN; if you're doing that with a ULA prefix it's exactly the same. You need per-prefix rules. Unfortunately, with the complexity of homenets that people seem to envisage for the future, I think we're going to see these enterprise type issues in complex homenets. Brian From mellon@fugue.com Sun Jun 23 20:07:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E8821F92E7 for ; Sun, 23 Jun 2013 20:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6FScNnqkBD9 for ; Sun, 23 Jun 2013 20:07:46 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1698021F9360 for ; Sun, 23 Jun 2013 20:07:45 -0700 (PDT) Received: from [IPv6:2001:470:88a3::447b:ecfe:46ca:a9bb] (unknown [IPv6:2001:470:88a3:0:447b:ecfe:46ca:a9bb]) by toccata.fugue.com (Postfix) with ESMTPSA id C57C02380986; Sun, 23 Jun 2013 23:07:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> Date: Sun, 23 Jun 2013 23:07:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@p ps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 03:07:51 -0000 The routing mesh you're describing sounds like it would work, and be = quite useful, but not for a homenet environment. The specific = functionality that I want is the same functionality you get with = infrastructure wifi in a large office environment: that my laptop = continues to work as I switch from AP to AP, without renumbering. I = don't think your mesh environment achieves that. From jch@pps.univ-paris-diderot.fr Mon Jun 24 04:46:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6480121F9377 for ; Mon, 24 Jun 2013 04:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTmVKXTCRRON for ; Mon, 24 Jun 2013 04:46:05 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 57C5421F9374 for ; Mon, 24 Jun 2013 04:46:05 -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/38117) with ESMTP id r5OBjvsv004934; Mon, 24 Jun 2013 13:45:59 +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 AC9514EEB8; Mon, 24 Jun 2013 13:45:57 +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 nlFBmGcPzRd9; Mon, 24 Jun 2013 13:45:56 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9435D4EEAB; Mon, 24 Jun 2013 13:45:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Ur5DY-0001I1-Pl; Mon, 24 Jun 2013 13:45:56 +0200 Date: Mon, 24 Jun 2013 13:45:56 +0200 Message-ID: <87mwqfn34b.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 24 Jun 2013 13:45:59 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:46:11 -0000 > The routing mesh you're describing sounds like it would work, and be > quite useful, but not for a homenet environment. Why so? > The specific functionality that I want is the same functionality you > get with infrastructure wifi in a large office environment: that my > laptop continues to work as I switch from AP to AP, without > renumbering. > I don't think your mesh environment achieves that. It certainly did last week. (I'm not in Paris right now, and I cannot check if it still does.) -- Juliusz From v6ops@globis.net Mon Jun 24 05:12:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8131A11E8137 for ; Mon, 24 Jun 2013 05:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sWwO3IhFbnJ for ; Mon, 24 Jun 2013 05:12:46 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12911E8138 for ; Mon, 24 Jun 2013 05:12:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E134787007C; Mon, 24 Jun 2013 14:12:29 +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 guRq+RF+p98k; Mon, 24 Jun 2013 14:12:29 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B52D1870002; Mon, 24 Jun 2013 14:12:29 +0200 (CEST) Message-ID: <51C837A7.3000005@globis.net> Date: Mon, 24 Jun 2013 14:12:23 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Juliusz Chroboczek References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <87mwqfn34b.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87mwqfn34b.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:12:47 -0000 Juliusz Chroboczek wrote: >> The routing mesh you're describing sounds like it would work, and be >> quite useful, but not for a homenet environment. > > Why so? > >> The specific functionality that I want is the same functionality you >> get with infrastructure wifi in a large office environment: that my >> laptop continues to work as I switch from AP to AP, without >> renumbering. > >> I don't think your mesh environment achieves that. > > It certainly did last week. (I'm not in Paris right now, and I cannot > check if it still does.) > > -- Juliusz Juliusz: I think Ted means, "without installing new (mesh knowledgable) code on my existing office device and have it participate in the routing protocol." Ted: working with AP's like the "infrastructure wifi in a large office environment" today implies a common bridged connection between all AP's advertising a single SSID and a common radio technology AFAIK. Don't hesitate to correct me if I'm wrong. May I suggest we make a summary table of all of the options on the table, together with pros, cons and assumptions behind each? I can think of at least 6 ways of approaching the desired result: none of which is perfect assuming a starting point of today's devices "out of the shrink wrap". So that suggests to me it's an important topic for Homenet to at least explicitly document as a gap. regards, RayH From mcr@sandelman.ca Mon Jun 24 06:27:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F9821E80DF for ; Mon, 24 Jun 2013 06:27:24 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsW7gUUbsB5r for ; Mon, 24 Jun 2013 06:27:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC9521E80DC for ; Mon, 24 Jun 2013 06:27:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8D58C2024B; Mon, 24 Jun 2013 10:31:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 210DB63A7C; Mon, 24 Jun 2013 09:26:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 14EFC63A5E; Mon, 24 Jun 2013 09:26:21 -0400 (EDT) From: Michael Richardson To: Ray Hunter In-Reply-To: <51C837A7.3000005@globis.net> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <87mwqfn34b.wl%jch@pps.univ-paris-diderot.fr> <51C837A7.3000005@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 Cc: "homenet@ietf.org Group" , Ted Lemon , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:27:25 -0000 --=-=-= Ray Hunter wrote: > Ted: working with AP's like the "infrastructure wifi in a large office > environment" today implies a common bridged connection between all AP's > advertising a single SSID and a common radio technology AFAIK. > Don't hesitate to correct me if I'm wrong. Yes, you are correct. And handoff between APs. I think that it's unobtainable in the home(net) at this time, and I think that it is out-of-scope for homenet. By this, I mean that I think that application of suitable specifications by AP vendors could make it happen without putting specific requirements on homenet. I think that the APs might have to do things like figure out how to do their wire-side coordination over IP(v6). -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUchI+oqHRg3pndX9AQL/bAQAoe+NK8SRT/nR27J3QPivLMV3BzfXJDnt UpyLTA6Cs5DqqZzLYJpOYq1eG37JaR3pRXdYl5Wty+ZeUIsSw0csy1u+CeVyYZ06 hGVkEifD6gNPaTPASliKRqNoY9WD7ikfRZ5WR84RGS8WuiySbL4sXHWOFM7SdsDW 5LVzDsBPOUc= =JuCP -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Mon Jun 24 06:48:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B253621E80E4 for ; Mon, 24 Jun 2013 06:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArVsoD8a--6P for ; Mon, 24 Jun 2013 06:48:52 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id F079811E813A for ; Mon, 24 Jun 2013 06:48:50 -0700 (PDT) Received: from [IPv6:2001:470:88a3::3883:3fd4:9e40:f2dd] (unknown [IPv6:2001:470:88a3:0:3883:3fd4:9e40:f2dd]) by toccata.fugue.com (Postfix) with ESMTPSA id A900723807E9; Mon, 24 Jun 2013 09:48:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <87mwqfn34b.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 24 Jun 2013 09:48:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05D93348-407A-4EF8-827C-8866D30B28C0@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <87mwqfn34b.wl%jch@p ps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:48:57 -0000 On Jun 24, 2013, at 7:45 AM, Juliusz Chroboczek = wrote: > It certainly did last week. (I'm not in Paris right now, and I cannot > check if it still does.) Okay, then maybe I just don't understand the architecture. You are = saying that it's a routed architecture, but in order for what I am = describing to work, you need either bridging between wired and wireless, = which is undesirable in the homenet architecture, or else you need some = kind of layer two tunnel mesh connecting the wireless links, using the = wired link as a transport for the tunnels. Based on what you are saying, it must be the case that you are doing = something like the latter, or else something like the former, but I = don't know your architecture, so I can't tell which. From mellon@fugue.com Mon Jun 24 06:55:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2106611E814B for ; Mon, 24 Jun 2013 06:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvaACguyyb7e for ; Mon, 24 Jun 2013 06:55:01 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6F37C21E80ED for ; Mon, 24 Jun 2013 06:53:58 -0700 (PDT) Received: from [IPv6:2001:470:88a3::3883:3fd4:9e40:f2dd] (unknown [IPv6:2001:470:88a3:0:3883:3fd4:9e40:f2dd]) by toccata.fugue.com (Postfix) with ESMTPSA id A553B23807E9; Mon, 24 Jun 2013 09:53:57 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <51C837A7.3000005@globis.net> Date: Mon, 24 Jun 2013 09:53:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <307E71C1-B05E-4D84-A9A3-1A0F8FE039AD@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <87mwqfn34b.wl%jch@pps.univ-paris-diderot.fr> <51C837A7.3000005@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:55:06 -0000 On Jun 24, 2013, at 8:12 AM, Ray Hunter wrote: > Juliusz: I think Ted means, "without installing new (mesh = knowledgable) > code on my existing office device and have it participate in the = routing > protocol." Yeah, clearly that is out of scope for homenet, but I think Juliusz = isn't asking us to do that, so it's okay. > Ted: working with AP's like the "infrastructure wifi in a large office > environment" today implies a common bridged connection between all = AP's > advertising a single SSID and a common radio technology AFAIK. That seems likely. Although if most of the communication is = wireless-to-wire, the common radio technology bit isn't as important, as = long as it's a common family=97e.g., 802.11a, 802.11b, 802.11g, 802.11n, = 802.11ac. But we don't know what most of the communication will be, so = that's questionable. > May I suggest we make a summary table of all of the options on the > table, together with pros, cons and assumptions behind each? >=20 > I can think of at least 6 ways of approaching the desired result: none > of which is perfect assuming a starting point of today's devices "out = of > the shrink wrap". >=20 > So that suggests to me it's an important topic for Homenet to at least > explicitly document as a gap. Yup. From mellon@fugue.com Mon Jun 24 07:00:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AC111E8152 for ; Mon, 24 Jun 2013 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltLI+-tNor6q for ; Mon, 24 Jun 2013 07:00:42 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE0211E8151 for ; Mon, 24 Jun 2013 07:00:42 -0700 (PDT) Received: from [IPv6:2001:470:88a3::3883:3fd4:9e40:f2dd] (unknown [IPv6:2001:470:88a3:0:3883:3fd4:9e40:f2dd]) by toccata.fugue.com (Postfix) with ESMTPSA id BCB6123807E9; Mon, 24 Jun 2013 10:00:41 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <26594.1372080381@sandelman.ca> Date: Mon, 24 Jun 2013 10:00:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <87mwqfn34b.wl%jch@pps.univ-paris-diderot.fr> <51C837A7.3000005@globis.net> <26594.13720803 81@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1508) Cc: Ray Hunter , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:00:54 -0000 On Jun 24, 2013, at 9:26 AM, Michael Richardson = wrote: > By this, I mean that I think that application of suitable = specifications by > AP vendors could make it happen without putting specific requirements = on > homenet. I think that the APs might have to do things like figure out = how to > do their wire-side coordination over IP(v6). This is a good point. I think documenting it as a gap is the way to = go=97I agree that there's probably no way to make the right thing happen = automatically, since "the right thing" is situationally variable. From jch@pps.univ-paris-diderot.fr Mon Jun 24 07:17:33 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332CB21E80ED for ; Mon, 24 Jun 2013 07:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QlfY+Z5xBvK for ; Mon, 24 Jun 2013 07:17:16 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 9166921E8102 for ; Mon, 24 Jun 2013 07:17:13 -0700 (PDT) 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/38117) with ESMTP id r5OEH5VV020704; Mon, 24 Jun 2013 16:17:05 +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 ED4274EED3; Mon, 24 Jun 2013 16:17:04 +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 3Pd_hxIFkqUg; Mon, 24 Jun 2013 16:16:58 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CE2854EEC5; Mon, 24 Jun 2013 16:16:58 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Ur7Zj-0001bF-4Q; Mon, 24 Jun 2013 16:16:59 +0200 Date: Mon, 24 Jun 2013 16:16:59 +0200 Message-ID: <8761x3mw4k.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <05D93348-407A-4EF8-827C-8866D30B28C0@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 24 Jun 2013 16:17:05 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:17:33 -0000 > > It certainly did last week. (I'm not in Paris right now, and I cannot > > check if it still does.) > Okay, then maybe I just don't understand the architecture. As Ray rightly noted, our mobile nodes are participating in the routing protocol (but not necessarily in routing -- they're just announcing a /128 to their own address). No renumbering happens when such a node roams. Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the same link, but the normal nodes need to renumber (and hence lose all TCP sessions) when they switch links. If you prefer, your network can evolve: you can use unmodified ("homenet-compatible") nodes on the homenet, but using modified ("homenet-aware") nodes you get extra functionality. I'll stress once again that this is not some paper protocol, this is stuff that we have been running daily for years, and is used to access the Internet for a number of grad students in our lab. (Unlike the official wifi, our mesh has good coverage of the couch in the grad students' coffee room.) (In practice, we're not running both RA and Babel on the same link; we prefer to set up multiple interfaces on the same physical radio, some of which run Babel and some of which run DHCPv4 and RA, due to NAT-related issues. In a pure IPv6 network, we'd probably be using a single interface.) This is why I'm hoping that the homenet architecture we converge on has the following properties: - it uses layer-3 routing; - the choice of routing protocol isn't wired too deep within the architecture (for example, configuration information is not carried by the routing protocol, which is bad engineering in any case); - the choice of routing protocol is not constrained too much by the architecture. -- Juliusz From gettysjim@gmail.com Mon Jun 24 07:37:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3821D21E80F3 for ; Mon, 24 Jun 2013 07:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLPqpuPHUSBZ for ; Mon, 24 Jun 2013 07:37:39 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 70A8021F9994 for ; Mon, 24 Jun 2013 07:37:39 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so12036025oag.30 for ; Mon, 24 Jun 2013 07:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IzLPSTWtMs1h+YgDk9/zVWv/eHp7HPgIymCfRv59jag=; b=0QQ8PUR+0Hx/RKE+lowmWkgDdhfAKdWwLNtYlLie4JABsVkBzoLTOYqjVYrF9P1E8T L8EEsPCEzPmcMfOsw6mdDQ3TILOkjEh7ApWViKwFA+HLBB7CbcQ1YZhM03IZBd67vUJz 5HsVV9fLRRFXICIww3Zjn09izSh9JPMVrD7eiV5GpwFngd6Go+k8P8ivOuFScoa9TF8z oEyL1p74P9sjZ99uYtG1vARCOoJXhhp7aaXi4jNqf7CxhhfNimORwx1t7nbHHhlzoeI7 a3ieVxs8n0fDRs4b+L3xpXbBwLaao1CSIyPv7QGLCdWnPNsCqpTCndhuveTZGBPNslyg 1F+g== MIME-Version: 1.0 X-Received: by 10.60.40.42 with SMTP id u10mr3796375oek.2.1372084658959; Mon, 24 Jun 2013 07:37:38 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.115.163 with HTTP; Mon, 24 Jun 2013 07:37:38 -0700 (PDT) In-Reply-To: <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 24 Jun 2013 10:37:38 -0400 X-Google-Sender-Auth: rtsNSP6RlQDH_dPpbWfEcVUI9GI Message-ID: From: Jim Gettys To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=089e0122a33ab2ffba04dfe75a7b Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:37:40 -0000 --089e0122a33ab2ffba04dfe75a7b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > if it turns out to be multicast specific it could go in 3.5.1. > > if there are more general issues to consider then perhaps a new > sub-section? > > No, I think it's more general. What about something like the following: > > Homenets tend to grow organically over many years, and a homenet > will typically be built over link-layer technologies from different > generations. Current homenets typically use links ranging from > 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed > discrepancy. We expect this discrepancy to get worse as both > high-speed and low-power technogies are deployed. > > Homenet protocols should be designed to deal well with > interconnecting links of very different speeds. In particular, > flows local to a link should not be flooded throughout the homenet, > even when sent over multicast, and, whenever possible, the homenet > protocols should be able to choose the faster links and avoid the > slower ones. > > If you wish, I can add a sentence saying "This implies that a link-state > protocol must be used in the homenet" ;-) > I'll stay out of the routing discussion.... But I'd like to point out that the problems we're already facing are not just multicast, as Dave Taht has educated me recently The scarcest resource can often now be "transmit-opportunities", or txopts; certainly this is true for WiFi (you get around 1000/second, and that's it...). So anything that causes packets to require their own txopt for transmission makes them very expensive. So, for example, whether it is even wise to use the hardware priority queues WiFi nominally has (even if they work correctly) at all is questionable; under a loaded network, bundling your voip traffic into the first available transmit opportunity along with other traffic you have queued is clearly better than having to burn an extra txopt to use the "feature" of the hardware queue, if no further delay will be incurred by doing so. Multicast is evil not only due to its inefficient use of the available bandwidth, but because it forces use of a separate txopt for transmission. The real point is we have several technological drivers toward wanting to avoid the network being "chatty", and liking protocols that allow for aggregation of packets when transmissions do occur. I'm not sure I can easily express this in RFCese, however. - Jim > -- Juliusz > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --089e0122a33ab2ffba04dfe75a7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri= , Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek <jch@pps.univ-pa= ris-diderot.fr> wrote:
> if it turns out to be multicast spe= cific it could go in 3.5.1.
> if there are more general issues to consider then perhaps a new sub-se= ction?

No, I think it's more general. =A0What about something like the f= ollowing:

=A0 Homenets tend to grow organically over many years, and a homenet
=A0 will typically be built over link-layer technologies from different
=A0 generations. =A0Current homenets typically use links ranging from
=A0 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed
=A0 discrepancy. =A0We expect this discrepancy to get worse as both
=A0 high-speed and low-power technogies are deployed.

=A0 Homenet protocols should be designed to deal well with
=A0 interconnecting links of very different speeds. =A0In particular,
=A0 flows local to a link should not be flooded throughout the homenet,
=A0 even when sent over multicast, and, whenever possible, the homenet
=A0 protocols should be able to choose the faster links and avoid the
=A0 slower ones.

If you wish, I can add a sentence saying "This implies that a link-sta= te
protocol must be used in the homenet" ;-)

I'll stay out= of the routing discussion....

But I'= d like to point out that the problems we're already facing are not just= multicast, as Dave Taht has educated me recently =A0The scarcest resource = can often now be "transmit-opportunities", or txopts; certainly t= his is true for WiFi (you get around 1000/second, and that's it...).

So anything that causes packet= s to require their own txopt for transmission makes them very expensive. = =A0So, for example, whether it is even wise to use the hardware priority qu= eues WiFi nominally has (even if they work correctly) at all is questionabl= e; under a loaded network, bundling your voip traffic into the first availa= ble transmit opportunity along with other traffic you have queued is clearl= y better than having to burn an extra txopt to use the "feature" = of the hardware queue, if no further delay will be incurred by doing so.

Multicast is evil not only due= to its inefficient use of the available bandwidth, but because it forces u= se of a separate txopt for transmission.

The real point is we have seve= ral technological drivers toward wanting to avoid the network being "c= hatty", and liking protocols that allow for aggregation of packets whe= n transmissions do occur.

I'm not sure I can easily = express this in RFCese, however. =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 - Jim


-- Juliusz
___________________________= ____________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--089e0122a33ab2ffba04dfe75a7b-- From mellon@fugue.com Mon Jun 24 07:42:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557E021F8F38 for ; Mon, 24 Jun 2013 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF1P-BqSvYMn for ; Mon, 24 Jun 2013 07:41:54 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2CC21F9A2A for ; Mon, 24 Jun 2013 07:41:52 -0700 (PDT) Received: from [IPv6:2001:470:88a3::3883:3fd4:9e40:f2dd] (unknown [IPv6:2001:470:88a3:0:3883:3fd4:9e40:f2dd]) by toccata.fugue.com (Postfix) with ESMTPSA id B127923807E9; Mon, 24 Jun 2013 10:41:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <8761x3mw4k.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 24 Jun 2013 10:41:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2AFD98F5-A324-4601-8DF7-DDCF71F7F936@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <8761x3mw4k.wl%jch@p ps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:42:00 -0000 On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek = wrote: > Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the > same link, but the normal nodes need to renumber (and hence lose all > TCP sessions) when they switch links. If you prefer, your network can > evolve: you can use unmodified ("homenet-compatible") nodes on the > homenet, but using modified ("homenet-aware") nodes you get extra > functionality. I don't think this is the right direction to go. Requiring some kind = of mobility stack on the host isn't something that I can see getting any = significant market penetration in the general-purpose host environment. = It's fine for service provider environments where the service provider = has some leverage to make special requirements on the host, and it's = fine for environments like public metropolitan wireless where there's a = strong incentive for adventurous people to install the software, but the = homenet environment isn't that. From mellon@fugue.com Mon Jun 24 08:04:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6273C11E8145 for ; Mon, 24 Jun 2013 08:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvHkRgvb7PCO for ; Mon, 24 Jun 2013 08:04:11 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 617EB21E80E9 for ; Mon, 24 Jun 2013 08:04:11 -0700 (PDT) Received: from [IPv6:2001:470:88a3::3883:3fd4:9e40:f2dd] (unknown [IPv6:2001:470:88a3:0:3883:3fd4:9e40:f2dd]) by toccata.fugue.com (Postfix) with ESMTPSA id 9A76A23807E9; Mon, 24 Jun 2013 11:04:10 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: Date: Mon, 24 Jun 2013 11:04:09 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7BBE71D9-7954-4EC4-A563-9796D8EB36AB@fugue.com> References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> To: Jim Gettys X-Mailer: Apple Mail (2.1508) Cc: Ole Troan , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:04:16 -0000 On Jun 24, 2013, at 10:37 AM, Jim Gettys wrote: > I'm not sure I can easily express this in RFCese, however. You seem to have expressed it quite well in email-ese. Why not try? From gettysjim@gmail.com Mon Jun 24 08:17:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8513021F9983 for ; Mon, 24 Jun 2013 08:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO1gPIGXvOMN for ; Mon, 24 Jun 2013 08:17:09 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A76E921F967C for ; Mon, 24 Jun 2013 08:17:09 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so10732409obc.40 for ; Mon, 24 Jun 2013 08:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9pcUopbrYoppe411ExphsR53PP+JMS59PRBvPBqRAkI=; b=NrAT59+RmKLFLv9Kj1/C0iaEDMYw8VLT6Y45HPjkJZ1b4M7xedg4e5weQ5r89hDnVG NVYsXXo95x31wyCMOAKaPCo25h9yUZWwqW6sJU3TLsZJR0Fnf1Ttr5zxy2UJ/PIag6MZ aWJdmPIznURcbvwKZJXtuYWoAOQg36BlKGXEIXbiGVUtbaCwYFPstvx9FkX0+HhBV9UD Zcd6MugM824p5DTyTSXhCtHGPU/1OAXO4Wj+0KWenRMKD1o5GELhNPpddgTGV51e5F+y kCmk+/RAx3QsIGovH7yL2aHy2ZHMZuJFceAhIufXlWNxsCi67xT7udgv0I3SOZUfsTb0 oCZg== MIME-Version: 1.0 X-Received: by 10.182.176.34 with SMTP id cf2mr8150670obc.45.1372086687642; Mon, 24 Jun 2013 08:11:27 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.115.163 with HTTP; Mon, 24 Jun 2013 08:11:27 -0700 (PDT) In-Reply-To: <2AFD98F5-A324-4601-8DF7-DDCF71F7F936@fugue.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <8761x3mw4k.wl%jch@pps.univ-paris-diderot.fr> <2AFD98F5-A324-4601-8DF7-DDCF71F7F936@fugue.com> Date: Mon, 24 Jun 2013 11:11:27 -0400 X-Google-Sender-Auth: yX2jRq5gQBMQtP-ET5LluQxQwQQ Message-ID: From: Jim Gettys To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8ff1cf829e3de704dfe7d332 Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:17:10 -0000 --e89a8ff1cf829e3de704dfe7d332 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon wrote: > On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek < > jch@pps.univ-paris-diderot.fr> wrote: > > Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the > > same link, but the normal nodes need to renumber (and hence lose all > > TCP sessions) when they switch links. If you prefer, your network can > > evolve: you can use unmodified ("homenet-compatible") nodes on the > > homenet, but using modified ("homenet-aware") nodes you get extra > > functionality. > > I don't think this is the right direction to go. Requiring some kind of > mobility stack on the host isn't something that I can see getting any > significant market penetration in the general-purpose host environment. > It's fine for service provider environments where the service provider has > some leverage to make special requirements on the host, and it's fine for > environments like public metropolitan wireless where there's a strong > incentive for adventurous people to install the software, but the homenet > environment isn't that. > Ted, Right now, we have a much bigger problem getting shipment of updated routers with anything that homenet may recommend at all; getting code on host operating systems is easier to do than getting router support deployed. I wish this weren't true, but it is. If we aren't being slightly optimistic, what are we doing spending our time on this mailing list? So if an approach has real value (and doesn't require a lot of kernel dependent changes to support; we ain't going to do IPv8!), by the time the routers ship, we can arrange to have host support. I must therefore disagree (given that Juliusz has running code which is not kernel intrusive today). Dismissing such options out of hand even before any analysis is done is therefore a mistake. - Jim > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --e89a8ff1cf829e3de704dfe7d332 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon= , Jun 24, 2013 at 10:41 AM, Ted Lemon <mellon@fugue.com> wrot= e:
On Jun 24, 2013, at 10:16 = AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
> Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the > same link, but the normal nodes need to renumber (and hence lose all > TCP sessions) when they switch links. =A0If you prefer, your network c= an
> evolve: you can use unmodified ("homenet-compatible") nodes = on the
> homenet, but using modified ("homenet-aware") nodes you get = extra
> functionality.

I don't think this is the right direction to go. =A0 Requiring so= me kind of mobility stack on the host isn't something that I can see ge= tting any significant market penetration in the general-purpose host enviro= nment. =A0 It's fine for service provider environments where the servic= e provider has some leverage to make special requirements on the host, and = it's fine for environments like public metropolitan wireless where ther= e's a strong incentive for adventurous people to install the software, = but the homenet environment isn't that.

Ted,
Right now, w= e have a =A0much bigger problem getting shipment of updated routers with an= ything that homenet may recommend at all; getting code on host operating sy= stems is easier to do than getting router support deployed. =A0I wish this = weren't true, but it is. =A0If we aren't being slightly optimistic,= what are we doing spending our time on this mailing list?

So if an approach has real val= ue (and doesn't require a lot of kernel dependent changes to support; w= e ain't going to do IPv8!), by the time the routers ship, we can arrang= e to have host support.

I must therefore disagree (giv= en that Juliusz has running code which is not kernel intrusive today).

Dismissing= such options out of hand even before any analysis is done is therefore a m= istake.
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim




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

--e89a8ff1cf829e3de704dfe7d332-- From acee.lindem@ericsson.com Mon Jun 24 08:31:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A104611E814D for ; Mon, 24 Jun 2013 08:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL9XQokZUj-P for ; Mon, 24 Jun 2013 08:31:01 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D500C11E8144 for ; Mon, 24 Jun 2013 08:31:00 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-34-51c866330f9d Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 91.26.05617.33668C15; Mon, 24 Jun 2013 17:31:00 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 11:30:33 -0400 From: Acee Lindem To: Jim Gettys Thread-Topic: [homenet] 2nd Working Group Last Call for draft-homenet-arch Thread-Index: AQHOYF8oD2/n0Jq0ZEK+oRQ4rPdZUJk06+OAgAXEzICAAvmhgIACyQCAgAClugCAAUFJAIAAJdSAgAAJ34CAABT+gIAAgnQAgABcQ4CAAA0EAIAARvaAgAALRACAAF0OgIAADF0AgAAWeQCAADVtgIAAkMwAgAAiU4CAAAfhgIAABvCAgAAIR4CAAAVTAA== Date: Mon, 24 Jun 2013 15:30:32 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47187916@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <8761x3mw4k.wl%jch@pps.univ-paris-diderot.fr> <2AFD98F5-A324-4601-8DF7-DDCF71F7F936@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47187916eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonVtck7USgQe9TDov3iw6xWHz+9I/V onPxY3aLN2uOMDmweKyas4HVo+nCMnaPJUt+Mnlc3P2OMYAlissmJTUnsyy1SN8ugSvj2NXH bAWf7CtuXtvF1sA416yLkZNDQsBE4nB/HyOELSZx4d56ti5GLg4hgaOMEv0T97NAOMsZJV4s WMsGUsUmoCPx/NE/ZhBbREBZ4uG7XUwgNrNAM6PEpmlgk4QFPCX+v7/BBFHjJTH7YBfYVBGB c4wSG1dMYgVJsAioSqzougg2iFfAW6Lj9TuobZM5JY69+QK2jVMgUOLk5E/sIDYj0H3fT62B 2iYucevJfCaIuwUkluw5zwxhi0q8fPyPFcJWlvg+5xELRH2+xNS1LxkhlglKnJz5hGUCo+gs JKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPoXqtJU4t/c+ErGYBI8cqRo7S4tSy3HQj w02MwNg8JsHmuINxwSfLQ4zSHCxK4rzvT+0KFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAo LFfyxYTn2/Y1HkGF0YI20kFW7l+2aHIkPTtxlK/aMdNhcZtr+75lmi1rV1oInO5Qa5vP1K5+ O2Xn9gnm6YqZuapNj1Y2bmSTa9V2a4xWUT3c+9b2h4lkl+Lv1I/XJ2z9/TujLWdrrNxq52tT jM4aSj6dwHy3/dXficI/f1yc97T67uZ/q9cqsRRnJBpqMRcVJwIAK5+2CpsCAAA= Cc: "homenet@ietf.org Group" , Ted Lemon , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:31:06 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47187916eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote: On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon > wrote: On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek > wrote: > Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the > same link, but the normal nodes need to renumber (and hence lose all > TCP sessions) when they switch links. If you prefer, your network can > evolve: you can use unmodified ("homenet-compatible") nodes on the > homenet, but using modified ("homenet-aware") nodes you get extra > functionality. I don't think this is the right direction to go. Requiring some kind of m= obility stack on the host isn't something that I can see getting any signif= icant market penetration in the general-purpose host environment. It's fi= ne for service provider environments where the service provider has some le= verage to make special requirements on the host, and it's fine for environm= ents like public metropolitan wireless where there's a strong incentive for= adventurous people to install the software, but the homenet environment is= n't that. Ted, Right now, we have a much bigger problem getting shipment of updated route= rs with anything that homenet may recommend at all; getting code on host op= erating systems is easier to do than getting router support deployed. I wi= sh this weren't true, but it is. If we aren't being slightly optimistic, w= hat are we doing spending our time on this mailing list? Jim - I'm not going to debate with you what is harder ;^) However, a requir= ement from the start of the Homenet WG is that we minimize changes to host = software with the goal being none. Thanks, Acee So if an approach has real value (and doesn't require a lot of kernel depen= dent changes to support; we ain't going to do IPv8!), by the time the route= rs ship, we can arrange to have host support. I must therefore disagree (given that Juliusz has running code which is not= kernel intrusive today). Dismissing such options out of hand even before any analysis is done is the= refore a mistake. - Jim _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --_000_94A203EA12AECE4BA92D42DBFFE0AE47187916eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <1207B01A6E640F4AB00E320125562963@ericsson.com> Content-Transfer-Encoding: quoted-printable
On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote:




On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon <mellon@fugue.com<= /a>> wrote:
On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr<= /a>> wrote:
> Once again: normal (RA) and mobile (AHCP+Babel) nodes can share th= e
> same link, but the normal nodes need to renumber (and hence lose all > TCP sessions) when they switch links.  If you prefer, your networ= k can
> evolve: you can use unmodified ("homenet-compatible") nodes = on the
> homenet, but using modified ("homenet-aware") nodes you get = extra
> functionality.

I don't think this is the right direction to go.   Requiring some kind= of mobility stack on the host isn't something that I can see getting any s= ignificant market penetration in the general-purpose host environment. &nbs= p; It's fine for service provider environments where the service provider has some leverage to make special requirements = on the host, and it's fine for environments like public metropolitan wirele= ss where there's a strong incentive for adventurous people to install the s= oftware, but the homenet environment isn't that.

Ted,

Right now, we have a=  much bigger problem getting shipment of updated routers with anythin= g that homenet may recommend at all; getting code on host operating systems= is easier to do than getting router support deployed.  I wish this weren't true, but it is.  If we aren't be= ing slightly optimistic, what are we doing spending our time on this mailin= g list?


Jim - I'm not going to debate with you what is harder ;^) However, a r= equirement from the start of the Homenet WG is that we minimize changes to = host software with the goal being none. 

Thanks,
Acee 



--_000_94A203EA12AECE4BA92D42DBFFE0AE47187916eusaamb101ericsso_-- From gettysjim@gmail.com Mon Jun 24 08:36:17 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0881211E814F for ; Mon, 24 Jun 2013 08:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJA5EPimUtgv for ; Mon, 24 Jun 2013 08:36:16 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2A11E814C for ; Mon, 24 Jun 2013 08:36:12 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so12121953oag.16 for ; Mon, 24 Jun 2013 08:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IrWWYGtMmGnSA3kUtpz6gCaLLZn+f/P7tuNTY/5x+XA=; b=thf385rcwDrdR5qOltZ28m4G+ysdGn/qTR46G+SbzoihY4np+/xrAhDz/9Jb6j914E ldw9SJD6nmuy5T1N8IDkS4iNfWB0ykSOSgMVQoFZOCGesQjII0Zoti4EI5O3m7ULfmRH Uz+PiNL0WABnO3Ovu4GvusdjJhiyT/0A33g7Ey7crzWRbAsv7Q6fRfbydDf56m9rmLr1 mGXStVOrUiEu51+7kocu9tGPOdMgGOQAyi74vkfotGT4svQdQRaeWW89jHIZ7nsFm+dV SzRdXU+tT2t54L4QEIKL+s1ZSTBBJy8WXr4bEzbcORDKvba7W/UZs3KxOYC6IyJx5r5x 7x7w== MIME-Version: 1.0 X-Received: by 10.60.40.42 with SMTP id u10mr3908363oek.2.1372088171900; Mon, 24 Jun 2013 08:36:11 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.115.163 with HTTP; Mon, 24 Jun 2013 08:36:11 -0700 (PDT) In-Reply-To: <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 24 Jun 2013 11:36:11 -0400 X-Google-Sender-Auth: 4wxUzAXcu9FG3XIYj4GcNZzceRM Message-ID: From: Jim Gettys To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=089e0122a33a16377d04dfe82c4f Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:36:17 -0000 --089e0122a33a16377d04dfe82c4f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > if it turns out to be multicast specific it could go in 3.5.1. > > if there are more general issues to consider then perhaps a new > sub-section? > > No, I think it's more general. What about something like the following: > > > > Homenets tend to grow organically over many years, and a homenet > will typically be built over link-layer technologies from different > generations. Current homenets typically use links ranging from > 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed > discrepancy. We expect this discrepancy to get worse as both > high-speed and low-power technogies are deployed. > > Homenet protocols should be designed to deal well with > interconnecting links of very different speeds. In particular, > flows local to a link should not be flooded throughout the homenet, > even when sent over multicast, and, whenever possible, the homenet > protocols should be able to choose the faster links and avoid the > slower ones. > Here's a version derived from Juliusz's try. I also substitute "bandwidth" for "speed", as being sloppy about the language has tended to get us into the bufferbloat mess. - Jim Homenets tend to grow organically over many years, and a homenet will typically be built over link-layer technologies from different generations. Current homenets typically use links ranging from 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude bandwidth discrepancy. We expect this discrepancy to widen further as both high-speed and low-power technologies are deployed. Homenet protocols should be designed to deal well with interconnecting links of very different bandwidths. In particular, flows local to a link should not be flooded throughout the homenet, even when sent over multicast, and, whenever possible, the homenet protocols should be able to choose the faster links and avoid the slower ones. Links (particularly wireless links) may also have limited numbers of transmit opportunities (txops), and there is a clear trend driven by both power and downward compatibility constraints toward aggregation of packets into these limited txops while increasing bandwidth. Transmit opportunities may be your scarcest resource and therefore also strongly limit actual bandwidth available. Therefore protocols that avoid being "chatty", do not require flooding, and enable isolation of traffic between subnets are preferable to those which burn scarce resources. > > If you wish, I can add a sentence saying "This implies that a link-state > protocol must be used in the homenet" ;-) > > -- Juliusz > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --089e0122a33a16377d04dfe82c4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21= , 2013 at 8:28 AM, Juliusz Chroboczek <jch@pps.univ-paris-dide= rot.fr> wrote:
> if it turns out to be multicast spe= cific it could go in 3.5.1.
> if there are more general issues to consider then perhaps a new sub-se= ction?

No, I think it's more general. =A0What about something like the f= ollowing:

=A0
<= /div>Homenets tend to grow organically over many years, and a homenet
=A0 will typically be built over link-layer technologies from different
=A0 generations. =A0Current homenets typically use links ranging from
=A0 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed
=A0 discrepancy. =A0We expect this discrepancy to get worse as both
=A0 high-speed and low-power technogies are deployed.

=A0 Homenet protocols should be designed to deal well with
=A0 interconnecting links of very different speeds. =A0In particular,
=A0 flows local to a link should not be flooded throughout the homenet,
=A0 even when sent over multicast, and, whenever possible, the homenet
=A0 protocols should be able to choose the faster links and avoid the
=A0 slower ones.
=A0
Here's a version= derived from Juliusz's try. =A0I also substitute "bandwidth"= for "speed", as
being sloppy about the language has tended to get us into the= bufferbloat mess.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim
<= div class=3D"gmail_default" style=3D"display:inline">

Homenets tend to grow organically over many years, and a homenet
will ty= pically be built over link-layer technologies from different
generations= . =A0Current homenets typically use links ranging from
1Mbit/s up to 1Gb= it/s, which is a three orders of magnitude bandwidth
discrepancy. =A0We expect this discrepancy to widen further as both
high= -speed and low-power technologies are deployed.=A0

Homenet protocols should be designed to deal well with=A0inte= rconnecting=A0
links of very different bandwidths. =A0In part= icular,=A0flows local to a link should=A0
not be flooded throughout the homenet,=A0even when sent over multicast,=A0=
and, whenever possible, the homenet protocols should be able to choose the= =A0
faster links and avoid the slower one= s.

Links (particularly wireless links) may also have limited numbers of transm= it opportunities=A0
(txops), and there is= a clear trend=A0driven by both power and downward compatibility constraint= s=A0
toward aggregation of packets into these limit= ed txops while increasing bandwidth.
Tran= smit opportunities may be your scarcest resource and therefore also strongl= y limit
actual bandwidth available.

Therefore= protocols that avoid being "chatty", do not require flooding, an= d enable isolation
of traffic between subnets are preferable to t= hose which burn scarce resources.


If you wish, I can add a sentence saying "This implies that a link-sta= te
protocol must be used in the homenet" ;-)

-- Juliusz
___________________________= ____________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--089e0122a33a16377d04dfe82c4f-- From gettysjim@gmail.com Mon Jun 24 08:40:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBB721E80E9 for ; Mon, 24 Jun 2013 08:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y9t4LYOvQRG for ; Mon, 24 Jun 2013 08:40:28 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79011E814C for ; Mon, 24 Jun 2013 08:40:28 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so11028921obc.12 for ; Mon, 24 Jun 2013 08:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IikUpmrNO91xsqKaqFdaO40w5lxp6cGXXeWNGW62qlg=; b=mP5B4ZXZTKUp2R19n6201Fim1z2R5frYM/TovVlY7Th8bAV1lzP4mA7tzGCfY/g/Jw UopxUsNmbQWtIFoW29BAy5k3FZndNTJXD/DHTm2qaqoq2nVnaIWUSkCWA7w5plOjcRWr 8Dc7OR3iG6kM29BqOoSZEPlQPt5d15faL1zDwUnBQKnb3SsCtHzcFlWAvkq5g4modO0k M+X3kXebkOIgx5Dj22Bl9oyCmA0uxO1yO2WzSBGoPWzTWJaSdzSOa67Chwllb55K+hsJ VLMM7jIzbVeoWyN+kf7FUWz0zMTnCI3jK+fSCzQarCmUPYiyLOXeLknsov+8kK5I8wSO oG+g== MIME-Version: 1.0 X-Received: by 10.182.53.194 with SMTP id d2mr8492267obp.28.1372088428011; Mon, 24 Jun 2013 08:40:28 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.115.163 with HTTP; Mon, 24 Jun 2013 08:40:27 -0700 (PDT) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47187916@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <8761x3mw4k.wl%jch@pps.univ-paris-diderot.fr> <2AFD98F5-A324-4601-8DF7-DDCF71F7F936@fugue.com> <94A203EA12AECE4BA92D42DBFFE0AE47187916@eusaamb101.ericsson.se> Date: Mon, 24 Jun 2013 11:40:27 -0400 X-Google-Sender-Auth: lePj57LqAFUJrwvipMS3EsAD3-g Message-ID: From: Jim Gettys To: Acee Lindem Content-Type: multipart/alternative; boundary=089e0158c5ae5a28a104dfe83bb1 Cc: "homenet@ietf.org Group" , Ted Lemon , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:40:29 -0000 --089e0158c5ae5a28a104dfe83bb1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 11:30 AM, Acee Lindem wrote: > > On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote: > > > > > On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon wrote: > >> On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek < >> jch@pps.univ-paris-diderot.fr> wrote: >> > Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the >> > same link, but the normal nodes need to renumber (and hence lose all >> > TCP sessions) when they switch links. If you prefer, your network can >> > evolve: you can use unmodified ("homenet-compatible") nodes on the >> > homenet, but using modified ("homenet-aware") nodes you get extra >> > functionality. >> >> I don't think this is the right direction to go. Requiring some kind >> of mobility stack on the host isn't something that I can see getting any >> significant market penetration in the general-purpose host environment. >> It's fine for service provider environments where the service provider has >> some leverage to make special requirements on the host, and it's fine for >> environments like public metropolitan wireless where there's a strong >> incentive for adventurous people to install the software, but the homenet >> environment isn't that. >> > > Ted, > > Right now, we have a much bigger problem getting shipment of updated > routers with anything that homenet may recommend at all; getting code on > host operating systems is easier to do than getting router support > deployed. I wish this weren't true, but it is. If we aren't being > slightly optimistic, what are we doing spending our time on this mailing > list? > > > > Jim - I'm not going to debate with you what is harder ;^) However, a > requirement from the start of the Homenet WG is that we minimize changes to > host software with the goal being none. > > Thanks, > Acee > As I currently run a small mesh (of two nodes) in my house, using Juliusz's babel protocol, and have not bothered to install the daemon that would be required for me to roam between them (ahcpd, IIRC), I will note that in practice, in a real home network, no upgrade is *required*. The web's abuse of TCP has assured most people won't notice. That it would be better if I bothered to install the code, I do not doubt. - Jim > > > So if an approach has real value (and doesn't require a lot of kernel > dependent changes to support; we ain't going to do IPv8!), by the time the > routers ship, we can arrange to have host support. > > I must therefore disagree (given that Juliusz has running code which is > not kernel intrusive today). > > Dismissing such options out of hand even before any analysis is done is > therefore a mistake. > - Jim > > > > >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > --089e0158c5ae5a28a104dfe83bb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon= , Jun 24, 2013 at 11:30 AM, Acee Lindem <acee.lindem@ericsson.com> wrote:

On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote:




On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon <mellon@fugue.com<= /a>> wrote:
On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek <jch@pps.univ-paris-didero= t.fr> wrote:
> Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the > same link, but the normal nodes need to renumber (and hence lose all > TCP sessions) when they switch links. =A0If you prefer, your network c= an
> evolve: you can use unmodified ("homenet-compatible") nodes = on the
> homenet, but using modified ("homenet-aware") nodes you get = extra
> functionality.

I don't think this is the right direction to go. =A0 Requiring some kin= d of mobility stack on the host isn't something that I can see getting = any significant market penetration in the general-purpose host environment.= =A0 It's fine for service provider environments where the service provider has some leverage to make special requirements = on the host, and it's fine for environments like public metropolitan wi= reless where there's a strong incentive for adventurous people to insta= ll the software, but the homenet environment isn't that.

Ted,

Right now, we have a =A0much bigger problem = getting shipment of updated routers with anything that homenet may recommen= d at all; getting code on host operating systems is easier to do than getti= ng router support deployed. =A0I wish this weren't true, but it is. =A0If we aren't = being slightly optimistic, what are we doing spending our time on this mail= ing list?



Thanks,
Acee=A0

As I currently run a small mesh (of t= wo nodes) in my house, using Juliusz's babel protocol, and have not bot= hered to install the daemon that would be required for me to roam between t= hem (ahcpd, IIRC), I will note that in practice, in a real home network, no= upgrade is *required*. =A0The web's abuse of TCP has assured most peop= le won't notice.

That it would be better if I b= othered to install the code, I do not doubt.

=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Ji= m
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


--089e0158c5ae5a28a104dfe83bb1-- From otroan@employees.org Mon Jun 24 08:48:39 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99011E8163 for ; Mon, 24 Jun 2013 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.587 X-Spam-Level: X-Spam-Status: No, score=-10.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kwseqlwztYN for ; Mon, 24 Jun 2013 08:48:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5211E815C for ; Mon, 24 Jun 2013 08:48:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAdqyFGQ/khN/2dsb2JhbABbgwkxwACBBhZ0giMBAQEDAQEBAWsLEAsOCi4nMAYTiAgGDLpBBI4XAQZ+MweDAmEDqQeDLCCBLAEf X-IronPort-AV: E=Sophos;i="4.87,929,1363132800"; d="scan'208";a="83603547" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 24 Jun 2013 15:48:25 +0000 Received: from dhcp-10-61-101-92.cisco.com (dhcp-10-61-101-92.cisco.com [10.61.101.92]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5OFmKFt006351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 15:48:22 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Mon, 24 Jun 2013 11:48:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> To: Jim Gettys X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:48:39 -0000 thanks Jim and Juliusz, I like that text. cheers, Ole On Jun 24, 2013, at 11:36 , Jim Gettys wrote: >=20 > On Fri, Jun 21, 2013 at 8:28 AM, Juliusz Chroboczek = wrote: > > if it turns out to be multicast specific it could go in 3.5.1. > > if there are more general issues to consider then perhaps a new = sub-section? >=20 > No, I think it's more general. What about something like the = following: >=20 > Homenets tend to grow organically over many years, and a homenet > will typically be built over link-layer technologies from different > generations. Current homenets typically use links ranging from > 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude speed > discrepancy. We expect this discrepancy to get worse as both > high-speed and low-power technogies are deployed. >=20 > Homenet protocols should be designed to deal well with > interconnecting links of very different speeds. In particular, > flows local to a link should not be flooded throughout the homenet, > even when sent over multicast, and, whenever possible, the homenet > protocols should be able to choose the faster links and avoid the > slower ones. > =20 > Here's a version derived from Juliusz's try. I also substitute = "bandwidth" for "speed", as > being sloppy about the language has tended to get us into the = bufferbloat mess. > - Jim >=20 >=20 > Homenets tend to grow organically over many years, and a homenet > will typically be built over link-layer technologies from different > generations. Current homenets typically use links ranging from > 1Mbit/s up to 1Gbit/s, which is a three orders of magnitude bandwidth > discrepancy. We expect this discrepancy to widen further as both > high-speed and low-power technologies are deployed.=20 >=20 > Homenet protocols should be designed to deal well with interconnecting=20= > links of very different bandwidths. In particular, flows local to a = link should=20 > not be flooded throughout the homenet, even when sent over multicast,=20= > and, whenever possible, the homenet protocols should be able to choose = the=20 > faster links and avoid the slower ones. >=20 > Links (particularly wireless links) may also have limited numbers of = transmit opportunities=20 > (txops), and there is a clear trend driven by both power and downward = compatibility constraints=20 > toward aggregation of packets into these limited txops while = increasing bandwidth. > Transmit opportunities may be your scarcest resource and therefore = also strongly limit > actual bandwidth available. >=20 > Therefore protocols that avoid being "chatty", do not require = flooding, and enable isolation > of traffic between subnets are preferable to those which burn scarce = resources. >=20 >=20 > If you wish, I can add a sentence saying "This implies that a = link-state > protocol must be used in the homenet" ;-) >=20 > -- Juliusz > _______________________________________________ > 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 jch@pps.univ-paris-diderot.fr Mon Jun 24 11:11:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6774421F969F for ; Mon, 24 Jun 2013 11:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eow8c9TAsd4G for ; Mon, 24 Jun 2013 11:11:43 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 4399D21F924A for ; Mon, 24 Jun 2013 11:11:42 -0700 (PDT) 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/38117) with ESMTP id r5OIBTDT001952; Mon, 24 Jun 2013 20:11: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 8A5BD4EF2D; Mon, 24 Jun 2013 20:11: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 eKBH3gi9J2Bh; Mon, 24 Jun 2013 20:11:28 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7DAA04EF2B; Mon, 24 Jun 2013 20:11:28 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UrBEf-0002KO-0w; Mon, 24 Jun 2013 20:11:29 +0200 Date: Mon, 24 Jun 2013 20:11:29 +0200 Message-ID: <871u7rcram.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Jim Gettys In-Reply-To: References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 24 Jun 2013 20:11:31 +0200 (CEST) Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 18:11:49 -0000 Please use "throughput" rather than "bandwidth". The latter has a precise technical meaning. -- Juliusz From hrogge@googlemail.com Mon Jun 24 12:58:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0C21E80FA for ; Mon, 24 Jun 2013 12:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6-fOe76rnX8 for ; Mon, 24 Jun 2013 12:58:56 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A421F99AC for ; Mon, 24 Jun 2013 12:58:56 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so6740980qcz.28 for ; Mon, 24 Jun 2013 12:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q3WerIcZBO6ow4GLpbR1xgBnpye1iAfrBVyePq0HQwg=; b=pSiH/+W9rAJM5h1irM444E0D8PBNcFDmupIBOZbsl7LXuut8KSp9R4mqlt8vf7MgsV 1yVJvp9v/4YOYCYVugMTYpxRO9As3cxEx3xxBOkqxIJrwNFyPNJBdYY37u9qihzIivmB 9urFGaPFs1zHdqWxU7wSh2+pQMsRd5SWk2S4rfLo/lVEljQqnY3RNwViU0L1R2d2bBxs R/Iv3ArIx1aGCoGN3YDATGygellyYXsdJlr8BFLgUFKXaXPBSbf26FmRhJ12r0KRtubs GiXFmIxjPGhODCG7gYbcVLD7rAlT67Vwz/8QcPDA8tKY6qFa89+WlRblDVs8VgREmHm+ PHIg== X-Received: by 10.224.177.135 with SMTP id bi7mr28978479qab.56.1372103935897; Mon, 24 Jun 2013 12:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.82 with HTTP; Mon, 24 Jun 2013 12:58:35 -0700 (PDT) In-Reply-To: <871u7rcram.wl%jch@pps.univ-paris-diderot.fr> References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> <871u7rcram.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Mon, 24 Jun 2013 21:58:35 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: Ole Troan , "homenet@ietf.org Group" , Jim Gettys Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:58:57 -0000 On Mon, Jun 24, 2013 at 8:11 PM, Juliusz Chroboczek wrote: > Please use "throughput" rather than "bandwidth". The latter has > a precise technical meaning. I agree... as soon as you meet someone specialized in radio technology, Bandwidth will be something measured in Hertz. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From gettysjim@gmail.com Mon Jun 24 13:03:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032EC11E8185 for ; Mon, 24 Jun 2013 13:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYplPlhaXLnD for ; Mon, 24 Jun 2013 13:03:56 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6A04A11E8184 for ; Mon, 24 Jun 2013 13:03:56 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id dn14so11254075obc.2 for ; Mon, 24 Jun 2013 13:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5jUIVnCC33wVbqlOumNV+j1WOgmlZaKM0vTiHBJogbo=; b=DnCT0zzu7vWMLBwPK+MG9jwGDunNMzUoRj7EikHws//CDP+iRhBox2BnyEHRj4x3oN hTTfymvf25MakQghR/UFNgZMNX+4I46wRCyCOR+Gpiljo2sQUbMMIxhFUy5k956HBhXH rzBXrzFJhP3N0QJizgrf7CaZpPVm0H98GwbgHeuNai9S3taHTCYPMUeqUl95cGi/mdnj FZIrYVa0xYixVXMaU1nGA9HpZ9zteZHqnQnzdUR4kE5eHjGeKYcM/LcQm4ssxIw3ujEZ drSvE4PYLk6QfQtYu27aODU5U++l/corBi+5HchmiGTGy0qUvgOjtmOJSfkNPZBFZ1Iz Rbkg== MIME-Version: 1.0 X-Received: by 10.182.50.200 with SMTP id e8mr9127160obo.35.1372104235953; Mon, 24 Jun 2013 13:03:55 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.115.163 with HTTP; Mon, 24 Jun 2013 13:03:55 -0700 (PDT) In-Reply-To: References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> <871u7rcram.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 24 Jun 2013 16:03:55 -0400 X-Google-Sender-Auth: GZu_xNokRlqGkwbGhcZV745T4i4 Message-ID: From: Jim Gettys To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b6700c99435f804dfebe903 Cc: Ole Troan , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:03:57 -0000 --047d7b6700c99435f804dfebe903 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 3:58 PM, Henning Rogge wrote: > On Mon, Jun 24, 2013 at 8:11 PM, Juliusz Chroboczek > wrote: > > Please use "throughput" rather than "bandwidth". The latter has > > a precise technical meaning. > > I agree... as soon as you meet someone specialized in radio > technology, Bandwidth will be something measured in Hertz. > I'm happy with that correction and will try to do likewise when I write other items. We have to get away from conflating "speed", with throughput or bandwidth, however: that is where we've gone wrong in the past. Speed is how "fast" something is for a user; for most applications, latency rather than throughput dominates performance in today's Internet. Unless all you care about is downloading your next episode of "Game of Thrones" ;-).... - Jim > > Henning Rogge > > > -- > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > --047d7b6700c99435f804dfebe903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon= , Jun 24, 2013 at 3:58 PM, Henning Rogge <hrogge@googlemail.com>= ; wrote:
On Mon, Jun 24, 2013 at 8:11 PM, Juliusz= Chroboczek
<jch@pps.univ-paris-did= erot.fr> wrote:
> Please use "throughput" rather than "bandwidth". = =A0The latter has
> a precise technical meaning.

I agree... as soon as you meet someone specialized in radio
technology, Bandwidth will be something measured in Hertz.
=

I'= ;m happy with that correction and will try to do likewise when I write othe= r items.

We have to get away from confl= ating "speed", with throughput or bandwidth, however: that is whe= re we've gone wrong in the past.

Speed is how "fast" = something is for a user; for most applications, latency rather than through= put dominates performance in today's Internet. =A0Unless all you care a= bout is downloading your next episode of "Game of Thrones" ;-)...= .
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim

Henning Rogge


--
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

--047d7b6700c99435f804dfebe903-- From teco@inf-net.nl Mon Jun 24 13:52:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A48621F99A7 for ; Mon, 24 Jun 2013 13:52:00 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAAh4F0Bwi0N for ; Mon, 24 Jun 2013 13:51:59 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3E21F99C7 for ; Mon, 24 Jun 2013 13:51:58 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b47so6249987eek.35 for ; Mon, 24 Jun 2013 13:51:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2Dkg7N/f96a2vhrPOgauOuyrMTnjlmB3MQn2ULXZ1Lk=; b=KhwWCh9rP3Qku+vbqDaKs89ZZb2J+1wxjmwK7olMQBYPibzeQNaY/UFKz77h6Fb7/z 2oc5fpWkmOvVNCJ+cSrqiyelhJy5eELUs+z2HYb/wtb66kYMt4I7+GBgjEIe2qva3j4V ttpN+DfsKgsY29m1dZLiEomTOo+FioRSKUtsRnQ51Ji8K/s/eOc5TJ6gbYnA+jFykHUY Kd0veshfxtIxwfW8xEYaoOPuVnaUfCzZDLpXunyv4YizYO+igOGP8dOXQ8QB65yvmDF5 XeKBBR5CbDmIDyYCKRit71mxqZ22oP/Wvsny4/qD7mDsO14WwQjLo6R8seMu/gZ/1JqL 0odw== X-Received: by 10.14.223.199 with SMTP id v47mr26596438eep.32.1372107116183; Mon, 24 Jun 2013 13:51:56 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id l42sm31005222eeo.14.2013.06.24.13.51.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 13:51:54 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <51C73CA6.8060802@globis.net> Date: Mon, 24 Jun 2013 22:51:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <51C73CA6.8060802@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQn27nhiVRlXBxwtfkixW94Z32axMTXFpxhVyrbBPA0DnHQ0yRdc51lH5cFfDSPGKX7+u3jt Cc: Andrew McGregor , Ted Lemon , Dave Taht , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:52:00 -0000 If TRILL isn't big enough, we can always take a look at Capwap = [RFC5415]. Teco =20 Op 23 jun. 2013, om 20:21 heeft Ray Hunter het = volgende geschreven: >> Ted Lemon >> 23 June 2013 18:18 >> There's been brief mention of the WiFi infrastructure problem for the >> homenet during this post-last-call conversation, but I don't think we >> drew a conclusion, and indeed some of what was said seems to suggest >> that we aren't addressing the issue. >>=20 >> Let's consider the following scenario: I have a wired infrastructure >> that connects my home and garage. The home and garage can't all be >> served by the same Wifi AP. I want to set up WiFi APs so that I can >> wander around between the various parts of my home, as well as >> outdoors, and have good WiFi connectivity in all of these locations, >> without expensive handoffs and without changing subnets (which would >> break connections, e.g. SIP calls, ssh sessions, etc). >>=20 >> There are a variety of ways of addressing this problem, and you and >> Andrew and Ray have touched on them a bit, but I didn't see a clear >> requirement stated, and I'd like to. I don't see one in the >> architecture document either. >>=20 > Sounds like a clear requirement for simple end node to router handoff > over wireless, with session survivability when the end node device > connects via another radio device. That could be expressed in the > architecture without moving on to the "how". >=20 >=20 >> The first question is, is this a use case that the Homenet >> architecture wants to address? I think the answer is yes, but I don't >> get the sense that everybody agrees with that, which is why I am >> asking the question directly. > Yes. I agree with the requirement (regardless of how it's implemented) >=20 >=20 >> Second, _can_ we address it, given other assumptions we're making in >> the architecture, and how? >=20 > There's a whole load of options: >=20 > wireless repeating where there's one AP + wireless extenders to create = a > single flat wireless LAN (WDS) =3D how most home networks work today. > Another would be layer 2 bridging over the entire homenet backbone + > multiple AP's advertising the same SSID on different channels = (generally > how most office wifi works today). > Pure routing and disjoint subnets + renumbering the end node would > probably break sessions, and would not work as desired as you rightly > point out. > Another would be carrying a common VLAN for wireless throughout the > homenet over a routed homenet backbone (Integrated Routing and = Bridging > in Cisco speak) or bridging over GRE/ other tunnel or other fancy = L2/L3 > combo that allows a single subnet to remain contiguous when spanning > routed links. > Mobile IP. > MANET. > Mobile end nodes to source / sink sessions from a software loopback > interface and route individual /128's around the Homenet. > Tunnel from the mobile end node to a central router over a point to > point link (like LTE) >=20 > Plenty of things to explore, and with varying degrees of end node > involvement, complexity, and survivability. > e.g. sessions over mobile IP requires significant complexity and end > node involvement, but would survive a move between different wireless > technologies. > Bridging requires no end node involvement, is simple within one media > type but problematic between types, and sessions would almost = certainly > not survive a move to a different radio technology . > Repeating requires no end node involvement, is generally proprietary, > and sessions would not survive a move to a different radio technology. >=20 >=20 >> I've mentioned the wired backbone/wireless AP model, but of course a >> lot of home environments won't have the luxury of a wired backbone, = so >> we will probably have to do air-to-air infrastructure links to make = it >> work. What does this look like? >=20 > That to me is a second requirement for wireless, and where we get into = a > potential conflict with your first requirement. >=20 > For end node - homenet it's only important that you can connect to at > least one device from a set of devices advertising your SSID, and the > end node will generally select the channel with the strongest signal = if > there's more than one. It's not relevant that you can simultaneously > reach ALL devices advertising the SSID. >=20 > For router - router communication, mutual visibility is very relevant, > as having all routers in a flat LAN will almost certainly seriously > impact common routing protocols being touted. As mentioned previously, > the quality of wireless links will vary substantially over time, as = will > adjacencies, even without moving the routers. >=20 >=20 >>=20 >> One way to make this work, which someone jokingly alluded to before, >> would be to have all the APs coexist in a TRILL layer 2. I'm sure I >> will attract some rotten tomatoes for that suggestion, but it _would_ >> work. Subnetting wouldn't work=97it would break connections every = time I >> changed APs. I am not convinced that making the whole homenet one big >> bridge is a good answer, but that would work, in the sense of >> addressing the specific use case I am describing. Mobile IP would = also >> work, but I don't think it would be practical to set up a Mobile IP >> infrastructure on a homenet. >>=20 >> It can also be argued that nobody needs this functionality. >>=20 >> Sorry for lobbing this question into an otherwise interesting and >> related WiFi mesh discussion, but is anybody else thinking about this >> and/or concerned about this? > You've brought up the two wireless use cases that triggered my = original > comments, so yes I am concerned that we are neglecting documenting > requirements. Speaking as someone who lives in a reinforced concrete > box, I also think that router to router connectivity over wireless is = a > requirement. >=20 > regards, > RayH >> Acee Lindem >> 23 June 2013 17:38 >> There is room for innovation here and I agree that one could come up >> with a model to support this. However, I'm not ready to take it as a >> requirement for an auto-configured homenet since the Wi-Fi broadcast >> network model has heretofore served us quite well.=20 >> Acee=20 >> On Jun 23, 2013, at 7:24 AM, Andrew McGregor wrote: >>=20 >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From dave.taht@gmail.com Mon Jun 24 14:23:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C2411E8143 for ; Mon, 24 Jun 2013 14:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o+ynd7BylAK for ; Mon, 24 Jun 2013 14:23:46 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 75ECF21F9A15 for ; Mon, 24 Jun 2013 14:23:40 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so26334952ieb.10 for ; Mon, 24 Jun 2013 14:23:38 -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=AVs1ROzsjkQZrv/aHSIxtU8AuPyncLAsFirlQyRLj+I=; b=ig7WZUfFaX/iabCPq8IcB7cIj/ObC6+V5NiWWfVQhz/ZEcCNvzekZ3I9GqNYnw6UR8 4zvcQznIa/H5/x/AoPyp5QTCTukz5VlXP8kchUkKM2wyPRkBfUJACElTSTYidd2EXHYv 5gp4RmbBfkAoGEcCwAJmRFhOclx4fByxwXyhv+KV+NctgKdMgzT6qDIbC2FxckS1w4J7 YUytToDrFGzRD2EkeCXWoYQ2/5T/LcnBbDdxZw8VU4unjGUel9FxElnLiCBNDMX5BP+O SsRbJbn5oXgrBmLb9qkJggIHt7ZlGqNKNYVCGg7MsSSQv3a/su6HdAmQkwyHHt/6IqXL 1PFg== MIME-Version: 1.0 X-Received: by 10.50.80.9 with SMTP id n9mr6809431igx.42.1372109018594; Mon, 24 Jun 2013 14:23:38 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Mon, 24 Jun 2013 14:23:38 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <51C73CA6.8060802@globis.net> Date: Mon, 24 Jun 2013 14:23:38 -0700 Message-ID: From: Dave Taht To: Teco Boot Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Andrew McGregor , Ted Lemon , Ray Hunter , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 21:23:50 -0000 On Mon, Jun 24, 2013 at 1:51 PM, Teco Boot wrote: > If TRILL isn't big enough, we can always take a look at Capwap [RFC5415]. I thought that capwap and its predecessor had some potential, I'm sorry to see it not widely implemented. For a longer view as to where in-home wireless may go take a look at 802.11ad, which among other problems uses a frequency range that cannot go through walls, and falls back to older protocols to do so. http://en.wikipedia.org/wiki/IEEE_802.11ad I have no idea how the IEEE intends to solve the problems raised here on homenet, been too busy trying to fix 802.11n. > Teco > > > Op 23 jun. 2013, om 20:21 heeft Ray Hunter het volgend= e geschreven: > >>> Ted Lemon >>> 23 June 2013 18:18 >>> There's been brief mention of the WiFi infrastructure problem for the >>> homenet during this post-last-call conversation, but I don't think we >>> drew a conclusion, and indeed some of what was said seems to suggest >>> that we aren't addressing the issue. >>> >>> Let's consider the following scenario: I have a wired infrastructure >>> that connects my home and garage. The home and garage can't all be >>> served by the same Wifi AP. I want to set up WiFi APs so that I can >>> wander around between the various parts of my home, as well as >>> outdoors, and have good WiFi connectivity in all of these locations, >>> without expensive handoffs and without changing subnets (which would >>> break connections, e.g. SIP calls, ssh sessions, etc). >>> >>> There are a variety of ways of addressing this problem, and you and >>> Andrew and Ray have touched on them a bit, but I didn't see a clear >>> requirement stated, and I'd like to. I don't see one in the >>> architecture document either. >>> >> Sounds like a clear requirement for simple end node to router handoff >> over wireless, with session survivability when the end node device >> connects via another radio device. That could be expressed in the >> architecture without moving on to the "how". >> >> >>> The first question is, is this a use case that the Homenet >>> architecture wants to address? I think the answer is yes, but I don't >>> get the sense that everybody agrees with that, which is why I am >>> asking the question directly. >> Yes. I agree with the requirement (regardless of how it's implemented) >> >> >>> Second, _can_ we address it, given other assumptions we're making in >>> the architecture, and how? >> >> There's a whole load of options: >> >> wireless repeating where there's one AP + wireless extenders to create a >> single flat wireless LAN (WDS) =3D how most home networks work today. >> Another would be layer 2 bridging over the entire homenet backbone + >> multiple AP's advertising the same SSID on different channels (generally >> how most office wifi works today). >> Pure routing and disjoint subnets + renumbering the end node would >> probably break sessions, and would not work as desired as you rightly >> point out. >> Another would be carrying a common VLAN for wireless throughout the >> homenet over a routed homenet backbone (Integrated Routing and Bridging >> in Cisco speak) or bridging over GRE/ other tunnel or other fancy L2/L3 >> combo that allows a single subnet to remain contiguous when spanning >> routed links. >> Mobile IP. >> MANET. >> Mobile end nodes to source / sink sessions from a software loopback >> interface and route individual /128's around the Homenet. >> Tunnel from the mobile end node to a central router over a point to >> point link (like LTE) >> >> Plenty of things to explore, and with varying degrees of end node >> involvement, complexity, and survivability. >> e.g. sessions over mobile IP requires significant complexity and end >> node involvement, but would survive a move between different wireless >> technologies. >> Bridging requires no end node involvement, is simple within one media >> type but problematic between types, and sessions would almost certainly >> not survive a move to a different radio technology . >> Repeating requires no end node involvement, is generally proprietary, >> and sessions would not survive a move to a different radio technology. >> >> >>> I've mentioned the wired backbone/wireless AP model, but of course a >>> lot of home environments won't have the luxury of a wired backbone, so >>> we will probably have to do air-to-air infrastructure links to make it >>> work. What does this look like? >> >> That to me is a second requirement for wireless, and where we get into a >> potential conflict with your first requirement. >> >> For end node - homenet it's only important that you can connect to at >> least one device from a set of devices advertising your SSID, and the >> end node will generally select the channel with the strongest signal if >> there's more than one. It's not relevant that you can simultaneously >> reach ALL devices advertising the SSID. >> >> For router - router communication, mutual visibility is very relevant, >> as having all routers in a flat LAN will almost certainly seriously >> impact common routing protocols being touted. As mentioned previously, >> the quality of wireless links will vary substantially over time, as will >> adjacencies, even without moving the routers. >> >> >>> >>> One way to make this work, which someone jokingly alluded to before, >>> would be to have all the APs coexist in a TRILL layer 2. I'm sure I >>> will attract some rotten tomatoes for that suggestion, but it _would_ >>> work. Subnetting wouldn't work=97it would break connections every time = I >>> changed APs. I am not convinced that making the whole homenet one big >>> bridge is a good answer, but that would work, in the sense of >>> addressing the specific use case I am describing. Mobile IP would also >>> work, but I don't think it would be practical to set up a Mobile IP >>> infrastructure on a homenet. >>> >>> It can also be argued that nobody needs this functionality. >>> >>> Sorry for lobbing this question into an otherwise interesting and >>> related WiFi mesh discussion, but is anybody else thinking about this >>> and/or concerned about this? >> You've brought up the two wireless use cases that triggered my original >> comments, so yes I am concerned that we are neglecting documenting >> requirements. Speaking as someone who lives in a reinforced concrete >> box, I also think that router to router connectivity over wireless is a >> requirement. >> >> regards, >> RayH >>> Acee Lindem >>> 23 June 2013 17:38 >>> There is room for innovation here and I agree that one could come up >>> with a model to support this. However, I'm not ready to take it as a >>> requirement for an auto-configured homenet since the Wi-Fi broadcast >>> network model has heretofore served us quite well. >>> Acee >>> On Jun 23, 2013, at 7:24 AM, Andrew McGregor wrote: >>> >>> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From hrogge@googlemail.com Mon Jun 24 22:53:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE01411E80C5 for ; Mon, 24 Jun 2013 22:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62uZWwyjXo2v for ; Mon, 24 Jun 2013 22:53:27 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7911E80CC for ; Mon, 24 Jun 2013 22:53:22 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so353451qak.14 for ; Mon, 24 Jun 2013 22:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Wmw7J0O2lkw+hgZEsfWWgj1mKhMWVJ0uC3pFysmfG6w=; b=zkSMDJMrVFVewSK5sgsrXR8STCToLwMmLYvhhvr973g8syUeOsAAaXspTo3QN2Sg6J ap9SZHEpNX2RohdD8oJIyJxcfVaQ/zaeyo7jfv4j3XCVdad9PxBolB//1eWK3hiyaZZk L2YR5CW7PmYMFmVUw8A0Rg5XNz9SReSMeX4CpVtuiiocPkwkRkxD7a2OFooNh6WVsTBU W3HIsVEO+SpHkLBaXpQUbSMtIjahwoAxLIvtErj3hMrFjtz6W8DGAlZNvWzl9rUb4yp+ 1NQ8AFjI7u9Lmbiq4v9lCX++mun1wxfxPcG6sZYj1V5JrZpv5ky6AGvLtZr6oJeQ9BLp xPzg== X-Received: by 10.49.103.136 with SMTP id fw8mr30625789qeb.65.1372139591253; Mon, 24 Jun 2013 22:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.82 with HTTP; Mon, 24 Jun 2013 22:52:51 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <51C73CA6.8060802@globis.net> From: Henning Rogge Date: Tue, 25 Jun 2013 07:52:51 +0200 Message-ID: To: Dave Taht Content-Type: text/plain; charset=ISO-8859-1 Cc: Teco Boot , Andrew McGregor , Ted Lemon , Ray Hunter , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 05:53:27 -0000 On Mon, Jun 24, 2013 at 11:23 PM, Dave Taht wrote: > On Mon, Jun 24, 2013 at 1:51 PM, Teco Boot wrote: >> If TRILL isn't big enough, we can always take a look at Capwap [RFC5415]. > > I thought that capwap and its predecessor had some potential, I'm > sorry to see it not widely implemented. > > For a longer view as to where in-home wireless may go take a look at > 802.11ad, which among other problems uses a frequency range that > cannot go through walls, and falls back to older protocols to do so. You mean falling back to a lower frequency band? > http://en.wikipedia.org/wiki/IEEE_802.11ad > > I have no idea how the IEEE intends to solve the problems raised here > on homenet, been too busy trying to fix 802.11n. I think the low range of 60 GHz radio links can be a great feature, because they limit the collision domain to a single room. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From mark@townsley.net Tue Jun 25 02:26:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7084C11E80D1 for ; Tue, 25 Jun 2013 02:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxJ6cepkzIov for ; Tue, 25 Jun 2013 02:26:10 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7568921F9FDC for ; Tue, 25 Jun 2013 02:26:09 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so9221876wgh.14 for ; Tue, 25 Jun 2013 02:26:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=K8ZWJeCcqOlFe6rIKVLAxEVhw4BbiZSK0ofSJrr4qtE=; b=pOxPLoAXVSuGnTii0tCqhp7rojJf0QB31KHlNpg0/Ds8xTz7ftI50ZKcTnujyVoU0J BEN5zdeMRp8A4CZdi1yHhOvFxDr5lhsAZwdSxXHAi88OTXSTPQ+1/xvyF8nXOd00i2aB ZzsgURM6iPeDH0UaxWZv+2ILwkOsWkXhL9Ry7ZKENW7JILFdoRsQ6O/rVW4GzkGdtcFv MdGoQbPwl1MAu1OZtq4aNIvjeTXseIDcxM6SFrUcfoHmVB68l1SUztb/59LVuK8Lbc92 k71DAoEXxSzrwG4KC6KcBlWPUh4EXAsvfe/mY5ycwQEf8KnEAmvCL7ErzVS8bSOv+YlG 8e1A== X-Received: by 10.194.170.168 with SMTP id an8mr10274937wjc.72.1372152369041; Tue, 25 Jun 2013 02:26:09 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id eu1sm2762363wib.8.2013.06.25.02.26.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 02:26:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Mark Townsley In-Reply-To: Date: Tue, 25 Jun 2013 11:26:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88EF54CA-3029-44F8-8E23-439B795C5087@townsley.net> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <51C73CA6.8060802@globis.net> To: Dave Taht X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkY+EdZk7NtDRngEnoeJFH/5Hi/09rpyGZzMm5TsBaPY/3lDmyKJ2KDs282+DuOts6xcTtq Cc: Teco Boot , Andrew McGregor , Ted Lemon , Ray Hunter , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:26:12 -0000 On Jun 24, 2013, at 11:23 PM, Dave Taht wrote: > On Mon, Jun 24, 2013 at 1:51 PM, Teco Boot wrote: >> If TRILL isn't big enough, we can always take a look at Capwap = [RFC5415]. >=20 > I thought that capwap and its predecessor had some potential, I'm > sorry to see it not widely implemented. capwap and lwapp are both widely deployed in enterprise wifi = installations. There is nothing stopping a home networking provider from = selling this today, though it does involve L2-tunneling of all traffic = from each AP back to a central node. - Mark >=20 > For a longer view as to where in-home wireless may go take a look at > 802.11ad, which among other problems uses a frequency range that > cannot go through walls, and falls back to older protocols to do so. >=20 > http://en.wikipedia.org/wiki/IEEE_802.11ad >=20 > I have no idea how the IEEE intends to solve the problems raised here > on homenet, been too busy trying to fix 802.11n. >=20 >> Teco >>=20 >>=20 >> Op 23 jun. 2013, om 20:21 heeft Ray Hunter het = volgende geschreven: >>=20 >>>> Ted Lemon >>>> 23 June 2013 18:18 >>>> There's been brief mention of the WiFi infrastructure problem for = the >>>> homenet during this post-last-call conversation, but I don't think = we >>>> drew a conclusion, and indeed some of what was said seems to = suggest >>>> that we aren't addressing the issue. >>>>=20 >>>> Let's consider the following scenario: I have a wired = infrastructure >>>> that connects my home and garage. The home and garage can't all be >>>> served by the same Wifi AP. I want to set up WiFi APs so that I can >>>> wander around between the various parts of my home, as well as >>>> outdoors, and have good WiFi connectivity in all of these = locations, >>>> without expensive handoffs and without changing subnets (which = would >>>> break connections, e.g. SIP calls, ssh sessions, etc). >>>>=20 >>>> There are a variety of ways of addressing this problem, and you and >>>> Andrew and Ray have touched on them a bit, but I didn't see a clear >>>> requirement stated, and I'd like to. I don't see one in the >>>> architecture document either. >>>>=20 >>> Sounds like a clear requirement for simple end node to router = handoff >>> over wireless, with session survivability when the end node device >>> connects via another radio device. That could be expressed in the >>> architecture without moving on to the "how". >>>=20 >>>=20 >>>> The first question is, is this a use case that the Homenet >>>> architecture wants to address? I think the answer is yes, but I = don't >>>> get the sense that everybody agrees with that, which is why I am >>>> asking the question directly. >>> Yes. I agree with the requirement (regardless of how it's = implemented) >>>=20 >>>=20 >>>> Second, _can_ we address it, given other assumptions we're making = in >>>> the architecture, and how? >>>=20 >>> There's a whole load of options: >>>=20 >>> wireless repeating where there's one AP + wireless extenders to = create a >>> single flat wireless LAN (WDS) =3D how most home networks work = today. >>> Another would be layer 2 bridging over the entire homenet backbone + >>> multiple AP's advertising the same SSID on different channels = (generally >>> how most office wifi works today). >>> Pure routing and disjoint subnets + renumbering the end node would >>> probably break sessions, and would not work as desired as you = rightly >>> point out. >>> Another would be carrying a common VLAN for wireless throughout the >>> homenet over a routed homenet backbone (Integrated Routing and = Bridging >>> in Cisco speak) or bridging over GRE/ other tunnel or other fancy = L2/L3 >>> combo that allows a single subnet to remain contiguous when spanning >>> routed links. >>> Mobile IP. >>> MANET. >>> Mobile end nodes to source / sink sessions from a software loopback >>> interface and route individual /128's around the Homenet. >>> Tunnel from the mobile end node to a central router over a point to >>> point link (like LTE) >>>=20 >>> Plenty of things to explore, and with varying degrees of end node >>> involvement, complexity, and survivability. >>> e.g. sessions over mobile IP requires significant complexity and end >>> node involvement, but would survive a move between different = wireless >>> technologies. >>> Bridging requires no end node involvement, is simple within one = media >>> type but problematic between types, and sessions would almost = certainly >>> not survive a move to a different radio technology . >>> Repeating requires no end node involvement, is generally = proprietary, >>> and sessions would not survive a move to a different radio = technology. >>>=20 >>>=20 >>>> I've mentioned the wired backbone/wireless AP model, but of course = a >>>> lot of home environments won't have the luxury of a wired backbone, = so >>>> we will probably have to do air-to-air infrastructure links to make = it >>>> work. What does this look like? >>>=20 >>> That to me is a second requirement for wireless, and where we get = into a >>> potential conflict with your first requirement. >>>=20 >>> For end node - homenet it's only important that you can connect to = at >>> least one device from a set of devices advertising your SSID, and = the >>> end node will generally select the channel with the strongest signal = if >>> there's more than one. It's not relevant that you can simultaneously >>> reach ALL devices advertising the SSID. >>>=20 >>> For router - router communication, mutual visibility is very = relevant, >>> as having all routers in a flat LAN will almost certainly seriously >>> impact common routing protocols being touted. As mentioned = previously, >>> the quality of wireless links will vary substantially over time, as = will >>> adjacencies, even without moving the routers. >>>=20 >>>=20 >>>>=20 >>>> One way to make this work, which someone jokingly alluded to = before, >>>> would be to have all the APs coexist in a TRILL layer 2. I'm sure I >>>> will attract some rotten tomatoes for that suggestion, but it = _would_ >>>> work. Subnetting wouldn't work=97it would break connections every = time I >>>> changed APs. I am not convinced that making the whole homenet one = big >>>> bridge is a good answer, but that would work, in the sense of >>>> addressing the specific use case I am describing. Mobile IP would = also >>>> work, but I don't think it would be practical to set up a Mobile IP >>>> infrastructure on a homenet. >>>>=20 >>>> It can also be argued that nobody needs this functionality. >>>>=20 >>>> Sorry for lobbing this question into an otherwise interesting and >>>> related WiFi mesh discussion, but is anybody else thinking about = this >>>> and/or concerned about this? >>> You've brought up the two wireless use cases that triggered my = original >>> comments, so yes I am concerned that we are neglecting documenting >>> requirements. Speaking as someone who lives in a reinforced concrete >>> box, I also think that router to router connectivity over wireless = is a >>> requirement. >>>=20 >>> regards, >>> RayH >>>> Acee Lindem >>>> 23 June 2013 17:38 >>>> There is room for innovation here and I agree that one could come = up >>>> with a model to support this. However, I'm not ready to take it as = a >>>> requirement for an auto-configured homenet since the Wi-Fi = broadcast >>>> network model has heretofore served us quite well. >>>> Acee >>>> On Jun 23, 2013, at 7:24 AM, Andrew McGregor wrote: >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Tue Jun 25 02:35:03 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AA421F9F21 for ; Tue, 25 Jun 2013 02:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTkZwwe-C+Rv for ; Tue, 25 Jun 2013 02:35:02 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6921F9958 for ; Tue, 25 Jun 2013 02:35:02 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so9133775wgg.10 for ; Tue, 25 Jun 2013 02:35:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=CktU6/LhNzgWf3rT8mFuBSzydIFLZcBNLhpXAe9p7xU=; b=Tjv5bnqdxU6nnOjLoDv4LuyCvRb2TsgdzGErQWfqJRpfBmJkyRkl28H2juaeNGV9Nc 6xoeEkKr9TGbafvnd9gUF72yBANkVm9mBXO1/fYaF3cfRl5wpGPk+bLi+OnLlW/XiOPj Ub7ghDqBmYNB0Sq9C+uOmUQ5Nyk9bqsG52c6/AiumQuT1D1Gl+sVx/H6vNh2SJjPOpmy SgT4eG6ymz4qzmU0ciyutLr7rqKw87FKNL+tHkQTHmN4AT2tScMk3xDjkcg74RD2eily CDqrE+CM6YWJKHuB8gl7O9Ak//2mtMZ1I6Lrdzq0pY7rNwWEHewSkUsWMZcIvJzf6W4w MwCw== X-Received: by 10.180.76.206 with SMTP id m14mr4855619wiw.38.1372152901586; Tue, 25 Jun 2013 02:35:01 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id j20sm2087172wie.7.2013.06.25.02.34.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 02:34:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_829FDFE2-AA0B-4E15-A7A1-0346BFF3E40E" From: Mark Townsley In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47187916@eusaamb101.ericsson.se> Date: Tue, 25 Jun 2013 11:34:57 +0200 Message-Id: <3CDC81A2-20AE-4FBB-9AF6-3E1E20513795@townsley.net> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <8761x3mw4k.wl%jch@p ps.univ-paris-diderot.fr> <2AFD98F5-A324-4601-8DF7-DDCF71F7F936@fugue.com> <94A203EA12AECE4BA92D42DBFFE0AE47187916@eusaamb101.ericsson.se> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkItbqiy9NLgn5/WW2/XrssM5D/+SDlFq4ugCMwJ6WAUpKeS/Fyj6RVqRPR6defs8u7GDFC Cc: "homenet@ietf.org Group" , Ted Lemon , Jim Gettys , Dave Thaler , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:35:03 -0000 --Apple-Mail=_829FDFE2-AA0B-4E15-A7A1-0346BFF3E40E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 24, 2013, at 5:30 PM, Acee Lindem wrote: >=20 > On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote: >=20 >>=20 >>=20 >>=20 >> On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon wrote: >> On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek = wrote: >> > Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the >> > same link, but the normal nodes need to renumber (and hence lose = all >> > TCP sessions) when they switch links. If you prefer, your network = can >> > evolve: you can use unmodified ("homenet-compatible") nodes on the >> > homenet, but using modified ("homenet-aware") nodes you get extra >> > functionality. >>=20 >> I don't think this is the right direction to go. Requiring some = kind of mobility stack on the host isn't something that I can see = getting any significant market penetration in the general-purpose host = environment. It's fine for service provider environments where the = service provider has some leverage to make special requirements on the = host, and it's fine for environments like public metropolitan wireless = where there's a strong incentive for adventurous people to install the = software, but the homenet environment isn't that. >>=20 >> Ted, >>=20 >> Right now, we have a much bigger problem getting shipment of updated = routers with anything that homenet may recommend at all; getting code on = host operating systems is easier to do than getting router support = deployed. I wish this weren't true, but it is. If we aren't being = slightly optimistic, what are we doing spending our time on this mailing = list? >=20 >=20 > Jim - I'm not going to debate with you what is harder ;^) However, a = requirement from the start of the Homenet WG is that we minimize changes = to host software with the goal being none.=20 During one of the WG meetings, I remember agreement around what we = deemed the "Thaler principle" - quite simply, that any solution phasing = would be drawn along the line of whether or not it affected existing = hosts. So, we *will* define a solution that doesn't affect hosts at all. = But, if we absolutely must, we can identify generally useful extensions = to the host stack.=20 Zero host changes would be nice, but I don't think we're going to get = away with that. Multihoming without NAT alone pushes us to the edges of = existing IPv6 stack capabilities.=20 - Mark >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> So if an approach has real value (and doesn't require a lot of kernel = dependent changes to support; we ain't going to do IPv8!), by the time = the routers ship, we can arrange to have host support. >>=20 >> I must therefore disagree (given that Juliusz has running code which = is not kernel intrusive today). >>=20 >> Dismissing such options out of hand even before any analysis is done = is therefore a mistake. >> - Jim >>=20 >>=20 >>=20 >>=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 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_829FDFE2-AA0B-4E15-A7A1-0346BFF3E40E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote:




On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon = <mellon@fugue.com> wrote:
On Jun 24, 2013, at 10:16 AM, Juliusz Chroboczek = <jch@pps.univ-paris-diderot.f= r> wrote:
> Once again: normal (RA) and mobile (AHCP+Babel) nodes can share = the
> same link, but the normal nodes need to renumber (and hence lose = all
> TCP sessions) when they switch links.  If you prefer, your = network can
> evolve: you can use unmodified ("homenet-compatible") nodes on = the
> homenet, but using modified ("homenet-aware") nodes you get = extra
> functionality.

I don't think this is the right direction to go.   Requiring some = kind of mobility stack on the host isn't something that I can see = getting any significant market penetration in the general-purpose host = environment.   It's fine for service provider environments where the service provider has some leverage to make special = requirements on the host, and it's fine for environments like public = metropolitan wireless where there's a strong incentive for adventurous = people to install the software, but the homenet environment isn't that.

Ted,

Right now, we = have a  much bigger problem getting shipment of updated routers = with anything that homenet may recommend at all; getting code on host = operating systems is easier to do than getting router support deployed.  I wish this weren't true, but it is.  If we aren't = being slightly optimistic, what are we doing spending our time on this = mailing list?


Jim - I'm not going to debate with you what is harder ;^) However, = a requirement from the start of the Homenet WG is that we minimize = changes to host software with the goal being = none. 

During one = of the WG meetings, I remember agreement around what we deemed the = "Thaler principle" - quite simply, that any solution phasing would be = drawn along the line of whether or not it affected existing hosts. So, = we *will* define a solution that doesn't affect hosts at all. But, if we = absolutely must, we can identify generally useful extensions to the host = stack. 

Zero host changes would be nice, = but I don't think we're going to get away with that. Multihoming without = NAT alone pushes us to the edges of existing IPv6 stack = capabilities. 

- Mark


Thanks,
Acee 



So if an approach = has real value (and doesn't require a lot of kernel dependent changes to = support; we ain't going to do IPv8!), by the time the routers ship, we = can arrange to have host support.

I must therefore = disagree (given that Juliusz has running code which is not kernel = intrusive today).

Dismissing such = options out of hand even before any analysis is done is therefore a = mistake.
    =                     =             - Jim




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

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.or= g/mailman/listinfo/homenet

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

= --Apple-Mail=_829FDFE2-AA0B-4E15-A7A1-0346BFF3E40E-- From teco@inf-net.nl Tue Jun 25 03:39:43 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CEF21F9EB6 for ; Tue, 25 Jun 2013 03:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OylC3APk1Jck for ; Tue, 25 Jun 2013 03:39:43 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id AB25A21F9EA2 for ; Tue, 25 Jun 2013 03:39:42 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id d49so6471477eek.23 for ; Tue, 25 Jun 2013 03:39:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=POlYp2qV2ah6CWADba8AKNs9zg7tt44tlHkzDhzuFoc=; b=OaLniJgHAI6qOcQb5xFcrzh+EkM2MMAN3wMydRJhT5PoMGYCu28p9YMdIdF1brmxD+ W55wj98pgthco6qa5BlPFn5S/VCBPSgV5SFQI7WxKCptzN4bz6Fv3gCHUCSzuu637Ae2 FEFbGW9m+yfUmr4xTlfq0VCk5O1eqcUv4o/TKKx5ZA/Zdn1hti8w7r83vmY38Lu23/wQ APwfb6II0eksXU89TnDZ+gTuYpbl6+1D3v8POuJyISJ1SOOnRgW91VOuOeSzEpz955Vc /dkb+xQ6FLgyIbnEMR6Ik99dLgKwXl49dRJV1IepFCjXsXHG6zMZ3ME19p1EyHUOEF5Q eXhw== X-Received: by 10.15.34.77 with SMTP id d53mr28870459eev.95.1372156781249; Tue, 25 Jun 2013 03:39:41 -0700 (PDT) Received: from [172.16.4.22] ([188.205.88.52]) by mx.google.com with ESMTPSA id m1sm34997730eex.17.2013.06.25.03.39.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 03:39:40 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <88EF54CA-3029-44F8-8E23-439B795C5087@townsley.net> Date: Tue, 25 Jun 2013 12:39:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59F936C4-1545-49E3-A5E1-79FF99BF2718@inf-net.nl> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <51C73CA6.8060802@globis.net> <88EF54CA-3029-44F8-8E23-439B795C5087@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnURvb5wW3cSQvJ0JWlECJY5GOOZZQOADGAi4w0n6r4jbw8gkV8cMVqFzsgV3y7yNT6nRpM Cc: Andrew McGregor , Ted Lemon , Dave Taht , Ray Hunter , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:39:43 -0000 Op 25 jun. 2013, om 11:26 heeft Mark Townsley het = volgende geschreven: >=20 > capwap and lwapp are both widely deployed in enterprise wifi = installations. There is nothing stopping a home networking provider from = selling this today, though it does involve L2-tunneling of all traffic = from each AP back to a central node. I guess there is a reason not shipping capwap for homenets yet. Maybe = costs, lack of plug&play, controller dependency, lack of open source = code or simply unaware. Just unboxed an Aironet 600 SOHO. This solves the office network = problem: it provides VPN to office network with ethernet & WiFi access. = I'll find out how home & guest networks are supported. Can such a WTP = connect to multiple AC's? I don't let control my home & guest networks = by others. So I need a mapping between SSID/LAN ports and my own AC. Or = box the 600 :-) Teco PS: Read RFC 5415 before asking details. And I am not the capwap expert. From tjc@ecs.soton.ac.uk Tue Jun 25 03:47:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA721F94DF for ; Tue, 25 Jun 2013 03:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4606youMByk7 for ; Tue, 25 Jun 2013 03:47:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id A039321F946C for ; Tue, 25 Jun 2013 03:47:07 -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 r5PAkxIb021094; Tue, 25 Jun 2013 11:46:59 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5PAkxIb021094 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1372157219; bh=QE+iMT+EvVNvXJkMCzY5/3FbOng=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=mTlNvEU/7lm4jW6r7eqH9hehYY7NST05epYLRQSTYdDQT1ebzJ2SGe1SXBPRtYAh1 mBJ3d9jcd5Aa7PDxhcsMaLYW6C+z0dFkNC8aDm4/OQQhWhZTfqTI//J4sZEy5ZrK8N ba/YvVlO7T12hzYnQDIon5aQW4xJBwB9+1tfskn0= 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 p5OBkx0544549768b0 ret-id none; Tue, 25 Jun 2013 11:46:59 +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 r5PAkuNq025026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 11:46:56 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <871u7rcram.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 25 Jun 2013 11:46:56 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <87y5a48kbh.wl%jch@pps.univ-paris-diderot.fr> <87y5a3ejhg.wl%jch@pps.univ-paris-diderot.fr> <871u7rcram.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5OBkx054454976800; tid=p5OBkx0544549768b0; 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: r5PAkxIb021094 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Ole Troan , "homenet@ietf.org Group" , Jim Gettys Subject: Re: [homenet] draft-ietf-homenet-arch comments X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:47:08 -0000 On 24 Jun 2013, at 19:11, Juliusz Chroboczek = wrote: > Please use "throughput" rather than "bandwidth". The latter has > a precise technical meaning. The text seems fine to me, thanks. Note that the variance in media is noted in the text already as one = reason for routing within the homenet, but this makes the broader = problem more explicit. Related is the edit to clarify that multicast may flow to/from the home, = not just within it. And another reason for link-state is indeed welcome ;) Tim= From jch@pps.univ-paris-diderot.fr Tue Jun 25 09:31:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EE921F9CEB for ; Tue, 25 Jun 2013 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2x3msxcjL+M for ; Tue, 25 Jun 2013 09:31:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24E21F9980 for ; Tue, 25 Jun 2013 09:30:46 -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/38117) with ESMTP id r5PGUjOT009485 for ; Tue, 25 Jun 2013 18:30:45 +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 CEF684F013 for ; Tue, 25 Jun 2013 18:30:45 +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 mE4mA-PhiJAO for ; Tue, 25 Jun 2013 18:30:43 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9F29E4F011 for ; Tue, 25 Jun 2013 18:30:43 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UrW8j-0001BO-3j for homenet@ietf.org; Tue, 25 Jun 2013 18:30:45 +0200 Date: Tue, 25 Jun 2013 18:30:45 +0200 Message-ID: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "homenet@ietf.org Group" User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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]); Tue, 25 Jun 2013 18:30:45 +0200 (CEST) Subject: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:31:21 -0000 Dear editors, dear group, After the recent thread on this list, and a number of private mail exchanges, I'm under the impression that there might be a consensus that configuration information should not be carried over the routing protocol. In this mail, I argue that configuration information should be carried by a protocol separate from the routing protocol. We should therefore make serious efforts to ensure that nothing in the arch documents prevents carrying configuration information in a separate protocol. Ideally, we should include language in the arch document that encourages such a separate implementation, but I'm not sure if we can build consensus at this point. This mail is structured as follows: 1. advantages of carrying configuration information over the routing protocol; 2. advantages of carrying configuration information over a separate protocol; 3. possible configuration protocols; 4. conclusions. 1. Advantages of carrying configuration information over the routing protocol I've heard the following advantages claimed for conflating the two functions: (i) it is not necessary to implement a new flooding protocol, which saves space on resource-limited routers; (ii) all routers participate in the routing protocol, while a new configuration protocol requires ensuring that all routers forward the configuration information. As I've shown with AHCP[1,2], however, a reasonably efficient, purely user-space, increasing diameter flooding protocol can be implemented in a hundred lines of C code or so, and takes just a few kB of flash and a few bytes of memory; this is why I find point (i) above unconvincing. Additionally, since homenet is planning to mandate the implementation of a new routing protocol on all home routers, mandating a configuration forwarding daemon does not break compatibility any further. 2. Advantages of separating configuration from routing There are significant advantages to distributing configuration information over a separate protocol. (i) distributing configuration information on a simple dedicated protocol makes monitoring and trouble-shooting easier; (ii) the architecture is more robust -- issues with the routing protocol do not prevent configuration information from being distributed; (iii) should new requirements arise, it is possible to reuse most of the homenet architecture with a new routing protocol; (iv) should new requireent arise, it is possible to reuse most of the homenet architecture while running multiple routing protocols. Point (i) is important -- experience with DHCPv4 and RA shows how easy it is to run into issues with configuration protocols, and how useful it is to be able to identify and decode configuration packets without having a full understanding of a complex routing protocol. Point (ii) is probably of secondary interest, since all implemen- tations of link-state protocols are perfectly robust and completely debugged. However, we all know the pain of recovering a router that has lost its IP addresses, anything that avoids such pain should be welcome. Points (iii) and (iv) are very important to me. I firmly believe that once homenet starts being deployed, smart amateurs are going to start building topologies that we don't even dream of, using link technologies that we never heard of. Most probably, the homenet routing protocol can then be extended to deal with the new topologies; but before this happens it will be important that people can reuse the homenet architecture with a different protocol. Hence, it is vitally important that the homenet architecture be modular enough to allow switching routing protocols. 3. Possible configuration protocols 3.1 RA RAs are ignored by routers, and rightly so -- RAs have no loop avoidance mechanism, and using RAs to configure routers leads to a number of problems that I believe to be unsolvable. Extending the RA protocol to be suitable for configuring routers is probably not worth the hassle, and will lead to confusion. 3.2 DHCPv6 There is an IETF standard configuration protocol, and that's DHCPv6. Other people on this list are more knowledgeable about DHCPv6, so I'll refrain from making a fool of myself; however, I'll take the risk of claiming that DHCPv6 (probably with extensions) looks like an eminently suitable protocol for configuring homenet routers. 3.3 A new protocol In the Babel experiment, I have designed a new protocol, which I called AHCP[1,2]. Since AHCP is designed to run before routing is functional, it makes minimal assumptions about the network -- it only requires each interface to have a link-local IPv6 address and to be able to participate in link-local multicast traffic. An AHCP client implements an increasing diameter search for an AHCP server. The full AHCP implementation (client+server+forwarder, with support for Linux and BSD Unix), consists of 3500 lines of C and 350 lines of bourne shell code, and compiles to less than 40 kB. Subset implemen- tations are possible. We have found AHCP to be very robust and reasonably fast even in the presence of massive packet loss. The traffic generated is very reasonable, even when simultaneously rebooting the whole network. I am not pushing AHCP as the homenet configuration protocol, since I have good hope that a variant of DHCPv6 can be used. However, I do hope that the results of the AHCP experiment can serve as useful input for this group. 4. Conclusions For the reasons outlined above, it is my firm opinion that configuration information should not be carried by the Homenet routing protocol. Homenet routers should either be configured by a variant of DHCPv6, or a new protocol should be designed. The arch document should be carefully reviewed, and anything that risks impeding such a solution must be eliminated. Ideally, the arch document should encourage separating configuration distribution from routing. Should DHCPv6 be finally chosen, I will be glad to collaborate on writing a tiny DHCPv6 daemon suitable for homenet. (And I have a fair amount of experience with writing tiny network daemons to run on 8MB routers.) [1] http://tools.ietf.org/html/draft-chroboczek-ahcp [2] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ From mellon@fugue.com Tue Jun 25 09:49:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA7B21E8091 for ; Tue, 25 Jun 2013 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiW8AEohteg0 for ; Tue, 25 Jun 2013 09:49:17 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 64C3C21F9A3A for ; Tue, 25 Jun 2013 09:49:16 -0700 (PDT) Received: from [IPv6:2001:470:88a3::5423:9b8c:f787:3191] (unknown [IPv6:2001:470:88a3:0:5423:9b8c:f787:3191]) by toccata.fugue.com (Postfix) with ESMTPSA id 0DC9323803B4; Tue, 25 Jun 2013 12:49:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <59F936C4-1545-49E3-A5E1-79FF99BF2718@inf-net.nl> Date: Tue, 25 Jun 2013 12:49:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <51C73CA6.8060802@globis.net> <88EF54CA-3029-44F8-8E23-439B795C5087@townsley.net> <59F936C4-1545-49E3-A5E1-79FF99BF2718@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1508) Cc: Andrew McGregor , Mark Townsley , Dave Taht , Ray Hunter , Acee Lindem , Ralph Droms , "homenet@ietf.org Group" Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:49:22 -0000 On Jun 25, 2013, at 6:39 AM, Teco Boot wrote: > I guess there is a reason not shipping capwap for homenets yet. Maybe = costs, lack of plug&play, controller dependency, lack of open source = code or simply unaware. capwap support was removed from the kernel in favor of vxlan support = quite some time ago, apparently. I don't know enough of the history to = know why. From mcr@sandelman.ca Tue Jun 25 11:04:33 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4637311E8122 for ; Tue, 25 Jun 2013 11:04:33 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESxfG0Znpep4 for ; Tue, 25 Jun 2013 11:04:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 2D61711E8118 for ; Tue, 25 Jun 2013 11:04:27 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id E907120171; Tue, 25 Jun 2013 15:08:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2D3B263A7C; Tue, 25 Jun 2013 14:03:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1C5FF63A5E; Tue, 25 Jun 2013 14:03:24 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek In-Reply-To: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> References: <878v1yqhje.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 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:04:33 -0000 --=-=-= Juliusz Chroboczek wrote: > Dear editors, dear group, > After the recent thread on this list, and a number of private mail > exchanges, I'm under the impression that there might be a consensus > that configuration information should not be carried over the routing > protocol. In this mail, I argue that > configuration information should be carried by a protocol separate > from the routing protocol. I do not agree with this statement. I believe that there are significant number of people who believe that configuration information *MUST* be disseminated at the same time as routing information. I understand that you'd like to see a diversity of routing protocols, specifically, babel and/or ahcp, and as much as I agree with the sentiment, I think that we need one good protocol, and that's it. If you feel that babel/ahcp (I'm not entirely sure if we need both) should be the homenet protocol over zOSPF: I'm open to that discussion. I am relatively ignorant of AHCP at this point, I intend to learn by doing, I hope by the end of the summer. > 3.3 A new protocol > In the Babel experiment, I have designed a new protocol, which > I called AHCP[1,2]. Since AHCP is designed to run before routing is > functional, it makes minimal assumptions about the network -- it only > requires each interface to have a link-local IPv6 address and to be > able to participate in link-local multicast traffic. An AHCP client > implements an increasing diameter search for an AHCP server. > The full AHCP implementation (client+server+forwarder, with support > for Linux and BSD Unix), consists of 3500 lines of C and 350 lines of > bourne shell code, and compiles to less than 40 kB. Subset implemen- > tations are possible. We have found AHCP to be very robust and > reasonably fast even in the presence of massive packet loss. The > traffic generated is very reasonable, even when simultaneously > rebooting the whole network. > I am not pushing AHCP as the homenet configuration protocol, since > I have good hope that a variant of DHCPv6 can be used. However, I do > hope that the results of the AHCP experiment can serve as useful input > for this group. I near you, but I believe that we can not achieve out goals if we do not do configuration at the same time as loop detection and therefore routing. Specifically, I think that we will have gaping security issues which will be very hard to close. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcnbaYqHRg3pndX9AQImBAP/brx0t5eQoEaSQR0qkCoVKA8y1tmGpAm9 y7KZMbA0h2xkwqIxu8IukihnfwNfE9ziyNXv8bXFMxCrXHmHh/+pzSBqTVYHKgA+ 6jBTFuyAfMYDkGCa7yF/ut5+Ean9csU1CF7pTEna8Uj/F2UaU/LCbqbpAB3FtshL xvBDXm63YbE= =GEoY -----END PGP SIGNATURE----- --=-=-=-- From dave.taht@gmail.com Tue Jun 25 12:58:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B621E80D4 for ; Tue, 25 Jun 2013 12:58:51 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRZvTHOUttto for ; Tue, 25 Jun 2013 12:58:50 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5A721E8099 for ; Tue, 25 Jun 2013 12:58:50 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so29068650iec.41 for ; Tue, 25 Jun 2013 12:58:49 -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=IymbZ2foBeFWop6P3ow4n6yga2ndHJsh36hlHQNyCBY=; b=Arjckt0mUCzWxOLvYZHk4o0ieH+94nGagC3FUXZvsYnSKH61t6UMGuDmnHC5FRuUNC uMFfYftdNO7GK43rGmtc5lt1WtWPazQnkbq0+A/ADbaFQ0LqmOW2gSuk1F5kT+fND5B4 6CSB9yYqh6AaSn/Hf5zlNa4/Uz4ZKWv3KypIEJpLup3o1VY7ad0w7imDJGcaZGT2N15e QQgo1neMIx+uVneBF2lcGZhqG1UPseesMJhsJIufmiuzPXow2SxlUC97e29FqgIokUJx HSHbgn0JaPXk5O8h5Gtf7lCOKHTSVSuv6P4IoNY3VVl7kEbJsRM5LSSEblPwI0aPaiMC nd+Q== MIME-Version: 1.0 X-Received: by 10.50.65.99 with SMTP id w3mr376697igs.37.1372190329852; Tue, 25 Jun 2013 12:58:49 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Tue, 25 Jun 2013 12:58:49 -0700 (PDT) In-Reply-To: <31616.1372183404@sandelman.ca> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <31616.1372183404@sandelman.ca> Date: Tue, 25 Jun 2013 12:58:49 -0700 Message-ID: From: Dave Taht To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:58:52 -0000 On Tue, Jun 25, 2013 at 11:03 AM, Michael Richardson wrote: > > Juliusz Chroboczek wrote: > > Dear editors, dear group, > > > After the recent thread on this list, and a number of private mail > > exchanges, I'm under the impression that there might be a consensus > > that configuration information should not be carried over the routi= ng > > protocol. In this mail, I argue that > > > configuration information should be carried by a protocol separate > > from the routing protocol. > > I do not agree with this statement. I have been on the fence on this issue for a very long time, preferring to wait for running code, and the opportunity to run it. Various problems, like the need for a small dhcpv6-pd capable server have been met, but the prefix distribution issue and choice of a routing protocol remains a sketchy one. Do we have consensus that the majority of connections in the homenet will be wireless? Does anyone believe that dhcpv6 or the prefix distribution methods discussed here are sufficient to provision wireless? > I believe that there are significant number of people who believe that > configuration information *MUST* be disseminated at the same time as rout= ing > information. I agree that there are a significant number of people that think these two problems are in-inextricably interlinked. I disagree with that, but would prefer to have thoroughly proven that they can indeed be nearly/almost/totally separated, which is not the case. I'm glad some zOSPF code is out there now for quagga and bird, it's long been on my todo list to experiment with. > I understand that you'd like to see a diversity of routing protocols, > specifically, babel and/or ahcp, and as much as I agree with the sentimen= t, I > think that we need one good protocol, and that's it. It would be nice to have one good protocol, for all definitions of "good". However a profusion of protocols exist, and having in a configuration protocol the ability to announce and/or select a routing protocol would be the most flexible. > > If you feel that babel/ahcp (I'm not entirely sure if we need both) shoul= d be > the homenet protocol over zOSPF: I'm open to that discussion. > > I am relatively ignorant of AHCP at this point, I intend to learn by doin= g, I > hope by the end of the summer. > > > 3.3 A new protocol > > > In the Babel experiment, I have designed a new protocol, which > > I called AHCP[1,2]. Since AHCP is designed to run before routing i= s > > functional, it makes minimal assumptions about the network -- it on= ly > > requires each interface to have a link-local IPv6 address and to be > > able to participate in link-local multicast traffic. An AHCP clien= t > > implements an increasing diameter search for an AHCP server. > > > The full AHCP implementation (client+server+forwarder, with support > > for Linux and BSD Unix), consists of 3500 lines of C and 350 lines = of > > bourne shell code, and compiles to less than 40 kB. Subset impleme= n- > > tations are possible. We have found AHCP to be very robust and > > reasonably fast even in the presence of massive packet loss. The > > traffic generated is very reasonable, even when simultaneously > > rebooting the whole network. > > > I am not pushing AHCP as the homenet configuration protocol, since > > I have good hope that a variant of DHCPv6 can be used. Actually I don't share that hope. present-day AHCP isn't sufficient either, but it did look straightforward to add prefix distribution to it and iterate forward as to other configuration needs as they were better defined. I'd like to see a conversation centered on "what is needed for a configuration protocol" for a homenet to flush out other requirements besides prefix distribution. As one example which I pointed out last week, in order for windows filesharing to work properly, wins server information needs to be propagated. >However, I do > > hope that the results of the AHCP experiment can serve as useful in= put > > for this group. > > I near you, but I believe that we can not achieve out goals if we do not = do > configuration at the same time as loop detection and therefore routing. Using /128 prefixes makes life tons easier. > Specifically, I think that we will have gaping security issues which will= be > very hard to close. The security problem has not been addressed in zOSPF either. > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From ietfdbh@comcast.net Tue Jun 25 13:23:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC021E80B3 for ; Tue, 25 Jun 2013 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1Chd5oarN9U for ; Tue, 25 Jun 2013 13:23:47 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 18AB511E813D for ; Tue, 25 Jun 2013 13:23:44 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id sdSt1l00C0mv7h059kPi0y; Tue, 25 Jun 2013 20:23:42 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta11.westchester.pa.mail.comcast.net with comcast id skPi1l00C2yZEBF3XkPiTf; Tue, 25 Jun 2013 20:23:42 +0000 From: "ietfdbh" To: "'Juliusz Chroboczek'" , References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 25 Jun 2013 16:23:27 -0400 Message-ID: <020301ce71e1$da38d120$8eaa7360$@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: AQE4C/NEd5Tcml5vUwFSyZ4r6e7WQZpzp5zw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372191822; bh=YW7WpZNp4PeYgdHxii0AN+iAW1yQ+kZ2xX92chtzYjA=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=DnZr4HtvhOSYkA+Em8BuEdvS7/NVEzTGNTkwGb+6aK7wSUopYoJXsNLHfctJVM5qQ u7G0/3p03URqTmH9v+EX11eq1VKfKgRUADSidmruqiMOwmU4w2U8kHOuxScYYx2I1t 676D6fXLWYKrlzwpueCPtfdpZQzZsLDl0cMEmQp6UTkP2Nm6dYHx9jXXGUmKWjzq+/ tFPEZjlb12ceumbOqnQoCH474mWacFRbCVEsMccPN9tg1u3dQZd4NNn+DeP6H/ms5o FrmZT2hLLm9LKrnP47LUU2SyuIIvLFddcoD+CX3yc/fQ/4blUd1mNi2q4FFzrOWa5Z mfLPr26vmuplQ== Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:23:52 -0000 Hi, Just a comment ... You say " There is an IETF standard configuration protocol, and that's DHCPv6." Actually, the IETF has a number of configuration protocol standards, not just DHCPv6. (Standards are wonderful; everybody should have one!) If you are going to consider using a standard configuration protocol, then you should also consider, depending on an analysis of the specific needs for homenet: DHCP, Netconf, RADIUS, Diameter, CAPWAP, COPS-PR, and SNMP, amongst others. Some of these I would not recommend for homenet, but they are IETF standard configuration protocols. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Juliusz Chroboczek Sent: Tuesday, June 25, 2013 12:31 PM To: homenet@ietf.org Group Subject: [homenet] Configuration must not be carried by the routing protocol Dear editors, dear group, After the recent thread on this list, and a number of private mail exchanges, I'm under the impression that there might be a consensus that configuration information should not be carried over the routing protocol. In this mail, I argue that configuration information should be carried by a protocol separate from the routing protocol. We should therefore make serious efforts to ensure that nothing in the arch documents prevents carrying configuration information in a separate protocol. Ideally, we should include language in the arch document that encourages such a separate implementation, but I'm not sure if we can build consensus at this point. This mail is structured as follows: 1. advantages of carrying configuration information over the routing protocol; 2. advantages of carrying configuration information over a separate protocol; 3. possible configuration protocols; 4. conclusions. 1. Advantages of carrying configuration information over the routing protocol I've heard the following advantages claimed for conflating the two functions: (i) it is not necessary to implement a new flooding protocol, which saves space on resource-limited routers; (ii) all routers participate in the routing protocol, while a new configuration protocol requires ensuring that all routers forward the configuration information. As I've shown with AHCP[1,2], however, a reasonably efficient, purely user-space, increasing diameter flooding protocol can be implemented in a hundred lines of C code or so, and takes just a few kB of flash and a few bytes of memory; this is why I find point (i) above unconvincing. Additionally, since homenet is planning to mandate the implementation of a new routing protocol on all home routers, mandating a configuration forwarding daemon does not break compatibility any further. 2. Advantages of separating configuration from routing There are significant advantages to distributing configuration information over a separate protocol. (i) distributing configuration information on a simple dedicated protocol makes monitoring and trouble-shooting easier; (ii) the architecture is more robust -- issues with the routing protocol do not prevent configuration information from being distributed; (iii) should new requirements arise, it is possible to reuse most of the homenet architecture with a new routing protocol; (iv) should new requireent arise, it is possible to reuse most of the homenet architecture while running multiple routing protocols. Point (i) is important -- experience with DHCPv4 and RA shows how easy it is to run into issues with configuration protocols, and how useful it is to be able to identify and decode configuration packets without having a full understanding of a complex routing protocol. Point (ii) is probably of secondary interest, since all implemen- tations of link-state protocols are perfectly robust and completely debugged. However, we all know the pain of recovering a router that has lost its IP addresses, anything that avoids such pain should be welcome. Points (iii) and (iv) are very important to me. I firmly believe that once homenet starts being deployed, smart amateurs are going to start building topologies that we don't even dream of, using link technologies that we never heard of. Most probably, the homenet routing protocol can then be extended to deal with the new topologies; but before this happens it will be important that people can reuse the homenet architecture with a different protocol. Hence, it is vitally important that the homenet architecture be modular enough to allow switching routing protocols. 3. Possible configuration protocols 3.1 RA RAs are ignored by routers, and rightly so -- RAs have no loop avoidance mechanism, and using RAs to configure routers leads to a number of problems that I believe to be unsolvable. Extending the RA protocol to be suitable for configuring routers is probably not worth the hassle, and will lead to confusion. 3.2 DHCPv6 There is an IETF standard configuration protocol, and that's DHCPv6. Other people on this list are more knowledgeable about DHCPv6, so I'll refrain from making a fool of myself; however, I'll take the risk of claiming that DHCPv6 (probably with extensions) looks like an eminently suitable protocol for configuring homenet routers. 3.3 A new protocol In the Babel experiment, I have designed a new protocol, which I called AHCP[1,2]. Since AHCP is designed to run before routing is functional, it makes minimal assumptions about the network -- it only requires each interface to have a link-local IPv6 address and to be able to participate in link-local multicast traffic. An AHCP client implements an increasing diameter search for an AHCP server. The full AHCP implementation (client+server+forwarder, with support for Linux and BSD Unix), consists of 3500 lines of C and 350 lines of bourne shell code, and compiles to less than 40 kB. Subset implemen- tations are possible. We have found AHCP to be very robust and reasonably fast even in the presence of massive packet loss. The traffic generated is very reasonable, even when simultaneously rebooting the whole network. I am not pushing AHCP as the homenet configuration protocol, since I have good hope that a variant of DHCPv6 can be used. However, I do hope that the results of the AHCP experiment can serve as useful input for this group. 4. Conclusions For the reasons outlined above, it is my firm opinion that configuration information should not be carried by the Homenet routing protocol. Homenet routers should either be configured by a variant of DHCPv6, or a new protocol should be designed. The arch document should be carefully reviewed, and anything that risks impeding such a solution must be eliminated. Ideally, the arch document should encourage separating configuration distribution from routing. Should DHCPv6 be finally chosen, I will be glad to collaborate on writing a tiny DHCPv6 daemon suitable for homenet. (And I have a fair amount of experience with writing tiny network daemons to run on 8MB routers.) [1] http://tools.ietf.org/html/draft-chroboczek-ahcp [2] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From acee.lindem@ericsson.com Tue Jun 25 13:34:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFB211E8140 for ; Tue, 25 Jun 2013 13:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A5FyWRRxjm3 for ; Tue, 25 Jun 2013 13:34:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E968411E8131 for ; Tue, 25 Jun 2013 13:34:50 -0700 (PDT) X-AuditID: c6180641-b7fba6d000003daf-f8-51c9fee96120 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E7.75.15791.AEEF9C15; Tue, 25 Jun 2013 22:34:50 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 16:34:50 -0400 From: Acee Lindem To: ietfdbh Thread-Topic: [homenet] Configuration must not be carried by the routing protocol Thread-Index: AQHOceIPpNycgrtak0ml9xXvvc4cjplHJigA Date: Tue, 25 Jun 2013 20:34:49 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47189B02@eusaamb101.ericsson.se> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> In-Reply-To: <020301ce71e1$da38d120$8eaa7360$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <8A868811B9BCD745AF2A59CD715F9F31@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXSPn+6rfycDDdp+yli8X3SIxeL2pRiL z5/+sTowe0x+PIfRY8mSn0weF3e/YwxgjuKySUnNySxLLdK3S+DK+DRlKmvBO8eKfw+PMTYw LjbtYuTgkBAwkZhx2q2LkRPIFJO4cG89WxcjF4eQwFFGiX0z57BCOMsZJU6en8cMUsUmoCPx /NE/ZpBmEQFFie13zEHCzAKJEgeeXwcLCwsESWzrFYSoCJY4f64WpEJEwEjizawdYENYBFQl jlyYC2bzCnhLvDy+nAXEFhLIlLi1sY0NxOYUsJI4v+gOE4jNCHTa91NrmCA2iUvcejKfCeJk AYkle84zQ9iiEi8f/2OFsJUlvs95xAJRryOxYPcnNpBzmAWsJc6vdIAIa0ssW/ga6gRBiZMz n7BMYBSfhWTDLCTdsxC6ZyHpnoWkewEj6ypGjtLi1LLcdCPDTYzA6Domwea4g3HBJ8tDjNIc LErivO9P7QoUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMj6TPuu5Ycry+a4MiZ8q1p0NlXp S+8/bjOLFXMy62qvh/l4czaX6Dh82dqvuE5xwV7xPQ731/2a2GaeuH7f3uiyt//X7uRrCDl/ hluWwerezs/OR8+5zd/qqne+7EzixwfSk3ctcX+3OOnC3xn93l5nT4VKXOJkvWhT8zXJ9M4v Q/tJXuuS4jqVWIozEg21mIuKEwEv/HeIfAIAAA== Cc: "" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:34:56 -0000 In any case, I just scanned the architecture document and there doesn't app= ear to be anything that implies a routing protocol will be used to dissemin= ate configuration. Hence, this discuss can be independent of the WGLC.=20 Acee=20 On Jun 25, 2013, at 4:23 PM, ietfdbh wrote: > Hi, >=20 > Just a comment ... > You say " There is an IETF standard configuration protocol, and that's > DHCPv6." >=20 > Actually, the IETF has a number of configuration protocol standards, not > just DHCPv6. > (Standards are wonderful; everybody should have one!) > If you are going to consider using a standard configuration protocol, the= n > you should also consider, depending on an analysis of the specific needs = for > homenet: > DHCP, Netconf, RADIUS, Diameter, CAPWAP, COPS-PR, and SNMP, amongst other= s. >=20 > Some of these I would not recommend for homenet, but they are IETF standa= rd > configuration protocols. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behal= f > Of Juliusz Chroboczek > Sent: Tuesday, June 25, 2013 12:31 PM > To: homenet@ietf.org Group > Subject: [homenet] Configuration must not be carried by the routing proto= col >=20 > Dear editors, dear group, >=20 > After the recent thread on this list, and a number of private mail > exchanges, I'm under the impression that there might be a consensus that > configuration information should not be carried over the routing protocol= . > In this mail, I argue that >=20 > configuration information should be carried by a protocol separate > from the routing protocol. >=20 > We should therefore make serious efforts to ensure that nothing in the ar= ch > documents prevents carrying configuration information in a separate > protocol. Ideally, we should include language in the arch document that > encourages such a separate implementation, but I'm not sure if we can bui= ld > consensus at this point. >=20 > This mail is structured as follows: >=20 > 1. advantages of carrying configuration information over the routing > protocol; 2. advantages of carrying configuration information over a > separate protocol; 3. possible configuration protocols; 4. conclusions. >=20 >=20 > 1. Advantages of carrying configuration information over the routing > protocol >=20 > I've heard the following advantages claimed for conflating the two > functions: >=20 > (i) it is not necessary to implement a new flooding protocol, which > saves space on resource-limited routers; > (ii) all routers participate in the routing protocol, while a new > configuration protocol requires ensuring that all routers forward > the configuration information. >=20 > As I've shown with AHCP[1,2], however, a reasonably efficient, purely > user-space, increasing diameter flooding protocol can be implemented in a > hundred lines of C code or so, and takes just a few kB of flash and a few > bytes of memory; this is why I find point (i) above unconvincing. > Additionally, since homenet is planning to mandate the implementation of = a > new routing protocol on all home routers, mandating a configuration > forwarding daemon does not break compatibility any further. >=20 >=20 > 2. Advantages of separating configuration from routing >=20 > There are significant advantages to distributing configuration informatio= n > over a separate protocol. >=20 > (i) distributing configuration information on a simple dedicated > protocol makes monitoring and trouble-shooting easier; > (ii) the architecture is more robust -- issues with the routing protocol > do not prevent configuration information from being distributed; > (iii) should new requirements arise, it is possible to reuse most of the > homenet architecture with a new routing protocol; > (iv) should new requireent arise, it is possible to reuse most of the > homenet architecture while running multiple routing protocols. >=20 > Point (i) is important -- experience with DHCPv4 and RA shows how easy it= is > to run into issues with configuration protocols, and how useful it is to = be > able to identify and decode configuration packets without having a full > understanding of a complex routing protocol. >=20 > Point (ii) is probably of secondary interest, since all implemen- tations= of > link-state protocols are perfectly robust and completely debugged. Howev= er, > we all know the pain of recovering a router that has lost its IP addresse= s, > anything that avoids such pain should be welcome. >=20 > Points (iii) and (iv) are very important to me. I firmly believe that on= ce > homenet starts being deployed, smart amateurs are going to start building > topologies that we don't even dream of, using link technologies that we > never heard of. Most probably, the homenet routing protocol can then be > extended to deal with the new topologies; but before this happens it will= be > important that people can reuse the homenet architecture with a different > protocol. Hence, it is vitally important that the homenet architecture b= e > modular enough to allow switching routing protocols. >=20 >=20 > 3. Possible configuration protocols >=20 > 3.1 RA >=20 > RAs are ignored by routers, and rightly so -- RAs have no loop avoidance > mechanism, and using RAs to configure routers leads to a number of proble= ms > that I believe to be unsolvable. Extending the RA protocol to be suitabl= e > for configuring routers is probably not worth the hassle, and will lead t= o > confusion. >=20 > 3.2 DHCPv6 >=20 > There is an IETF standard configuration protocol, and that's DHCPv6. > Other people on this list are more knowledgeable about DHCPv6, so I'll > refrain from making a fool of myself; however, I'll take the risk of > claiming that DHCPv6 (probably with extensions) looks like an eminently > suitable protocol for configuring homenet routers. >=20 > 3.3 A new protocol >=20 > In the Babel experiment, I have designed a new protocol, which I called > AHCP[1,2]. Since AHCP is designed to run before routing is functional, i= t > makes minimal assumptions about the network -- it only requires each > interface to have a link-local IPv6 address and to be able to participate= in > link-local multicast traffic. An AHCP client implements an increasing > diameter search for an AHCP server. >=20 > The full AHCP implementation (client+server+forwarder, with support for > Linux and BSD Unix), consists of 3500 lines of C and 350 lines of bourne > shell code, and compiles to less than 40 kB. Subset implemen- tations ar= e > possible. We have found AHCP to be very robust and reasonably fast even = in > the presence of massive packet loss. The traffic generated is very > reasonable, even when simultaneously rebooting the whole network. >=20 > I am not pushing AHCP as the homenet configuration protocol, since I have > good hope that a variant of DHCPv6 can be used. However, I do hope that = the > results of the AHCP experiment can serve as useful input for this group. >=20 >=20 > 4. Conclusions >=20 > For the reasons outlined above, it is my firm opinion that configuration > information should not be carried by the Homenet routing protocol. Homen= et > routers should either be configured by a variant of DHCPv6, or a new > protocol should be designed. >=20 > The arch document should be carefully reviewed, and anything that risks > impeding such a solution must be eliminated. Ideally, the arch document > should encourage separating configuration distribution from routing. >=20 > Should DHCPv6 be finally chosen, I will be glad to collaborate on writing= a > tiny DHCPv6 daemon suitable for homenet. (And I have a fair amount of > experience with writing tiny network daemons to run on 8MB routers.) >=20 >=20 > [1] http://tools.ietf.org/html/draft-chroboczek-ahcp > [2] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ > _______________________________________________ > 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 john_leddy@cable.comcast.com Tue Jun 25 13:42:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1F511E8155 for ; Tue, 25 Jun 2013 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caltVkNHpkc5 for ; Tue, 25 Jun 2013 13:42:30 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id F1D7211E8151 for ; Tue, 25 Jun 2013 13:42:25 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.56646719; Tue, 25 Jun 2013 16:41:01 -0400 Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.141]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Tue, 25 Jun 2013 16:42:21 -0400 From: "Leddy, John" To: Dave Taht , Michael Richardson Thread-Topic: [homenet] Configuration must not be carried by the routing protocol Thread-Index: AQHOceR9NMCq1bvg3kuCUnnDg9dRmw== Date: Tue, 25 Jun 2013 20:42:20 +0000 Message-ID: <9FB60CE5849B194190DC0CDAD4825AEC3F4272EC@PACDCEXMB13.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.248] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B43BACBA870C042A7182ED5D03CE8FB@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:42:36 -0000 On 6/25/13 3:58 PM, "Dave Taht" wrote: > >I have been on the fence on this issue for a very long time, >preferring to wait for running code, and the opportunity to run it. >Various problems, like the need for a small dhcpv6-pd capable server >have been met, but the prefix distribution issue and choice of a >routing protocol remains a sketchy one. > >Do we have consensus that the majority of connections in the homenet >will be wireless? If you really mean wireless not wifi, I would agree. But don't forget about Zigbee on the wireless side (and futures). Also technologies using existing wiring; MoCA, HPNA and HomePlug (and futures). =20 They may be for direct attachment (ex. IP STBs) or dongles for ethernet, wireless, HomeNet router extension. John From mcr@sandelman.ca Tue Jun 25 13:57:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C221F9E07 for ; Tue, 25 Jun 2013 13:57:00 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgkk5P+MBkNb for ; Tue, 25 Jun 2013 13:56:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id B384821F9DE6 for ; Tue, 25 Jun 2013 13:56:54 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9968420172; Tue, 25 Jun 2013 18:00:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 401B063A7C; Tue, 25 Jun 2013 16:55:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2EDDB63732; Tue, 25 Jun 2013 16:55:49 -0400 (EDT) From: Michael Richardson To: Dave Taht In-Reply-To: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <31616.1372183404@sandelman.ca> 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 Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:57:01 -0000 Dave Taht wrote: > On Tue, Jun 25, 2013 at 11:03 AM, Michael Richardson > wrote: >> >> Juliusz Chroboczek wrote: >> > Dear editors, dear group, >> >> > After the recent thread on this list, and a number of private mail >> > exchanges, I'm under the impression that there might be a consensus >> > that configuration information should not be carried over the routing >> > protocol. In this mail, I argue that >> >> > configuration information should be carried by a protocol separate >> > from the routing protocol. >> >> I do not agree with this statement. > I have been on the fence on this issue for a very long time, > preferring to wait for running code, and the opportunity to run it. > Various problems, like the need for a small dhcpv6-pd capable server > have been met, but the prefix distribution issue and choice of a > routing protocol remains a sketchy one. > Do we have consensus that the majority of connections in the homenet > will be wireless? Now that the gamers know about bufferbloat, they are realizing why none of them use wireless for gaming. my understanding is that 802.11ac will be even worse for latency. Gamers matter, because they replace their stuff sooner than anyone else. It seems that many of telco/ipTV people have figured out that wireless doesn't work for them. So, tell me what a "connection" is... one assumes you don't mean TCP connection... >> I believe that there are significant number of people who believe that >> configuration information *MUST* be disseminated at the same time as routing >> information. > I agree that there are a significant number of people that think these > two problems are in-inextricably interlinked. Good, we agree that there are people who disagree with the original statement. > However a profusion of protocols exist, and having in a configuration > protocol the ability to announce and/or select a routing protocol > would be the most flexible. I don't want this. Then we get into MUST implement routing protocols, and SHOULD implement routing protocols, etc... > I'd like to see a conversation centered on "what is needed for a > configuration protocol" for a homenet to flush out other requirements > besides prefix distribution. As one example which I pointed out last > week, in order for windows filesharing to work properly, wins server > information needs to be propagated. I agree. >> Specifically, I think that we will have gaping security issues which will be >> very hard to close. > The security problem has not been addressed in zOSPF either. I didn't claim that it was. I am claiming that the decision, "can we trust this configuration information" may be linked to "what route this this configuration information arrive". So, let me rephrase my claim. I think if we have two protocols, and that they are implemented by seperate daemons on a router, that they security linkages of state will not be implemented. Further, after we document the linkages that we need, we will effectively have one protocol that runs on two ports using messages in two different formats. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From jch@pps.univ-paris-diderot.fr Tue Jun 25 13:59:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F7221F9DE6 for ; Tue, 25 Jun 2013 13:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-3F9qOpSS22 for ; Tue, 25 Jun 2013 13:58:54 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 7522C21F9E96 for ; Tue, 25 Jun 2013 13:58:46 -0700 (PDT) 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/38117) with ESMTP id r5PKwYhI004455; Tue, 25 Jun 2013 22:58:34 +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 7235C4F032; Tue, 25 Jun 2013 22:58:34 +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 1Cl_at_kzrCi; Tue, 25 Jun 2013 22:58:33 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 582854F031; Tue, 25 Jun 2013 22:58:33 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UraJt-0003I3-Gq; Tue, 25 Jun 2013 22:58:33 +0200 Date: Tue, 25 Jun 2013 22:58:33 +0200 Message-ID: <87bo6tq552.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Acee Lindem In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47189B02@eusaamb101.ericsson.se> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <94A203EA12AECE4BA92D42DBFFE0AE47189B02@eusaamb101.ericsson.se> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 25 Jun 2013 22:58:34 +0200 (CEST) Cc: "" , ietfdbh Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:59:00 -0000 > In any case, I just scanned the architecture document and there > doesn't appear to be anything that implies a routing protocol will > be used to disseminate configuration. Thanks for taking the time to do that. -- Juliusz From tjc@ecs.soton.ac.uk Tue Jun 25 14:12:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEA611E8152 for ; Tue, 25 Jun 2013 14:12:14 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkFgPxKtIgsV for ; Tue, 25 Jun 2013 14:12:13 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id F1BCB11E814C for ; Tue, 25 Jun 2013 14:12:09 -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 r5PLC1o4021681; Tue, 25 Jun 2013 22:12:01 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5PLC1o4021681 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1372194721; bh=lKeM9RidvCoj1qPIqoSSUdwrL7E=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=Sn1EAucx+N3Ns6s7P95v9lo3xov++Mx/CAac5k+SAnf3cL/f634MSOhA85/rej06d /vlZHwDwiTnR3ii0gOErywqMro8k/Yum7oYI8Nn4udEB32gHMfOp76AWUEiEB3tJlD 3pRlJmb0Ay5YZwa4GfuSvtGZpZV3+LbKAeQgVn7A= 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 p5OMC10544557017uJ ret-id none; Tue, 25 Jun 2013 22:12:01 +0100 Received: from [192.168.1.110] (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 r5PLBqH5020371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 22:11:53 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47189B02@eusaamb101.ericsson.se> Date: Tue, 25 Jun 2013 22:11:54 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <94A203EA12AECE4BA92D42DBFFE0AE47189B02@eusaamb101.ericsson.se> <3BC166B2-EAAE-4AF8-9B20-0DE59ADB1FA0@ecs.soton.ac.uk> To: Acee Lindem X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5OMC1054455701700; tid=p5OMC10544557017uJ; 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: r5PLC1o4021681 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "" , ietfdbh , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 21:12:14 -0000 On 25 Jun 2013, at 21:34, Acee Lindem wrote: > In any case, I just scanned the architecture document and there = doesn't appear to be anything that implies a routing protocol will be = used to disseminate configuration. Hence, this discuss can be = independent of the WGLC.=20 Indeed. Tim From jch@pps.univ-paris-diderot.fr Tue Jun 25 15:03:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36D411E815C for ; Tue, 25 Jun 2013 15:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6zotEjffqib for ; Tue, 25 Jun 2013 15:02:50 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id B621211E814D for ; Tue, 25 Jun 2013 15:02:48 -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/38117) with ESMTP id r5PM2bpn024544; Wed, 26 Jun 2013 00:02:38 +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 E0FEC4F034; Wed, 26 Jun 2013 00:02: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 JuC3HZgj7O9C; Wed, 26 Jun 2013 00:02:36 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B56E24F01E; Wed, 26 Jun 2013 00:02:36 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UrbJs-0004nQ-L6; Wed, 26 Jun 2013 00:02:36 +0200 Date: Wed, 26 Jun 2013 00:02:36 +0200 Message-ID: <87y59xonlv.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Acee Lindem In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47189B02@eusaamb101.ericsson.se> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <94A203EA12AECE4BA92D42DBFFE0AE47189B02@eusaamb101.ericsson.se> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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]); Wed, 26 Jun 2013 00:02:40 +0200 (CEST) Cc: "" , ietfdbh Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 22:03:05 -0000 > In any case, I just scanned the architecture document and there > doesn't appear to be anything that implies a routing protocol will > be used to disseminate configuration. Yes, it looks you're right. -- Juliusz From jch@pps.univ-paris-diderot.fr Tue Jun 25 15:03:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D0811E8165 for ; Tue, 25 Jun 2013 15:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3hUrElZE2uG for ; Tue, 25 Jun 2013 15:03:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA6711E8166 for ; Tue, 25 Jun 2013 15:03:16 -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/38117) with ESMTP id r5PM3DgD024667; Wed, 26 Jun 2013 00:03:13 +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 29F844F03A; Wed, 26 Jun 2013 00:03:13 +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 smRcEQToK-eq; Wed, 26 Jun 2013 00:03:12 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0D0A34F038; Wed, 26 Jun 2013 00:03:12 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UrbKS-0004nV-6b; Wed, 26 Jun 2013 00:03:12 +0200 Date: Wed, 26 Jun 2013 00:03:12 +0200 Message-ID: <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "ietfdbh" In-Reply-To: <020301ce71e1$da38d120$8eaa7360$@comcast.net> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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]); Wed, 26 Jun 2013 00:03:13 +0200 (CEST) Cc: homenet@ietf.org, 'Juliusz Chroboczek' Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 22:03:20 -0000 > Just a comment ... > You say " There is an IETF standard configuration protocol, and that's > DHCPv6." > Actually, the IETF has a number of configuration protocol standards, not > just DHCPv6. Point duly taken. -- Juliusz From teco@inf-net.nl Tue Jun 25 22:49:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED72A21E80C4 for ; Tue, 25 Jun 2013 22:49:44 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmxYhQuE+1ry for ; Tue, 25 Jun 2013 22:49:44 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BB21C21E80A6 for ; Tue, 25 Jun 2013 22:49:31 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id je9so4625251bkc.4 for ; Tue, 25 Jun 2013 22:49:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3mrId8bPd4QOyLpPnDotJoAmPabHgJDiOv5UyNvshKQ=; b=FSy7q5iOLx3quM3NXs26Aq6J3hDF82Ga7uGRhJiXvNYpDk5RV+5dntveePeHI5Xprm /tsnrIRXMPVOjBuDB1YSk8/HKTQLRFGGp16w9SAOk+kGSr0vHAc7iIxuLe+8TlvlWiOa nTrKn092jBpEawqYNx4McSGs1Mw2w8dOAqHygnsrBtfANnNv1CNWmWh0/Y4O0/Wij4ny 4TN7t+bYPj3plh+ldIezQwGFuxCZ/xhf3EpHLs94yapTfBOs4ktTF9D8U68A6ThdvC8p 8VJfNbGouBXk1bH/xNx0/QBGDH/Nfz/wDk5AqQMKQx6Q6WID7+yqSiZbURW4fH4qbuTC iXwA== X-Received: by 10.205.8.70 with SMTP id or6mr263567bkb.177.1372225771015; Tue, 25 Jun 2013 22:49:31 -0700 (PDT) Received: from [10.87.35.31] ([88.128.80.4]) by mx.google.com with ESMTPSA id kv3sm7231090bkb.10.2013.06.25.22.49.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 22:49:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <19181.1372193749@sandelman.ca> Date: Wed, 26 Jun 2013 07:49:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <31616.1372183404@sandelman.ca> <19181.1372193749@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnSr9pw8EMEsGBXaZpS1WmyFjqPsuqoLTD3wbYuDS+gtt0vsKFw1SWXqttocFV+CK5+ORQW Cc: "homenet@ietf.org Group" , Dave Taht , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 05:49:45 -0000 Op 25 jun. 2013, om 22:55 heeft Michael Richardson = het volgende geschreven: >=20 > So, let me rephrase my claim. > I think if we have two protocols, and that they are implemented by = seperate > daemons on a router, that they security linkages of state will not be > implemented. Further, after we document the linkages that we need, we = will > effectively have one protocol that runs on two ports using messages in = two > different formats. Address configuration and routing are separate daemons for decades. And = there is more to do. Teco= From lorenzo@google.com Tue Jun 25 23:44:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08C121E8095 for ; Tue, 25 Jun 2013 23:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64KPc0JcxsZW for ; Tue, 25 Jun 2013 23:44:15 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id C33A111E813F for ; Tue, 25 Jun 2013 23:44:14 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so10849885veb.8 for ; Tue, 25 Jun 2013 23:44:14 -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=ZaDjXQCho0FmVMEtwLrGVcyJr4XlBg6bKQZ8CRNI3RA=; b=C+ut3Mm0HTFUtujrWZmDv1ZQQT3NSUpffroaUOiBQulMR5Wq3PXDqnACBoWrim30dT zAd/zgy8ZdhjBAqOJimyhoBjdYFYxIgRJkCEKITGQ6chOkjBr6pU80TnDxJ2GY9SdBht DtmqpELgeoPRBrgLZdqsGLRk7v+XBEnvnQ98ZHtGTJ0jYCZAYTupn2g6Y0sTnDZel/YT U2xfz4L0gXPoM2Q4EmmdQDsksmVxWh7Hs7+INTgX7f4XZw+7M5A2Rzts6ar4ZQpzoZm+ kK9bNfciUK28+meCZL0SjC2by3H3iak3aEQtQQ4J8A7qLnPqsY/bwsKeGxddRxxiNi4Z oRNQ== X-Google-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:x-gm-message-state; bh=ZaDjXQCho0FmVMEtwLrGVcyJr4XlBg6bKQZ8CRNI3RA=; b=Ircc8TeKki3DkEWwr0qky7Pq9aDea/H8+xgy5nRlOga5CjEAJj5en9MhL9FZoMUAOu 7FH/E0nyuhZVjwoHLMG5fg/gqD98xmDMU0m4fpfx5cur0WuhvldzIiKuDGssZcsD+YZz IqzvwZz7nXdwvTPFCyFVyZqcVRX/BO17LFko18IQnMM9mVDznZbv+NDIpzj8Glzg0h9C udXOrumcxITt3sFaVdnH1BNF2BMdXaT3zcSekhvz+HXuAlyfQ8Qt+hOA1AGBk0ERZ+QJ IpLRCt3oBHCj02ZVEkfD1LJnFI+MHYoaoORY+HDxgA6tG2Q9xVd4QM017hG9dZsVBU0c f3Gg== X-Received: by 10.58.76.34 with SMTP id h2mr1131226vew.93.1372229054137; Tue, 25 Jun 2013 23:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.172.66 with HTTP; Tue, 25 Jun 2013 23:43:53 -0700 (PDT) In-Reply-To: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Wed, 26 Jun 2013 15:43:53 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=047d7b3437e452bb0904e008f9ec X-Gm-Message-State: ALoCoQnGuJhHdYRUjsPKxGN5l6GzKbR2WdDt+nJikBxXDw2takVs/bLwhAciHkBgEZjx6x8xVJG76pgkrY3Q+qD23OL0tbQcaA6SyTeTW9cTzG6zyfQhW1PwIkt5RI7vv+Cf1a/YGbsXx69MtwTVVN3pJ/sCyPDGCW8G6Vtkra7PKrJCHwKpYdEZfMG09iJWRBRaCgSsGKiO Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 06:44:16 -0000 --047d7b3437e452bb0904e008f9ec Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 26, 2013 at 1:30 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > (i) distributing configuration information on a simple dedicated > protocol makes monitoring and trouble-shooting easier; > Actually, it doesn't, because in the "advantages of a routing protocol" section above you forgot to mention one important advantage: fate sharing. If you have one protocol that is distributing all the information in the network, then all the information is either disseminated to a particular device or it isn't, and when it is disseminated, it is disseminated all together. If you have two protocols, then the two sets of information are disseminated asynchronously, and potentially - if there is a problem with one of the two - not at all. As running IPv4 and IPv6 in parallel shows, it's way harder to make two things work than just one, because it's so much harder to figure out if things are working or not. --047d7b3437e452bb0904e008f9ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 26, 2013 at 1:30 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
(i) =A0 distribut= ing configuration information on a simple dedicated
=A0 =A0 =A0 protocol makes monitoring and trouble-shooting easier;

Actually, it doesn't, because in the "= advantages of a routing protocol" section above you forgot to mention = one important advantage: fate sharing.

If you have one protocol that is distributing all the i= nformation in the network, then all the information is either disseminated = to a particular device or it isn't, and when it is disseminated, it is = disseminated all together.

If you have two protocols, then the two sets of informa= tion are disseminated asynchronously, and potentially - if there is a probl= em with one of the two - not at all.

As running IP= v4 and IPv6 in parallel shows, it's way harder to make two things work = than just one, because it's so much harder to figure out if things are = working or not.
--047d7b3437e452bb0904e008f9ec-- From mark@townsley.net Wed Jun 26 01:08:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52B21F9F82 for ; Wed, 26 Jun 2013 01:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMeFnhnR-IEH for ; Wed, 26 Jun 2013 01:08:36 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01511E819E for ; Wed, 26 Jun 2013 01:08:35 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so10077770wgh.31 for ; Wed, 26 Jun 2013 01:08:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=yysDIqz/CslFfHVV0Vd/ZNLuSnUbUJIPcmJ4zECIKW0=; b=MK/MeHNLxaPxvzU9U/PlTKqzhgos6UswqrdAWwhMBI2yKUP8hs8ZNRy0a4zDF+2d0s euapvt1Xu0CBnw6+0IDzIKhUGCd9PuGtKLRj693y+tML7C+SvOK7iDFTA56hvIvps89H sxI+JKsDMu39apRVVaATj0np5X7d5VfjZHTXYxDTzkKiZ0Aqjfj/U4Km69ayWtxb/Y1V I4Ket4Ess/P1XCwq+cOyhNbgPoTgLJIs1aQ5Pqb6DGA9nLQtKB6+KmCJrYwI+OmQkXwR xO++puVQxVsgEXMFfojTUMWBeZ+39l3XPeiHhLs0CoH2bYTbtty2urxxXrfpSODQd4RL RqmQ== X-Received: by 10.180.38.37 with SMTP id d5mr11596372wik.37.1372234114637; Wed, 26 Jun 2013 01:08:34 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id eu1sm9051420wib.8.2013.06.26.01.08.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 01:08:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_04874BE2-EF05-4176-B0F7-ECF7E500E8EA" From: Mark Townsley In-Reply-To: <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> Date: Wed, 26 Jun 2013 10:08:31 +0200 Message-Id: <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnkUS/IQVwiiOAfNtPgp+18RlRGWmKYRj3zYY//MpA9hsWwawsK6qOQtY3saxOqshCQ4WOC Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:08:36 -0000 --Apple-Mail=_04874BE2-EF05-4176-B0F7-ECF7E500E8EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 26, 2013, at 12:03 AM, Juliusz Chroboczek wrote: >> Just a comment ... >> You say " There is an IETF standard configuration protocol, and = that's >> DHCPv6." >=20 >> Actually, the IETF has a number of configuration protocol standards, = not >> just DHCPv6. Not to mention "HC" stands for "Host Configuration" not "Router = Configuration."=20 RFC 2131 is very clear,=20 " DHCP is not intended for use in configuring routers." That explicit statement went away in RFC 3315, though the terminology = section makes it very clear that a Host is not a Router. - Mark >=20 > Point duly taken. >=20 > -- Juliusz > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_04874BE2-EF05-4176-B0F7-ECF7E500E8EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Just a comment = ...
You say " There is an IETF = standard configuration protocol, and that's
DHCPv6."

Actually, the IETF has a number of configuration protocol = standards, not
just = DHCPv6.

Not = to mention "HC" stands for "Host Configuration" not "Router = Configuration." 

RFC 2131 is very = clear, 
"   DHCP is not intended for use in configuring routers."

That explicit statement went away in =
RFC 3315, though the terminology section makes it very clear that a Host =
is not a Router.
- =
Mark



Point duly taken.

-- = Juliusz
_______________________________________________
homenet = mailing list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail=_04874BE2-EF05-4176-B0F7-ECF7E500E8EA-- From swmike@swm.pp.se Wed Jun 26 01:16:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746CA21E8105 for ; Wed, 26 Jun 2013 01:16:52 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6M6tecLLBQN for ; Wed, 26 Jun 2013 01:16:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 153F321E80D7 for ; Wed, 26 Jun 2013 01:16:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AB9D59F; Wed, 26 Jun 2013 10:16:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A66549C; Wed, 26 Jun 2013 10:16:44 +0200 (CEST) Date: Wed, 26 Jun 2013 10:16:44 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:16:53 -0000 On Wed, 26 Jun 2013, Lorenzo Colitti wrote: > If you have two protocols, then the two sets of information are > disseminated asynchronously, and potentially - if there is a problem > with one of the two - not at all. > > As running IPv4 and IPv6 in parallel shows, it's way harder to make two > things work than just one, because it's so much harder to figure out if > things are working or not. I agree with this. As an exmaple there has been great pain with LDP and IGPs in the MPLS space, up to the point where people had to invent mechanisms to hack around stuff so IGP wouldn't start using the link until the other one was done. So if multiple protocols are to be used, great thought has to be put in to make sure the devices know about these mechanisms and can handle situations where one of them doesn't work. I'm sure there are multiple other examples. -- Mikael Abrahamsson email: swmike@swm.pp.se From mike@mtcc.com Wed Jun 26 01:50:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1B11E81A3 for ; Wed, 26 Jun 2013 01:50:41 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUJJm6u8WWwE for ; Wed, 26 Jun 2013 01:50:37 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7F811E81A4 for ; Wed, 26 Jun 2013 01:50:37 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5Q8oaBt018323 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 01:50:36 -0700 Message-ID: <51CAAB5B.5060105@mtcc.com> Date: Wed, 26 Jun 2013 01:50:35 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Mark Townsley References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> In-Reply-To: <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=709; t=1372236636; x=1373100636; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Configuration=20must=20not= 20be=20carried=20by=20the=20routing=20protocol |Sender:=20 |To:=20Mark=20Townsley=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=SU2U5Gb2pCOXl0aHaFx8wgnM4UwVTMi72pviGeGVXsU=; b=X63NmJmBHIf/AjGQfaKfEgHLjM1ZKDH39BnZ0dbAfQsdqCj1DQnMutnUJG xnIeHewaETRYf+KPFmv9/chQGA2uhnIXItU/ajhtRcDI1/VMiP429UvskcQ7 NhZicWbOBzFo50Qo/nsFaSmS8SFWQrq9FIrDXnXba/d00td1dKEh8=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:50:41 -0000 On 06/26/2013 01:08 AM, Mark Townsley wrote: > > > On Jun 26, 2013, at 12:03 AM, Juliusz Chroboczek wrote: > >>> Just a comment ... >>> You say " There is an IETF standard configuration protocol, and that's >>> DHCPv6." >> >>> Actually, the IETF has a number of configuration protocol standards, not >>> just DHCPv6. > > Not to mention "HC" stands for "Host Configuration" not "Router Configuration." > > RFC 2131 is very clear, > " DHCP is not intended for use in configuring routers." > That explicit statement went away in RFC 3315, though the terminology section makes it very clear that a Host is not a Router. > The implication being that dhcp prefix delegation is bogus? Mike From teco@inf-net.nl Wed Jun 26 03:19:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7511E81AF for ; Wed, 26 Jun 2013 03:19:49 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYQMVbVzBkHQ for ; Wed, 26 Jun 2013 03:19:48 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id CF70D11E80D2 for ; Wed, 26 Jun 2013 03:19:46 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id b57so7306765eek.22 for ; Wed, 26 Jun 2013 03:19:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=BDtzSuvEy+t5Qct5b2MrHoI6b6/R/ANYPkk3Gn5gu9Q=; b=IHDyN9shCZcVH0F18Kx8GKRU4bh+NukVW835OIXFDXm1+Wh11vUunpd5AoyF4MF7Dh UkCykCeZUiMafNF0qCJp5gEB23zWjj36OwAVz7GE0tRNE229DNhqJR3kALFYRsS5H74H 6yEr7KFQhqisK6DIkNKImWjk11NBrCs0XUXloEQozl56fJsjsn7tMKbqdv1fDrXZ+/Th /Vkf9YVZWoAl9ly5l/ZlC5W2kHlMY3Q3mWJMaym99K8I2YCWQS+AXv3C03dduHKmb1gh oKvxw3IqFyHIV5IxjdZVfXSGRoVHRrmaKXxl3rvFyX2U8l6B9vwKtgTypVZTUfVRFOlI Y1Zw== X-Received: by 10.14.95.69 with SMTP id o45mr3416350eef.48.1372241986103; Wed, 26 Jun 2013 03:19:46 -0700 (PDT) Received: from [172.16.4.22] ([188.205.88.52]) by mx.google.com with ESMTPSA id b3sm41915364eev.10.2013.06.26.03.19.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 03:19:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> Date: Wed, 26 Jun 2013 12:19:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkfM/TG6MZR+8B33/iAiYYtj0W4cVKC7i5r2mXZXSRzRG3XVv3w6PJB7+IYTvtk3LPaLGlD Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:19:49 -0000 Op 26 jun. 2013, om 10:08 heeft Mark Townsley het = volgende geschreven: > On Jun 26, 2013, at 12:03 AM, Juliusz Chroboczek wrote: >=20 >>> Just a comment ... >>> You say " There is an IETF standard configuration protocol, and = that's >>> DHCPv6." >>=20 >>> Actually, the IETF has a number of configuration protocol standards, = not >>> just DHCPv6. >=20 > Not to mention "HC" stands for "Host Configuration" not "Router = Configuration."=20 >=20 > RFC 2131 is very clear,=20 > " DHCP is not intended for use in configuring routers." >=20 > That explicit statement went away in RFC 3315, though the terminology = section makes it very clear that a Host is not a Router. I guess you don't intend to turn off Internet access for many because = DHCP is not for routers. Teco PS: Mail delivered via IPv4, via interfaces on multiple routers with = DHCP client enabled. From teco@inf-net.nl Wed Jun 26 03:34:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAB821E8138 for ; Wed, 26 Jun 2013 03:34:58 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ineSzXKp69Wa for ; Wed, 26 Jun 2013 03:34:58 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2C62E21E8137 for ; Wed, 26 Jun 2013 03:34:56 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c41so7415438eek.12 for ; Wed, 26 Jun 2013 03:34:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=p1sSENh1XR9oCamyujTyFDQTBPbWLVNMe0BMfkkfmaE=; b=HFx7/a0yDUVFvjUgl7SpUvvRScQ8ceN6WMMitY9hrbphNMZpFDyyue06AKAxcwL01w xdu41gcy5Indsl6BKk8swBvIOJxZoXTwR1z3Cs5yh5dq+n8a7RgyfyCaDsd63hPgE6Bz /v/aTAxMFMIVX70NLq+h8IJVhE73hzLPxTUeFWAbuL3DZznLHSF4fZZ2jF0yAO9OeSRz pCz7YX2GPqM3zbUWsBGjF9wi0wmggbG229Jd3YCOBWQQshV2I3bfri0SKUdYbcsNpQKf ZDaFC6UpYK5+9lHCJisi+71QEi6FU1bvOqInQR3KY82ipTFK7bxY/NBWHCVzBDLGnPcf vBHQ== X-Received: by 10.14.1.70 with SMTP id 46mr3417100eec.82.1372242894362; Wed, 26 Jun 2013 03:34:54 -0700 (PDT) Received: from [172.16.4.22] ([188.205.88.52]) by mx.google.com with ESMTPSA id b7sm42044816eef.16.2013.06.26.03.34.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 03:34:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> Date: Wed, 26 Jun 2013 12:34:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmWbIQZwCgzNCLRRnm2Bre5CWJga37EuTPEvAVCiyqM1bKW096dn7XqFJ/5rDWmHXbraVGq Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:34:58 -0000 Op 25 jun. 2013, om 18:30 heeft Juliusz Chroboczek = het volgende geschreven: >=20 > 3. Possible configuration protocols >=20 > 3.1 RA >=20 > RAs are ignored by routers, and rightly so -- RAs have no loop > avoidance mechanism, and using RAs to configure routers leads to > a number of problems that I believe to be unsolvable. Extending the > RA protocol to be suitable for configuring routers is probably not > worth the hassle, and will lead to confusion. RA's are used for address auto configuration, also for routers. Using RA's has an important advantage: new options can be added easily. = This sets up a signaling channel to all nodes. Non-upgraded hosts shall = ignore the new options. Upgraded hosts (like MPTCP) need such info. I'm = not a great fan on implementing a large set of flavors of routing = protocols on hosts. Hosts are not homenet-only, that is why I highly = prefer a single solution that works on many types of networks. RA packet is single hop. Info in RA comes from other places, could be = manually configured, could be from remote. There are many proposals = adding some kind of hop-by-hop RA option. Loop-free dissemination is not = an issue. So I have to disagree here, RA is a viable option. Teco= From mellon@fugue.com Wed Jun 26 06:53:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900D621E80E3 for ; Wed, 26 Jun 2013 06:53:26 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Pa6zx1ljzsw for ; Wed, 26 Jun 2013 06:53:18 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9D43521F9C0F for ; Wed, 26 Jun 2013 06:52:43 -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 E00A72381D5F; Wed, 26 Jun 2013 09:52:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> Date: Wed, 26 Jun 2013 09:52:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:53:41 -0000 On Jun 26, 2013, at 4:08 AM, Mark Townsley wrote: > That explicit statement went away in RFC 3315, though the terminology = section makes it very clear that a Host is not a Router. DHCPv6 PD is explicitly for configuring routers, so I think this = assertion is wrong. I think Lorenzo's argument is a better one. From hrogge@googlemail.com Wed Jun 26 07:43:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF8911E81C0 for ; Wed, 26 Jun 2013 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITyUO6GWpcvg for ; Wed, 26 Jun 2013 07:43:15 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3121E811E for ; Wed, 26 Jun 2013 07:43:08 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so8278754qcz.14 for ; Wed, 26 Jun 2013 07:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5sOd8pWGzllmKRxaFy/bDxcP/R64Nf5XyBTgEuuKQPk=; b=gv3TRaYVqpSKyJeZ7jeCOvOKvi9o5hmUGibiFtOWIKpJ8BZARAadXzpE+3oz/UPZnz w06ZnRxihXTfIC8+xcd4MiucrTSeWCm2KKJKgg3qijHXum8Fwsuq9U25GwzrQLEqUdVI /Hc+k1R7ei1EqJrQrwKj5ghOQk78/W7tFBeugUYWEB/p5xC7yz3CXedQqNV1cmsC7yEF 3xP9xMnpmmrEmJX5W2AGT9tQTc/ID4j7MqYSNbsVSXbUP+67cjnJ1eimOzmNILuHx3Q3 DCPnnA/JKQ0rbDu4MotvFQU/qZR5Evc2Gw9/8qAN3piRU5IUCIy5ub+jvE7dxhaBI7L5 QQcw== X-Received: by 10.49.41.41 with SMTP id c9mr5024426qel.19.1372257786585; Wed, 26 Jun 2013 07:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.82 with HTTP; Wed, 26 Jun 2013 07:42:46 -0700 (PDT) In-Reply-To: <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> From: Henning Rogge Date: Wed, 26 Jun 2013 16:42:46 +0200 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org Group" , Mark Townsley , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 14:43:15 -0000 On Wed, Jun 26, 2013 at 3:52 PM, Ted Lemon wrote: > On Jun 26, 2013, at 4:08 AM, Mark Townsley wrote: > DHCPv6 PD is explicitly for configuring routers, so I think this assertion is wrong. I think Lorenzo's argument is a better one. The routing protocol should be able to draw most (maybe all?) settings from watching the interface addresses of the local router and maybe a special local routing table. This should allow to minimize synchronization problems. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From mark@townsley.net Wed Jun 26 10:42:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150D821F9DBB for ; Wed, 26 Jun 2013 10:42:14 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeZUklXoIkYu for ; Wed, 26 Jun 2013 10:42:13 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5903721F9D07 for ; Wed, 26 Jun 2013 10:42:13 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so10657630wgh.27 for ; Wed, 26 Jun 2013 10:42:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=XiKnKIXk5S/JUaO1iGJHWM6f4vpxKH+3J7Pgbpq0lSw=; b=b9iWddhi359FxfRwlvOpEB9lJTDTL93i8r4BBeAR60096+u3d5jNWNGFAJlhM/JYDS F3yKVDqRjtjICGqR8/FvKfsE7Bd5upteGeUnTyS4CXMSYhsTy7GaDg6CDFGel7oqaB9/ kcGgJ9L1dIckWurfqil9VbE//0VCpwIxAMHmWi4uxXJ/aW7TOAJcVGi4yb4Id3f+aYBN 3SIcUJAq2DkOlZ+bUcvVYb6sj0sa0on9MchiNE7QbbweoFKplQnxEZjTfpHlUrxzZ0sh 1+DCxZPlAtqZOD4nvTz9OZm+JTYPuBKA18+fnjgrcepeODbf4XJBtH4MT7YT36rMlqsw 6zPg== X-Received: by 10.194.243.226 with SMTP id xb2mr3643833wjc.67.1372268532428; Wed, 26 Jun 2013 10:42:12 -0700 (PDT) Received: from ?IPv6:2001:420:44f0:1004:90c:ea8e:a056:5036? ([2001:420:44f0:1004:90c:ea8e:a056:5036]) by mx.google.com with ESMTPSA id w4sm12254124wia.9.2013.06.26.10.42.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 10:42:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> Date: Wed, 26 Jun 2013 19:42:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmeX8UpcGxdtSbbjrjvPs84yoyWnH/Q8KVnjCFe6PA6tzcaDKW4MHbV66SORnj/CxZdkVgZ Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:42:14 -0000 On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote: > On Jun 26, 2013, at 4:08 AM, Mark Townsley wrote: >> That explicit statement went away in RFC 3315, though the terminology = section makes it very clear that a Host is not a Router. >=20 > DHCPv6 PD is explicitly for configuring routers, so I think this = assertion is wrong. =20 This was linked back to the assertion that "the IETF has a configuration = protocol, it is DHCP" or some such. I was simply trying to point out = what "the IETF" has on record in this regard. Certainly, we often use protocols beyond their original intent. RFC 5218 = calls this "Wild Success", with plenty of examples.=20 DHCPv6 PD has been referred to by one of its co-authors as "a Fax = replacement", so that the user doesn't have to type in his prefix sent = to him in printed form from his ISP. I think that analogy was given to = sway anyone away from trying to rely on it for more than a very = long-lived, essentially static, value from an ISP.=20 > I think Lorenzo's argument is a better one. Agreed. - Mark From mike@mtcc.com Wed Jun 26 10:47:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C5021F9F05 for ; Wed, 26 Jun 2013 10:47:01 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXm9jWi5g4Gb for ; Wed, 26 Jun 2013 10:46:56 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D45D621F9E82 for ; Wed, 26 Jun 2013 10:46:56 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5QHkrXx002916 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 10:46:54 -0700 Message-ID: <51CB290D.6000100@mtcc.com> Date: Wed, 26 Jun 2013 10:46:53 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Mark Townsley References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> In-Reply-To: <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1180; t=1372268814; x=1373132814; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Configuration=20must=20not= 20be=20carried=20by=20the=20routing=20protocol |Sender:=20 |To:=20Mark=20Townsley=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=IO3XOyBHI4tePfJpIfWzEipzIwvyz7Xqx6DN+Uw+mhE=; b=bYxvbie+S82aLL93re6gp1Ikbh2RbkkpHWaYeHUeESEktXfIBbUweHE1yX chngiWJyGduRVNXqlcBEgIFZp0FRYn3a9veUqFhN2Ogzt0qVqHzJBjUzMG4z sDY1N8Pft8fL5n3IB9z26PoR6BdDANv/NYneysJ72XVSJwpnG3/dQ=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" , Ted Lemon , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:47:01 -0000 On 06/26/2013 10:42 AM, Mark Townsley wrote: > On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote: > >> On Jun 26, 2013, at 4:08 AM, Mark Townsley wrote: >>> That explicit statement went away in RFC 3315, though the terminology section makes it very clear that a Host is not a Router. >> DHCPv6 PD is explicitly for configuring routers, so I think this assertion is wrong. > This was linked back to the assertion that "the IETF has a configuration protocol, it is DHCP" or some such. I was simply trying to point out what "the IETF" has on record in this regard. > > Certainly, we often use protocols beyond their original intent. RFC 5218 calls this "Wild Success", with plenty of examples. > > DHCPv6 PD has been referred to by one of its co-authors as "a Fax replacement", so that the user doesn't have to type in his prefix sent to him in printed form from his ISP. I think that analogy was given to sway anyone away from trying to rely on it for more than a very long-lived, essentially static, value from an ISP. > Isn't a Somebody's-Law that states that "every successful protocol will become a transport protocol for something else"? Mike From mellon@fugue.com Wed Jun 26 11:05:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F63111E81CF for ; Wed, 26 Jun 2013 11:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiEKMyzYdJ-Q for ; Wed, 26 Jun 2013 11:05:43 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4954F11E8115 for ; Wed, 26 Jun 2013 11:05:43 -0700 (PDT) Received: from [IPv6:2001:470:88a3::e9b5:193b:216d:267d] (unknown [IPv6:2001:470:88a3:0:e9b5:193b:216d:267d]) by toccata.fugue.com (Postfix) with ESMTPSA id A33B72381D5F; Wed, 26 Jun 2013 14:05:41 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Lemon In-Reply-To: <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> Date: Wed, 26 Jun 2013 14:05:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:05:48 -0000 On Jun 26, 2013, at 1:42 PM, Mark Townsley wrote: > DHCPv6 PD has been referred to by one of its co-authors as "a Fax = replacement", so that the user doesn't have to type in his prefix sent = to him in printed form from his ISP. I think that analogy was given to = sway anyone away from trying to rely on it for more than a very = long-lived, essentially static, value from an ISP.=20 I find this sort of report remarkably unhelpful in making design = decisions. Like all IETF consensus documents, the DHCPv6-PD document = is a product of the working group and, ultimately, the IETF. An = opinion expressed by one author at one time during the development of = the document provides us with little guidance as to how to interpret the = document in the present. What's in the document should stand on its = own. Certainly current use cases treat DHCPv6-PD as dynamic, not = static, for varying values of dynamic right up to "forced renumbering = every day." I also find statements like "the IETF has a configuration protocol, it = is DHCP" to be unhelpful, because it's even less grounded in any = consensus process. But let's not fight fire with fire=97I think most = people reading this statement would have the same reaction to it that we = do. Certainly, a working group chair who used a statement like this as = part of a consensus determination would be making a grievous error! From daveoran@orandom.net Wed Jun 26 11:23:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EC421F9F6B for ; Wed, 26 Jun 2013 11:23:27 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9en3cTdO4FiD for ; Wed, 26 Jun 2013 11:23:27 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) by ietfa.amsl.com (Postfix) with ESMTP id 0751A21F9C06 for ; Wed, 26 Jun 2013 11:23:26 -0700 (PDT) Received: from [10.86.114.155] (198-135-0-233.cisco.com [198.135.0.233]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r5QINDMw023012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Jun 2013 11:23:15 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1780.1\)) From: David R Oran In-Reply-To: <51CB290D.6000100@mtcc.com> Date: Wed, 26 Jun 2013 14:22:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F300BF6-6F42-415E-B422-08A0F71E7B96@orandom.net> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> <51CB290D.6000100@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1780.1) Cc: Ted Lemon , "homenet@ietf.org Group" , Mark Townsley , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:23:27 -0000 On Jun 26, 2013, at 1:46 PM, Michael Thomas wrote: > On 06/26/2013 10:42 AM, Mark Townsley wrote: >> On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote: >>=20 >>> On Jun 26, 2013, at 4:08 AM, Mark Townsley = wrote: >>>> That explicit statement went away in RFC 3315, though the = terminology section makes it very clear that a Host is not a Router. >>> DHCPv6 PD is explicitly for configuring routers, so I think this = assertion is wrong. >> This was linked back to the assertion that "the IETF has a = configuration protocol, it is DHCP" or some such. I was simply trying to = point out what "the IETF" has on record in this regard. >>=20 >> Certainly, we often use protocols beyond their original intent. RFC = 5218 calls this "Wild Success", with plenty of examples. >>=20 >> DHCPv6 PD has been referred to by one of its co-authors as "a Fax = replacement", so that the user doesn't have to type in his prefix sent = to him in printed form from his ISP. I think that analogy was given to = sway anyone away from trying to rely on it for more than a very = long-lived, essentially static, value from an ISP. >>=20 >=20 > Isn't a Somebody's-Law that states that "every successful protocol = will become a > transport protocol for something else=94?Yup. I claim >=20 Yup - I claim to have coined that one. DaveO. > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Wed Jun 26 11:24:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E131C11E8117 for ; Wed, 26 Jun 2013 11:24:42 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om3gX9BlceFF for ; Wed, 26 Jun 2013 11:24:38 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7142121F9EF5 for ; Wed, 26 Jun 2013 11:24:38 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5QIOaet015734 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 11:24:37 -0700 Message-ID: <51CB31E4.8080504@mtcc.com> Date: Wed, 26 Jun 2013 11:24:36 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: David R Oran References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> <51CB290D.6000100@mtcc.com> <9F300BF6-6F42-415E-B422-08A0F71E7B96@orandom.net> In-Reply-To: <9F300BF6-6F42-415E-B422-08A0F71E7B96@orandom.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1438; t=1372271077; x=1373135077; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Configuration=20must=20not= 20be=20carried=20by=20the=20routing=20protocol |Sender:=20 |To:=20David=20R=20Oran=20 |Content-Type:=20text/plain=3B=20charset=3Dwindows-1252=3B= 20format=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=cF1PzXj9NgS3nC7cvCJRY9zs2SNhKlPOiQYUWHgttqg=; b=cAQlgTG/Y46ia0b6PyAXTGGPhULVYYTF79/NxAr15rv+mkDKIEReayMhqy uNuHyuw6SDrkxNXLX4QCvEgwB1YIIRnX2fvWZqUYnsG3wnpo9Bkx8eA/6Nd5 uJTe3RKij50jGY+p+/JcU2MCIXaQ8o+JLqwKT72tpZag4DP9g21eQ=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ted Lemon , "homenet@ietf.org Group" , Mark Townsley , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:24:43 -0000 On 06/26/2013 11:22 AM, David R Oran wrote: > On Jun 26, 2013, at 1:46 PM, Michael Thomas wrote: > >> On 06/26/2013 10:42 AM, Mark Townsley wrote: >>> On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote: >>> >>>> On Jun 26, 2013, at 4:08 AM, Mark Townsley wrote: >>>>> That explicit statement went away in RFC 3315, though the terminology section makes it very clear that a Host is not a Router. >>>> DHCPv6 PD is explicitly for configuring routers, so I think this assertion is wrong. >>> This was linked back to the assertion that "the IETF has a configuration protocol, it is DHCP" or some such. I was simply trying to point out what "the IETF" has on record in this regard. >>> >>> Certainly, we often use protocols beyond their original intent. RFC 5218 calls this "Wild Success", with plenty of examples. >>> >>> DHCPv6 PD has been referred to by one of its co-authors as "a Fax replacement", so that the user doesn't have to type in his prefix sent to him in printed form from his ISP. I think that analogy was given to sway anyone away from trying to rely on it for more than a very long-lived, essentially static, value from an ISP. >>> >> Isn't a Somebody's-Law that states that "every successful protocol will become a >> transport protocol for something else”?Yup. I claim >> > Yup - I claim to have coined that one. > Heh -- I definitely heard it from you first :) Mike From otroan@employees.org Wed Jun 26 12:13:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5330211E812D for ; Wed, 26 Jun 2013 12:13:46 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD0ZdGY+1bkc for ; Wed, 26 Jun 2013 12:13:45 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id F234411E812B for ; Wed, 26 Jun 2013 12:13:44 -0700 (PDT) Received: from dhcp-10-61-101-10.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id EBA475E5C; Wed, 26 Jun 2013 12:13:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> Date: Wed, 26 Jun 2013 15:13:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E223B9A-F615-4E46-971C-84A3117AA27A@employees.org> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 19:13:46 -0000 what do we need for distributing configuration information between = routers? a distributed database. what's a routing protocol? a distributed database. do we need to invent a separate distributed database for each class of = information? cheers, Ole On Jun 25, 2013, at 12:30 , Juliusz Chroboczek = wrote: > Dear editors, dear group, >=20 > After the recent thread on this list, and a number of private mail > exchanges, I'm under the impression that there might be a consensus > that configuration information should not be carried over the routing > protocol. In this mail, I argue that >=20 > configuration information should be carried by a protocol separate > from the routing protocol. >=20 > We should therefore make serious efforts to ensure that nothing in the > arch documents prevents carrying configuration information in > a separate protocol. Ideally, we should include language in the arch > document that encourages such a separate implementation, but I'm not > sure if we can build consensus at this point. >=20 > This mail is structured as follows: >=20 > 1. advantages of carrying configuration information over the routing = protocol; > 2. advantages of carrying configuration information over a separate = protocol; > 3. possible configuration protocols; > 4. conclusions. >=20 >=20 > 1. Advantages of carrying configuration information over the routing > protocol >=20 > I've heard the following advantages claimed for conflating the two = functions: >=20 > (i) it is not necessary to implement a new flooding protocol, which > saves space on resource-limited routers; > (ii) all routers participate in the routing protocol, while a new > configuration protocol requires ensuring that all routers forward > the configuration information. >=20 > As I've shown with AHCP[1,2], however, a reasonably efficient, purely > user-space, increasing diameter flooding protocol can be implemented > in a hundred lines of C code or so, and takes just a few kB of flash > and a few bytes of memory; this is why I find point (i) above > unconvincing. Additionally, since homenet is planning to mandate the > implementation of a new routing protocol on all home routers, = mandating > a configuration forwarding daemon does not break compatibility any = further. >=20 >=20 > 2. Advantages of separating configuration from routing >=20 > There are significant advantages to distributing configuration > information over a separate protocol. >=20 > (i) distributing configuration information on a simple dedicated > protocol makes monitoring and trouble-shooting easier; > (ii) the architecture is more robust -- issues with the routing = protocol > do not prevent configuration information from being distributed; > (iii) should new requirements arise, it is possible to reuse most of = the > homenet architecture with a new routing protocol; > (iv) should new requireent arise, it is possible to reuse most of the > homenet architecture while running multiple routing protocols. >=20 > Point (i) is important -- experience with DHCPv4 and RA shows how easy > it is to run into issues with configuration protocols, and how useful > it is to be able to identify and decode configuration packets without > having a full understanding of a complex routing protocol. >=20 > Point (ii) is probably of secondary interest, since all implemen- > tations of link-state protocols are perfectly robust and completely > debugged. However, we all know the pain of recovering a router that > has lost its IP addresses, anything that avoids such pain should be > welcome. >=20 > Points (iii) and (iv) are very important to me. I firmly believe that > once homenet starts being deployed, smart amateurs are going to start > building topologies that we don't even dream of, using link > technologies that we never heard of. Most probably, the homenet > routing protocol can then be extended to deal with the new topologies; > but before this happens it will be important that people can reuse the > homenet architecture with a different protocol. Hence, it is vitally > important that the homenet architecture be modular enough to allow > switching routing protocols. >=20 >=20 > 3. Possible configuration protocols >=20 > 3.1 RA >=20 > RAs are ignored by routers, and rightly so -- RAs have no loop > avoidance mechanism, and using RAs to configure routers leads to > a number of problems that I believe to be unsolvable. Extending the > RA protocol to be suitable for configuring routers is probably not > worth the hassle, and will lead to confusion. >=20 > 3.2 DHCPv6 >=20 > There is an IETF standard configuration protocol, and that's DHCPv6. > Other people on this list are more knowledgeable about DHCPv6, so I'll > refrain from making a fool of myself; however, I'll take the risk of > claiming that DHCPv6 (probably with extensions) looks like an > eminently suitable protocol for configuring homenet routers. >=20 > 3.3 A new protocol >=20 > In the Babel experiment, I have designed a new protocol, which > I called AHCP[1,2]. Since AHCP is designed to run before routing is > functional, it makes minimal assumptions about the network -- it only > requires each interface to have a link-local IPv6 address and to be > able to participate in link-local multicast traffic. An AHCP client > implements an increasing diameter search for an AHCP server. >=20 > The full AHCP implementation (client+server+forwarder, with support > for Linux and BSD Unix), consists of 3500 lines of C and 350 lines of > bourne shell code, and compiles to less than 40 kB. Subset implemen- > tations are possible. We have found AHCP to be very robust and > reasonably fast even in the presence of massive packet loss. The > traffic generated is very reasonable, even when simultaneously > rebooting the whole network. >=20 > I am not pushing AHCP as the homenet configuration protocol, since > I have good hope that a variant of DHCPv6 can be used. However, I do > hope that the results of the AHCP experiment can serve as useful input > for this group. >=20 >=20 > 4. Conclusions >=20 > For the reasons outlined above, it is my firm opinion that = configuration > information should not be carried by the Homenet routing protocol. = Homenet > routers should either be configured by a variant of DHCPv6, or a new > protocol should be designed. >=20 > The arch document should be carefully reviewed, and anything that > risks impeding such a solution must be eliminated. Ideally, the arch > document should encourage separating configuration distribution from > routing. >=20 > Should DHCPv6 be finally chosen, I will be glad to collaborate on = writing > a tiny DHCPv6 daemon suitable for homenet. (And I have a fair amount > of experience with writing tiny network daemons to run on 8MB = routers.) >=20 >=20 > [1] http://tools.ietf.org/html/draft-chroboczek-ahcp > [2] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/ > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From gettysjim@gmail.com Wed Jun 26 12:15:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE1711E8138 for ; Wed, 26 Jun 2013 12:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPGFw2-D7mtx for ; Wed, 26 Jun 2013 12:15:26 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 32A9811E812B for ; Wed, 26 Jun 2013 12:15:26 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so13925092obc.31 for ; Wed, 26 Jun 2013 12:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kyzzmVYkhHGHn1Or67IRoyeu9OveEYKK1uRG7IgxjNw=; b=PsTGvWDc0IceN6Iy05ZJHp7nUYE8h7UReUT99mKswchlDKInnnn+jY/7R8w+Lk4WBi aYxsx5Ij+VJjx5xRuPTGrZdfYLT6ILQEfNJ+PxDygI+q/gwQWGSDVTd/eCgqYvv+O8yy qjdYgdvOxCFTb0Jf58WXGCEIx8LDJD15NctW8SJMo+HGFMosXMcHufBGxXDZq7b139P5 tHzy1fRKoocIyzMzl5EIY/iuHsFCe6RMMLZ3ALm5qsIdeT793xeqJrTiox3iE51YVq1k DohtddVGCKP+fYB0guIGQTcBgWVQaT+nGUdfzebXabdxC8XID2K7zYyuwIDDxrJ1zC4y FmxA== MIME-Version: 1.0 X-Received: by 10.60.37.233 with SMTP id b9mr1161059oek.61.1372274124675; Wed, 26 Jun 2013 12:15:24 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.144.67 with HTTP; Wed, 26 Jun 2013 12:15:24 -0700 (PDT) In-Reply-To: <51CB31E4.8080504@mtcc.com> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <020301ce71e1$da38d120$8eaa7360$@comcast.net> <87wqphonkv.wl%jch@pps.univ-paris-diderot.fr> <1A4D24AC-445C-422A-B2C8-D9C307347BA0@townsley.net> <31A37EFD-C5E5-4D6E-81C2-301EC64CD58B@fugue.com> <93311FD2-507C-4415-9CBC-9D5671F91405@townsley.net> <51CB290D.6000100@mtcc.com> <9F300BF6-6F42-415E-B422-08A0F71E7B96@orandom.net> <51CB31E4.8080504@mtcc.com> Date: Wed, 26 Jun 2013 15:15:24 -0400 X-Google-Sender-Auth: poJ13AGRrxJqlU6TPt5CGeKKfOQ Message-ID: From: Jim Gettys To: Michael Thomas Content-Type: multipart/alternative; boundary=089e013c6a70bc618204e01377a7 Cc: Mark Townsley , "homenet@ietf.org Group" , Ted Lemon , David R Oran , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 19:15:27 -0000 --089e013c6a70bc618204e01377a7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jun 26, 2013 at 2:24 PM, Michael Thomas wrote: > On 06/26/2013 11:22 AM, David R Oran wrote: > >> On Jun 26, 2013, at 1:46 PM, Michael Thomas wrote: >> >> On 06/26/2013 10:42 AM, Mark Townsley wrote: >>> >>>> On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote: >>>> >>>> On Jun 26, 2013, at 4:08 AM, Mark Townsley wrote: >>>>> >>>>>> That explicit statement went away in RFC 3315, though the terminolog= y >>>>>> section makes it very clear that a Host is not a Router. >>>>>> >>>>> DHCPv6 PD is explicitly for configuring routers, so I think this >>>>> assertion is wrong. >>>>> >>>> This was linked back to the assertion that "the IETF has a >>>> configuration protocol, it is DHCP" or some such. I was simply trying = to >>>> point out what "the IETF" has on record in this regard. >>>> >>>> Certainly, we often use protocols beyond their original intent. RFC >>>> 5218 calls this "Wild Success", with plenty of examples. >>>> >>>> DHCPv6 PD has been referred to by one of its co-authors as "a Fax >>>> replacement", so that the user doesn't have to type in his prefix sent= to >>>> him in printed form from his ISP. I think that analogy was given to sw= ay >>>> anyone away from trying to rely on it for more than a very long-lived, >>>> essentially static, value from an ISP. >>>> >>>> Isn't a Somebody's-Law that states that "every successful protocol >>> will become a >>> transport protocol for something else=94?Yup. I claim >>> >>> Yup - I claim to have coined that one. >> >> > Heh -- I definitely heard it from you first :) > > > And it's soooo true, though I managed to discourage using X protocol as an RPC framework, back in the day. Unfortunately, no success with HTTP :-(. - Jim --089e013c6a70bc618204e01377a7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Wed= , Jun 26, 2013 at 2:24 PM, Michael Thomas <mike@mtcc.com> wrote:=
On 06/26/2013 11:22 AM, Da= vid R Oran wrote:
On Jun 26, 2013, at 1:46 PM, Michael Thomas <mike@mtcc.com> wrote:

On 06/26/2013 10:42 AM, Mark Townsley wrote:
On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote:

On Jun 26, 2013, at 4:08 AM, Mark Townsley <mark@townsley.net> wrote:
That explicit statement went away in RFC 3315, though the terminology secti= on makes it very clear that a Host is not a Router.
DHCPv6 PD is explicitly for configuring routers, so I think this assertion = is wrong.
This was linked back to the assertion that "the IETF has a configurati= on protocol, it is DHCP" or some such. I was simply trying to point ou= t what "the IETF" has on record in this regard.

Certainly, we often use protocols beyond their original intent. RFC 5218 ca= lls this "Wild Success", with plenty of examples.

DHCPv6 PD has been referred to by one of its co-authors as "a Fax repl= acement", so that the user doesn't have to type in his prefix sent= to him in printed form from his ISP. I think that analogy was given to swa= y anyone away from trying to rely on it for more than a very long-lived, es= sentially static, value from an ISP.

Isn't a Somebody's-Law that states that "every successful prot= ocol will become a
transport protocol for something else=94?Yup. I claim

Yup - I claim to have coined that one.


Heh -- I definitely heard it from you first :)



And it's soooo true, though I managed to discou= rage using X protocol as an RPC framework, back in the day.

Unfortunat= ely, no success with HTTP :-(.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0- Jim
--089e013c6a70bc618204e01377a7-- From jch@pps.univ-paris-diderot.fr Wed Jun 26 15:15:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3740621F9B2D for ; Wed, 26 Jun 2013 15:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt3bbeCo6SaY for ; Wed, 26 Jun 2013 15:15:46 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 2232F21F9B1C for ; Wed, 26 Jun 2013 15:15:45 -0700 (PDT) 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/38117) with ESMTP id r5QMFdp0007977; Thu, 27 Jun 2013 00:15:39 +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 895BE4F11E; Thu, 27 Jun 2013 00:15:39 +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 Xhzc_qbwySZQ; Thu, 27 Jun 2013 00:15:38 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5972B4F11F; Thu, 27 Jun 2013 00:15:38 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Ury03-0001LT-Un; Thu, 27 Jun 2013 00:15:39 +0200 Date: Thu, 27 Jun 2013 00:15:39 +0200 Message-ID: <87ehbobjsk.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Jun 2013 00:15:41 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 22:15:52 -0000 > in the "advantages of a routing protocol" section above you forgot > to mention one important advantage: fate sharing. Agreed. That is a thought-provoking argument indeed. -- Juliusz From jch@pps.univ-paris-diderot.fr Wed Jun 26 15:37:34 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B4E11E8111 for ; Wed, 26 Jun 2013 15:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+ca0DSUoF6p for ; Wed, 26 Jun 2013 15:37:23 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id F19E221F9433 for ; Wed, 26 Jun 2013 15:37:22 -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/38117) with ESMTP id r5QMbK6X027846; Thu, 27 Jun 2013 00:37:20 +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 CBE614F11E; Thu, 27 Jun 2013 00:37:20 +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 62Mh07RNUvyI; Thu, 27 Jun 2013 00:37:19 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B993F4F11C; Thu, 27 Jun 2013 00:37:19 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UryL3-0001aN-EO; Thu, 27 Jun 2013 00:37:21 +0200 Date: Thu, 27 Jun 2013 00:37:21 +0200 Message-ID: <87bo6sbise.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Michael Richardson In-Reply-To: <19181.1372193749@sandelman.ca> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <31616.1372183404@sandelman.ca> <19181.1372193749@sandelman.ca> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 27 Jun 2013 00:37:21 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 22:37:34 -0000 >> However a profusion of protocols exist, and having in a configuration >> protocol the ability to announce and/or select a routing protocol >> would be the most flexible. > I don't want this. > Then we get into MUST implement routing protocols, and SHOULD implement > routing protocols, etc... We define The One Homenet routing protocol. Full stop. We don't want any options in Homenet (RFC 1869, page 2), we want a clean protocol stack that guarantees interoperability. However, this should not prevent us from designing it as a modular collection of protocols (using already-deployed protocols whenever possible) rather than throwing everything including the kitchen sink into one monstruous protocol that nobody is ever able to reimplement from scratch. > I am claiming that the decision, "can we trust this configuration > information" may be linked to "what route this this configuration > information arrive". I don't buy this. Actually, I don't buy any claims about security that don't include a clearly defined threat model and don't show how the proposed policy applies to the threat model. -- Juliusz From jch@pps.univ-paris-diderot.fr Wed Jun 26 15:56:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1E521F99A8 for ; Wed, 26 Jun 2013 15:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LKsR2auVdkL for ; Wed, 26 Jun 2013 15:56:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id D339E11E8112 for ; Wed, 26 Jun 2013 15:56:08 -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/38117) with ESMTP id r5QMu2Im002580; Thu, 27 Jun 2013 00:56:03 +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 DC3A94F120; Thu, 27 Jun 2013 00:56: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 eC4CW_wpy6Tv; Thu, 27 Jun 2013 00:56:01 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C880D4F11C; Thu, 27 Jun 2013 00:56:01 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Uryd9-0001ag-GA; Thu, 27 Jun 2013 00:56:03 +0200 Date: Thu, 27 Jun 2013 00:56:03 +0200 Message-ID: <87a9mcbhx8.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ole Troan In-Reply-To: <0E223B9A-F615-4E46-971C-84A3117AA27A@employees.org> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <0E223B9A-F615-4E46-971C-84A3117AA27A@employees.org> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 27 Jun 2013 00:56:04 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 22:56:15 -0000 > what's a routing protocol? > a distributed database. No, it isn't. A link state protocol implements a replicated -- not distributed -- database within each area. (All of the local link-state databases must be exactly identical, or else all hell breaks loose.) In a distance vector protocol, the set of RIBs of all the routers is nothing like a database -- every router has a different vision of the network, since each router has potentially selected different routes. The only thing that's roughly synchronised is the set of reachable prefixes, and even that is not fully replicated in the presence of filtering or aggregation. > do we need to invent a separate distributed database for each class > of information? Yes, because different kinds of information have different requirements. There is information that needs to be reliably synchronised in a timely manner (the link-state DB), there is information that must be distributed in a timely manner but need not be synchronised throughout the network (configuration information), there is global information that is too large to be distributed except on demand (DNS), there is local information that is not distributed except on demand (mDNS), and probably many other kinds that I'm missing. -- Juliusz From mike@mtcc.com Wed Jun 26 16:11:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDF411E8142 for ; Wed, 26 Jun 2013 16:11:00 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2c-jdC1cvgk for ; Wed, 26 Jun 2013 16:10:55 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 9517911E8111 for ; Wed, 26 Jun 2013 16:10:54 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r5QNArvm014879 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 16:10:54 -0700 Message-ID: <51CB74FD.1030801@mtcc.com> Date: Wed, 26 Jun 2013 16:10:53 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <0E223B9A-F615-4E46-971C-84A3117AA27A@employees.org> <87a9mcbhx8.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87a9mcbhx8.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1692; t=1372288254; x=1373152254; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Configuration=20must=20not= 20be=20carried=20by=20the=20routing=09protocol |Sender:=20 |To:=20Juliusz=20Chroboczek=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=TfuE59qZ+Ufub0Sqf4rAsQ0Hnp2aLd4gSPdUMs3r2Vo=; b=K06uJUI+BPnB5HZQrecCiSr7y9Mzf5RVPoiukDs3pJjhrhoyxi7+NLz36l RmVWSrLssaKVOoNWEGKlHTaef/1QWiV6iRWOcw0Q3bc28SKz8alwLHW8N28K 3i43OCIcgZ2R1HwnHVOGb1CZsTuNLs+LW/DdhNIsM3nEusxBovkOQ=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:11:00 -0000 On 06/26/2013 03:56 PM, Juliusz Chroboczek wrote: > > do we need to invent a separate distributed database for each class > of information? > Yes, because different kinds of information have different > requirements. There is information that needs to be reliably > synchronised in a timely manner (the link-state DB), there is > information that must be distributed in a timely manner but need not > be synchronised throughout the network (configuration information), > there is global information that is too large to be distributed except > on demand (DNS), there is local information that is not distributed > except on demand (mDNS), and probably many other kinds that I'm missing. > I'm not sure that I have an opinion on this debate, but I'd like to point out that there are probably other classes of information that have little to do with routing, but a lot of desire to be replicated across a homenet's routers. For example if I have a DNS repository, I'd sure like to be able to take a dead router, throw it in the trash, plug in a new one, all the while where my network still was serving up my names. DNS in particular has ways to transfer the zones, but I'm less certain about whether there's anything that would orchestrate that hot standby kind of desire, and I'm even more dubious that it would satisfy zero/littleconf requirements even if there were. Picking ULA's seems to be another kind of problem that needs some kind of config replication/coordination too at the router level if it's to be zeroconf. Whether routing protocols would be a good fit, I don't know but it seems like an odd way to think about the problem to me. Mike From hrogge@googlemail.com Wed Jun 26 22:55:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE1D21F9C2F for ; Wed, 26 Jun 2013 22:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74uW5HQxiZza for ; Wed, 26 Jun 2013 22:55:52 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0303921F9C31 for ; Wed, 26 Jun 2013 22:55:51 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so308816qab.8 for ; Wed, 26 Jun 2013 22:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1o9tj6ZUllEjadogsiIxtqd3U3uMYBjy0sOnS0557ic=; b=Q++Dg7Wl5dWYVd9zawd5XqjgXvLXWt/A4eEM1lVzV/837QKVNBa5PVzHZSbxyzsISx 01xXMXpLIj1ZKrbIo5IgfkUSaH1JdbLN2nBYg4C1e0H7Aq8RqZc64sUSTgKycda7Tss8 fRvqqYu30tHSUcpuzWIehhsx+XZbdkgyH1v2/Fb24A6yvMWLEn3vr3ZlaMD/tv1IdG0J CVLftbiNOFkEaqHFGv3r3d4TuJyHqxrN3DhorZmnMdakjnidYmr4tHsiAmQ9Tm4mkl22 DtBlsaCfrk9uE1+P+lPRo3qRerYYdpnNvyJn625U5PPO/yu/BLmRg+OSohIz1RnXX6/+ hIYQ== X-Received: by 10.49.62.33 with SMTP id v1mr8644503qer.53.1372312550358; Wed, 26 Jun 2013 22:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.82 with HTTP; Wed, 26 Jun 2013 22:55:30 -0700 (PDT) In-Reply-To: <87a9mcbhx8.wl%jch@pps.univ-paris-diderot.fr> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <0E223B9A-F615-4E46-971C-84A3117AA27A@employees.org> <87a9mcbhx8.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Thu, 27 Jun 2013 07:55:30 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: Ole Troan , "homenet@ietf.org Group" Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:55:52 -0000 On Thu, Jun 27, 2013 at 12:56 AM, Juliusz Chroboczek wrote: >> what's a routing protocol? >> a distributed database. > > No, it isn't. > > .... > >> do we need to invent a separate distributed database for each class >> of information? > > Yes, because different kinds of information have different > requirements. There is information that needs to be reliably > synchronised in a timely manner (the link-state DB), there is > information that must be distributed in a timely manner but need not > be synchronised throughout the network (configuration information), > there is global information that is too large to be distributed except > on demand (DNS), there is local information that is not distributed > except on demand (mDNS), and probably many other kinds that I'm missing. I agree with Juliusz, putting all information transfer in the homenet (including routing decisions, configuration and DNS?) area into a single protocol is crazy. We don't gain a lot by this strategy except a lot of complexity and inflexibility in the implementation. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From teco@inf-net.nl Wed Jun 26 23:28:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B521F9C22 for ; Wed, 26 Jun 2013 23:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcvlnOQAFQ9y for ; Wed, 26 Jun 2013 23:28:42 -0700 (PDT) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id B4B3F21F9C55 for ; Wed, 26 Jun 2013 23:28:41 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g15so158713eak.18 for ; Wed, 26 Jun 2013 23:28:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JvYICsmhpAnfcjlvOJaEji8CuYzQEcZep3nknC3ALkM=; b=k3gfbN7BdPBfvGhgi4g9OQaum2C/dy32uOM3ZPEjBRlO0T1fjn9fJZgwGRw+CY5AUT Qf8Uy08d/y3ytD4/X9J6PR3clVeirXa3oruGclMZmeRogjEdecO5K4yCYphx0o+b0K3B PG34c4THy1jVciWf4nkRSMYL/4wEYsFEdqNmgPbF5CbaiF3kFuF0Iq0f5EiA5fWKXFE4 U7xM4PoJEEv5ckHqtJkBEcehOeI4Vcej3zh27iFWKMmz9P+3B95+/83hasF4NKhV6KgI /Q/ipfNih5auZovfjJoHSk4jLqeatJ6ALVyVhkhUWYoI7Q0kJOW4BAKNNjIzaXtxh6Ns neLw== X-Received: by 10.14.2.137 with SMTP id 9mr7309405eef.64.1372314518610; Wed, 26 Jun 2013 23:28:38 -0700 (PDT) Received: from [172.16.4.22] ([188.205.88.52]) by mx.google.com with ESMTPSA id e44sm1750947eeh.11.2013.06.26.23.28.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 23:28:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Teco Boot In-Reply-To: Date: Thu, 27 Jun 2013 08:28:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <299C00BD-EA94-448E-AF10-556CC566042E@inf-net.nl> References: <878v1yqhje.wl%jch@pps.univ-paris-diderot.fr> <0E223B9A-F615-4E46-971C-84A3117AA27A@employees.org> <87a9mcbhx8.wl%jch@pps.univ-paris-diderot.fr> To: Henning Rogge X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQlChQlKKslPlDzZSMGxRjMtYCzZKLacE2AhJRwHqlmDcMA7br0XkBbbJQM1+3mdPhIDOxhf Cc: Ole Troan , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] Configuration must not be carried by the routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 06:28:46 -0000 Op 27 jun. 2013, om 07:55 heeft Henning Rogge = het volgende geschreven: > On Thu, Jun 27, 2013 at 12:56 AM, Juliusz Chroboczek > wrote: >>> what's a routing protocol? >>> a distributed database. >>=20 >> No, it isn't. >>=20 >> .... >>=20 >>> do we need to invent a separate distributed database for each class >>> of information? >>=20 >> Yes, because different kinds of information have different >> requirements. There is information that needs to be reliably >> synchronised in a timely manner (the link-state DB), there is >> information that must be distributed in a timely manner but need not >> be synchronised throughout the network (configuration information), >> there is global information that is too large to be distributed = except >> on demand (DNS), there is local information that is not distributed >> except on demand (mDNS), and probably many other kinds that I'm = missing. >=20 > I agree with Juliusz, putting all information transfer in the homenet > (including routing decisions, configuration and DNS?) area into a > single protocol is crazy. We don't gain a lot by this strategy except > a lot of complexity and inflexibility in the implementation. There are different aspects such as single routing protocol, single = routing protocol instance, single daemon. Reusing existing stuff, clean separation of functionality and good = efficiency are all nice goals. We end up somewhere in the middle and = improve from there. Just the routing protocol choice: do we need a single protocol for IPv4 = and IPv6? With single instance and single topology? Is multicast routing = fully integrated? A lot of questions already. Teco > Henning Rogge >=20 > -- > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From lorenzo@google.com Thu Jun 27 05:05:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E02C21F9D19 for ; Thu, 27 Jun 2013 05:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXKcrw0jls-s for ; Thu, 27 Jun 2013 05:05:36 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id AA05721F9D18 for ; Thu, 27 Jun 2013 05:05:36 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so548118veb.41 for ; Thu, 27 Jun 2013 05:05:35 -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=Gi1iZPkBxRQMEKLPkqhRSwvKDAEIlCsLjt0SDBy2MQk=; b=Bv4dgGZWGXAOfr1EHndRTZZK3L0kEitpdd9KS1NUM54/mARRvFsQF0jCu+HKwDDZoA OSv1ftbcfpMtOA0EXlHDnV9CqdRl2I363cHVvOFYsr/f3dy+0Aj+u/glyUlXiiuzf0fn +bX8GJWbJHnevpT7dgyaqV63uu1IVHGbyHuOkygJ2D8o8b2sszzJ2/bc8BDYrFYFjnIO wNHxo5Vt8KTns2THY8GhZ1JKqGcD891wq3qgf/j3E8wzlF0rmjTapmWqN6r85aUc7ZWL EId4O9Bh/4WShXHcOqXFuuCOP3w/6R0n6WqfJiPzd5fxERW4S4lu00oGeG5FkdgHpO/0 KSFQ== X-Google-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:x-gm-message-state; bh=Gi1iZPkBxRQMEKLPkqhRSwvKDAEIlCsLjt0SDBy2MQk=; b=nwWI1dDWjzJeL917YeWyVoJ+N+dka02phRh2v7GgrwKkVc3qFbyRI3uO2dddZ5qB1s LwMW+Hw3c0X+IAzX0zNYrLSvzZdmbnQ/WQte8Gb+RpgVrT0vnYnXOVtmOVA15K/x7gmB VHkG0BRN4i4+0C34emg4w5EuMTcAt3Ir3Rke9SpjK8LoUTsi+L5Rn3i5055/Je77g08c s51VtdZJkTXTa2Fmnq8ZuScqlx86X8+MBoVsb0B90x2LKeGnbMvLvVXEEQ+VuLrQPG49 Is16AeWWMMCuLsMFhYeXiGp8GBrN9SJfVcWib9p41Btw3Ls2x3AguJ88JaT2tC9f80fh fowQ== X-Received: by 10.58.219.232 with SMTP id pr8mr3365285vec.80.1372334735067; Thu, 27 Jun 2013 05:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.172.66 with HTTP; Thu, 27 Jun 2013 05:05:15 -0700 (PDT) In-Reply-To: <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Thu, 27 Jun 2013 21:05:15 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=047d7bd6b88c65c92f04e0219420 X-Gm-Message-State: ALoCoQmzhi/Ao77Pay3YKGtfCTgPLH9CWogL33l2ifJhzHC9lXdqFXbgT0gsctC80HaDPHBlLd/t1bIioUB5hHXBb8nB+yGu/eXV0kzcex6yVVyIWyjB9TWmuMl0kHKVOWpLikxuSYIJKoTDc3buvkw2fLAFzIWyF+cZ1ZeEqjhRpRuW/I+zRY/P7huJC5kI4t765eDSiVZ4 Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:05:37 -0000 --047d7bd6b88c65c92f04e0219420 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 24, 2013 at 8:56 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > If you don't care about compatibility with normal devices, you run the > routing protocol on each mobile node, but have it filter any routes > except for announcing its own /128 Its own? You don't mean to say that every device may only have one IP address? That would be so... 1997. --047d7bd6b88c65c92f04e0219420 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 24, 2013 at 8:56 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
If you don't care about compatibility with nor= mal devices, you run the
routing protocol on each mobile node, but have it filter any routes
except for announcing its own /128

Its own?= You don't mean to say that every device may only have one IP address? = That would be so... 1997.
--047d7bd6b88c65c92f04e0219420-- From dave.taht@gmail.com Thu Jun 27 11:32:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A432F21F9EAC for ; Thu, 27 Jun 2013 11:32:25 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df5cXWAZQpyC for ; Thu, 27 Jun 2013 11:32:24 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C305821F9EAB for ; Thu, 27 Jun 2013 11:32:21 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so2200774iea.39 for ; Thu, 27 Jun 2013 11:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eLp5CQVc9cqbOGXsMWIK3CZKFzYr9741cQWEUgVx45s=; b=pbaJYvckkH/twOTs8Mz401Souh+VlYHiIvKEZdysNv4jAaxu99HraMmv8y77MWyOxz pDX3O2yA7lkJ/W1Mbj/Ew/jrDYTBfUizEFhm4mE03JpcLDHBXaSBdReiKHxUNRlMpyUs 8oEZ3AsCR7yCxZ9Q2HzSq8ni9l1eoR1cDTCqAqnPNGvie82Fl0zJjof5JS94V0uRFKQF jxEwDNe/RnRmE4I7sGtyPrhR9A+ufVNAfZWrHsz/joEv2GdN0+JQdeVukxmF4jBsr6G0 MvFRwI7P0utVsIDOUXuIp6ESeTGKztMe6RoqNvYYktxdvIBFhRwDEqvaPx1R/Mqg8TGh sRxQ== MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr4351050igb.37.1372357941361; Thu, 27 Jun 2013 11:32:21 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Thu, 27 Jun 2013 11:32:21 -0700 (PDT) Date: Thu, 27 Jun 2013 11:32:21 -0700 Message-ID: From: Dave Taht To: HOMENET Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [homenet] dnssdext wg bof at ietf 87 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:32:25 -0000 I tend to regard the naming/service discovery problem as the biggest one in a routed home network (regardless of the routing protocol, prefix distribution mechanism, etc, etc) so I am pleased to see a bof scheduled for what we were calling mdnsext and now the more accurate dnssdext. (I think I've seen a typo for dnsnext?) http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#dnssdext In there is the open question about homenet's relationship to this group. Is it the intent of homenet wg to defer to the decisions of the dnssdext working group, or... --=20 Dave T=E4ht Better testing for bloat: https://plus.google.com/u/0/107942175615993706558/posts/W5EmsoHFx9q From jch@pps.univ-paris-diderot.fr Thu Jun 27 12:54:02 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82DA21F9F52 for ; Thu, 27 Jun 2013 12:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.448 X-Spam-Level: X-Spam-Status: No, score=0.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPe6LcjORlWh for ; Thu, 27 Jun 2013 12:53:58 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 6393A21F9F53 for ; Thu, 27 Jun 2013 12:53:57 -0700 (PDT) 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/38117) with ESMTP id r5RJrqZK021796 for ; Thu, 27 Jun 2013 21:53: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 043644F1FF for ; Thu, 27 Jun 2013 21:53: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 yfEb5Icfe9gd for ; Thu, 27 Jun 2013 21:53:49 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AFAD64F1FB for ; Thu, 27 Jun 2013 21:53:49 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1UsIGL-0007XJ-CW for homenet@ietf.org; Thu, 27 Jun 2013 21:53:49 +0200 Date: Thu, 27 Jun 2013 21:53:49 +0200 Message-ID: <7ia9mbtjn6.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: homenet@ietf.org References: <7ibo6rtjoo.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Jun 2013 21:53:55 +0200 (CEST) Subject: [homenet] Fwd: ANNOUNCE: source-specific routing in Babel X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 19:54:03 -0000 Date: Thu, 27 Jun 2013 21:52:55 +0200 Message-ID: <7ibo6rtjoo.wl%jch@pps.univ-paris-diderot.fr> From: Matthieu Boutier To: babel-users@lists.alioth.debian.org CC: Markus Stenberg , fred@cisco.com Subject: ANNOUNCE: source-specific routing in Babel Dear all, We are pleased to announce a first implementation of Babel-S, a variant of Babel able to distribute source-specific routes. The code is available using git clone -b source-specific git://git.wifi.pps.univ-paris-diderot.fr/babels.git with a web inteface on http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git and a backup on https://github.com/boutier/babeld Motivation ========== Consider the case of a multihomed network (a network connected to two ISPs). If the network is using provider-specific addresses, a packet needs to be routed to the right ISP depending on its *source* address. This is in contrast to traditional routing, which only considers the *destination* when making a routing decision. ISP A ISP B \ / packets \ / packets sourced \ / sourced from A \ / from B end node Markus Stenberg has recently published a prototype of source-specific routing for OSPF[1]. Babel-S is our attempt at a production-quality implementation of source-specific routing within the Babel routing protocol[2]. Implementation details ====================== In the presence of source-specific routing, a route is identified by a pair (D, S) where D is a destination prefix and S is a sourcer prefix. In the general case, there is a possibile ambiguity between two routes. For example, in our experimental network there is a default source-specific route (0.0.0.0/0, 192.168.4.0/24) ^ ^ | | dest source and a non-source-specific route (192.168.4.42/32, 0.0.0.0/0) A packet that is both sourced from 192.168.4.0/24 and destined to 192.168.4.42 is ambiguous. As was explained to us by Fred Baker, in this case the destination should "win" -- the packet should follow the non-source-specific route. Unfortunately, the one Linux kernel API that works is the "rule" system, which doesn't implement this semantics naturally. For this reason, we are inserting extra "disambiguation" routes for the intersection (192.168.4.42/32, 192.168.4.0/24) The exact algorithm is somewhat involved, and will be described at some later point. Enjoy the code in route.c in case you're interested. Limitations =========== - There are some limitations wrt. routes found in the kernel that were not installed by babeld. - Requests for source-specific routes are broken (we're working on it); this could cause starvation in some very unlikely cases. - The number of kernel tables used by the daemon cannot be configured yet. Usage ===== Without any special configuration, Babel-S reannounces source-specific routes received from other Babel peers and installs them in the kernel. In order to introduce source-specific routes in the network, some routers should redistribute their routes as source-specific. This is done via the "source-prefix" configuration option. For example, to redistribute his routes with the source 192.168.4.0/24, a router will be configured with: source-prefix 192.168.4.0/24 By default, Babel-S will use the routing tables 10 to 19 and the rules' priorities 100 to 109. You can see kernel rules and tables using the ip command: ip rule show ip route show table 10 Babel-S defines in total 5 new configuration options, described in details in the manual pages. These are: - source-specific - first-table-number - first-rule-priority - announce-with-default-source-prefix - install-specific This is experimental code, likely to change at any time. Any feedback will be very much welcome. -- Matthieu Boutier and Juliusz Chroboczek [1] https://github.com/fingon/hnet-core [2] http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ From tjc@ecs.soton.ac.uk Thu Jun 27 13:01:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E916D21F9E58 for ; Thu, 27 Jun 2013 13:01:00 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXZHYwo7JOiA for ; Thu, 27 Jun 2013 13:01:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id EF39511E80A5 for ; Thu, 27 Jun 2013 13:00:59 -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 r5RK0th8007024 for ; Thu, 27 Jun 2013 21:00:55 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5RK0th8007024 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1372363255; bh=N7hmlIGH25N/X3U+JDsNbHsilvc=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=5kQ6P91z3XydSNIt80fNZ2MCgpItJS5B97AQLsDSccwOT3KvT438QD6p1xrPruK7m XJ7yU9Xf9SzXDyd4wuUpBvsoERnA413Yo4NFPjNQh0/dQbzo7mMfeBnfA8m8zcYmLP /xzXrcUIaPrMxeILPrq5/wmd8fwOKEJUu94ZEmgQ= 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 p5QL0y0544517730eE ret-id none; Thu, 27 Jun 2013 21:00:55 +0100 Received: from [192.168.1.110] (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 r5RJxZsq019259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 27 Jun 2013 20:59:36 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: Date: Thu, 27 Jun 2013 20:59:37 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: HOMENET X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5QL0y054451773000; tid=p5QL0y0544517730eE; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r5RK0th8007024 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] dnssdext wg bof at ietf 87 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:01:01 -0000 On 27 Jun 2013, at 19:32, Dave Taht wrote: > I tend to regard the naming/service discovery problem as the biggest > one in a routed home network (regardless of the routing protocol, > prefix distribution mechanism, etc, etc) >=20 > so I am pleased to see a bof scheduled for what we were calling > mdnsext and now the more accurate dnssdext. > (I think I've seen a typo for dnsnext?) >=20 > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#dnssdext >=20 > In there is the open question about homenet's relationship to this > group. Is it the intent of homenet wg to defer to the decisions of the > dnssdext working group, or... There will need to be close linkage between the groups (assuming = dnssdext is formed). I would expect this to be discussed in Berlin, and = that there will be some steer from the ADs, given both are Int Area. One = point to note is that the dnssdext scope is larger than just homenet, = including enterprise and campus environments.=20 The name of the dnssdext BoF was originally sdnssd (scalable dns sd), = but that was changed in case anyone glancing at the meeting schedule = assumed it was a SDN-related BoF. The final name of the WG, again if = formed, is to be determined. Tim= From jch@pps.univ-paris-diderot.fr Thu Jun 27 13:17:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27611E8122 for ; Thu, 27 Jun 2013 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxR6DkUuKQQx for ; Thu, 27 Jun 2013 13:17:11 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 361E711E811B for ; Thu, 27 Jun 2013 13:17:10 -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/38117) with ESMTP id r5RKH9jr011482; Thu, 27 Jun 2013 22:17:09 +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 12E634F204; Thu, 27 Jun 2013 22:17:09 +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 SC-4SKsJENBL; Thu, 27 Jun 2013 22:17:07 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B0D074F203; Thu, 27 Jun 2013 22:17:07 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1UsIct-0007Y2-Cx; Thu, 27 Jun 2013 22:17:07 +0200 Date: Thu, 27 Jun 2013 22:17:07 +0200 Message-ID: <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 27 Jun 2013 22:17:09 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:17:16 -0000 > If you don't care about compatibility with normal devices, you run the > routing protocol on each mobile node, but have it filter any routes > except for announcing its own /128 > > Its own? You don't mean to say that every device may only have one > IP address? That would be so... 1997. I realise you're joking, but it's actually an interesting point you're raising. Should the interfaces of a mobile node be numbered? One way, which is quite natural from a mesh networking point of view, is to have an IP on the loopback interface and leave all interfaces unnumbered. This simplifies configuration and reduces routing traffic, and actually improves compatibility with applications that assume a single IP. Another way is to use the same IP on all interfaces. That's more or less equivalent to the above, and is the Linux way of representing unnumbered interfaces. Then there's of course the possibility to put a distinct IP on each interface. It makes the networking specialists happy, but causes a number of problems with applications that assume a single IP. I guess it might be somewhat premature to discuss that particular issue within the group, hence the OT marker. -- Juliusz From mcr@sandelman.ca Thu Jun 27 15:29:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658DF21F9E82 for ; Thu, 27 Jun 2013 15:29:45 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM7NxUOqdDW1 for ; Thu, 27 Jun 2013 15:29:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id EE6BB21F9E80 for ; Thu, 27 Jun 2013 15:29:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A24992018E for ; Thu, 27 Jun 2013 19:33:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2E8B363A7C; Thu, 27 Jun 2013 18:28:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1FE7C63732 for ; Thu, 27 Jun 2013 18:28:39 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <7ibo6rtjoo.wl%jch@pps.univ-paris-diderot.fr> References: <7ibo6rtjoo.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 Subject: Re: [homenet] [Babel-users] ANNOUNCE: source-specific routing in Babel X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 22:29:45 -0000 --=-=-= From: Matthieu Boutier To: babel-users@lists.alioth.debian.org User-Agent: Wanderlust/2.15.9 X-policyd-weight: using cached result; rate: -7.6 Subject: [Babel-users] ANNOUNCE: source-specific routing in Babel Sender: "Babel-users" Dear all, We are pleased to announce a first implementation of Babel-S, a variant of Babel able to distribute source-specific routes. The code is available using git clone -b source-specific git://git.wifi.pps.univ-paris-diderot.fr/babels.git with a web inteface on http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git and a backup on https://github.com/boutier/babeld Motivation ========== Consider the case of a multihomed network (a network connected to two ISPs). If the network is using provider-specific addresses, a packet needs to be routed to the right ISP depending on its *source* address. This is in contrast to traditional routing, which only considers the *destination* when making a routing decision. ISP A ISP B \ / packets \ / packets sourced \ / sourced from A \ / from B end node Markus Stenberg has recently published a prototype of source-specific routing for OSPF[1]. Babel-S is our attempt at a production-quality implementation of source-specific routing within the Babel routing protocol[2]. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcy8joqHRg3pndX9AQIUdwQApdIeRTzRS5Cfxc/zy26kDrk1WOeWSn5E +m/1apNnDsmCSx8AOdUb+Ewk9C3it0uYB6+HU2oLWtFbGm542M0vV3rLumCO4t16 M2a1WTuFN5fh4qz9BNDJ5Cl0JcNKBQkRz/gGspUfCj2T2i4HKrWOJGUwyrJ5FTxv jbgNOzRzEVY= =lbDZ -----END PGP SIGNATURE----- --=-=-=-- From lorenzo@google.com Thu Jun 27 17:17:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7362A21F9123 for ; Thu, 27 Jun 2013 17:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwlDKyljbFP7 for ; Thu, 27 Jun 2013 17:17:56 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E543121F9130 for ; Thu, 27 Jun 2013 17:17:55 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p13so1251811vbe.28 for ; Thu, 27 Jun 2013 17:17: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=PxBMJdC1u6LYMgiJE0ONmFrC5DvkRuqjt7C2go15+HE=; b=AbFUZNU5d1dhgomGkm/QpXiadDdMh6eILuO0xDmM5wmZSHmU1vld0jKnD90LYTsMYi UEnWZRrARq16ZMIqfqlbP4ZlDe4ujl1ELzXPaPoR5+Owc7bKf0rg+Gm02GN0BWLMt0Bi 8t8hrSW9QXVRQ11l4Qzi4WRwnZcNW+wo6QzHXXK0SIBQ+b8CHVOkSs611kgG7Q9iUJes JNScirAhOhzuNYQPAxbl1x3b1MS84FLCdc9k6WwGPH31P+leiqBJCjTC4EkcZQnxDcOd C8q7AJz43YjhnSiAUo2u9NU3CV5x4GjTwoB4ssqwrS3hsIeSfIhsMvW8zo2jnWNKHPX5 n0/w== X-Google-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:x-gm-message-state; bh=PxBMJdC1u6LYMgiJE0ONmFrC5DvkRuqjt7C2go15+HE=; b=bkgWtljeiX8phY2mSi8+eqWv260Aj97r9bcgQinL0e+EdhQ3Bai+LgIuTwi2EjVeqO MyepU/NkvyguvYhcPVjSHQ+AJX1DW042Kj48GaqaXnIBojj5U2GQYnRiKJbbxLDfD4Oo HHOALuph+jbMKOqwQnkyxbXCyXOGv/riFicQZzEHxvNcBP10a6s5iFfIdyT08Zg6xVwG gr+q1+w6S7iBFVGPtbmdI6Ca+pAPPg/AFJ/MijrGLYgzbGDlyxYGQ5X12vLRic1jYn3S kd/rB6Uty1pn+sSyDczfHzXYApgpNyJe0sXT7xI/A1pqMAJweQC6v5JHUf5gVXaPcjvT 1vNw== X-Received: by 10.52.31.170 with SMTP id b10mr3732146vdi.115.1372378674263; Thu, 27 Jun 2013 17:17:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.172.66 with HTTP; Thu, 27 Jun 2013 17:17:33 -0700 (PDT) In-Reply-To: <7ia9mbtjn6.wl%jch@pps.univ-paris-diderot.fr> References: <7ibo6rtjoo.wl%jch@pps.univ-paris-diderot.fr> <7ia9mbtjn6.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Fri, 28 Jun 2013 09:17:33 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=bcaec51d291660a6dc04e02bcf47 X-Gm-Message-State: ALoCoQlvH++v4sWZy2cKmvJ0NFVvJKRV8TJ3V1nCJuEJiakwt6lXT1M4ZVVp36jnFjd3GS19pchpzdyYSOKiyUDEFMtXhqGGSh0l34dCtkxWWjeYinxJLgGROX1xcnUkLK7F7mGumETVipIOuNd+NZ1h36cZmr49HRRXlp9coE8grbLy+riDyClivfU8NQa6riNc69mHj/+s Cc: "homenet@ietf.org" Subject: Re: [homenet] Fwd: ANNOUNCE: source-specific routing in Babel X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:17:56 -0000 --bcaec51d291660a6dc04e02bcf47 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 4:53 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > For example, in our experimental network there is a default > source-specific route > > (0.0.0.0/0, 192.168.4.0/24) > Is there support for IPv6? (IPv4 is not really the main target for homenet.) --bcaec51d291660a6dc04e02bcf47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 28, 2013 at 4:53 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
For example, in o= ur experimental network there is a default
source-specific route

=A0 (0.0.0.0/0, 192.168.4.0/24)

Is there support for IPv6?

(IPv4 is not really the main target for homenet.)
--bcaec51d291660a6dc04e02bcf47-- From jch@pps.univ-paris-diderot.fr Thu Jun 27 17:47:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA8821F9ADD for ; Thu, 27 Jun 2013 17:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3q6pKSvJwuP for ; Thu, 27 Jun 2013 17:47:00 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB2A21F99A1 for ; Thu, 27 Jun 2013 17:46:59 -0700 (PDT) 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/38117) with ESMTP id r5S0kvus023751; Fri, 28 Jun 2013 02:46:57 +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 CBDD74F213; Fri, 28 Jun 2013 02:46:57 +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 faA7XsfEdHxS; Fri, 28 Jun 2013 02:46:56 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C21C94F207; Fri, 28 Jun 2013 02:46:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UsMq0-0003JD-8m; Fri, 28 Jun 2013 02:46:56 +0200 Date: Fri, 28 Jun 2013 02:46:56 +0200 Message-ID: <87bo6rrri7.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <7ibo6rtjoo.wl%jch@pps.univ-paris-diderot.fr> <7ia9mbtjn6.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 28 Jun 2013 02:46:57 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] ANNOUNCE: source-specific routing in Babel X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:47:06 -0000 > For example, in our experimental network there is a default > source-specific route > >   (0.0.0.0/0, 192.168.4.0/24) > > Is there support for IPv6? Yes, but it has received less testing than the IPv4 support. We're aiming for a formal release (stable on-the-wire encoding, stable configuration syntax, reasonably tested) before the end of the summer. -- Juliusz From hrogge@googlemail.com Thu Jun 27 22:51:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8729C21F9FA2 for ; Thu, 27 Jun 2013 22:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7uufFSjiaik for ; Thu, 27 Jun 2013 22:51:29 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E255721F9F9B for ; Thu, 27 Jun 2013 22:51:01 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so1112408qcy.18 for ; Thu, 27 Jun 2013 22:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iPT8cEoKbIp5K8sdxQKZeQXUOPekwb3Wg8zl8BPwalY=; b=UZ6UPKQy60PFXvcXqYvZEsFs7FgkQIzr8tAGuhXKZ+fXbWu8oCNAPXi1wOSpVfCqed YG5WFUW2CvHKbSxoQVKuPP3fbYMLtnJB5HwAVYqkLqsuRarwOMWqRKUt5ugdmgz2LhNy 6zT6TbTTR1VnHw9zhs2ImI4P1uDxRXiTs7YUPTUuDZinnHpRZWJX+l+znyJ+0oi4svxc KUyy7dwHy79+CjFQuSmc8FLEoRrIkNO7O06cv+q9/b4PDdyPR7b3bBCcHyekqdiFo6OV ExrO6bRxsjtEBkY+U1813pI2l58I2FhWbdOZFyhV0CBBJv0TvTtggQYGfl+AZkA3S50y AsqQ== X-Received: by 10.224.136.73 with SMTP id q9mr6441459qat.8.1372398660287; Thu, 27 Jun 2013 22:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.82 with HTTP; Thu, 27 Jun 2013 22:50:40 -0700 (PDT) In-Reply-To: <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Fri, 28 Jun 2013 07:50:40 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 05:51:30 -0000 On Thu, Jun 27, 2013 at 10:17 PM, Juliusz Chroboczek wrote: >> If you don't care about compatibility with normal devices, you run the >> routing protocol on each mobile node, but have it filter any routes >> except for announcing its own /128 >> >> Its own? You don't mean to say that every device may only have one >> IP address? That would be so... 1997. > > I realise you're joking, but it's actually an interesting point you're > raising. Should the interfaces of a mobile node be numbered? > > One way, which is quite natural from a mesh networking point of view, > is to have an IP on the loopback interface and leave all interfaces > unnumbered. This simplifies configuration and reduces routing > traffic, and actually improves compatibility with applications that > assume a single IP. A "homenet-scope" or global IP on loopback and linklocal IPs on the interfaces works fine and keeps the routing tables small. It also makes it easier to compensate for linkloss. If we put a "homenet-scope" IP on the interfaces a connection will break if the interface with its destination IP goes down. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From lorenzo@google.com Thu Jun 27 23:11:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BBB21F842E for ; Thu, 27 Jun 2013 23:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp6m+GdTw8gg for ; Thu, 27 Jun 2013 23:11:12 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 478F721F8467 for ; Thu, 27 Jun 2013 23:09:45 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so1407579vbb.37 for ; Thu, 27 Jun 2013 23:09:36 -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=P93hSSoX+RqRF11DB1Q0Ww0qAW4wiWRMX+CyI4GIbJY=; b=glVFZx5AVE2ECe3ZG4tLpBbbEuDQaJCJ5dzP/w8v5y09GdVakzHpqluTB9yo/TI0j5 4kO91YFZz3KJ9Y31jnKw6HL+fnaJUz8amVhobqJ/eRdpcHKfBypvknqpSAthbd28ZQfk J2C2Qlg4MdYHI2ThIpRtWO0FwLuDyfZuBXSRgpi+ww1FklMyHW/bqNGM2dHKzk6qImE9 968JLSqiNqPqvshj0tWjIzjbVzls52UhKCAMhtHivAyV6UaKryugbEcoPcIiwwsaZZbk xi2L97aOZP3ZhGCtngAjeA7BWYDctBkMMwypZJ5hcNCLAkMLzDk/A6Csc7gdC02cEBd1 5XZw== X-Google-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:x-gm-message-state; bh=P93hSSoX+RqRF11DB1Q0Ww0qAW4wiWRMX+CyI4GIbJY=; b=bRohxGwam9m9GQG+UzEIGkIlaHSkuf7OXj8QXLOEkmMwECIDp4qhIPfgwOg3MkY8+V SOatLK6rmhwkm1uQISoOJn/uCRmTg2WMPGOmBUsfzpzm4HRedvsg0JKhQAvJvdoxxeGa iXGU7HviwQzCZ15W+lTYGG5GouohI0mPTLIv1iqgRNy9HzRovtQ8EJkc0/cyUWHk1uOw mycS343+7XYkdNmIpO9qyVVkMOLpQQcM151VL1rSLYHZ4Tl4YARV5C6vNRLOWj4vjQ3M +UtKT46xyeqk10CFUpnzjwb/73/WNsbX8vONCJsP7FoqVHeasgossRGfYtcf29KmNMsq CzUA== X-Received: by 10.220.97.134 with SMTP id l6mr5002109vcn.44.1372399300806; Thu, 27 Jun 2013 23:01:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.172.66 with HTTP; Thu, 27 Jun 2013 23:01:20 -0700 (PDT) In-Reply-To: <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Fri, 28 Jun 2013 15:01:20 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=089e01635454d0bf4604e0309cd0 X-Gm-Message-State: ALoCoQmnrPxlEoY3NRp+oxo8GwOzz5PcIlG3dxTJhpVkjjiCcmWyAQrmsTlQROZYfheehADsvsqDDlJoL/vQPaX/B57XViILzYXDCgBRFwjNqgQSKDs/VSzwbpbbP7/xhqmP+Ir3rscD/sxPQmDjmVDPPTcsxTpGFSBu9Zz8qKax9Tb0qOPMrP+jLrpgp8FsGgnIUzZXUXvW Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 06:11:31 -0000 --089e01635454d0bf4604e0309cd0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 5:17 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Another way is to use the same IP on all interfaces. That's more or > less equivalent to the above, and is the Linux way of representing > unnumbered interfaces. > Not really. What about link-local addresses? What about privacy addresses? What about seamless renumbering? What about multihoming via source+destination based routing? All of those require support for multiple IPv6 addresses on the same node. I realize your main target is IPv4, and these things are not necessary in IPv4, but the goal here is to design something whose primary target is IPv6, so it must be designed with IPv6 in mind. Of course, you can probably make the existing protocol support this by simply tracking each address separately, but please think of the scaling limitations that your design might encounter. If a node has too many addresses, will you run out of packet space and be forced to drop the "extra" addresses like kerberos does? Will you fragment routing packets? Will the extra updates cause the system to become less efficient? Will a host be able to DOS the system by simply acquiring too many IPv6 addresses? And so on. Remember: for the purposes of this working group, IPv4 is legacy and nice to have. IPv6 is the design target. --089e01635454d0bf4604e0309cd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 28, 2013 at 5:17 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
Another way is to= use the same IP on all interfaces. =A0That's more or
less equivalent to the above, and is the Linux way of representing
unnumbered interfaces.

Not really. What= about link-local addresses? What about privacy addresses? What about seaml= ess renumbering? What about multihoming via source+destination based routin= g? All of those require support for multiple IPv6 addresses on the same nod= e.

I realize your main target is IPv4, and these things ar= e not necessary in IPv4, but the goal here is to design something whose pri= mary target is IPv6, so it must be designed with IPv6 in mind.

Of course, you can probably make the existing protocol suppo= rt this by simply tracking each address separately, but please think of the= scaling limitations that your design might encounter. If a node has too ma= ny addresses, will you run out of packet space and be forced to drop the &q= uot;extra" addresses like kerberos does? Will you fragment routing pac= kets? Will the extra updates cause the system to become less efficient? Wil= l a host be able to DOS the system by simply acquiring too many IPv6 addres= ses? And so on.

Remember: for the purposes of this working group, IPv4 = is legacy and nice to have. IPv6 is the design target.
--089e01635454d0bf4604e0309cd0-- From jch@pps.univ-paris-diderot.fr Fri Jun 28 06:32:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCC021F9C59 for ; Fri, 28 Jun 2013 06:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-1cuz4n56tu for ; Fri, 28 Jun 2013 06:32:23 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3BB21F9C2C for ; Fri, 28 Jun 2013 06:32:22 -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/38117) with ESMTP id r5SDWK8m010446; Fri, 28 Jun 2013 15:32:20 +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 AC50D4F275; Fri, 28 Jun 2013 15:32:20 +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 dV1LFNBIa1sM; Fri, 28 Jun 2013 15:32:19 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 394F64F26A; Fri, 28 Jun 2013 15:32:19 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UsYmg-0001Gj-P1; Fri, 28 Jun 2013 15:32:18 +0200 Date: Fri, 28 Jun 2013 15:32:18 +0200 Message-ID: <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 28 Jun 2013 15:32:20 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:32:29 -0000 > All of those require support for multiple IPv6 addresses on the same node. Lorenzo, no modern protocol has any issues with a single node announcing multiple host routes to itself. That includes at least OSPF, IS-IS, EIGRP, RIPv2, RIPng, EIGRP and Babel. (You might run into issues with RIPv1 and IGRP, which is a pity, since I rather like IGRP.) > I realize your main target is IPv4, Please do not put words into my mouth. My main goal is to develop algorithms and protocols for networking, and show that they work in practice. Most of my work is independent of any practical protocol, and could very well be applied to PUP if you felt so inclined. It turns out that both Babel and AHCP were initially IPv6-only protocols, and I only added IPv4 support when my users complained. (That's the trouble with having users.) > the goal here is to design something whose primary target is IPv6, > so it must be designed with IPv6 in mind. That's okay. I've heard of that IPv6 thing before. > please think of the scaling limitations that your design might encounter. I don't know how to break it to you, Lorenzo, but the routing community has given a little bit of thought to getting its algorithms to scale. > If a node has too many addresses, will you run out of packet space > and be forced to drop the "extra" addresses like kerberos does? No. > Will you fragment routing packets? No. > Will the extra updates cause the system to become less efficient? Yes. The effect is linear in distance vector, and O(n log n) in naive link state. It is possible to achieve linear scaling in link state if you're smart. We used to teach that in third year. We do it in fourth year now. > Will a host be able to DOS the system by simply acquiring too many > IPv6 addresses? Yes. Acquiring a few million addresses should be enough to notice. -- Juliusz From mcr@sandelman.ca Fri Jun 28 08:15:23 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EE621F9B11 for ; Fri, 28 Jun 2013 08:15:23 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SeF6vuk-5IS for ; Fri, 28 Jun 2013 08:15:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id CE13A21F9B0A for ; Fri, 28 Jun 2013 08:15:17 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 129D32017B; Fri, 28 Jun 2013 12:19:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B968163A5E; Fri, 28 Jun 2013 11:14:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A978163732; Fri, 28 Jun 2013 11:14:04 -0400 (EDT) From: Michael Richardson To: Acee Lindem In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47187916@eusaamb101.ericsson.se> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <8761x3mw4k.wl%jch@p ps.univ- paris-diderot.fr> <2AFD98F5-A324-4601-8DF7-DDCF71F7F936@fugue.com> <94A203EA12AECE4BA92D42DBFFE0AE47187916@eusaamb101.ericsson.se> 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 Cc: "homenet@ietf.org Group" , Ted Lemon , Jim Gettys , Juliusz Chroboczek Subject: Re: [homenet] 2nd Working Group Last Call for draft-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:15:23 -0000 --=-=-= Acee Lindem wrote: ac> Jim - I'm not going to debate with you what is harder ;^) However, a ac> requirement from the start of the Homenet WG is that we minimize changes to ac> host software with the goal being none. 1) minimize != zero 2) Juliusz' code works for hosts with current hosts stack, they just wind up renumbering if they change access points. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUc2oOoqHRg3pndX9AQL3xAP+Lt0HDgct6LRnOMN2Q5dZvBUz7gM+YbS/ 6Q+Q/aUFK26B3qh7vXVSCTEHNjKbZ85Le6vEyF+iqGvaSwOfY8QkoCfLn0dgdIUK 8T1clcRiBswuNCbcwA8Ez92m2KTUsmv5cUu0Ug7gF60CxCYIknMiWn3QLev/bZs7 uTqND2uAn2g= =9bJm -----END PGP SIGNATURE----- --=-=-=-- From lorenzo@google.com Fri Jun 28 08:29:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03621F9B4D for ; Fri, 28 Jun 2013 08:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khDrA5Jac7Wi for ; Fri, 28 Jun 2013 08:29:42 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EC04421F9B45 for ; Fri, 28 Jun 2013 08:29:41 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so1923434veb.5 for ; Fri, 28 Jun 2013 08:29:40 -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=SSe+FGXzpRq9pObaAleUhld5HGEHbO4uxm/WOh21ISs=; b=CttucyfRRcK3VLa+bivlD+auO2D4jpbxdpdNebBcvS1WNM9Ww1r8p6KXdbJGUSihIr 1S80PNvnerCPH8iSc8NpaTf4wc0KhHVHbwGW4ebpD/yGPFW2omkcJbWzQ6rtjuuRTmFU xnyClGihMbb2VA3viP5xnaw/srhCZBsMYu/e9NDf/J9f6kqrUz1bBRExZyy6DSqGjgJT oMgxhaSILJwG1RUB0GyIGMn5O/PQ33h1AMCw9TyoRKciOOlZFemk/gwIZP3k0bHsf3Qb rOhoBIVuGBprOobUaDt0d7ZvtI5y2FxYzbyTojo/jMgFZh73sVCW9zMpMZO+63J19DWE 6CSw== X-Google-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:x-gm-message-state; bh=SSe+FGXzpRq9pObaAleUhld5HGEHbO4uxm/WOh21ISs=; b=ZgAu8XmGXQOndoGaZLHc/IlXTBlJPnMpfPMHUnv0zkGewJTIL+w1u5tV4dhZg0+kso CIiUjasS2vP3U0RHKKC+9A3v5CIzSqsCeIzUM5xEYm2BS+7utMGRkuEuxNmMG6PzcXPX hVp0z+C2rCei4e8W5wvjM3lAgAu0PdzVxSfm6KyJvGOzv8+o0bBwoHqnEo4r3krY63L2 6Jqi9m2JyvMHeJgUVrCVkMkowMF0chUtkrRWrn4r2CaBub8Sm4YmlL4+awzLWJoexra2 vM4I2RLJ0j1Ynp53fLseBgcWDQRpc18xZVA97X6GH6JLedy/zawquou3foTtEv63hoNC VW9w== X-Received: by 10.221.49.134 with SMTP id va6mr5809905vcb.14.1372433380215; Fri, 28 Jun 2013 08:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.172.66 with HTTP; Fri, 28 Jun 2013 08:29:19 -0700 (PDT) In-Reply-To: <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Sat, 29 Jun 2013 00:29:19 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a11339eda1b41c404e0388cb6 X-Gm-Message-State: ALoCoQndJ7lLs2Z9aSwGhmA/F5PnkWzfiU1m+ak2h0yZJIeC9xsQEQhd9pZKwsuYKJ6/Rj3wsMYGToXjzJ56uBGjikkNYFHipvThC3dBu5OABxO4Gg613OHTIc59nJDcxzCBlbbnAqTgzmCAO9KJ841AK6harULvGbfs37mlfGnRU4oo5imBmQPU155pFjZVSpXT3r69P7Mw Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:29:42 -0000 --001a11339eda1b41c404e0388cb6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 10:32 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Lorenzo, no modern protocol has any issues with a single node > announcing multiple host routes to itself. That includes at least > OSPF, IS-IS, EIGRP, RIPv2, RIPng, EIGRP and Babel. (You might run > into issues with RIPv1 and IGRP, which is a pity, since I rather like > IGRP.) > Then we have no problem, then. We'll expect each host to announce N routing entries, one per address, and document things as such. I only asked the question because you said "its address" instead of "its addresses", which to me suggested you weren't thinking of multiple addresses. I assume the implementation does this today, then? > We used to teach that in third year. We do it in fourth year now. > One of the things that are always very hard to understand in fourth year is that often the performance of real-world designs (not to mention implementations) is very far away from what is optimal. --001a11339eda1b41c404e0388cb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 28, 2013 at 10:32 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
Lorenzo, no modern protocol has any issues with a = single node
announcing multiple host routes to itself. =A0That includes at least
OSPF, IS-IS, EIGRP, RIPv2, RIPng, EIGRP and Babel. =A0(You might run
into issues with RIPv1 and IGRP, which is a pity, since I rather like
IGRP.)

Then we have no problem, then. W= e'll expect each host to announce N routing entries, one per address, a= nd document things as such. I only asked the question because you said &quo= t;its address" instead of "its addresses", which to me sugge= sted you weren't thinking of multiple addresses. I assume the implement= ation does this today, then?
=A0
We used to teach that in third year. =A0We do it in fourth year now.

One of the things that are always very hard t= o understand in fourth year is that often the performance of real-world des= igns (not to mention implementations) is very far away from what is optimal= .
--001a11339eda1b41c404e0388cb6-- From jch@pps.univ-paris-diderot.fr Fri Jun 28 13:13:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF021F8605 for ; Fri, 28 Jun 2013 13:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjJ3UBbKqYHZ for ; Fri, 28 Jun 2013 13:13:43 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0141D21F9C20 for ; Fri, 28 Jun 2013 13:13: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/38117) with ESMTP id r5SKDZRh001755; Fri, 28 Jun 2013 22:13:35 +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 08CBC4F2AD; Fri, 28 Jun 2013 22:13:35 +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 D9RDwJ2RDaY7; Fri, 28 Jun 2013 22:13:33 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B80324F2AC; Fri, 28 Jun 2013 22:13:33 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Usf2z-00011f-8m; Fri, 28 Jun 2013 22:13:33 +0200 Date: Fri, 28 Jun 2013 22:13:33 +0200 Message-ID: <87ip0y56z6.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 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, 28 Jun 2013 22:13:37 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:13:48 -0000 >> no modern protocol has any issues with a single node announcing >> multiple host routes to itself. > We'll expect each host to announce N routing entries, one per > address, and document things as such. [...] > I assume the implementation does this today, then? The standalone babeld implementation does this by default. The implementation included in Quagga has defaults consistent with the other routing protocols included in Quagga, and needs some reconfiguration to behave as you desire. Please have a look at http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/ You'll see that the node with router-id e2:46:9a:ff:fe:4e:91:e2 has addresses 2001:41d0:1:f19f:e246:9aff:fe4e:91e2 192.168.4.40 which are both being redistributed as host routes (metric=96 from ariane). These happen to belong to different address families, but I could simply add another IPv6 address to this node, and the routing daemon would react within seconds and redistribute an additional host route. Please let me know if you want a demo, we'll try to do it in real time. (Isn't Babelweb cool? Demonstrating routing protocls across the Atlantic :-) The important thing to realise is that none of the above is specific to Babel -- Babel is just what I'm most competent with, so I tend to use it for my demos. Any good technician familiar with any of the classless routing protocols I listed in my previous mail could do the same with his favourite routing daemon. (And in case you're wondering, while only Babel has Babelweb, the mesh community have been developing some pretty cool network visualisation software for the other mesh routing protocols; unfortunately, they are not being advertised, and are rotting in confidential git repositories somewhere in central Europe. Folks, when you get ready to market your first Homenet router, speak to us -- both your users and your bosses will love pretty pictures that update in real time.) -- Juliusz