From Carl.Wuyts@technicolor.com Sun Jan 1 23:54:13 2012 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 7DCC421F8F0B for ; Sun, 1 Jan 2012 23:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, 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 r4uHoTDbHuJI for ; Sun, 1 Jan 2012 23:54:12 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id 594E821F8F05 for ; Sun, 1 Jan 2012 23:54:12 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTwFioeGlpbm8WF9+XMAMGEWsL/MI608J@postini.com; Sun, 01 Jan 2012 23:54:12 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 2 Jan 2012 08:52:39 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 2 Jan 2012 08:53:02 +0100 From: Wuyts Carl To: "homenet@ietf.org" Date: Mon, 2 Jan 2012 08:53:00 +0100 Thread-Topic: [homenet] Next steps Thread-Index: AczHG9vSnl289rDKTV6qV8V7l2+t5ACBJ72w Message-ID: <867F4B6A1672E541A94676D556793ACD0CB56948BB@MOPESMBX01.eu.thmulti.com> References: <5EAB9925-C2C7-4431-A826-13EEC46CDADC@townsley.net> <6688.1321540127@marajade.sandelman.ca> <97159911-1841-45B5-AF46-538DBD25E7F9@apple.com> <1962.1323713739@marajade.sandelman.ca> <4EF5E76C.7000704@riw.us> <24787.1325082280@marajade.sandelman.ca> <4EFC96F3.30602@riw.us> <791.1325254986@marajade.sandelman.ca> <4EFDF089.7090007@freedesktop.org> <7654.1325267565@marajade.sandelman.ca> In-Reply-To: <7654.1325267565@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Next steps 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, 02 Jan 2012 07:54:13 -0000 I've the impression that these "Next steps" are just adding (too much??) co= mplexity ?? It seems to be heading into the "mixing" L3 and L2 stuff (and = indeed, L2 is not "easier" or "more trivial" than L3, I agree), tunneling, = asking all devices to support MSTP ??, needing UI for end-user, ... Personally, but I might be completely wrong on this, I think the chance for= success in this is very small if too much complexity is involved, for sure= if you start forcing end-users having to do some (lots of) configuration. = I'm working in an environment, targeting residential CPE deployment, and o= ne of the things to avoid (from operator's perspective) is configuration. = Configuration works very well for techies, but is often to avoid for generi= c deployment, involving "average" users, at least that's the info I'm getti= ng/seeing from our customer base. Carl Wuyts -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Michael Richardson Sent: vrijdag 30 december 2011 18:53 To: homenet@ietf.org Subject: Re: [homenet] Next steps >>>>> "Jim" =3D=3D Jim Gettys writes: >> It's not simpler. It just looks that way because layer-2 bridging >> seems ubiquitous and trivial to layer-3 people. The recent TRILL >> work at the IETF demonstrates the limitations of layer-2. The >> idea is to make things simpler, and layer-2+MSTP doesn't seem at >> all simpler to me. (and I've both designed such networks and >> written the code) But, you have simply replaced one routing table >> (layer-3, that includes source routing and loop detection) with >> another routing table (layer-2, that is flood with pruning, and >> no loop detection). Jim> And you really don't want random multicast traffic to pollute a Jim> wireless network for which it is not intended (given the way Jim> 802.11 works, this is a real headache). A little multicast can Jim> ruin your whole day on 802.11; as the bandwidths have gone up, Jim> this problem has become increasingly acute (since the Jim> transmission rate at which broadcast is constrained hasn't). So, Russ' suggestion is to have this single layer-2 VLAN among exit routers= only, and it would be used by exit routers so that they can get a packet straight to another exit router. This layer-2 VLAN would not be bridged onto any other LAN, so the multicast vs wireless issue does not = arise. However! It does require that all routers (not just edge routers) implement layer-2 VLANs with (M)STP. Up to the "MSTP" part (which we really need), i= t's true that it's already present in a Linux stack. What concerns me, more than just that we are invoking a more complicated co= de path is: a) if this can really work, then some people will ask, again and again, why not bridge everything, period. (Your answer is one answer) b) this really limits everything in the future to being ethernet-like, while a layer-3 solution liberates us from that. --=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Mon Jan 2 13:08:20 2012 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 7773B21F8AD9 for ; Mon, 2 Jan 2012 13:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 4E1OXiEXwuyI for ; Mon, 2 Jan 2012 13:08:20 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE3FF21F8AD8 for ; Mon, 2 Jan 2012 13:08:19 -0800 (PST) Received: by eekc14 with SMTP id c14so14330308eek.31 for ; Mon, 02 Jan 2012 13:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LZ1rUrGMs7CoLwlkWRxCiFAywJRYPg3uDazySksTMtw=; b=w0ZQx7qNmRXS2lhpl4aKxL8Lp3xWVoSmOWsHVErnlKObkFx1fgkOZBe3Xtx4S5Yw1L SXiTDsDH8yTuaBJZkmmjZ4aN6VKcZRgAn8ZkaRf4bA2BffEl+M0Ecq3gIMOZMdM6HGHO E6ZYiuj8/wOwqcxdd35KUpxjrE0snkZoMFf1M= Received: by 10.14.15.99 with SMTP id e75mr19954979eee.67.1325538498919; Mon, 02 Jan 2012 13:08:18 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id b49sm165324513eec.9.2012.01.02.13.08.15 (version=SSLv3 cipher=OTHER); Mon, 02 Jan 2012 13:08:17 -0800 (PST) Message-ID: <4F021CB6.5050202@gmail.com> Date: Tue, 03 Jan 2012 10:08:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet@ietf.org References: <20111229192947.8993.35018.idtracker@ietfa.amsl.com> In-Reply-To: <20111229192947.8993.35018.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] I-D Action: draft-howard-homenet-routing-requirements-00.txt 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, 02 Jan 2012 21:08:20 -0000 Hi, > It may be assumed that each upstream will be connected via a > separate router, not multihomed off the same router. This seems to asume that one router equals one access network equals one provider. I don't think that's valid as a long term assumption. Any combination might arise - several upstreams via one router, different routers for different upstreams, and some upstreams via more than one router. In fact, > A host with mutliple upstream paths to the same destination (in- > home or external) should be able to use another in case on fails. seems to contradict the assumption. Or it's about multi-prefix based multihoming, which is a different problem altogether (see shim6 or draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat). > Must support a "walled-garden" network. This might routing > based on either source address (from the walled garden network) > or destination address (to the walled garden network); support > for both is not required. I thought that the IETF was about the Internet, so we shouldn't be assisting the creation of walled gardens. However, source-address-based selection of the next hop is needed anyway, to support multihoming and deal with ingress filtering. I don't see how any scenario can avoid destination-address-based routing, so I think that support for both *is* required. Regards Brian Carpenter From mcr@sandelman.ca Mon Jan 2 19:00:49 2012 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 2F43821F857F for ; Mon, 2 Jan 2012 19:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 pYpROyzahKur for ; Mon, 2 Jan 2012 19:00:48 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id BF7A621F8581 for ; Mon, 2 Jan 2012 19:00:48 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id ED2963445D; Mon, 2 Jan 2012 21:58:52 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id C1C0698147; Mon, 2 Jan 2012 22:00:41 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id AF6579812A; Mon, 2 Jan 2012 22:00:41 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <4F021CB6.5050202@gmail.com> References: <20111229192947.8993.35018.idtracker@ietfa.amsl.com> <4F021CB6.5050202@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 02 Jan 2012 22:00:41 -0500 Message-ID: <15691.1325559641@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-howard-homenet-routing-requirements-00.txt 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, 03 Jan 2012 03:00:49 -0000 >>>>> "Brian" == Brian E Carpenter writes: >> Must support a "walled-garden" network. This might routing based >> on either source address (from the walled garden network) or >> destination address (to the walled garden network); support for >> both is not required. Brian> I thought that the IETF was about the Internet, so we Brian> shouldn't be assisting the creation of walled Brian> gardens. However, source-address-based selection of the next No, the IETF is about commuication using the internet (suite of) protocols. The Internet is just the biggest garden out there. Not supporting walled gardens (which are globally uniquely numbered, but not globally reachable) leads to NAT66 at the border gateways. (And, we still don't seem to accept packets from Mars. All sorts of advice about doing Martian filtering...) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From Ray.Bellis@nominet.org.uk Tue Jan 3 05:41:02 2012 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 5012B21F853C for ; Tue, 3 Jan 2012 05:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 qe+ivD9Vxroc for ; Tue, 3 Jan 2012 05:41:01 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 093D021F8539 for ; Tue, 3 Jan 2012 05:41:00 -0800 (PST) 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:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=mozy22rxzFrm3t/c0LiQ6UBz4a3F1ecwDLmS+yS6sI53iFGbePqiEFnU aviuLuh1w6l71/EHxrWO7UXP38rbthUQ3oTS+zHilaNBOJi1yYnSbfgtN Ia+a2Yn56+CGPKl; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1325598061; x=1357134061; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20New=20Version=20Notificatio n=09for=0D=0A=09draft-howard-homenet-routing-comparison-0 0.txt|Date:=20Tue,=203=20Jan=202012=2013:40:56=20+0000 |Message-ID:=20<89BEBB84-AE13-433E-8322-E3EEF045E4F5@nomi net.org.uk>|To:=20"Howard,=20Lee"=20|CC:=20"homenet@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20|In-Reply-To:=20|References:=20; bh=zi1yFLLeXk4851f48GQZytfdiRiOiNbqdPftfNaLkno=; b=JOUvjyFcivAcZdMbBifo8wWh5NzLjISbyb/DLevu8hkGSLmIMhElYIAB KOmuvIVNmcbWEl7AGlvLVPF5UOBtoLvHxLkAisgvS9LcMyXZzeOG9/4d5 2aD2o+qcVo+qYF6; X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; d="scan'208";a="30427146" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 03 Jan 2012 13:40:58 +0000 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%19]) with mapi; Tue, 3 Jan 2012 13:40:58 +0000 From: Ray Bellis To: "Howard, Lee" Thread-Topic: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt Thread-Index: AQHMyh1RD4hbPHkyPEC+SWvbnOfYbg== Date: Tue, 3 Jan 2012 13:40:56 +0000 Message-ID: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 03 Jan 2012 13:41:02 -0000 On 29 Dec 2011, at 22:33, Howard, Lee wrote: > I got tired of waiting for someone else to drive consensus on a routing s= olution If there is consensus, it's for zOSPF, if only because no-one else appears = to believe strongly enough in their preferred solution to write a draft abo= ut it. I think Mark and I will need to make that call quite soon, but probably not= until the authors of the architecture draft have incorporated the routing = requirements and other comments since Taipei and put those into -01. > I hope folks find this useful.[2] Thanks Lee, that does indeed look useful. Ray From brian.e.carpenter@gmail.com Tue Jan 3 12:30:21 2012 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 4E2B911E80FF for ; Tue, 3 Jan 2012 12:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 nCBje8erB-9W for ; Tue, 3 Jan 2012 12:30:20 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C605111E80FC for ; Tue, 3 Jan 2012 12:30:20 -0800 (PST) Received: by ggnk5 with SMTP id k5so11339523ggn.31 for ; Tue, 03 Jan 2012 12:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8rkXP6Ra6/7WNwT4+wbNebNXR9F2E+R8wAu/17szsTE=; b=kqQaVH0uBNCLRNY48l6u2IO1v9wAoFVhlorc31y4m/fv+lrlzaTf4JE0FYDKwgLkTj gG8Qi165ERTawJCsR8vkBvD5mKQeIIHor2Wq0twDmF7W1+x1JDaYnkMRGDzwmRoXBbVp bLA/F4vxV/1bGOtSJ9WfAiabdhNj/ailiQ9IE= Received: by 10.50.189.199 with SMTP id gk7mr63134752igc.30.1325622618857; Tue, 03 Jan 2012 12:30:18 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id py9sm91196646igc.2.2012.01.03.12.30.16 (version=SSLv3 cipher=OTHER); Tue, 03 Jan 2012 12:30:17 -0800 (PST) Message-ID: <4F036555.4050903@gmail.com> Date: Wed, 04 Jan 2012 09:30:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <20111229192947.8993.35018.idtracker@ietfa.amsl.com> <4F021CB6.5050202@gmail.com> <15691.1325559641@marajade.sandelman.ca> In-Reply-To: <15691.1325559641@marajade.sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-howard-homenet-routing-requirements-00.txt 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, 03 Jan 2012 20:30:21 -0000 On 2012-01-03 16:00, Michael Richardson wrote: >>>>>> "Brian" == Brian E Carpenter writes: > >> Must support a "walled-garden" network. This might routing based > >> on either source address (from the walled garden network) or > >> destination address (to the walled garden network); support for > >> both is not required. > > Brian> I thought that the IETF was about the Internet, so we > Brian> shouldn't be assisting the creation of walled > Brian> gardens. However, source-address-based selection of the next > > No, the IETF is about commuication using the internet (suite of) protocols. RFC 3935 says otherwise. > The Internet is just the biggest garden out there. > > Not supporting walled gardens (which are globally uniquely numbered, but > not globally reachable) leads to NAT66 at the border gateways. It leads to RFC 4864 actually, which some people objected to violently for exactly that reason. > (And, we still don't seem to accept packets from Mars. All sorts of > advice about doing Martian filtering...) Right, but those packets aren't exactly in the spirit of RFC 3935 either. In any case - my point was that we don't need to make statements about walled gardens in order to derive the need for source-based routing decisions. We need that anyway, for multihoming-without-ipv6nat. Brian From mcr@sandelman.ca Tue Jan 3 13:11:08 2012 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 E27021F0C3E for ; Tue, 3 Jan 2012 13:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 ZE2lt4zq9b0e for ; Tue, 3 Jan 2012 13:11:06 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC721F8466 for ; Tue, 3 Jan 2012 13:11:02 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id C8F9234449; Tue, 3 Jan 2012 16:09:05 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 8B19B98147; Tue, 3 Jan 2012 16:10:58 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 846C29812A; Tue, 3 Jan 2012 16:10:58 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <4F036555.4050903@gmail.com> References: <20111229192947.8993.35018.idtracker@ietfa.amsl.com> <4F021CB6.5050202@gmail.com> <15691.1325559641@marajade.sandelman.ca> <4F036555.4050903@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 03 Jan 2012 16:10:58 -0500 Message-ID: <1472.1325625058@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-howard-homenet-routing-requirements-00.txt 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, 03 Jan 2012 21:11:08 -0000 >>>>> "Brian" == Brian E Carpenter writes: Brian> In any case - my point was that we don't need to make Brian> statements about walled gardens in order to derive the need Brian> for source-based routing decisions. We need that anyway, for Brian> multihoming-without-ipv6nat. okay, I was concerned that you were arguing against source-based routing decisions. I personally think that GUA numbered walled gardens are so incredibly better than NAT(XYZ) that it's close to a killer app for IPv6. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From lee.howard@twcable.com Fri Jan 13 08:49:28 2012 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 1AE1921F8579 for ; Fri, 13 Jan 2012 08:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 7IkeIy0mA4-U for ; Fri, 13 Jan 2012 08:49:27 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7701A21F862F for ; Fri, 13 Jan 2012 08:49:27 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,504,1320642000"; d="scan'208";a="307920527" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jan 2012 11:47:43 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 13 Jan 2012 11:49:26 -0500 From: "Howard, Lee" To: Ray Bellis Date: Fri, 13 Jan 2012 11:49:24 -0500 Thread-Topic: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt Thread-Index: AQHMyh1RD4hbPHkyPEC+SWvbnOfYbpYKjEDA Message-ID: References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> In-Reply-To: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 13 Jan 2012 16:49:28 -0000 > -----Original Message----- > From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] > Sent: Tuesday, January 03, 2012 8:41 AM > To: Howard, Lee > Cc: homenet@ietf.org > Subject: Re: [homenet] New Version Notification for draft-howard-homenet-= routing- > comparison-00.txt > > > On 29 Dec 2011, at 22:33, Howard, Lee wrote: > > > I got tired of waiting for someone else to drive consensus on a routing= solution > > If there is consensus, it's for zOSPF, if only because no-one else appear= s to believe strongly > enough in their preferred solution to write a draft about it. I don't think there's consensus on zOSPF. I think there are a few strong a= dvocates and a lot of pointed silence I did present an alternative (based o= n a draft), which had an equal mix of "interesting" and "bleah." The problem with zOSPF is that it doesn't meet our requirements. It doesn'= t detect borders (unless the border happens to have another zOSPF router wi= th the wrong password), it requires configuration (for the password), it do= esn't handle walled gardens (a requirement being debated), it's not lightwe= ight. I'm trying to be fair, and not just protect the PIO proposal because I prop= osed it. It needs work. Its biggest lack is the need for hierarchical add= ressing, but I think draft-baker-homenet-prefix-assignment solves that. I = don't want to see zOSPF adopted just because its advocates were louder. > I think Mark and I will need to make that call quite soon, but probably n= ot until the authors > of the architecture draft have incorporated the routing requirements and = other comments > since Taipei and put those into -01. My perception is that we have three people in favor of zOSPF, three support= ing a PIO, seven each supporting a different alternative, and 30 silent. Lee 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 d.sturek@att.net Fri Jan 13 09:14:04 2012 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 C3D1521F85BB for ; Fri, 13 Jan 2012 09:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 eOZXUTTxRy-O for ; Fri, 13 Jan 2012 09:14:04 -0800 (PST) Received: from nm14-vm0.access.bullet.mail.mud.yahoo.com (nm14-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.15]) by ietfa.amsl.com (Postfix) with SMTP id 0B5E021F85AC for ; Fri, 13 Jan 2012 09:14:03 -0800 (PST) Received: from [66.94.237.199] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Jan 2012 17:14:01 -0000 Received: from [98.139.221.49] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Jan 2012 17:14:01 -0000 Received: from [127.0.0.1] by smtp102.sbc.mail.bf1.yahoo.com with NNFMP; 13 Jan 2012 17:14:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1326474840; bh=1DetjJxmMHj/M2hIs2vQgHYwvOUU7azkIcyTuK/Ahgo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=QUn5fJr6fEJ240bwDRLUrYEcCWTP+1qe5UNRqfY/bT56g97PKXHkOdVcV4n5qMTYlFtYEGNoYDP0/C9InNH+tpfyGJtXBs0vqLMIl8ywdgMUN5A5MFPYIN7/ljLkWdHLrXmKnF8cCz3pIpmk14v70KoW9+x6k25F0dsgbb6lbW4= X-Yahoo-Newman-Id: 967704.92088.bm@smtp102.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: FIDiaxkVM1nHXyDOw4rV.dU.s72HlZWnODlJ.mzexTtB9.3 ZHL0.1IwJsnK2459DexTGAQjW9YBsYCLRhcF8zBb8j9gpAmQ2txHDlvl1U_r 4pudfa5fLMfVGpDOBu2avshF.sB0AFKyDRjqZur6F89edhIYe5gF69a3a2iT 8cbMtspIHGY.Pr0qQsZrD5Q_XSBNyTofHv8kCVgkE_QwD4Vh_KEzmzShby_R x1oJ2Sklh1_i7smi7NRZoVYG3bL6mCWW6fYSPW0kY3DqRrtJuH8upx0oqUPr 50Ksy0UpFohDdeHV9mzvbPfnp0r2Gz5tg3kTxdddyugGy5xSB3CWsjJ21fga Vt4nI46TJYchqhmmUHz47gW1yuL2au8Q9mBkNFVrZsoApSbvG9Ns2gLdz38t xA6GGkcpJgAnGLvMXmGzyx33.T_QHwc6GktV11FhOXcN0.u6EhCpbK5GVCx0 - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.108] (d.sturek@174.78.56.227 with login) by smtp102.sbc.mail.bf1.yahoo.com with SMTP; 13 Jan 2012 09:13:56 -0800 PST User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 13 Jan 2012 09:13:45 -0800 From: Don Sturek To: "Howard, Lee" , Ray Bellis Message-ID: Thread-Topic: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 13 Jan 2012 17:14:05 -0000 As one of the "silent" ones in Lee's note, I agree with what he is saying. While homenet needs to define a home routing solution, the following are the requirements for that solution from my perspective: 1) Must be an established, existing, deployed routing protocol (or heavily based on one). We cannot afford to go through the process of defining something new in homenet...... 2) Must be lightweight. Unfortunately, I don't see a lot of Wi-Fi (or other current home networking) router vendors in the group (or chipset manufacturers for these solutions) but there is not a lot of spare flash/RAM in many devices to support a large footprint solution. It might even be worth reaching out to some of these folks to get their opinions if they aren't participating in homenet..... 3) Must be auto configurable. For nearly all device deployments (eg, smart energy, video/audio distribution), it cannot take professional IT to install, configure or update home routing networks. Also, many devices will be "headless" in that they cannot support user input. Even having a third device like a smart phone, tablet, etc. to configure a headless device onto a home network requires software, documentation, etc. If it requires support then there is probably a major question whether it would be deployed by manufacturers. Hopefully the routing solution we choose meets the criteria above....... Don On 1/13/12 8:49 AM, "Howard, Lee" wrote: > > >> -----Original Message----- >> From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] >> Sent: Tuesday, January 03, 2012 8:41 AM >> To: Howard, Lee >> Cc: homenet@ietf.org >> Subject: Re: [homenet] New Version Notification for >>draft-howard-homenet-routing- >> comparison-00.txt >> >> >> On 29 Dec 2011, at 22:33, Howard, Lee wrote: >> >> > I got tired of waiting for someone else to drive consensus on a >>routing solution >> >> If there is consensus, it's for zOSPF, if only because no-one else >>appears to believe strongly >> enough in their preferred solution to write a draft about it. > >I don't think there's consensus on zOSPF. I think there are a few strong >advocates and a lot of pointed silence I did present an alternative >(based on a draft), which had an equal mix of "interesting" and "bleah." > >The problem with zOSPF is that it doesn't meet our requirements. It >doesn't detect borders (unless the border happens to have another zOSPF >router with the wrong password), it requires configuration (for the >password), it doesn't handle walled gardens (a requirement being >debated), it's not lightweight. > >I'm trying to be fair, and not just protect the PIO proposal because I >proposed it. It needs work. Its biggest lack is the need for >hierarchical addressing, but I think >draft-baker-homenet-prefix-assignment solves that. I don't want to see >zOSPF adopted just because its advocates were louder. > >> I think Mark and I will need to make that call quite soon, but probably >>not until the authors >> of the architecture draft have incorporated the routing requirements >>and other comments >> since Taipei and put those into -01. > >My perception is that we have three people in favor of zOSPF, three >supporting a PIO, seven each supporting a different alternative, and 30 >silent. > >Lee > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use 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 dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From acee.lindem@ericsson.com Fri Jan 13 09:39:06 2012 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 892E621F869D for ; Fri, 13 Jan 2012 09:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, 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 TXy7bnLbxIG7 for ; Fri, 13 Jan 2012 09:39:02 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA721F852B for ; Fri, 13 Jan 2012 09:39:02 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0DHcxVB010986; Fri, 13 Jan 2012 11:39:01 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.25]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 13 Jan 2012 12:38:55 -0500 From: Acee Lindem To: "Howard, Lee" Date: Fri, 13 Jan 2012 12:38:52 -0500 Thread-Topic: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt Thread-Index: AczSGjg4ukmbmqUGRDWN/2dACQs6bQ== Message-ID: References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Bellis , "homenet@ietf.org" Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 13 Jan 2012 17:39:06 -0000 Hi Lee, See inline.=20 On Jan 13, 2012, at 11:49 AM, Howard, Lee wrote: >=20 >=20 >> -----Original Message----- >> From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] >> Sent: Tuesday, January 03, 2012 8:41 AM >> To: Howard, Lee >> Cc: homenet@ietf.org >> Subject: Re: [homenet] New Version Notification for draft-howard-homenet= -routing- >> comparison-00.txt >>=20 >>=20 >> On 29 Dec 2011, at 22:33, Howard, Lee wrote: >>=20 >>> I got tired of waiting for someone else to drive consensus on a routing= solution >>=20 >> If there is consensus, it's for zOSPF, if only because no-one else appea= rs to believe strongly >> enough in their preferred solution to write a draft about it. >=20 > I don't think there's consensus on zOSPF. I think there are a few strong= advocates and a lot of pointed silence I did present an alternative (based= on a draft), which had an equal mix of "interesting" and "bleah." First let's quit calling it zOSPF. It is OSPFv3 with auto-configuration.=20 >=20 > The problem with zOSPF is that it doesn't meet our requirements. It does= n't detect borders (unless the border happens to have another zOSPF router = with the wrong password), While this should be part of the solution, I don't see this as something th= at it necessarily should be built into the routing protocol.=20 > it requires configuration (for the password), How does any protocol do authentication w/o a shared key? If you don't do a= uthentication, you don't need a key.=20 > it doesn't handle walled gardens (a requirement being debated), I don't fully understand this requirement and how it would be handled w/o c= onfiguration.=20 > it's not lightweight. A commercial router implementation supporting all the features including OS= PF TE and VPNs is certainly not lightweight. However, I just downloaded the= latest quagga suite and it is only about 21K there.=20 Acee-Lindems-iMac-2:ospf6d ealflin$ wc -l *.[c.h]=20 875 ospf6_abr.c 78 ospf6_abr.h 787 ospf6_area.c 129 ospf6_area.h 1270 ospf6_asbr.c 95 ospf6_asbr.h 1027 ospf6_flood.c 66 ospf6_flood.h 1654 ospf6_interface.c 154 ospf6_interface.h 1578 ospf6_intra.c 220 ospf6_intra.h 1019 ospf6_lsa.c 254 ospf6_lsa.h 582 ospf6_lsdb.c 98 ospf6_lsdb.h 348 ospf6_main.c 2548 ospf6_message.c 149 ospf6_message.h 945 ospf6_neighbor.c 137 ospf6_neighbor.h 322 ospf6_network.c 50 ospf6_network.h 85 ospf6_proto.c 122 ospf6_proto.h 1409 ospf6_route.c 305 ospf6_route.h 535 ospf6_snmp.c 29 ospf6_snmp.h 701 ospf6_spf.c 94 ospf6_spf.h 707 ospf6_top.c 78 ospf6_top.h 697 ospf6_zebra.c 51 ospf6_zebra.h 1892 ospf6d.c 125 ospf6d.h 21215 total I'm not sure about commercial deployments, but I know this distribution has= been used as the basis for network research.=20 Thanks, Acee=20 >=20 > I'm trying to be fair, and not just protect the PIO proposal because I pr= oposed it. It needs work. Its biggest lack is the need for hierarchical a= ddressing, but I think draft-baker-homenet-prefix-assignment solves that. = I don't want to see zOSPF adopted just because its advocates were louder. >=20 >> I think Mark and I will need to make that call quite soon, but probably = not until the authors >> of the architecture draft have incorporated the routing requirements and= other comments >> since Taipei and put those into -01. >=20 > My perception is that we have three people in favor of zOSPF, three suppo= rting a PIO, seven each supporting a different alternative, and 30 silent. >=20 > Lee >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Fri Jan 13 12:40:55 2012 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 1C73521F852E for ; Fri, 13 Jan 2012 12:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_41=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 qqEeWzULpgyU for ; Fri, 13 Jan 2012 12:40:54 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 335D921F84AE for ; Fri, 13 Jan 2012 12:40:54 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id EABAF34470 for ; Fri, 13 Jan 2012 15:38:52 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 8DCA39845D; Fri, 13 Jan 2012 15:40:51 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 851BC98147 for ; Fri, 13 Jan 2012 15:40:51 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 13 Jan 2012 15:40:51 -0500 Message-ID: <12241.1326487251@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 13 Jan 2012 20:40:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Acee" =3D=3D Acee Lindem writes: >> The problem with zOSPF is that it doesn't meet our requirements. >> It doesn't detect borders (unless the border happens to have >> another zOSPF router with the wrong password), Acee> While this should be part of the solution, I don't see this as Acee> something that it necessarily should be built into the routing Acee> protocol. >> it requires configuration (for the password), Acee> How does any protocol do authentication w/o a shared key? If Acee> you don't do authentication, you don't need a key. Yes, this is a general problem, which is why I keep asking what are our real requirements here. >> it doesn't handle walled gardens (a requirement being debated), Acee> I don't fully understand this requirement and how it would be Acee> handled w/o configuration. I don't understand this criticism. Why are walled gardens different than multiple ISPs? >> it's not lightweight. Acee> A commercial router implementation supporting all the features Acee> including OSPF TE and VPNs is certainly not Acee> lightweight. However, I just downloaded the latest quagga Acee> suite and it is only about 21K there. rtr3-[/usr/pkg/sbin] mcr 10007 %size ospf6d /usr/pkg/lib/libzebra.so.0 text data bss dec hex filename 221476 11328 3132 235936 399a0 ospf6d 272449 23848 3120 299417 49199 /usr/pkg/lib/libzebra.so.0 No all of libzebra might really be used. So 11K code, plus up to 23K. I think that half of the code can be ripped out (and I wish I had time to do). =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUATxCW04qHRg3pndX9AQLLCwP+N4MCWouEIBC2Ce9LEH2iDBvtV9c4VZv1 50dwKOx9H6ououEeOPDqnPItlWLwvACibj9J+Wxb+IaUO8ioI7mwKtDZgIxpXKxK +vLbkLvz1qKOyutddk+U617ikzaJrWPqaJ/vKPi/WnlHgXLk1L96CcP18JYKe2yX m0kgyoPMYcE= =Lu4O -----END PGP SIGNATURE----- --=-=-=-- From acee.lindem@ericsson.com Fri Jan 13 13:03:59 2012 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 DF37321F852C for ; Fri, 13 Jan 2012 13:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 zPVA1LdYx2wA for ; Fri, 13 Jan 2012 13:03:59 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 47D0B21F8528 for ; Fri, 13 Jan 2012 13:03:59 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0DL3veb024024; Fri, 13 Jan 2012 15:03:58 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.25]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 13 Jan 2012 16:03:51 -0500 From: Acee Lindem To: Michael Richardson Date: Fri, 13 Jan 2012 16:03:49 -0500 Thread-Topic: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt Thread-Index: AczSNtmWDPO0LMgUTpCjyvYcK/i4AQ== Message-ID: <2541EE0E-4C7D-49F1-9E75-D2A22667A9FB@ericsson.com> References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> <12241.1326487251@marajade.sandelman.ca> In-Reply-To: <12241.1326487251@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 13 Jan 2012 21:04:00 -0000 Hi Michael, Can you provided a precise definition of "walled garden", as well as, defin= e the bi-directional connectivity rules with a few bullets (hopefully less = than 5).=20 I fear there may be more than one view of this (or possibly I'm the only on= e ;^).=20 Thanks, Acee=20 On Jan 13, 2012, at 3:40 PM, Michael Richardson wrote: >=20 >=20 >=20 >>>>>> "Acee" =3D=3D Acee Lindem writes: >>> The problem with zOSPF is that it doesn't meet our requirements. >>> It doesn't detect borders (unless the border happens to have >>> another zOSPF router with the wrong password), >=20 > Acee> While this should be part of the solution, I don't see this as > Acee> something that it necessarily should be built into the routing > Acee> protocol. >=20 >>> it requires configuration (for the password), >=20 > Acee> How does any protocol do authentication w/o a shared key? If > Acee> you don't do authentication, you don't need a key. >=20 > Yes, this is a general problem, which is why I keep asking what are our > real requirements here. >=20 >>> it doesn't handle walled gardens (a requirement being debated), >=20 > Acee> I don't fully understand this requirement and how it would be > Acee> handled w/o configuration. >=20 > I don't understand this criticism. Why are walled gardens different > than multiple ISPs? >=20 >>> it's not lightweight. >=20 > Acee> A commercial router implementation supporting all the features > Acee> including OSPF TE and VPNs is certainly not > Acee> lightweight. However, I just downloaded the latest quagga > Acee> suite and it is only about 21K there. >=20 > rtr3-[/usr/pkg/sbin] mcr 10007 %size ospf6d /usr/pkg/lib/libzebra.so.0 > text data bss dec hex filename > 221476 11328 3132 235936 399a0 ospf6d > 272449 23848 3120 299417 49199 /usr/pkg/lib/libzebra.so.0 >=20 > No all of libzebra might really be used. So 11K code, plus up to 23K. > I think that half of the code can be ripped out (and I wish I had time > to do). >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | firewa= lls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net arch= itect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device d= river[ > Kyoto Plus: watch the video > then sign the petition.=20 From v6ops@globis.net Fri Jan 13 13:04:17 2012 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 D834021F851D for ; Fri, 13 Jan 2012 13:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 3-rjqvCxdzCv for ; Fri, 13 Jan 2012 13:04:04 -0800 (PST) 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 F3CF811E8072 for ; Fri, 13 Jan 2012 13:04:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 730A78700D9; Fri, 13 Jan 2012 22:04:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 1pKNuhk8AXfa; Fri, 13 Jan 2012 22:03:55 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B2B3387007E; Fri, 13 Jan 2012 22:03:55 +0100 (CET) Message-ID: <4F109C3B.9090707@globis.net> Date: Fri, 13 Jan 2012 22:03:55 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Howard, Lee" References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090705010600020400030106" Cc: Ray Bellis , Acee Lindem , "homenet@ietf.org" Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 13 Jan 2012 21:04:18 -0000 This is a multi-part message in MIME format. --------------090705010600020400030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit How would PIO cope with marginal / ad hoc L2 wireless associations that can come and go depending on local radio conditions? [A can always see B, B can always see C, but A can only sometimes see C] Unless we're assuming all Homenet inter-router links are wired (which is certainly not the case in my house) AFAIK OSPFv3 has better support for routing over ad hoc wireless links if necessary (MANET). I believe most "traditional" routing protocols cannot cope well with this challenge. e.g IS-IS could fail to elect a Designated Intermediate System visible to all nodes. regards, RayH Acee Lindem wrote: > Hi Lee, > > See inline. > > On Jan 13, 2012, at 11:49 AM, Howard, Lee wrote: > > >> >>> -----Original Message----- >>> From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] >>> Sent: Tuesday, January 03, 2012 8:41 AM >>> To: Howard, Lee >>> Cc: homenet@ietf.org >>> Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing- >>> comparison-00.txt >>> >>> >>> On 29 Dec 2011, at 22:33, Howard, Lee wrote: >>> >>> >>>> I got tired of waiting for someone else to drive consensus on a routing solution >>>> >>> If there is consensus, it's for zOSPF, if only because no-one else appears to believe strongly >>> enough in their preferred solution to write a draft about it. >>> >> I don't think there's consensus on zOSPF. I think there are a few strong advocates and a lot of pointed silence I did present an alternative (based on a draft), which had an equal mix of "interesting" and "bleah." >> > > First let's quit calling it zOSPF. It is OSPFv3 with auto-configuration. > > >> The problem with zOSPF is that it doesn't meet our requirements. It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password), >> > > While this should be part of the solution, I don't see this as something that it necessarily should be built into the routing protocol. > > >> it requires configuration (for the password), >> > > How does any protocol do authentication w/o a shared key? If you don't do authentication, you don't need a key. > > >> it doesn't handle walled gardens (a requirement being debated), >> > > I don't fully understand this requirement and how it would be handled w/o configuration. > > >> it's not lightweight. >> > > A commercial router implementation supporting all the features including OSPF TE and VPNs is certainly not lightweight. However, I just downloaded the latest quagga suite and it is only about 21K there. > > Acee-Lindems-iMac-2:ospf6d ealflin$ wc -l *.[c.h] > 875 ospf6_abr.c > 78 ospf6_abr.h > 787 ospf6_area.c > 129 ospf6_area.h > 1270 ospf6_asbr.c > 95 ospf6_asbr.h > 1027 ospf6_flood.c > 66 ospf6_flood.h > 1654 ospf6_interface.c > 154 ospf6_interface.h > 1578 ospf6_intra.c > 220 ospf6_intra.h > 1019 ospf6_lsa.c > 254 ospf6_lsa.h > 582 ospf6_lsdb.c > 98 ospf6_lsdb.h > 348 ospf6_main.c > 2548 ospf6_message.c > 149 ospf6_message.h > 945 ospf6_neighbor.c > 137 ospf6_neighbor.h > 322 ospf6_network.c > 50 ospf6_network.h > 85 ospf6_proto.c > 122 ospf6_proto.h > 1409 ospf6_route.c > 305 ospf6_route.h > 535 ospf6_snmp.c > 29 ospf6_snmp.h > 701 ospf6_spf.c > 94 ospf6_spf.h > 707 ospf6_top.c > 78 ospf6_top.h > 697 ospf6_zebra.c > 51 ospf6_zebra.h > 1892 ospf6d.c > 125 ospf6d.h > 21215 total > > I'm not sure about commercial deployments, but I know this distribution has been used as the basis for network research. > > Thanks, > Acee > > > >> I'm trying to be fair, and not just protect the PIO proposal because I proposed it. It needs work. Its biggest lack is the need for hierarchical addressing, but I think draft-baker-homenet-prefix-assignment solves that. I don't want to see zOSPF adopted just because its advocates were louder. >> >> >>> I think Mark and I will need to make that call quite soon, but probably not until the authors >>> of the architecture draft have incorporated the routing requirements and other comments >>> since Taipei and put those into -01. >>> >> My perception is that we have three people in favor of zOSPF, three supporting a PIO, seven each supporting a different alternative, and 30 silent. >> >> Lee >> >> >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > --------------090705010600020400030106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit How would PIO cope with marginal / ad hoc L2 wireless associations that can come and go depending on local radio conditions?
[A can always see B, B can always see C, but A can only sometimes see C]

Unless we're assuming all Homenet inter-router links are wired (which is certainly not the case in my house)

AFAIK OSPFv3 has better support for routing over ad hoc wireless links if necessary (MANET).

I believe most "traditional" routing protocols cannot cope well with this challenge.
e.g IS-IS could fail to elect a Designated Intermediate System visible to all nodes.

regards,
RayH


Acee Lindem wrote: 
Hi Lee,

See inline. 

On Jan 13, 2012, at 11:49 AM, Howard, Lee wrote:

  
    
-----Original Message-----
From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk]
Sent: Tuesday, January 03, 2012 8:41 AM
To: Howard, Lee
Cc: homenet@ietf.org
Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-
comparison-00.txt


On 29 Dec 2011, at 22:33, Howard, Lee wrote:

      
I got tired of waiting for someone else to drive consensus on a routing solution
        
If there is consensus, it's for zOSPF, if only because no-one else appears to believe strongly
enough in their preferred solution to write a draft about it.
      
I don't think there's consensus on zOSPF.  I think there are a few strong advocates and a lot of pointed silence I did present an alternative (based on a draft), which had an equal mix of "interesting" and "bleah."
    

First let's quit calling it zOSPF. It is OSPFv3 with auto-configuration. 

  
The problem with zOSPF is that it doesn't meet our requirements.  It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password),
    

While this should be part of the solution, I don't see this as something that it necessarily should be built into the routing protocol. 

  
it requires configuration (for the password),
    

How does any protocol do authentication w/o a shared key? If you don't do authentication, you don't need a key. 

  
it doesn't handle walled gardens (a requirement being debated),
    

I don't fully understand this requirement and how it would be handled w/o configuration. 

  
it's not lightweight.
    

A commercial router implementation supporting all the features including OSPF TE and VPNs is certainly not lightweight. However, I just downloaded the latest quagga suite and it is only about 21K there. 

Acee-Lindems-iMac-2:ospf6d ealflin$ wc -l  *.[c.h] 
     875 ospf6_abr.c
      78 ospf6_abr.h
     787 ospf6_area.c
     129 ospf6_area.h
    1270 ospf6_asbr.c
      95 ospf6_asbr.h
    1027 ospf6_flood.c
      66 ospf6_flood.h
    1654 ospf6_interface.c
     154 ospf6_interface.h
    1578 ospf6_intra.c
     220 ospf6_intra.h
    1019 ospf6_lsa.c
     254 ospf6_lsa.h
     582 ospf6_lsdb.c
      98 ospf6_lsdb.h
     348 ospf6_main.c
    2548 ospf6_message.c
     149 ospf6_message.h
     945 ospf6_neighbor.c
     137 ospf6_neighbor.h
     322 ospf6_network.c
      50 ospf6_network.h
      85 ospf6_proto.c
     122 ospf6_proto.h
    1409 ospf6_route.c
     305 ospf6_route.h
     535 ospf6_snmp.c
      29 ospf6_snmp.h
     701 ospf6_spf.c
      94 ospf6_spf.h
     707 ospf6_top.c
      78 ospf6_top.h
     697 ospf6_zebra.c
      51 ospf6_zebra.h
    1892 ospf6d.c
     125 ospf6d.h
   21215 total

I'm not sure about commercial deployments, but I know this distribution has been used as the basis for network research. 

Thanks,
Acee 


  
I'm trying to be fair, and not just protect the PIO proposal because I proposed it.  It needs work.  Its biggest lack is the need for hierarchical addressing, but I think draft-baker-homenet-prefix-assignment solves that.  I don't want to see zOSPF adopted just because its advocates were louder.

    
I think Mark and I will need to make that call quite soon, but probably not until the authors
of the architecture draft have incorporated the routing requirements and other comments
since Taipei and put those into -01.
      
My perception is that we have three people in favor of zOSPF, three supporting a PIO, seven each supporting a different alternative, and 30 silent.

Lee


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--------------090705010600020400030106-- From ot@cisco.com Fri Jan 13 14:38:55 2012 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 61B1221F861F for ; Fri, 13 Jan 2012 14:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 SRj-ziHDpaAX for ; Fri, 13 Jan 2012 14:38:54 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5B82C21F861E for ; Fri, 13 Jan 2012 14:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=2926; q=dns/txt; s=iport; t=1326494334; x=1327703934; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=v7TUQt2kB/F2fDqzbvGyKDQO+AUnNu09JwKkKxSeb7U=; b=EjY+hfI/km9oihUdfTthp7CwgYKhpH3bsi/I5PadJqstFyIWPecP7chP t76JJpQqQ+vZU4oTyiFF/b3DhLPN6lTkHEoDN8/n/mgNOjwvshDO4mlUF LUiZc6c29Cm8pkPDso79v+jJzZtgDXIwmYoc1dc5Cy29wr+mhoIJeAK2h g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMWxEE+Q/khM/2dsb2JhbABCrTKBBYFyAQEBAwEBAQEPASc0CQIFCwswFhwLMAYTGQIHh1gImGgBjSWDdo0Og32FBoI3YwSGc44fi1+GYQ X-IronPort-AV: E=Sophos;i="4.71,506,1320624000"; d="scan'208";a="63581598" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Jan 2012 22:38:53 +0000 Received: from dhcp-10-55-91-162.cisco.com (dhcp-10-55-91-162.cisco.com [10.55.91.162]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0DMcqXm000952; Fri, 13 Jan 2012 22:38:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <2541EE0E-4C7D-49F1-9E75-D2A22667A9FB@ericsson.com> Date: Fri, 13 Jan 2012 23:38:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> <12241.1326487251@marajade.sandelman.ca> <2541EE0E-4C7D-49F1-9E75-D2A22667A9FB@ericsson.com> To: Acee Lindem X-Mailer: Apple Mail (2.1084) Cc: "homenet@ietf.org" , Michael Richardson Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 13 Jan 2012 22:38:55 -0000 > Can you provided a precise definition of "walled garden", as well as, = define the bi-directional connectivity rules with a few bullets = (hopefully less than 5).=20 > I fear there may be more than one view of this (or possibly I'm the = only one ;^).=20 I presume we are talking about multi-homing to non-congruent topologies. as described here = http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6n= at-03 not sure what exact problems with walled gardens would affect routing = though.=20 cheers, Ole >>>>>>> "Acee" =3D=3D Acee Lindem writes: >>>> The problem with zOSPF is that it doesn't meet our requirements. >>>> It doesn't detect borders (unless the border happens to have >>>> another zOSPF router with the wrong password), >>=20 >> Acee> While this should be part of the solution, I don't see this = as >> Acee> something that it necessarily should be built into the = routing >> Acee> protocol. >>=20 >>>> it requires configuration (for the password), >>=20 >> Acee> How does any protocol do authentication w/o a shared key? If >> Acee> you don't do authentication, you don't need a key. >>=20 >> Yes, this is a general problem, which is why I keep asking what are = our >> real requirements here. >>=20 >>>> it doesn't handle walled gardens (a requirement being debated), >>=20 >> Acee> I don't fully understand this requirement and how it would be >> Acee> handled w/o configuration. >>=20 >> I don't understand this criticism. Why are walled gardens different >> than multiple ISPs? >=20 >=20 >=20 >=20 >=20 >>=20 >>>> it's not lightweight. >>=20 >> Acee> A commercial router implementation supporting all the = features >> Acee> including OSPF TE and VPNs is certainly not >> Acee> lightweight. However, I just downloaded the latest quagga >> Acee> suite and it is only about 21K there. >>=20 >> rtr3-[/usr/pkg/sbin] mcr 10007 %size ospf6d = /usr/pkg/lib/libzebra.so.0 >> text data bss dec hex filename >> 221476 11328 3132 235936 399a0 ospf6d >> 272449 23848 3120 299417 49199 /usr/pkg/lib/libzebra.so.0 >>=20 >> No all of libzebra might really be used. So 11K code, plus up to = 23K. >> I think that half of the code can be ripped out (and I wish I had = time >> to do). >>=20 >> --=20 >> ] He who is tired of Weird Al is tired of life! | = firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >> Kyoto Plus: watch the video = >> then sign the petition.=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Mon Jan 16 11:32:16 2012 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 BA5DE21F8683 for ; Mon, 16 Jan 2012 11:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, 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 q2m5ieBMjLG6 for ; Mon, 16 Jan 2012 11:32:16 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7421F8682 for ; Mon, 16 Jan 2012 11:32:15 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id E530234456; Mon, 16 Jan 2012 14:30:11 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 61823CD583; Mon, 16 Jan 2012 14:32:12 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5C3ACDD18D; Mon, 16 Jan 2012 14:32:12 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: <2541EE0E-4C7D-49F1-9E75-D2A22667A9FB@ericsson.com> References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> <12241.1326487251@marajade.sandelman.ca> <2541EE0E-4C7D-49F1-9E75-D2A22667A9FB@ericsson.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 16 Jan 2012 14:32:12 -0500 Message-ID: <30842.1326742332@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Acee Lindem Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 16 Jan 2012 19:32:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Acee" =3D=3D Acee Lindem writes: Acee> Hi Michael, Can you provided a precise definition of "walled Acee> garden", as well as, define the bi-directional connectivity Acee> rules with a few bullets (hopefully less than 5). I fear there Acee> may be more than one view of this (or possibly I'm the only Acee> one ;^). I don't have a precise definition. This is what I would advance: + A walled-garden network is provided by a service-specific internet service provider (SS/ISP) to a residential or small office.=20=20 + The service-specific connection is in the form of a dedicated WAN link = into the dwelling. (The link may be physical or might be carried by a virtual layer-2). Some dwellings may have only the service specific connection. + The service-specific connection provides access to a service (IPTV is a known example), and is not general Internet service. + The IPv6 service is reachable only using IPv6 from a block that the service-specific ISP will allocate to the residence using regular mechanism.=20=20 + The IPv6 service is numbered using globally unique IPv6 addresses, which are usually not accessible outside of the "garden", i.e. they are not routed in the global Default-Free Zone. + In IPv6, no special DNS tricks are required to make the clients systems pick the right target address. Multiple AAAA records,=20 (possibly with walled-garden ACLs on authoritative servers) and happy eyeballs is enough. A walled-garden is no different than a multiple ISPs in a residence, except that general internet traffic does not transit that connection. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 =20=20=20=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUATxR7PIqHRg3pndX9AQJ8iwP+L/ghatMXg1Qap/QExTFyrZo0RiBB1LME aNcDQ3ULsIyDMTfpG+W1apxDIpDrJl0+cRMNqsMCiEgIeuOXRMn5SAmoAuC9E75l FRpX5BqQKyOhamfgbNTNrJEm0S3sa/oHlJHqSJR2T/5sIqObhbTWK3yy1V6gZmF1 CSaKgos3Y68= =dZsz -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Jan 16 17:29:11 2012 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 B8E2921F85E4 for ; Mon, 16 Jan 2012 17:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, SARE_MONEYTERMS=0.681] 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 Qos8RygbXr6v for ; Mon, 16 Jan 2012 17:29:10 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id CEAB921F85AA for ; Mon, 16 Jan 2012 17:29:10 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id C3CBE3446F for ; Mon, 16 Jan 2012 20:27:07 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 739809845D; Mon, 16 Jan 2012 20:29:08 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6ED0A98147 for ; Mon, 16 Jan 2012 20:29:08 -0500 (EST) From: Michael Richardson To: homenet@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 16 Jan 2012 20:29:08 -0500 Message-ID: <9482.1326763748@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] some comments on baker-homenet-prefix-assignment 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, 17 Jan 2012 01:29:11 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I finally read draft-baker-homenet-prefix-assignment on my way home on Frid= ay.=A0 This mechanism is that I had expected that we would use. I agree that=20 draft-arkko-homenet-prefix-assignment-01 might take fewer messages and less code. I had a few minor comments which are appended below, but I had two general questions.=20 First, I think that the RAAI option first describe in section 3.1.1 is a new creation; certainly by the IANA considerations, that is clear, but at first I thought maybe that this was yet-another-RA-option I did not know about... Section 5 gives the abstract for what I think is a new option. Should this concept go forward, I suggest that the name of this option go into the title of the document, as in: Using the Router Advertisement Allocator Information (RAAI) for subnet allocation in Home Networks. Second, the process by which the two routers in section 3.1.2.2 hear each other and release the prefix was a bit startling! It wasn't until the last paragraph of 4.3 that some addition to the algorithm is mentioned. minor comments: 1. To avoid duplicate address assignment, a router first listens for RAs on the link attached to its downstream interface. If the router does not receive an RA after listening for INTERVAL1 microfortnights, the Assuming that my calculation is correct, and microfortnights are approximately 1.2s, my feeling is that this dead time should be on the order of 16 microfortnights (20s). I base this number upon the time it wou= ld take me to replace my home router back on the shelf after rebooting it, then walk back to the kitchen table, and check to see if my laptop got an address. Another 10s later, I'm back at the router to wonder if it really rebooted again. 2. why doesn't a router send a RS on the link first? Given multiple ISPs, it may be entirely reasonable that the interface is in fact downstream for another prefix, and an upstream interface for another, so the RS isn't even wasted.=20 3. a link would seem to be unclaimed if (a/one or more) RS is heard on the link, and no RA is later heard. As I recall, RAs in response to RS may be unicast, but, why can't the router in question send it's own RS to verify connectivity. Here is where the zOSPFv3 method may be more productive. 4. It seems that an ISP might well return a RAAI to a client machine, and if it did so, it could allocate as many or as few /64s as each customer needs, at the cost for it, of additional routing entries. I realize that this might be undesireable from an architectural point of view, but I can see occuring in some informal multi-tenant situations, where the "building" starts initially as a single tenant, and grows. As such, it may be useful to put a flag in the RAAI that says, "I am a security boundary". =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 =20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUATxTO5IqHRg3pndX9AQI4igQAyusW62xNwRzRBL8hRfz1vtQPVDVh2psE Qdyw980dF6YZplaptHSGYKacBpSgIppuDzT/FtK69Tg7G0z4wM9374LxN2+enErR VaxW7MZRHIOSVVAak0x8TB/LTC4jo/Qp+CEIAmOfo/mIOQGQe+0dlOdx8VooElZc FoXENMZGt/A= =WGj2 -----END PGP SIGNATURE----- --=-=-=-- From jari.arkko@piuha.net Fri Jan 20 05:54:33 2012 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 BDC0421F8589 for ; Fri, 20 Jan 2012 05:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 1uqzz9-V-p2A for ; Fri, 20 Jan 2012 05:54:33 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E41AA21F8578 for ; Fri, 20 Jan 2012 05:54:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 32CC22CC44; Fri, 20 Jan 2012 15:54:31 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUZ_pKUPF46G; Fri, 20 Jan 2012 15:54:30 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 05A342CC39; Fri, 20 Jan 2012 15:54:29 +0200 (EET) Message-ID: <4F197215.3020600@piuha.net> Date: Fri, 20 Jan 2012 15:54:29 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: "Howard, Lee" References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Bellis , "homenet@ietf.org" Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 20 Jan 2012 13:54:33 -0000 Lee, I have to send a more in-depth review of your draft later, but just touching on a couple of important points: > The problem with zOSPF is that it doesn't meet our requirements. It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password), The problem is that we have incomplete proposals, and people are making evaluations based on assumptions on what those incomplete specification or implementation parts might be. We also have a _system_, not an individual protocol, and several protocol implementation modules need to co-operate so that the system delivers the desired behavior. For instance, if we think about the home network as a black box, it needs to talk to external world probably at least with DHCP and DHCP-PD, talk to hosts within the network with ND, do something for naming and discovery protocols, etc. Internally, it may do something black box magic for the routing and other things, of course. A case in point. I'm working on an implementation that most definitely detects borders, and still uses OSPF autoconfiguration to handle routing. How does it detect borders? It attempts to do DHCP, DHCP-PD, OSPF autoconfiguration, and the usual "I have a working connection to the Internet" probing techniques. It also allows for manual configuration, or the "this port is for Internet, the other one is for internal network" models. > it requires configuration (for the password), Acee's autoconfiguration design is nice in that it can be guaranteed to not accidentally connect to enterprise and ISP networks simply due to the selection of the area and instance IDs. See Section 2 in draft-acee. I think it would be useful to provide an automatic security model on top of the autoconfiguration design, and some ideas for that have been circulated on the list. But I would think that the security model and issues in setting it up are very similar between different routing protocol-based designs and with the PIO design. For instance, we can provide ssh-like security relatively easily, but if you want to go beyond that then you must have configuration. > it doesn't handle walled gardens (a requirement being debated), it's not lightweight. I agree that link state routing protocols are a bigger amount of code than, say, RIP. But I think the crux is code availability and reliability, rather than pure measurement of lines of code. Most home network vendors would use an openly available implementation rather than write their own, so having one available is more important than the number of lines in it. I think I have seen the working group favor support for complex topologies, preventing user action from leading to non-working network more than for absolutely simplicity. I think for absolute simplicity and code availability, RIP could be our choice. Jari From jari.arkko@piuha.net Fri Jan 20 06:19:44 2012 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 7E77921F853C for ; Fri, 20 Jan 2012 06:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 f5AenTBShoD8 for ; Fri, 20 Jan 2012 06:19:44 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id F337B21F8539 for ; Fri, 20 Jan 2012 06:19:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CE54E2CC44; Fri, 20 Jan 2012 16:19:42 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G3Bbrxi5yMy; Fri, 20 Jan 2012 16:19:42 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6576F2CC39; Fri, 20 Jan 2012 16:19:42 +0200 (EET) Message-ID: <4F1977FE.4070709@piuha.net> Date: Fri, 20 Jan 2012 16:19:42 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: "Howard, Lee" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] FW: New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 20 Jan 2012 14:19:44 -0000 Many thanks for writing the draft(s)! > In particular, I have no knowledge of MANEMO or RPL, so I can't evaluate them. MANEMO probably shouldn't be here, since there isn't even a draft to point to. I think you can delete the MANEMO part. MANEMO was loose collection of ideas roughly in the same direction as your PIO proposal. For RPL, IS-IS, etc. you'll find that you have to come up with some additional ideas on how the other aspects of the home network are handled, not just the pure routing part. (For this reason, it might actually be useful to break down the analysis a bit. For the pure routing part, PIO-RIP-OSPFAC differ in such and such ways. The mechanisms for border detection are A-B-C and they differ in these other ways. Etc.) Jari From jari.arkko@piuha.net Fri Jan 20 06:55:31 2012 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 3A1FA21F8592 for ; Fri, 20 Jan 2012 06:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 j4ENA0ydzEub for ; Fri, 20 Jan 2012 06:55:30 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 9063C21F8587 for ; Fri, 20 Jan 2012 06:55:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 10EFB2CC44; Fri, 20 Jan 2012 16:55:25 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1v9ZrozPbjY; Fri, 20 Jan 2012 16:55:21 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 139B22CC39; Fri, 20 Jan 2012 16:55:21 +0200 (EET) Message-ID: <4F198058.4030309@piuha.net> Date: Fri, 20 Jan 2012 16:55:20 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: draft-howard-homenet-routing-requirements@tools.ietf.org, "Howard, Lee" , "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] comments on draft-howard-homenet-routing-requirements 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, 20 Jan 2012 14:55:31 -0000 Thanks again for writing this document. A couple of comments: In general, I agree with almost all of the requirements. A couple of discussion points, however: #rant on I think we as a group as pretty over-focused on multihoming and I'm not sure I buy the "multiple upstream networks" requirement in its entirety. I don't have a better suggestion, and I know many people in the group have talked about things along these lines. However, as a reality check, I'm aware of only a handful of people (myself included) who actually run multihomed networks in their homes. Within that set of people, most seem to be doing it in some more special way rather than as a general-purpose hot-standby multihoming network (myself included). I'm also concerned that since our WG consists of many well-known multihoming hopefuls from various IETF efforts over the years (myself included), that we are taking our own wishes more than the reality as a basis of our design. In particular, what I *do* see being very widely deployed is separate networks. I have plenty, for instance, because my utility providers want to do their own thing and they just don't trust my networks. They have their own device/router, own uplinks. I think we will see more of this in the coming years as smart grids etc. are coming online. But the multiple upstream networks requirements says very little about this case. But I think it would be possible to provide better support for using shared infrastructure, yet different networks in a home setting. I just don't think we would necessarily think about that in the light of destinations and sources addresses... perhaps more in the light of separate VLANs, separate OSPF instance IDs, and so on. All that being said, I think the statement from the interim which said that we should offer the ability to have multiple upstream links was useful. Still, I think those requirements are more in the optional category. #rant off The looping requirement avoids the interesting details. "Prevent" or "live with"? Any topology? Personally, I'm in James Woodyatt's camp and believe that we must survive trial-and-error plug-in exercises by the users. The requirements draft did not talk about walled gardens. From the comparison draft 6F, I had trouble understanding what exactly is required. I also do not personally believe we should go out of our way in the IETF to support walled gardens. Jari From v6ops@globis.net Sat Jan 21 04:23:42 2012 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 6161E21F8537 for ; Sat, 21 Jan 2012 04:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 tNHWGQgNiPMO for ; Sat, 21 Jan 2012 04:23:41 -0800 (PST) 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 4E83821F85D8 for ; Sat, 21 Jan 2012 04:23:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 587A88700E2; Sat, 21 Jan 2012 13:23:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 bSOVUkLuuZUo; Sat, 21 Jan 2012 13:23:34 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 988928700E1; Sat, 21 Jan 2012 13:23:34 +0100 (CET) Message-ID: <4F1AAE46.30404@globis.net> Date: Sat, 21 Jan 2012 13:23:34 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Michael Richardson References: <89BEBB84-AE13-433E-8322-E3EEF045E4F5@nominet.org.uk> <12241.1326487251@marajade.sandelman.ca> <2541EE0E-4C7D-49F1-9E75-D2A22667A9FB@ericsson.com> <30842.1326742332@marajade.sandelman.ca> In-Reply-To: <30842.1326742332@marajade.sandelman.ca> Content-Type: multipart/alternative; boundary="------------060908000906090704040307" Cc: "homenet@ietf.org" , Acee Lindem Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt 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, 21 Jan 2012 12:23:42 -0000 This is a multi-part message in MIME format. --------------060908000906090704040307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit What is wrong with applying the Autonomous System concept to Homenet (as defined in RFC1930)? IMVHO a number of problems might become clearer if Homenet explicitly acknowledged management boundaries and potential conflicts in routing policy. Under RFC1930: Homenet would be classified as a multi-homed site. A "Walled Garden" would then be when a Homenet AS has a private peering with a non-transit AS. On the upside, there's also a number of private AS numbers reserved for use if needed. Interestingly enough, applying the AS model also highlights a potential downside weakness in the current RFC6204 & 6204bis documents (which seem to assume that the customer's site is an integral part of a single provider's AS, and not an independent entity with its own routing policy), and PD & DHCPv6 (the protocol does not contain an AS number, and a Homenet may communicate with multiple non-coordinated sources of management information). BTW I am not explicitly advocating BGP. regards, RayH Michael Richardson wrote: >>>>>> "Acee" == Acee Lindem writes: >>>>>> > Acee> Hi Michael, Can you provided a precise definition of "walled > Acee> garden", as well as, define the bi-directional connectivity > Acee> rules with a few bullets (hopefully less than 5). I fear there > Acee> may be more than one view of this (or possibly I'm the only > Acee> one ;^). > > I don't have a precise definition. > This is what I would advance: > > + A walled-garden network is provided by a service-specific internet > service provider (SS/ISP) to a residential or small office. > + The service-specific connection is in the form of a dedicated WAN link into > the dwelling. (The link may be physical or might be carried by a virtual > layer-2). Some dwellings may have only the service specific connection. > + The service-specific connection provides access to a service > (IPTV is a known example), and is not general Internet service. > + The IPv6 service is reachable only using IPv6 from a block that the > service-specific ISP will allocate to the residence using regular > mechanism. > + The IPv6 service is numbered using globally unique IPv6 addresses, > which are usually not accessible outside of the "garden", i.e. they > are not routed in the global Default-Free Zone. > + In IPv6, no special DNS tricks are required to make the clients > systems pick the right target address. Multiple AAAA records, > (possibly with walled-garden ACLs on authoritative servers) and > happy eyeballs is enough. > > A walled-garden is no different than a multiple ISPs in a residence, > except that general internet traffic does not transit that connection. > > --------------060908000906090704040307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit What is wrong with applying the Autonomous System concept to Homenet (as defined in RFC1930)?

IMVHO a number of problems might become clearer if Homenet explicitly acknowledged management boundaries and potential conflicts in routing policy.

Under RFC1930: Homenet would be classified as a multi-homed site.

A "Walled Garden" would then be when a Homenet AS has a private peering with a non-transit AS.

On the upside, there's also a number of private AS numbers reserved for use if needed.

Interestingly enough, applying the AS model also highlights a potential downside weakness in the current RFC6204 & 6204bis documents (which seem to assume that the customer's site is an integral part of a single provider's AS, and not an independent entity with its own routing policy), and PD & DHCPv6 (the protocol does not contain an AS number, and a Homenet may communicate with multiple non-coordinated sources of management information).

BTW I am not explicitly advocating BGP.

regards,
RayH

Michael Richardson wrote: 
"Acee" == Acee Lindem <acee.lindem@ericsson.com> writes:
            
    Acee> Hi Michael, Can you provided a precise definition of "walled
    Acee> garden", as well as, define the bi-directional connectivity
    Acee> rules with a few bullets (hopefully less than 5). I fear there
    Acee> may be more than one view of this (or possibly I'm the only
    Acee> one ;^).

I don't have a precise definition.
This is what I would advance:

  + A walled-garden network is provided by a service-specific internet
    service provider (SS/ISP) to a residential or small office.  
  + The service-specific connection is in the form of a dedicated WAN link into
    the dwelling. (The link may be physical or might be carried by a virtual
    layer-2).  Some dwellings may have only the service specific connection.
  + The service-specific connection provides access to a service
    (IPTV is a known example), and is not general Internet service.
  + The IPv6 service is reachable only using IPv6 from a block that the
    service-specific ISP will allocate to the residence using regular
    mechanism.  
  + The IPv6 service is numbered using globally unique IPv6 addresses,
    which are usually not accessible outside of the "garden", i.e. they
    are not routed in the global Default-Free Zone.
  + In IPv6, no special DNS tricks are required to make the clients
    systems pick the right target address.  Multiple AAAA records, 
    (possibly with walled-garden ACLs on authoritative servers) and
    happy eyeballs is enough.

A walled-garden is no different than a multiple ISPs in a residence,
except that general internet traffic does not transit that connection.
--------------060908000906090704040307-- From internet-drafts@ietf.org Mon Jan 30 08:39:07 2012 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 EA8FE11E8072; Mon, 30 Jan 2012 08:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 QG8OvYkK0Eoy; Mon, 30 Jan 2012 08:39:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35311E8071; Mon, 30 Jan 2012 08:38:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 08:38:45 -0800 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-01.txt 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, 30 Jan 2012 16:39:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Home Networking Working Group of the = IETF. Title : Home Networking Architecture for IPv6 Author(s) : Jari Arkko Anders Brandt Tim Chown Jason Weil Ole Troan Filename : draft-ietf-homenet-arch-01.txt Pages : 34 Date : 2012-01-30 This text describes evolving networking technology within small "residential home" networks. The goal of this memo is to define the architecture for IPv6-based home networking and the associated principles, considerations and requirements. The text highlights the impact of IPv6 on home networking, illustrates topology scenarios, and shows how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-homenet-arch-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-homenet-arch-01.txt From mcr@sandelman.ca Mon Jan 30 12:08:28 2012 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 B166A21F8644 for ; Mon, 30 Jan 2012 12:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 94fPa5BNqwit for ; Mon, 30 Jan 2012 12:08:28 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5C21F863C for ; Mon, 30 Jan 2012 12:08:27 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 051A934491 for ; Mon, 30 Jan 2012 15:06:17 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 680AA984EE; Mon, 30 Jan 2012 15:08:25 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5BAC9984ED for ; Mon, 30 Jan 2012 15:08:25 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 30 Jan 2012 15:08:25 -0500 Message-ID: <7355.1327954105@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-01.txt 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, 30 Jan 2012 20:08:28 -0000 Thanks for this update! (to all: If you haven't tried the rfcdiff tool, I highly recommend it http://tools.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-01 ) I notice the additional text in the security area. I am still uncomfortable about "Advanced security" being in scope, as RFC6092 already exists, but does not spell out PCP vs uPNP at all. (never mentioned in that document, uPNP mentioned in 4864). If our document simply specifies (one, or makes the security mechanism discoverable), then I would be very very happy. re, router is well known at 192.168.1.1, we could very well define (IANA action) some ULA-C space from fec0::/7 as being always a router. "fec0::1" (/128) maybe. That could easily go into a DNS name that the router vendor would provide. Scenario F has been added, which I think is rather reasonable. Nobody so far has shouted that any of the scenarios are completely unrealistic. I feel that they are all relevant. This paragraph is too inclusive (wishy-washy) if taken out of context of the subsequent text: The general approach for IPv6 multihoming is for a hosts to receive multiple addresses from multiple providers, and to select the appropriate source address to communicate via a given provider. An alternative is to deploy ULAs with a site and then use NPTv6 [RFC6296], a prefix translation-based mechanism, at the edge. This obviously comes at some architectural cost, which is why approaches such as [I-D.v6ops-multihoming-without-ipv6nat] have been suggested. There has been much work on multihoming in the IETF, without (yet) widespread deployment of proposed solutions. Host-based methods such as Shim6 [RFC5533] have also been defined, but of course require support in the hosts. I would like MH3 to use a stronger term than "desireable". change: MH4) Solutions that REQUIRE host changes should be avoided, but solutions which incrementally improve with host changes MAY be acceptable. (I'm thinking shim6 here!) change: MH7) "Just" picking the right source address to use to fall foul of ingress filtering on upstream ISP connections (as per Network Model D) is not a trivial task. A solution is highly desirable, but out of scope of homenet. to: MH7) Picking the wrong source address will run afoul of upstream ISP ingress filtering on upstream ISP connections (as per Network Model D). However, "just" picking the right source address is not a trivial task. A solution is highly desirable, but out of scope of homenet. Solutions SHOULD assume that "Happy Eyeballs" (reference?) solutions do exist on hosts, and that hosts/applications will try all combinations of destination addresses. (MH8 says more about this, and maybe some it is redundant) I have read the rest of the document, and I had no further comments. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.