On Thu, Jul 4, 2013 at 4:24 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

Matthieu Boutier and myself hav= e just submitted

=A0 http://www.ietf.org/id/draft-boutier-hom= enet-source-specific-routing-00.txt

which describes our experience with an extension to the Babel routing
protocol with support for source-specific routing.

Er... did you read http://tools.ietf.org/html/draft-troan-homenet-sadr-00 =A0before submitting this? With the exception of the text on babel, a lo= t of the material you wrote is already covered there.=A0

On Sat, Jun 29, 2013 at 5:13 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

> We'll expect each host to announce N routing entries, one per
=

> address, and document things as such.

[...]

> I assume the implementation does this today, then?

The standalone babeld implementation does this by default. =A0The
implementation included in Quagga has defaults consistent with the
other routing protocols included in Quagga, and needs some
reconfiguration to behave as you desire.

Please have a look at

=A0 http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/

Snazzy!

A couple of thin= gs aren't clear to me, though:

1. How does this support the IPv6 subnet model with lin= k-local multicast and link-local addresses and so on? The IPv6 over Etherne= t RFC sort of relies on that to work, and I'm wondering if it makes ass= umptions that don't hold in a situation where every host has to announc= e /128s.

2. Also, what about DAD? If all the hosts participate in the routing p= rotocol, you can implement DAD over that, but what about current hosts?
=

Cheers,
Lorenzo

--bcaec547c61f87e99604e0af31cc-- From mcr@sandelman.ca Thu Jul 4 06:57:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5711E8121 for ; Thu, 4 Jul 2013 06:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmq4128nCW9v for ; Thu, 4 Jul 2013 06:57:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BE3A711E80E9 for ; Thu, 4 Jul 2013 06:57:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68D802018B; Thu, 4 Jul 2013 11:01:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3315DA902A; Thu, 4 Jul 2013 09:56:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 208B6636AD; Thu, 4 Jul 2013 09:56:09 -0400 (EDT) From: Michael Richardson To: Ray Bellis In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDE9962@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDE9962@wds-exc1.okna.nominet.org.uk> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" Subject: Re: [homenet] IETF 87 - call for agenda items X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 13:57:22 -0000 --=-=-= I would like the WG to spend some face time dealing with (making a list of), things that need to be configured, which are not routes. (So, I would include prefixes in the list) I think that it is important for the group as a whole to recap some of the discussion that has occured here. If it would help the group, I could write a draft that had an initial list. (I will not be in Berlin, but I will be remote) -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUdV+9YqHRg3pndX9AQLFYwP/cHtjLh5/xyOAFdgfm3VHtDdgmhz7mIiq aUWDa0D2saskgn5yII1tourbQH1zdR12t7Wz2NsmIOY/8VCn388w8fvJDaZmIjFA KTl5ZEAc6MVpKVfcfpi4fm7GxC4ctqjNkOFU3REklQnI7cI2MSmYeFBpCFCUtAtL uCyBUUv+ze4= =JUmg -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Thu Jul 4 07:02:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6134811E8133 for ; Thu, 4 Jul 2013 07:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uipPlBhOgh4t for ; Thu, 4 Jul 2013 07:02:29 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id BC80F11E8132 for ; Thu, 4 Jul 2013 07:02:26 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id B57192380503; Thu, 4 Jul 2013 10:02:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Ted Lemon In-Reply-To: <51D54054.7070507@globis.net> Date: Thu, 4 Jul 2013 10:02:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <17D50E0C-3439-4C1C-825A-E999D2A2864A@fugue.com> <51D3906F.70303@joelhalpern.com> <51D4801F.6050801@globis.net> <874ncbnn2a.wl%jch@pps.univ-paris-diderot.fr> <51D54054.7070507@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1508) Cc: "homenet@ietf.org" , Juliusz Chroboczek Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:02:40 -0000 On Jul 4, 2013, at 5:28 AM, Ray Hunter wrote: > I thought this classification would be useful in Homenet, as there are > likely to be devices that do not contain persistent storage. Generally speaking, I think devices of this type are probably either end = nodes or non-edge participants in a 6lowpan network, so they don't need = to maintain state anyway. If the edge routers can't maintain state, = that's a different matter. From mcr@sandelman.ca Thu Jul 4 07:19:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A64321F918F for ; Thu, 4 Jul 2013 07:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhOtq1gWodXQ for ; Thu, 4 Jul 2013 07:19:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 4631421F90E4 for ; Thu, 4 Jul 2013 07:19:40 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 17AB52018B; Thu, 4 Jul 2013 11:24:14 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5EB8DA902A; Thu, 4 Jul 2013 10:18:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 509F9636AD; Thu, 4 Jul 2013 10:18:31 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org Group" , "Joel M. Halpern" , Lorenzo Colitti In-Reply-To: <51D4886B.9000501@globis.net> References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <17D50E0C-3439-4C1C-825A-E999D2A2864A@fugue.com> <51D3906F.70303@joelhalpern.com> <51D4801F.6050801@globis.net> <51D4846A.1090404@mtcc.com> <51D4886B.9000501@globis.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:19:45 -0000 --=-=-= Ray Hunter wrote: > ALL configuration for ALL homenet devices, including end nodes. > Which is why I think we need to look at a layered set of solutions, > with each layer almost certainly consisting of a number of protocols. > There's no point in having a nice standardised routing protocol if the > end nodes still can't resolve names. > On the other hand, trying to shoe horn all of DHCPv6 and all it's > future (vendor) extensions into a routing protocol clearly ain't going > to work either. so we have stateful configuration of IPv6. Let me recap, stating the obvious, so that I know that I am on the same page as others. We have the M and O bits in the RA. I think that we will typically have M=0 and O=1. The client then asks for more information via DHCPv6, which goes to a link-local multicast address. (I'm unclear when the site-scoped address is used). I don't think that *anything* can or *should* change here(*) (What and how the client does DNS vs mDNS vs sdnsext is a higher-level issue for the moment) The question is: how does the non-ISP-connected router get the right information to use to answer the DHCPv6 requests it sees and/or realize that it shouldn't run full DHCPv6, but rather just be a DHCPv6 relay. So I think that the set of information that the *routers* need to exchange is really not that large, if we assume that the "DHCPv6 server is HERE" is one of those pieces of information. (*) THERE IS STILL an issue of what do hosts and routers do if there are two ISP connected routers, and potentially two completely different sources of DHCPv6 information. Even in the simplest two ISP case, hosts can see both of these DHCPv6 servers directly. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUdWENIqHRg3pndX9AQJugQQAvDhL3/2/PT+6QildrT6ZxL8b/FhewMTp RDylEXG50dFyAGRuA/vu5AcZAVEzBw69e1gSqentNbeiD68SHfhgq4yMczJlIy2b hNA19vExiu/HLA58wMTUOCH8YCv3Ac4HudMPsZXkbBvGKWyS1z4GENYyKQKv37iP ob/rn5HE2ms= =DSGH -----END PGP SIGNATURE----- --=-=-=-- From baptiste.jonglez@ens-lyon.fr Thu Jul 4 07:35:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090A21F9FD5 for ; Thu, 4 Jul 2013 07:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 f0xyZIaCMuAZ for ; Thu, 4 Jul 2013 07:35:54 -0700 (PDT) Received: from jabiru.ens-lyon.fr (jabiru.ens-lyon.fr [140.77.51.2]) by ietfa.amsl.com (Postfix) with ESMTP id F1C4321F9F70 for ; Thu, 4 Jul 2013 07:35:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id 9222F1EB1AB for ; Thu, 4 Jul 2013 16:35:42 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ens-lyon.fr Received: from jabiru.ens-lyon.fr ([127.0.0.1]) by localhost (jabiru.ens-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRkKrWKZu6I0 for ; Thu, 4 Jul 2013 16:35:41 +0200 (CEST) Received: from localhost (rev20.vpn.fdn.fr [80.67.179.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by jabiru.ens-lyon.fr (Postfix) with ESMTPSA id 26DE21EB2AD for ; Thu, 4 Jul 2013 16:35:40 +0200 (CEST) Date: Thu, 4 Jul 2013 16:35:39 +0200 From: Baptiste Jonglez To: homenet@ietf.org Message-ID: <20130704143539.GF1041@ens-lyon.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hUH5gZbnpyIv7Mn4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:35:59 -0000 --hUH5gZbnpyIv7Mn4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 04, 2013 at 09:20:40PM +0900, Lorenzo Colitti wrote: > Er... did you read > http://tools.ietf.org/html/draft-troan-homenet-sadr-00 before > submitting this? With the exception of the text on babel, a lot of > the material you wrote is already covered there. This document is listed as a reference: [TROAN]. However, it is not directly used anywhere in the draft. --hUH5gZbnpyIv7Mn4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR1Yg7AAoJEAwdk2Chmk9b7kwP/0FGCI4C6bUI4xAiYzvTGwgg f8mAcwNgd+9PV7iscTZvNFZ2f5WdyFEX8DIac0Baz8pAAi0wepaTaGlWIF7AKnk9 K6wMyoQks31hnXkGelGQl6ko0BlsQfPpz4EF2IpTbQmBw6ZFi4aRGCUUQfAl9DUF ERXawiW0wiUxh+3jSCT5/vl+rAorO6d0+4kIaaapJj7FfMhXU//VQLgycN05Fdjf edFE6E22+E6kawKQ6zT6lFKEXOoVJJHmxN8DjtBBT1IYoiVOlptLLHvW8k7M51cu deWvbExZfR2INmw5TyATVeowO8mLHVIn34Ca5nGeDtkG24EmYEP1l3KoF3yokmOT nGW+W7IK5uQya3PVnNDj7fPCZpxacUE29CDfbtouRt2Aoi9fqPHKtQYhArRIys7M QtfRcc/gCCtdATmhuC2oxqeSp4TQ/ni5ZA+L+1ue+htZSERhOGNKCjd0NcN38pIu mCd7wTw54pb74eHOqiAPYyrzMY8O8XiBw8RezyUx3lgRr4mHwBRyGec5JpSmf831 4/cGR2+p5gJTDWjQJajMOMMhkNY1BQNYn5ztZZ0N8UG2IDDQ7YXLJvs2SOEVOQN2 OHFgk6d7/2BMI6UWjp6TYjk54l9bteZIK6lLCmCExeOz5F66PCnHzCY+aginTW1j rCR5RYldRUH0apUEmH/B =nMgC -----END PGP SIGNATURE----- --hUH5gZbnpyIv7Mn4-- From lorenzo@google.com Thu Jul 4 07:57:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC6611E8127 for ; Thu, 4 Jul 2013 07:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibOWdlr7SvFP for ; Thu, 4 Jul 2013 07:57:06 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AE44C11E812A for ; Thu, 4 Jul 2013 07:56:59 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so1092603vea.29 for ; Thu, 04 Jul 2013 07:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=T/fDAy/GPLMRfOetC8VrIIhfrBgxV2/S6BNoa7jTnJs=; b=EkwR1nyEpOeWAbKkqFLES6d2YjXMmbCSztGI3zX2SqzPt10DP+7baCfcQra+fCh46h YWcZjwVwzMkIIJltrKztsdsiy56RippsVzlHy8aSTN02E6KqPzjNUAR/nS+DoN66VGgJ b4EAHr53CLF2xnpCOgd3fWPzn7YFU+0YCqUVJTJhn7ZUsuNsXrj4Q6lDwg1dCHH/kQ/4 dn/k7ZxbwuIEZv++EehT1Ik7PN8hnlmL4byhoTCsRWbP1SaEzb33XoPa4PExn1T1bw3+ Uz/hsx5O+b1O+1whrRncOZyxUnWDjabOEBG+iVGiEvTx73O+CbPnNIBWrinYyRUyDwVX HQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=T/fDAy/GPLMRfOetC8VrIIhfrBgxV2/S6BNoa7jTnJs=; b=GvsaFzZ7yKlU1ET4B56YtyQTP3SRIn1qBrEKVN0r2Y4ndEQvJr1dQQLwB0pNrAPMmM Ys5GXZSo1R+7cU7Bz5IoXRdT/uHgMvB8teoht9DvxTOcN0gmrdt5k4ToBEMpAdTBFZOZ Z+zy8NAdiJxn3lIbpRpXXYXQ0yD10ygdx6zZkxCl3nTbPZol/q4bvOcE/f9d2AlMV3E0 N+MeJulFlwtNVdEgiKadyGjTwtoYdGsTvDou4SVDSK1DSOPlvUv17LvmGre+iBqzNx9J wOKzhW8Xuve827fqfC8ein5cZQF8i+Bf9JOn9kRvl4JA5dwaym9L3LoNbVJHYMH8Z/X2 cECg== X-Received: by 10.58.226.199 with SMTP id ru7mr3280731vec.68.1372949817890; Thu, 04 Jul 2013 07:56:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.175.12 with HTTP; Thu, 4 Jul 2013 07:56:37 -0700 (PDT) In-Reply-To: <20130704143539.GF1041@ens-lyon.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <20130704143539.GF1041@ens-lyon.fr> From: Lorenzo Colitti Date: Thu, 4 Jul 2013 23:56:37 +0900 Message-ID: To: Baptiste Jonglez Content-Type: multipart/alternative; boundary=047d7bd6afe630c43c04e0b0cac5 X-Gm-Message-State: ALoCoQl9U20McmiubbyHUNYI1v5CQ2lh6Z0xzCJwqHF1aUkZgJBiqUZdNiAVIwz6fFfL+RL2fKedRJs5kmFLkDpPKfIKnmexqB6SwDufB/p/FaHQOswPrBcPylaiyNuUiI+vUE0YZo0bnBgNff6UDWOG3xATT1JT4zoo/94SjXkdrthINoEsj+OiNb0619yTmjxda+g+PURP Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:57:06 -0000 --047d7bd6afe630c43c04e0b0cac5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 4, 2013 at 11:35 PM, Baptiste Jonglez < baptiste.jonglez@ens-lyon.fr> wrote: > This document is listed as a reference: [TROAN]. > That doesn't answer the "did you read it" question :-) --047d7bd6afe630c43c04e0b0cac5 Content-Type: text/html; charset=ISO-8859-1

On Thu, Jul 4, 2013 at 11:35 PM, Baptiste Jonglez <baptiste.jonglez@ens-lyon.fr> wrote:

This document is listed as a reference: [TROAN].

That doesn't answer the "did you read it" question :-)

--047d7bd6afe630c43c04e0b0cac5-- From mike@mtcc.com Thu Jul 4 08:42:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE421F9FD8 for ; Thu, 4 Jul 2013 08:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-FE4Z7Oggk4 for ; Thu, 4 Jul 2013 08:42:15 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4F21F9E9B for ; Thu, 4 Jul 2013 08:42:15 -0700 (PDT) Received: from michael-thomass-macbook.local (aric.mtcc.com [50.0.18.225] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r64FgEZ0009537 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 4 Jul 2013 08:42:15 -0700 Message-ID: <51D597D3.3090400@mtcc.com> Date: Thu, 04 Jul 2013 08:42:11 -0700 From: mike User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: homenet@ietf.org References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <17D50E0C-3439-4C1C-825A-E999D2A2864A@fugue.com> <51D3906F.70303@joelhalpern.com> <51D4801F.6050801@globis.net> <51D4846A.1090404@mtcc.com> <51D4886B.9000501@globis.net> <26777.1372947511@sandelman.ca> In-Reply-To: <26777.1372947511@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1884; t=1372952535; x=1373816535; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20mike=20 |Subject:=20Re=3A=20[homenet]=20draft-chroboczek-homenet-co nfiguration-separate-00 |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=NM30DQyHPJPGB5JZyjVcjwJt/7MWK/8jNYJwVjTm+nc=; b=b0YpWNBoo4d42CPRNNxueZjguWJMNfAoT2OUOOsHXwbjxLsmdaxqLeSTYI oyy90TH7dRwDXKIscv4DxLF1+wj0WKGy0JLgBktqfyoTo23gppLHJJf1IH4s 8SMltGox2GyQXEK22fcchgI83bENyIZFe6fafs4Vv342asDn+NuaA=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:42:20 -0000 On 7/4/13 7:18 AM, Michael Richardson wrote: > > (*) THERE IS STILL an issue of what do hosts and routers do if there are > two ISP connected routers, and potentially two completely different > sources of DHCPv6 information. Even in the simplest two ISP case, > hosts can see both of these DHCPv6 servers directly. > Maybe there's really a few things going on here? There is clearly some ISP specific information that ought to be relayed to the host. But there's also "configurator of last resort" insofar as since there generally isn't much clue in the routers, the ISP's fill the void by providing that information. Sometimes it's benign, sometimes it's in the ISP's self interest. And if we have two ISP's due to multihoming, there's going to be conflict if it's of the self-interest kind for the ISP's. As far as I can tell now, it would just be a race in the multihoming situation, right? Pretty much whichever DHCP server responded first (or their relay) would win which could cause some inconsistency for configuration that is "shared". DNS, for example, might give different results if, say, one of my upstream providers answered queries differently than another because one has, say, a service to do split horizon DNS to fake up names for my home and the other doesn't. Or if you hate that example, there have got to be dozens of others in the kitchen sink of DHCP options. I'm not exactly sure what ought to be done about that because each ISP is incented to be the ultimate truth of configuration information. It seems to me that the only arbitrator for such problems is likely to be a human being at home dealing with this. Maybe the right thing is to synthesize DHCP responses in homenet routers to be the things that ISP can/will provide, and the choices the homenet wants to chose when there's conflict? Mike From mellon@fugue.com Thu Jul 4 08:51:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0011E8138 for ; Thu, 4 Jul 2013 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdzS-e3VQ7Cv for ; Thu, 4 Jul 2013 08:51:10 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8A11E812E for ; Thu, 4 Jul 2013 08:51:10 -0700 (PDT) Received: from [IPv6:2001:470:88a3::4964:ec45:edc7:bf33] (unknown [IPv6:2001:470:88a3:0:4964:ec45:edc7:bf33]) by toccata.fugue.com (Postfix) with ESMTPSA id 030982380503; Thu, 4 Jul 2013 11:51:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Ted Lemon In-Reply-To: <51D597D3.3090400@mtcc.com> Date: Thu, 4 Jul 2013 11:51:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4D2AB7A7-93AB-4AC1-9142-9E98097A926A@fugue.com> References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <17D50E0C-3439-4C1C-825A-E999D2A2864A@fugue.com> <51D3906F.70303@joelhalpern.com> <51D4801F.6050801@globis.net> <51D4846A.1090404@mtcc.com> <51D4886B.9000501@globis.net> <26777.1372947511@sandelman.ca> <51D597D3.3090400@mtcc.com> To: mike X-Mailer: Apple Mail (2.1508) Cc: homenet@ietf.org Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:51:16 -0000 On Jul 4, 2013, at 11:42 AM, mike wrote: > As far as I can tell now, it would just be a race in the multihoming = situation, right? > Pretty much whichever DHCP server responded first (or their relay) = would win which > could cause some inconsistency for configuration that is "shared". = DNS, for example, > might give different results if, say, one of my upstream providers = answered queries > differently than another because one has, say, a service to do split = horizon DNS to > fake up names for my home and the other doesn't. Or if you hate that = example, there > have got to be dozens of others in the kitchen sink of DHCP options. Work is being done on this in the MIF working group at the moment; we = believe the problem is tractable. To future-proof against work that = has not yet completed there, the right thing for homenet to do is make = sure that the information is tagged as to its source, and not just = dumped into a pot and mixed together. It may be that for the moment the engine that actually delivers the = information to the end node has to do some mixing, but the point is that = it should not be mixed before it gets to the final point of delivery, = and ideally not even then. From jch@pps.univ-paris-diderot.fr Thu Jul 4 09:59:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED021F9733 for ; Thu, 4 Jul 2013 09:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyjq6h82dTJn for ; Thu, 4 Jul 2013 09:59:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 64F9B21F9CB3 for ; Thu, 4 Jul 2013 09:59:13 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r64GwiZn024754; Thu, 4 Jul 2013 18:58:44 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1F41A4F722; Thu, 4 Jul 2013 18:58:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id N_64Cgp-P4yt; Thu, 4 Jul 2013 18:58:42 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D4EF54F721; Thu, 4 Jul 2013 18:58:42 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1Uumri-0002sp-Gj; Thu, 04 Jul 2013 18:58:42 +0200 Date: Thu, 04 Jul 2013 18:58:42 +0200 Message-ID: <7iip0qw9bx.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <51D54054.7070507@globis.net> References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <17D50E0C-3439-4C1C-825A-E999D2A2864A@fugue.com> <51D3906F.70303@joelhalpern.com> <51D4801F.6050801@globis.net> <874ncbnn2a.wl%jch@pps.univ-paris-diderot.fr> <51D54054.7070507@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 04 Jul 2013 18:58:44 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 16:59:21 -0000 > > Could you please give some examples of such "temporally dependent" > > information? > I think there IS a tight binding between topology discovery, identifying > homenet border routers, identifying external interfaces to an ISP [etc.] > Does that make sense to you? I understand what you are saying, but I'd like to see concrete examples of such coupling. Routing protocols are designed to react in a timely manner to addressing and topology changes, so I'd expect address configuration, CPE discovery and the routing protocol to be able to run asynchronously. I am probably missing something obvious, but my gut reaction is that any such "temporal dependency" indicates a mere limitation of the implementation of the routing protocol. -- Juliusz From v6ops@globis.net Thu Jul 4 10:09:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBB621F9DE1 for ; Thu, 4 Jul 2013 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oijzq3E0jUuS for ; Thu, 4 Jul 2013 10:09:50 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8421F9D86 for ; Thu, 4 Jul 2013 10:09:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 56B51870081; Thu, 4 Jul 2013 19:09:34 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke+wi8ZvlbGc; Thu, 4 Jul 2013 19:09:34 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 35538870002; Thu, 4 Jul 2013 19:09:34 +0200 (CEST) Message-ID: <51D5AC47.20206@globis.net> Date: Thu, 04 Jul 2013 19:09:27 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Juliusz Chroboczek References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <17D50E0C-3439-4C1C-825A-E999D2A2864A@fugue.com> <51D3906F.70303@joelhalpern.com> <51D4801F.6050801@globis.net> <874ncbnn2a.wl%jch@pps.univ-paris-diderot.fr> <51D54054.7070507@globis.net> <7iip0qw9bx.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <7iip0qw9bx.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 17:09:51 -0000 > Juliusz Chroboczek > 4 July 2013 18:58 >>> Could you please give some examples of such "temporally dependent" >>> information? > >> I think there IS a tight binding between topology discovery, identifying >> homenet border routers, identifying external interfaces to an ISP [etc.] > >> Does that make sense to you? > > I understand what you are saying, but I'd like to see concrete > examples of such coupling. Routing protocols are designed to react in > a timely manner to addressing and topology changes, so I'd expect > address configuration, CPE discovery and the routing protocol to be > able to run asynchronously. > > I am probably missing something obvious, but my gut reaction is that > any such "temporal dependency" indicates a mere limitation of the > implementation of the routing protocol. > > -- Juliusz > I think you're missing the requirement for automatic topology discovery. It wouldn't be smart to run an IGP routing protocol either transmitting or listening on the ISP interface. You don't want it to peer with your neighbor's CPE on a shared medium just because it's been rebooted. And vice versa, when the router is moved and plugged in by the user as an "internal" router, it should learn to start up a routing process in that case. Normally that topology information is either pre-defined in the hardware, or soft configured even before the routing protocol starts up. If you're going to use OSPF to discover topology (and assign prefixes) you're going to have to send out some types of LSA before others. regards, RayH From jch@pps.univ-paris-diderot.fr Thu Jul 4 10:17:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3AE21F9E0B for ; Thu, 4 Jul 2013 10:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_MILLIONSOF=0.315] 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 iUSCOndiRTVo for ; Thu, 4 Jul 2013 10:16:58 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 0405321F9D71 for ; Thu, 4 Jul 2013 10:16:57 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r64HGsLn003591; Thu, 4 Jul 2013 19:16:54 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 78B704F720; Thu, 4 Jul 2013 19:16:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OhqBl7LnR7NL; Thu, 4 Jul 2013 19:16:53 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1B8D84F703; Thu, 4 Jul 2013 19:16:52 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1Uun9I-0002tJ-P0; Thu, 04 Jul 2013 19:16:52 +0200 Date: Thu, 04 Jul 2013 19:16:52 +0200 Message-ID: <7ihagaw8hn.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: mike In-Reply-To: <51D44472.8040002@mtcc.com> References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <8761wr3lno.wl%jch@pps.univ-paris-diderot.fr> <201A0496-6D65-4822-B5F6-EB3B5C77273E@fugue.com> <87r4ff22ye.wl%jch@pps.univ-paris-diderot.fr> <51D44472.8040002@mtcc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 04 Jul 2013 19:16:55 +0200 (CEST) Cc: homenet@ietf.org Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 17:17:14 -0000 >> draft-chroboczek-ahcp-00? > I had not, but now I've skimmed it over. Since I just skimmed, the > question that didn't get answered in the introduction is how this > differs from DHCP with a relay? That's a good point, yes. It almost tempts me to public -01. I actually considered using a packet format derived from DHCPv6 initially, then decided it's not worth the bother for this particular experiment. The main difference is that AHCP defines a forwarding strategy that allows efficient and redundant communication with no risk of looping. Perhaps I'm missing something, but it would appear that no such strategy is defined for DHCPv6 relays. I haven't actually tried it out, but I believe that AHCP's forwarding strategy could almost be used with the DHCPv6 packet format -- the one thing that appears to be missing (but perhaps I haven't looked hard enough) is a place to store a nonce that allows efficient duplicate detection. I that one could store it within an option, but haven't looked at it in depth. Then, the layering is different -- AHCP forwarders just blindly forward packets, without caring about clients and servers, so AHCP could be used for a peer-to-peer configuration strategy (zOSPF style) with not changes to the forwarders -- a somewhat important point if we're going to put the configuration forwarder into the firmware of millions of homenet routers. There are other differences, like the ability to mandate that an option should be used ("Do not use this configuration unless you're prepared to act on the following option"), but they are probably of little interest to homenet. -- Juliusz From jch@pps.univ-paris-diderot.fr Thu Jul 4 10:19:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506C521F8887 for ; Thu, 4 Jul 2013 10:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lDFi78-tGPf for ; Thu, 4 Jul 2013 10:19:39 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id CE92E21F9931 for ; Thu, 4 Jul 2013 10:19:38 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r64HJAxp004312; Thu, 4 Jul 2013 19:19:10 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A1A144F724; Thu, 4 Jul 2013 19:19:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id A42MDNO35Dgh; Thu, 4 Jul 2013 19:19:09 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A1D894F723; Thu, 4 Jul 2013 19:19:09 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1UunBV-0002tV-Ac; Thu, 04 Jul 2013 19:19:09 +0200 Date: Thu, 04 Jul 2013 19:19:09 +0200 Message-ID: <7ifvvuw8du.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <51D5AC47.20206@globis.net> References: <87d2r01ktg.wl%jch@pps.univ-paris-diderot.fr> <17D50E0C-3439-4C1C-825A-E999D2A2864A@fugue.com> <51D3906F.70303@joelhalpern.com> <51D4801F.6050801@globis.net> <874ncbnn2a.wl%jch@pps.univ-paris-diderot.fr> <51D54054.7070507@globis.net> <7iip0qw9bx.wl%jch@pps.univ-paris-diderot.fr> <51D5AC47.20206@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 04 Jul 2013 19:19:10 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-chroboczek-homenet-configuration-separate-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 17:19:44 -0000 > > I am probably missing something obvious, > I think you're missing the requirement for automatic topology discovery. > > It wouldn't be smart to run an IGP routing protocol either transmitting > or listening on the ISP interface. Yes, that's it. Thanks for the explanation. -- Juliusz From jch@pps.univ-paris-diderot.fr Thu Jul 4 10:35:32 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5963821F9A57 for ; Thu, 4 Jul 2013 10:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L1ryhx8+kWM for ; Thu, 4 Jul 2013 10:35:27 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0B721F9C8F for ; Thu, 4 Jul 2013 10:35:26 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r64HZMBw008640; Thu, 4 Jul 2013 19:35:22 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1C5344F728; Thu, 4 Jul 2013 19:35:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2tf9soRA7Dqe; Thu, 4 Jul 2013 19:35:21 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0EB4B4F720; Thu, 4 Jul 2013 19:35:21 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1UunRA-0002tv-OM; Thu, 04 Jul 2013 19:35:20 +0200 Date: Thu, 04 Jul 2013 19:35:20 +0200 Message-ID: <7id2qyw7mv.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> <87ip0y56z6.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 04 Jul 2013 19:35:23 +0200 (CEST) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 17:35:32 -0000 > Snazzy! Thanks. > 1. How does this support the IPv6 subnet model with link-local > multicast and link-local addresses and so on? Nothing changes. Link-local addresses are still assigned to each interface, as usual. In a pure mesh network, the behaviour of link-local multicast changes somewhat, so things like mDNS don't work well. Intuitively, "link-local" doesn't make sense in this universe, it's rather "local to your set of neighbours". > 2. Also, what about DAD? If all the hosts participate in the routing > protocol, you can implement DAD over that, but what about current > hosts? You're right, we don't do DAD. That's related to the issues with link-local above. -- Juliusz From jch@pps.univ-paris-diderot.fr Thu Jul 4 10:41:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7921F9D90 for ; Thu, 4 Jul 2013 10:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m6qMn-dVJx8 for ; Thu, 4 Jul 2013 10:41:38 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 312FF21F9DB6 for ; Thu, 4 Jul 2013 10:41:37 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r64Hfa2M011450; Thu, 4 Jul 2013 19:41:36 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E58464F722; Thu, 4 Jul 2013 19:41:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2lcfjIYw6O3i; Thu, 4 Jul 2013 19:41:34 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 87B384F720; Thu, 4 Jul 2013 19:41:34 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1UunXC-0002u1-75; Thu, 04 Jul 2013 19:41:34 +0200 Date: Thu, 04 Jul 2013 19:41:34 +0200 Message-ID: <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 04 Jul 2013 19:41:36 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 17:41:42 -0000 > Er... did you read > http://tools.ietf.org/html/draft-troan-homenet-sadr-00 > before submitting this? I have read it carefully. I've even had the courtesy of citing it (it's reference [TROAN]). > With the exception of the text on babel, a lot of the material you > wrote is already covered there. Your draft covers what we describe in Sections 2.1.1 and part of 2.2.2. That's roughly 15% of our text. -- Juliusz From lorenzo@google.com Thu Jul 4 18:50:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768D11E8118 for ; Thu, 4 Jul 2013 18:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH2GjhYTq80T for ; Thu, 4 Jul 2013 18:50:11 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8A02121F91B4 for ; Thu, 4 Jul 2013 18:50:11 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so1398641veb.5 for ; Thu, 04 Jul 2013 18:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XquyeDShMqoxxi7v2fEt8VhuNU27T3Nq/jMyULbrqvM=; b=h2JbIsuubuIaQWCeN/9udAGx1oClt1oU9KVRlyNouhgDGpQhrwPDwLqLE2uUSoZtme o3Sc22a08u2j3/hrblL92zK28d5DKZ83aNNZTnDktL92Intl2qlz5uTkV257QbhAVv4+ nXPN0vQJKOR86a6Rltn9ggFT37BM89YGjRdAsfS0qNqVBRUNIKWO971cM+o9iGiakatA 5wgPorTtUBTcYP1QFAiXFIhehJZSqdA04kbVPjQkkioiTQdNq2iTtvQ14h9hgsFJk4Q+ X36jaqplnnJKxf4kWtaqIyRuqXUsiJnJvteySTI3rgVscioD/4EmHr0tAvIgyWzFoTku KuaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=XquyeDShMqoxxi7v2fEt8VhuNU27T3Nq/jMyULbrqvM=; b=Ees+WNX9Lp4m7u+kF2AQqtI7m0W5qau6tfFKbcpMgO4hqhEcNtnI68jiwI59DCXyi9 fHUofD8w8++8cs7TopL+azclPvB6UdThH9spvQdpqwyAnDp5htr3M5V6cgsVXh2LAhA4 kn+W365LqWbg2jp94e4TVwLg1nwwNXRe9oAk7xl4WIgzldFsRb8hTx1unh5t94WHYDV8 wWcFfQEZBDXh3P0y64fAfzKhe4g9ZRzJQsUfEHsoGGlujELcq1a2Xn7322RHiVolURcc fKEwlQEERLz7PqAzP6ctAeHUdQLz55Ell5O+VoX7QLiRTzRHAIlzYoASvc7rXb2/OWGD Bd3Q== X-Received: by 10.52.31.230 with SMTP id d6mr4039293vdi.43.1372989009853; Thu, 04 Jul 2013 18:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.252.66 with HTTP; Thu, 4 Jul 2013 18:49:49 -0700 (PDT) In-Reply-To: <7id2qyw7mv.wl%jch@pps.univ-paris-diderot.fr> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> <87ip0y56z6.wl%jch@pps.univ-paris-diderot.fr> <7id2qyw7mv.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Fri, 5 Jul 2013 10:49:49 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=bcaec519646d36bc2f04e0b9ea8f X-Gm-Message-State: ALoCoQkecVSkrW2h74aX4xLM6nU9guhkIlzBk0X9qPdFlvpu6XN+ooJJ5GpuZ83RKi/onabXtO5EGDH1iUmkKkNAoImul5ZTDukh+tYFVP7W1cQOs6TjEMufOkJojX/Y+eUyqDsRJSUftMx6cBDgMBcW9ApIKfnnMY8H/+ZbLJp89Z31S3Dw021/LvlGUJisp1NmHb/58TAB Cc: "homenet@ietf.org Group" Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 01:50:12 -0000 --bcaec519646d36bc2f04e0b9ea8f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 5, 2013 at 2:35 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > 2. Also, what about DAD? If all the hosts participate in the routing > > protocol, you can implement DAD over that, but what about current > > hosts? > > You're right, we don't do DAD. That's related to the issues with > link-local above. > I see. So this is a significant change in semantics. Given that RFC 2462 says: Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions: then it's fair to expect that standard implementations can (and likely do) assume that if DAD succeeds, then their IPv6 address is unique and usable. That being the case, how can you ensure that there are no duplicate addresses in the network? If all hosts on the nework speak the routing protocol, then that's easy, but what about legacy hosts? Does this scheme require that all hosts on the network speak the routing protocol? --bcaec519646d36bc2f04e0b9ea8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 5, 2013 at 2:35 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

> 2. Also,= what about DAD? If all the hosts participate in the routing
> protocol, you can implement DAD over that, but what about current
> hosts?

You're right, we don't do DAD. =A0That's related to the i= ssues with
link-local above.

I see. So this is a s= ignificant change in semantics. Given that RFC 2462 says:

=A0 =A0Duplicate Address Detection MUST be performed on all un= icast

=A0 =A0addresses prior to assigning them to an interface, regardless o= f

=A0 =A0whether they are obtained through stateless autoconfigur= ation,

=A0 =A0DHCPv6, or manual configuration, with the following= exceptions:

then it's fair to expect that standard implem= entations can (and likely do) assume that if DAD succeeds, then their IPv6 = address is unique and usable.

That being the case,= how can you ensure that there are no duplicate addresses in the network? I= f all hosts on the nework speak the routing protocol, then that's easy,= but what about legacy hosts? Does this scheme require that all hosts on th= e network speak the routing protocol?

--bcaec519646d36bc2f04e0b9ea8f-- From victor@jvknet.com Thu Jul 4 19:49:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DC311E8109 for ; Thu, 4 Jul 2013 19:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_OBFU_OTHER=0.135] 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 3JcJYTXwsPfw for ; Thu, 4 Jul 2013 19:49:05 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id B5DE021F9A13 for ; Thu, 4 Jul 2013 19:49:05 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so4481894ied.0 for ; Thu, 04 Jul 2013 19:49:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=FUyF/ADHFjE4/PsPOx6P0yRCyBZ1JzzdHH4RcAQi8UM=; b=RD6VOl6EHY2awLa3euJAyflSawdHy2PhaZNQ5CLt/B5gawxBz2MI+WBSNGp9bv7cqF 14mqh7DTi3xB9BbpTOndJT+mzz1KBFXK9Ka5ZvZgzz1xDRGenQmsFIk1+cfrRKIacjiN 1ajBUUnO5lrnBqQZB7Mo/0o/U8fCM7M2use9CqpUi92Uy/y6v5Ui+pEE/mYBK4CqD4a3 9Uh5t+fhh91OmI/nm/bEP7xTLvd19rgv/4j2P+xwj5nsYBKAlfQdiPDLEMOCUyG9OxB/ bPR1QGVoUYJ0GWDyYDRgwmbUya1dlHGSBe71TeK6YF60oD4idBym/mD1xsW7e6jwk+7I 1+7A== X-Received: by 10.42.113.197 with SMTP id d5mr3157406icq.46.1372992545099; Thu, 04 Jul 2013 19:49:05 -0700 (PDT) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPSA id y9sm26417924iga.9.2013.07.04.19.49.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Jul 2013 19:49:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 04 Jul 2013 22:48:58 -0400 From: Victor Kuarsingh To: Message-ID: Thread-Topic: New Version Notification for draft-jvkjjmb-home-networking-incremental-00.txt In-Reply-To: <20130705023457.7547.27123.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmgdeB6yLNnxChjMqajeGDtYrHCHI7Jgqn9Ig/C4RpOimi02Ri08cpmdE+B4dIYhDA+iK1R Cc: ray.bellis@nominet.org.uk, John McQueen , mark@townsley.net, Chris Grundemann , John Jason Brzozowski Subject: [homenet] FW: New Version Notification for draft-jvkjjmb-home-networking-incremental-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, 05 Jul 2013 02:49:10 -0000 Homenet WG, A draft has been submitted (below) which outlines a home network progression from current state (reference point RFC6204) to future advanced states. The progression is outlined as an incremental approach to achieve the full envisioned homenet architecture over a series of phases (additive capabilities). The progression outlined was envisioned such that the home network can be evolve in a controlled and feasible manner considering the realities of brownfield deployments in environments that must remain operational during the transition. The WGs feedback is desired and requested. Regards, Victor K On 2013-07-04 10:34 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-jvkjjmb-home-networking-incremental-00.txt >has been successfully submitted by Victor Kuarsingh and posted to the >IETF repository. > >Filename: draft-jvkjjmb-home-networking-incremental >Revision: 00 >Title: An incremental solution to advanced home networking >Creation date: 2013-07-04 >Group: Individual Submission >Number of pages: 24 >URL: >http://www.ietf.org/internet-drafts/draft-jvkjjmb-home-networking-incremen >tal-00.txt >Status: >http://datatracker.ietf.org/doc/draft-jvkjjmb-home-networking-incremental >Htmlized: >http://tools.ietf.org/html/draft-jvkjjmb-home-networking-incremental-00 > > >Abstract: > The home network is an environment subject to ongoing evolution and > change. Many home networks today are simplistic in nature, often > comprising of a single router/gateway. The expectation over time is > predicated on the notion that the home network will be more complex > servicing many in-home and Internet functions. The home network will > evolve necessitating the replacement and update to current hardware > and software to more advanced devices and software capable of > operating in more complex environments. This document provides a > view on how the home network can progress from today's foundational > form, to a more advanced environment, using progressive technological > capabilities. > > > > > > >The IETF Secretariat > From hrogge@googlemail.com Thu Jul 4 22:31:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377D311E823C for ; Thu, 4 Jul 2013 22:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yry7L1YMDBnw for ; Thu, 4 Jul 2013 22:31:55 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9892311E823B for ; Thu, 4 Jul 2013 22:31:55 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id j10so1077754qcx.3 for ; Thu, 04 Jul 2013 22:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5hKtv1Gz/jjzHlTGFzPmeVXUBZOkWZ2gfjiyLklpw8E=; b=KQ901wX+crtx1an1c1MXgFKpwG4KEGQ540ywf1vuqt064vKjG7IqN0rps/w9JzDV+S QvheduwbL9lW3Zt0lIAI8L3avxLa5yd0TlMvwzJ6j56ATeoOaTL2QlKaFEqdGt392yKW zJq6ZUiuUQF0m/ipEVz2p6xSW6YHU4yZxbBk/l5wboAW+aAPEBWhYgZYxHE7+Q4CxNXz 8hLijUvvFEzcRtakqjFDittDz/i3R+d3PNfk6I+fL7MkWYQ8lC7COBbQHYGAU/fsu3RB LYT/jTUOgQ8+0y9Hgl5SHlDwntoN+zkTdAd3P2WasZx1KOfOP7eBXzXNqAggEvSAMZYu 3U7g== X-Received: by 10.224.7.129 with SMTP id d1mr8488874qad.108.1373002315113; Thu, 04 Jul 2013 22:31:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.73 with HTTP; Thu, 4 Jul 2013 22:31:35 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> <87ip0y56z6.wl%jch@pps.univ-paris-diderot.fr> <7id2qyw7mv.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Fri, 5 Jul 2013 07:31:35 +0200 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 05:31:56 -0000 the DAD as defined in the IPv6 RFCs doesn't work in a multihop radio network, because of the hidden station problem. Imagine a situation with three nodes A, B and C. A can hear B, B can hear A and C, C can hear B. If A and C choose the same address, DAD will not detect the problem because A and C cannot talk to each other directly, but B will have two neighbors with the same address. Because of this problem you need a different approach to generate your addresses. Henning Rogge On Fri, Jul 5, 2013 at 3:49 AM, Lorenzo Colitti wrote: > On Fri, Jul 5, 2013 at 2:35 AM, Juliusz Chroboczek > wrote: >> >> > 2. Also, what about DAD? If all the hosts participate in the routing >> > protocol, you can implement DAD over that, but what about current >> > hosts? >> >> You're right, we don't do DAD. That's related to the issues with >> link-local above. > > > I see. So this is a significant change in semantics. Given that RFC 2462 > says: > > Duplicate Address Detection MUST be performed on all unicast > addresses prior to assigning them to an interface, regardless of > whether they are obtained through stateless autoconfiguration, > DHCPv6, or manual configuration, with the following exceptions: > > then it's fair to expect that standard implementations can (and likely do) > assume that if DAD succeeds, then their IPv6 address is unique and usable. > > That being the case, how can you ensure that there are no duplicate > addresses in the network? If all hosts on the nework speak the routing > protocol, then that's easy, but what about legacy hosts? Does this scheme > require that all hosts on the network speak the routing protocol? > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From andrewmcgr@gmail.com Thu Jul 4 23:02:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9179621F9BFB for ; Thu, 4 Jul 2013 23:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWdUDxdgRCK9 for ; Thu, 4 Jul 2013 23:02:07 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id AFDEE11E8242 for ; Thu, 4 Jul 2013 23:02:02 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fo12so1734298lab.25 for ; Thu, 04 Jul 2013 23:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NpTTJkFanuHZEFqbh7zzZTjrKXwtlpwYdJlRYTu/s/E=; b=sW79gXJw9bcDhJGLxG5uk+ZGx5+gqmuYcgWdsKOnO2X9ChUmlGWQalxDCweJ/673Yp crPmcAkf9Ag+7yGcjDAzWpGqx/aFpbUIb/xWKPH6We+pMzkYEg5px07z0ye+CMeAlWNf LrE/zPY72CrBLYhwOiyhye2jtxvtQ0CcaEQI5As3Plwj6qU2oGwrF8Y+J6//q0gL4gb4 7Y9jFUD5ZgIob2v6sQoJX1fyT/nJhxrOzq3vQ2udTT8qhJTTtOoPLz0uu59rpZpfWXsn /wTFDYtKOGMnr5xAqJjC7a2X8soofIQoB8VXk3WTul5yuYhesJqgNpetKr+W8wnDM8TL nrmQ== MIME-Version: 1.0 X-Received: by 10.152.27.40 with SMTP id q8mr4233712lag.75.1373004121612; Thu, 04 Jul 2013 23:02:01 -0700 (PDT) Received: by 10.112.51.41 with HTTP; Thu, 4 Jul 2013 23:02:01 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> <87ip0y56z6.wl%jch@pps.univ-paris-diderot.fr> <7id2qyw7mv.wl%jch@pps.univ-paris-diderot.fr>

Date: Fri, 5 Jul 2013 16:02:01 +1000 Message-ID: From: Andrew McGregor To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0158c5aaf1aa2404e0bd6e61 Cc: "homenet@ietf.org Group" , Juliusz Chroboczek , Lorenzo Colitti Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 06:02:08 -0000 --089e0158c5aaf1aa2404e0bd6e61 Content-Type: text/plain; charset=ISO-8859-1 DAD could be interpreted to mean, not the specific method defined in the IPv6 RFCs, but 'some way of detecting duplicate addresses that is likely to work in this situation'. However, given that DAD as deployed doesn't work due to hidden nodes, this becomes an extra requirement on APs and other wireless devices to help out the DAD process. Presumably we need homenet routers, especially the wireless ones, to proxy DAD when they know an address exists on any link, whether or not there's an expectation that the two hosts could communicate directly. On Fri, Jul 5, 2013 at 3:31 PM, Henning Rogge wrote: > the DAD as defined in the IPv6 RFCs doesn't work in a multihop radio > network, because of the hidden station problem. > > Imagine a situation with three nodes A, B and C. A can hear B, B can > hear A and C, C can hear B. > > If A and C choose the same address, DAD will not detect the problem > because A and C cannot talk to each other directly, but B will have > two neighbors with the same address. > > Because of this problem you need a different approach to generate your > addresses. > > Henning Rogge > > On Fri, Jul 5, 2013 at 3:49 AM, Lorenzo Colitti > wrote: > > On Fri, Jul 5, 2013 at 2:35 AM, Juliusz Chroboczek > > wrote: > >> > >> > 2. Also, what about DAD? If all the hosts participate in the routing > >> > protocol, you can implement DAD over that, but what about current > >> > hosts? > >> > >> You're right, we don't do DAD. That's related to the issues with > >> link-local above. > > > > > > I see. So this is a significant change in semantics. Given that RFC 2462 > > says: > > > > Duplicate Address Detection MUST be performed on all unicast > > addresses prior to assigning them to an interface, regardless of > > whether they are obtained through stateless autoconfiguration, > > DHCPv6, or manual configuration, with the following exceptions: > > > > then it's fair to expect that standard implementations can (and likely > do) > > assume that if DAD succeeds, then their IPv6 address is unique and > usable. > > > > That being the case, how can you ensure that there are no duplicate > > addresses in the network? If all hosts on the nework speak the routing > > protocol, then that's easy, but what about legacy hosts? Does this scheme > > require that all hosts on the network speak the routing protocol? > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > > > -- > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --089e0158c5aaf1aa2404e0bd6e61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

DAD could be interpreted to mean, not the specific method = defined in the IPv6 RFCs, but 'some way of detecting duplicate addresse= s that is likely to work in this situation'.

However= , given that DAD as deployed doesn't work due to hidden nodes, this bec= omes an extra requirement on APs and other wireless devices to help out the= DAD process. Presumably we need homenet routers, especially the wireless o= nes, to proxy DAD when they know an address exists on any link, whether or = not there's an expectation that the two hosts could communicate directl= y.

On Fri,= Jul 5, 2013 at 3:31 PM, Henning Rogge <hrogge@googlemail.com><= /span> wrote:

the DAD as defined in the IPv6 RFCs doesn= 9;t work in a multihop radio
network, because of the hidden station problem.

Imagine a situation with three nodes A, B and C. A can hear B, B can
hear A and C, C can hear B.

If A and C choose the same address, DAD will not detect the problem
because A and C cannot talk to each other directly, but B will have
two neighbors with the same address.

Because of this problem you need a different approach to generate your
addresses.

Henning Rogge

On Fri, Jul 5, 2013 at 3:49 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Fri, Jul 5, 2013 at 2:35 AM, Juliusz Chroboczek
> <jch@pps.univ-pari= s-diderot.fr> wrote:
>>
>> > 2. Also, what about DAD? If all the hosts participate in the = routing
>> > protocol, you can implement DAD over that, but what about cur= rent
>> > hosts?
>>
>> You're right, we don't do DAD. =A0That's related to th= e issues with
>> link-local above.
>
>
> I see. So this is a significant change in semantics. Given that RFC 24= 62
> says:
>
> =A0 =A0Duplicate Address Detection MUST be performed on all unicast > =A0 =A0addresses prior to assigning them to an interface, regardless o= f
> =A0 =A0whether they are obtained through stateless autoconfiguration,<= br> > =A0 =A0DHCPv6, or manual configuration, with the following exceptions:=
>
> then it's fair to expect that standard implementations can (and li= kely do)
> assume that if DAD succeeds, then their IPv6 address is unique and usa= ble.
>
> That being the case, how can you ensure that there are no duplicate > addresses in the network? If all hosts on the nework speak the routing=
> protocol, then that's easy, but what about legacy hosts? Does this= scheme
> require that all hosts on the network speak the routing protocol?
>

> _________________________________= ______________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

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

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

--089e0158c5aaf1aa2404e0bd6e61-- From swmike@swm.pp.se Thu Jul 4 23:54:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A16E11E822B for ; Thu, 4 Jul 2013 23:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS7CIh3mcmBu for ; Thu, 4 Jul 2013 23:54:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4A56F11E8267 for ; Thu, 4 Jul 2013 23:53:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2672A9C; Fri, 5 Jul 2013 08:53:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1BC019A; Fri, 5 Jul 2013 08:53:50 +0200 (CEST) Date: Fri, 5 Jul 2013 08:53:50 +0200 (CEST) From: Mikael Abrahamsson To: Michael Richardson In-Reply-To: <22885.1372946169@sandelman.ca> Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDE9962@wds-exc1.okna.nominet.org.uk> <22885.1372946169@sandelman.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "homenet@ietf.org Group" Subject: Re: [homenet] IETF 87 - call for agenda items 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, 05 Jul 2013 06:54:16 -0000 On Thu, 4 Jul 2013, Michael Richardson wrote: > I would like the WG to spend some face time dealing with (making a list > of), things that need to be configured, which are not routes. I would like to see a scheme where anything can be configured, including stuff which can be vendor-specific/proprietary so vendors can deploy new functionality quickly without going through a standardisation process, and then at a later date when it becomes a standard, they can abolish the vendor-specific identifiers they've been using. I'm thinking along the way SNMP works here... So yes, there should be a discussion about what homenet needs to be configured, but overall I would homenet to create a solution that other configuration information can ride along with. High level goal I have in mind I would like to see "just working" in 5-10 years. I buy a new device. I unpack it and start it up. It sees a bunch of Wifi networks, I select one that is mine. On another device I run a "control my home" app, where I can see in chronological order what devices have requested access. I grant access to the device I just started up, it connects, sees configuration information from the network, and asks what role it should configure itself as. I select "Mikael Abrahamsson portable device", and through the same app mentioned before, I get a request, and I grant it. Now this device aquires a certain amount of privileges and configuration that I have configured all my portable devices to have, including mail accounts etc. All authorization/encryption/communication is done encrypted with a TPM style component internal to the device. Now this device automatically has configured itself to have my printers etc. Now I bring this device to my friends house. He has already allowed access to "Mikael Abrahamsson devices" with some kind of guest privileges. My new device has already received information about what "friends" I have and since my friends network is broadcasting a key that belongs to my friend, my device automatically tries to connect, before that it verifies that the public key is correct (authenticating the network), my friends network autenticates my device, and my new device is allowed to connect without any unique action taken by my friend or me. Same thing when I buy a new network device to connect to my network, I connect it, authorize it, what role it should have, and then everything is configured automatically. The above scenario requires a staggering amount of configuration information, discovery and interaction. Not all of it new, but it needs to be tied together a lot and whatever configuration/discovery architecture we come up with should not be in the way of future developments in this area. Am I totally "up in the sky" with the above vision of where things should be headed, or do we have a shared long-term vision within the WG? -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Fri Jul 5 00:53:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FD211E825D for ; Fri, 5 Jul 2013 00:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqxzcgNjx+mw for ; Fri, 5 Jul 2013 00:53:56 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EBB1F11E825B for ; Fri, 5 Jul 2013 00:53:55 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz10so1578617veb.31 for ; Fri, 05 Jul 2013 00:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=/dcOn9/yiUdpaMb9VkXF9VBHoqcKRTr6GwFjEVvrO7g=; b=I9pUyI1y5lEFXEohA93CY8hhizD59BQeIl2Xv47u3Vnnxt8AIKXGY+T3AqDCadnD5p fuXsL51USX+IqW26cbPjj6nK/OOtJmN6flY0iiTIblYJV6UECQonbqqAO8RngjRg5dhC a4XjkvHPsfmhyghPqmyUSd8m3tV4e7tIJuvkk1caYwp3e6qLiYe8ogI5OiVhy6CKhqwi VeNTRvX/t13upRuE+SVUndrqhN4/Y8OUD7+tX3PNeTa/tnd1XptPliu44sFNkp+PazhG Zh/YbsG9tkHu4ly4Pk0NNyEteIhm3R07M6+F4B35z+OBFsNzO7aW9kA7zJ6nOzkUSoPn jTZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-gm-message-state; bh=/dcOn9/yiUdpaMb9VkXF9VBHoqcKRTr6GwFjEVvrO7g=; b=B6aMtcQ1DwSqmdaS9CpgFArd1GZri4boPT1F+n7daKWmZWCPeUc7ryHw3dJ3ysgLlZ Bu4hGpeviKSonaeqVz4k0kYMAdPkz9cEOrd65RV5DYLiL8iVZRk5N7sDmKOGKHOZnlnp KcvO3iI5KLLCpzcLwCZXto53sWhzaSQNK+CAZJsUnt5fPuzer3H5Z9MeYEUXC68lkmP3 wzBEpgIwe16oN7ZpInfNqP8Lh67zkzImDFh8Sibrsc+/O+E+B82LuKESRIODMDWIrJtD nae/2vDd7p0Cmp6IOzU8k3a/zxBD4iwW3tgE+5oO3swq5ChK7Kwgl/VITHucZ+rndZDl GYlw== X-Received: by 10.220.198.133 with SMTP id eo5mt6738975vcb.24.1373010835232; Fri, 05 Jul 2013 00:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.241.136 with HTTP; Fri, 5 Jul 2013 00:53:34 -0700 (PDT) In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DD9D252@wds-exc1.okna.nominet.org.uk> <9D7D0D56-BCAD-4028-818F-B2FF46AD21E5@gmail.com> <5DC7A376-906C-4278-897B-3C6679D78FC7@fugue.com> <160953AF-4B2E-4189-B472-41E20CBA87AE@gmail.com> <51C5DB8C.1070104@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185A4D@eusaamb101.ericsson.se> <51C6038F.2050500@globis.net> <94A203EA12AECE4BA92D42DBFFE0AE47185C5C@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE47186532@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE471868AB@eusaamb101.ericsson.se> <3FB7F9ED-2CA6-4C55-98C8-80908FD1291D@fugue.com> <87a9mglclo.wl%jch@pps.univ-paris-diderot.fr> <1B90DAEA-BD29-4640-85EF-BF1B7F524E0B@fugue.com> <871u7sl6tv.wl%jch@pps.univ-paris-diderot.fr> <7i8v1vtikc.wl%jch@pps.univ-paris-diderot.fr> <87zjuatl7h.wl%jch@pps.univ-paris-diderot.fr> <87ip0y56z6.wl%jch@pps.univ-paris-diderot.fr> <7id2qyw7mv.wl%jch@pps.univ-paris-diderot.fr>

From: Lorenzo Colitti Date: Fri, 5 Jul 2013 16:53:34 +0900 Message-ID: Content-Type: multipart/alternative; boundary=001a11c1c4521c99af04e0beffc4 X-Gm-Message-State: ALoCoQnvapDZUKc2mjXi7FhQtYeQFywVhif6uMNh+el4GhHPnxioj7ojQybXGC/+p+6VNtSJX6ia61yEpd/8+393dO4RfOhSYGE1BUad/txN3IhGdmZugId1I5aBm5BXCN7fNnnNOKcjyjHpdH9E4upjW+NkI5lep8lAQDRs6MMO2TpICinPPGu2d3Cl05MCM4USlvkx3tsG Cc: Henning Rogge , "homenet@ietf.org Group" , Juliusz Chroboczek Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 07:53:56 -0000 --001a11c1c4521c99af04e0beffc4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 5, 2013 at 3:02 PM, Andrew McGregor wrote: > DAD could be interpreted to mean, not the specific method defined in the > IPv6 RFCs, but 'some way of detecting duplicate addresses that is likely to > work in this situation'. > Where "work in this situation" means "works without modifying existing host implementations", yes? --001a11c1c4521c99af04e0beffc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

--001a11c1c4521c99af04e0beffc4-- From lorenzo@google.com Fri Jul 5 00:59:38 2013 Return-Path:

On Fri, Jul 5, 2013 at 9:49 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

> Why does= [TROAN] not also cover 2.2.3? Is the conceptual forwarding algorithm
> in [TROAN] incomplete?

2.2.3 describes the "disambiguation routes" technique that = we use in
order to coerce a hostile API (Linux' rule API) into having the right behaviour.

Oh, I see. But then 2.2.3 just d= escribes one possible way to implement the algorithm proposed in [TROAN] on= a system that is constrained by different lower-level primitives, right?

In that case, might I suggest that you clarify the text= so it clearly separates the desired behaviour from its implementation, pre= sents the limitations of current OSes in this regard, and then presents you= r disambiguation routes as a possible implementation of the desired behavio= ur within the capabilities of current OSes.

Also in that case, I would suggest completely getting r= id of the concept of "ambiguity". The draft appears to define &qu= ot;ambiguity" as the case where multiple entries match a given packet,= but this is in no way specific to source+destination routing, it happens i= n destination-based routing as well (that's why we use longest-prefix m= atches). That said, since ambiguity can obviously only exist where the rule= s are not clearly defined, if you clearly separate the desired behaviour fr= om the implementation, you might end up finding that there is no need for t= his concept. In a sense, it seems that the problem is not ambiguity, it'= ;s that current OSes don't implement the rules that are needed to make = source+destination routing work.

There is no mention of disambiguation route= s in your
draft, there is not even a mention of the fact that the existing
low-level APIs might have a different default behaviour and that a lot
of work needs to be done in order to get the lower layers to behave.

Well, but that's because they're not = needed, right? [TROAN] doesn't mention disambiguation because the conce= ptual forwarding algorithm that it presents is not ambiguous, and so no nee= d to resolve ambiguity.

I was under the impression that you make no= claim about being able to
implement the "conceptual forwarding algorithm" on existing opera= ting
systems. =A0If that's not the case, I'd be curious to see your impl= ementation.

Does the algorithm you prop= ose implement the conceptual forwarding algorithm in [TROAN], then? If so, = then why not say so? That way we don't have two drafts describing the s= ame algorithm in different words.

--20cf307d012a7a96c304e0fb68cf-- From jch@pps.univ-paris-diderot.fr Mon Jul 8 07:04:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDEF21F9D08 for ; Mon, 8 Jul 2013 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKLMpQl7mMug for ; Mon, 8 Jul 2013 07:04:35 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CF821F9D04 for ; Mon, 8 Jul 2013 07:04:34 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r68E4TUT028083; Mon, 8 Jul 2013 16:04:29 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 100BE4F9A7; Mon, 8 Jul 2013 16:04:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qUPKJMn2unCd; Mon, 8 Jul 2013 16:04:23 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2FA674F9FB; Mon, 8 Jul 2013 16:04:23 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UwC3C-0001Jv-Ni; Mon, 08 Jul 2013 16:04:22 +0200 Date: Mon, 08 Jul 2013 16:04:22 +0200 Message-ID: <878v1hxi55.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 08 Jul 2013 16:04:31 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:04:41 -0000 Lorenzo, In [1], you claim that your draft subsumes our work. In [2], you rather rudely question whether we've read your draft. In [3], you imply that our draft consists of just one page of content and that the rest is unrelated filler. Perhaps you could take the time to retract these claims before we continue this discussion? -- Juliusz [1] [2] [3] From lorenzo@google.com Mon Jul 8 08:37:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F7221F9D17 for ; Mon, 8 Jul 2013 08:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqs-oukDRUEH for ; Mon, 8 Jul 2013 08:37:48 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1E21F9D15 for ; Mon, 8 Jul 2013 08:37:48 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id p14so3490651vbm.4 for ; Mon, 08 Jul 2013 08:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nrYoIuSqYU6sfmxNFqCfx+ngjdmB0CO4KSKc5QnNMJc=; b=OKyEl8P8R6qNrK+LBgxMJvckOpk+qW9DM1AQt8X/KLnzWaq5i9NxwifHKbXw3PucMO AeYjferQx8rkMaWsVR2rUvsyeW9S0fN63e2wkHytodNk6KSz+XtfofvLWwjhZGpYOqpC s6G+nCcJfIS1hDFqNCzPVWjX7e3PuLVUHf35o7lOGI+VkfL7hUbbwZ1jfgCl2wYrP73U s5P2kP4Rn/oPC1BlIeJgLhm1z/mthcCXNe6u8ymt6EzwHGiUC3Suohx6V7zWltnX0qd/ 7XE144U3XHVryqov4bF7lj6YXSfoFhv4+3POCb2XFbZt+1GnKiEU1WrGuAiiohPXVrU0 +7nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=nrYoIuSqYU6sfmxNFqCfx+ngjdmB0CO4KSKc5QnNMJc=; b=dQa3UwrDgkR6iF3UpYI+X2Qxhu0wPD6R7fRmJSMA1tCdPdDtAtJZ6objAUMOV85gQ9 XGKd+voCEoKykdKixlm242btluZDZ/OUtsOBq5j2utvZZ1OlTzYUvfqYAfDeDx+kS/a2 pebrTbFCYVnxEUsqYCh1REmeG7XvLEvxdHlBQKgtH+OF6dlOFk/YszXi0YvHV8uL1/2f eL4c4+wstVuztMExbeDwC7Kmxpa1JDKcZcnpS6IEDFhwQXYMplaC2R7rMOuX0u+f036q MjOix1kzofCZMHeoIeq6FCDDuX6Tth44LkNopMPtOMPpdK6tvGg8C5eGBLVStCovfphr e43Q== X-Received: by 10.220.68.144 with SMTP id v16mr14157444vci.76.1373297867580; Mon, 08 Jul 2013 08:37:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.217.141 with HTTP; Mon, 8 Jul 2013 08:37:26 -0700 (PDT) In-Reply-To: <878v1hxi55.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <878v1hxi55.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Tue, 9 Jul 2013 00:37:26 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=047d7b3a938691929004e101d329 X-Gm-Message-State: ALoCoQlE8aPkrQ9Etx2nRquEQ7r8JKvtaHyYGCcuWFU5YzTmoUAk77fKfdjHPYUy8zhN4OHPSpfup79SlpK9s9nDCPiDzVFFqRtHuf8zSufZz39Siac5jgNHF/tbpjD4L2z6/roxBS45Pd5WY2Wti0sj++rajLTkKnT5kmdbmk4/hSLQCp8W0dL7ft4yBMKK0VJynHKxjhGl Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:37:49 -0000 --047d7b3a938691929004e101d329 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 11:04 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > In [1], you claim that your draft subsumes our work. In [2], you > rather rudely question whether we've read your draft. In [3], you > imply that our draft consists of just one page of content and that the > rest is unrelated filler. > > Perhaps you could take the time to retract these claims before we > continue this discussion? > I apologize if that is the way you read the messages. But I did not make these claims. I do think that there is substantial overlap between [TROAN] and your work. I'm still trying to understand if the conceptual algorithm is fundamentally the same, but it seems to me that it is. If that's true, then as a working group, it makes more sense to build on [TROAN] rather to introduce a second draft with a different formalization of what is in effect the same problem and the same solution (apart from the part of the draft that documents implementation experience, which is of course useful since it's implementation experience). I maintain this opinion, and others may of course disagree. As for claiming that your draft is one page of content and unrelated filler, I said nothing of the sort. You said [TROAN] covered roughly 15% of your text, and I said that longer does not necessarily mean more useful. The "6x" example was just that - an example. I thought you would agree with me that if we increased the length of [TROAN] by 6x by adding irrelevant text then it would not be an improvement. I didn't mean that 85% of your draft is irrelevant. --047d7b3a938691929004e101d329 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 8, 2013 at 11:04 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

In [1], you claim that your dra= ft subsumes our work. =A0In [2], you
rather rudely question whether we've read your draft. =A0In [3], you imply that our draft consists of just one page of content and that the
rest is unrelated filler.

Perhaps you could take the time to retract these claims before we
continue this discussion?

I apologize i= f that is the way you read the messages. But I did not make these claims.

I do think that there is substantial overlap betwee= n [TROAN] and your work. I'm still trying to understand if the conceptu= al algorithm is fundamentally the same, but it seems to me that it is. If t= hat's true, then as a working group, it makes more sense to build on [T= ROAN] rather to introduce a second draft with a different formalization of = what is in effect the same problem and the same solution (apart from the pa= rt of the draft that documents implementation experience, which is of cours= e useful since it's implementation experience). I maintain this opinion= , and others may of course disagree.

As for claiming that your draft is one page of content = and unrelated filler, I said nothing of the sort. You said [TROAN] covered = roughly 15% of your text, and I said that longer does not necessarily mean = more useful. The "6x" example was just that - an example. I thoug= ht you would agree with me that if we increased the length of [TROAN] by 6x= =A0by adding irrelevant text then it would not be an improvement. I didn= 9;t mean that 85% of your draft is irrelevant.

--047d7b3a938691929004e101d329-- From victor@jvknet.com Mon Jul 8 08:43:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D521B21F9D39 for ; Mon, 8 Jul 2013 08:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356, SARE_SUB_OBFU_OTHER=0.135] 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 jC-7AurbMHOT for ; Mon, 8 Jul 2013 08:43:24 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id C5F6821F9D3B for ; Mon, 8 Jul 2013 08:43:23 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so10564482iej.29 for ; Mon, 08 Jul 2013 08:43:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-type:x-gm-message-state; bh=diliOohszFVb2k8Kh0twjvOC2ryFIoJxt58WVYPP2IY=; b=Emwwc+sMplEpKFhqAF2SW6T5ZtPh/6eyDxrAVXJnxJEmEibvdcwkeKA/X+vIVu1WZ7 QsN0nDfYHk+0zGimBk1dMxWFSxo+95lJv9l36sKqCAstMkeHrlM3zAjj3WJBWi/QWYTF sNqEU+h946FFM9i8G4LG+RiH4xm0xcpEcgcpwbV/aULK/FrVrmzJeg5VIiE3FipKdala jX+ORTdN6hkXakGMcn5IsrUhrP2wIpcjPYLc9vLjwOLkUz17RJuMsKLQqP0ODpXxoVgi QBPotpnsEHBWwbinCuARMfRpUZG10KRpH27YMQ/qxL9NR9mn/2HCYnuuh9tEd8PgJXat v99A== X-Received: by 10.42.132.3 with SMTP id b3mr7472743ict.98.1373298202243; Mon, 08 Jul 2013 08:43:22 -0700 (PDT) Received: from [192.168.0.41] ([65.97.213.8]) by mx.google.com with ESMTPSA id w5sm23868385igz.10.2013.07.08.08.43.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Jul 2013 08:43:21 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 08 Jul 2013 11:43:15 -0400 From: Victor Kuarsingh To: Lorenzo Colitti Message-ID: Thread-Topic: [homenet] FW: New Version Notification for draft-jvkjjmb-home-networking-incremental-00.txt Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3456128603_7921057" X-Gm-Message-State: ALoCoQkhAWqzmEpGYJLZwpEnBp6VVEM8OKZcjRfd4XJ0pfzRvTVA1FWoruhlZUb/rhdJzcVYLXQ6 Cc: Chris Grundemann , John McQueen , Mark Townsley , Ray Bellis , John Jason Brzozowski , "homenet@ietf.org" Subject: Re: [homenet] FW: New Version Notification for draft-jvkjjmb-home-networking-incremental-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, 08 Jul 2013 15:43:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3456128603_7921057 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Lorenzo, thanks for posting. A few responses and comment. From: Lorenzo Colitti >First, some of the draft, particularly the flowing prose in sections 1-3, = or things like "will not only act as an enabler but will also provide >critica= lity required transition capabilities to ensure advanced phases can also be depl= oyed seamlessly to both customers and operators >with minimal disruption" is unnecessarily verbose and marketing-y for a technical document. Perhaps it = could be shortened. [VK] Ok, we can review this to address salient points. >More importantly, I see issues with the message of the draft itself. For a draft whose main proposal is an "incremental upgrade path", I'm >surprised = that no upgrade path is actually presented. [VK] The goal of the draft was to describe (as other incrementals in the past) that path, but not spell out each detail. Details on how to move to = a given technological phase should be part of the work of a given technology. It would be a very long and tedious task to deal with that on just one document. Also, given the flux with some of the current work, I am not sur= e we know enough to spell that out now anyway. >A number of phases are described, but no actual upgrade path is provided. = I think >this is a real concern, because I see important ways in >which each = the intermediate phases, instead of being an incremental step, could >actually = be a barrier to further progress. [VK] It would be good to vet these potential barriers out. I would say that the first phase is actually today (what we have in networks by virtue of 6402 or 6402-like code already in the wild). If we suggest the last phase (Posterus) is much of what many (in this WG) think is the end state, then it's the second (medius) and third (provectus) phase progressions whic= h are in question. To that point, going from 6204 to phase 2 (of which HIPnet is an option) appears to be very achievable. So the question (in my mind) comes down to how to progress from that to using routing protocols in the home (with our without it's prefix assignment capabilities). I think moving from 6204/6204-bis to homenet is as much a challenge as moving from hipnet to homenet., I would like to know how we had planned on moving from 6204 to phase 3/4. And, would still like to know what barriers phase 2 would have on phase 3/4 (I.e. How would adding a routing protocol a= s an overlay [option] to an existing home network be problematic). >A very basic example is ISPs delegating only a /64 to each home network. T= his is a barrier to evolution, because home routers are often >written to the l= owest common denominator. If ISPs hand out /64s, we might see widespread adoption= of routers that only support /64 >and choke when given anything else. At that point, it becomes impossible for ISPs to hand out prefixes larger than /64s because of the >fear of breaking customer connectivity. Fortunately this do= es not appear to be the case because most ISPs started to provide larger than = >/64 prefixes from day one; but it would have been a real problem if most ISPs h= ad standardized on /64. [VK]. I note this, not as a design point, but a reality of what is in the wild. I cannot ignore it. I think many operators had (past) chosen this a= s an initial step due to problems with CPE equipment that reacted poorly to shorter (larger) prefixes. I suspect this will change once the risk is lower (operators are not allowed to just impact customers willy nilly to achieve technological advancement). I agree that long term use of a /64 is problematic.. I don't like this =AD but I again will say I cannot ignore it a= s a potential in some networks and/or a condition of error at times. Any solution needs to know what to do in such a case. >Another example is the fact that the draft proposes a tree topology ("Medi= us" and "Provectus") as intermediate between a flat one-link >topology and a fu= lly meshed topology. That sounds good in theory, but in practice things aren't = that simple, because as soon as you have >even just one device that doesn't supp= ort meshing, the mesh doesn't work any more. [VK] Well most home networks we see in our networks are actually flat. Som= e use sub-tended equipment to achieve WiFi range extensions and/or port coun= t increases (I am speaking of people who may have full router/gateway to extend WiFi and not a proper extender which is not a L3 point in the topology). [VK]Of those tandem devices, they are often tree in nature (hanging off the main gateway). I know we have spoken about meshes to date, and I agree thi= s can happen, but I have not seen any data suggesting it's a significant portion of the deployment base. But this is a point of discussion. Try putting an router that only supports EIGRP into >an OSPF or IS-IS based network - the whole thing falls over. So in fact, far from being an intermediate step, these phases actually >constitute barriers that make it harder to get to the end state. [VK] For the routing piece, I don't think anyone is suggesting that there i= s a mixed mode of routing protocols. I think the draft did present some options. That said, it is possible to run more then one Routing protocol i= n big networks (we do it all the time), but I am not sure that's a good idea for a home network. EIGRP was not discussed. There was some discussion of RIP, which is still an option (some may disagree). RiP does have some advantages due to simplicity and is widely used in circumstances where it makes sense (not saying home net is one of them). >As another example, in the "Provectus" phase, it is stated that a routing protocol is "optional". How is this going to work? What happens >when some = but not all routers speak the routing protocol? Which source of information wil= l be authoritative? Who is going to turn the >routing protocol on? And so on. [VK] discussion around this is welcome. If you have gleaned routing (form prefix assignment and default for north), then you don't need a full complement of routes running routing protocols (the routing table my be comprised of routes form different soruces). This may not be the most efficient mode of operation, but again, we are talking about brown field. To expect a full home network swap out of like-capable equipment is not reasonable operationally (so all solutions need to deal with modes of operation with previous-gen and current-gen functions operating together). >So saying "we'll get there in phases" is well and good, but to do that the draft needs to explain how to get from one phase to another, >and explain h= ow deploying "intermediate" phases makes the end result easier, not more diffi= cult, to achieve. [VK] I can only go with experience here. I have had very few opportunities to build greenfield. Most of the networks we have in general are here base= d on progression. Mind you that was managed networks, but I think the principle still holds. In my mind, to suggest we don't need phases is more contrary to our experience and how we can get from A-Z in a single step is questionable. I can tell you today we spend most of our time as operators trying to get stuff upgraded (mobile and wireline) and making stuff work (not break) while we do it. It's a difficult reality we deal with every day. Regards, Victor K On Fri, Jul 5, 2013 at 11:48 AM, Victor Kuarsingh wrote= : > Homenet WG, >=20 > A draft has been submitted (below) which outlines a home network > progression from current state (reference point RFC6204) to future > advanced states. >=20 > The progression is outlined as an incremental approach to achieve the ful= l > envisioned homenet architecture over a series of phases (additive > capabilities). >=20 > The progression outlined was envisioned such that the home network can be > evolve in a controlled and feasible manner considering the realities of > brownfield deployments in environments that must remain operational durin= g > the transition. >=20 > The WGs feedback is desired and requested. >=20 > Regards, >=20 > Victor K >=20 >=20 > On 2013-07-04 10:34 PM, "internet-drafts@ietf.org" > wrote: >=20 >> > >> >A new version of I-D, draft-jvkjjmb-home-networking-incremental-00.txt >> >has been successfully submitted by Victor Kuarsingh and posted to the >> >IETF repository. >> > >> >Filename: draft-jvkjjmb-home-networking-incremental >> >Revision: 00 >> >Title: An incremental solution to advanced home networking >> >Creation date: 2013-07-04 >> >Group: Individual Submission >> >Number of pages: 24 >> >URL: >> >http://www.ietf.org/internet-drafts/draft-jvkjjmb-home-networking-incre= men >> >tal-00.txt >> >Status: >> >http://datatracker.ietf.org/doc/draft-jvkjjmb-home-networking-increment= al >> >Htmlized: >> >http://tools.ietf.org/html/draft-jvkjjmb-home-networking-incremental-00 >> > >> > >> >Abstract: >> > The home network is an environment subject to ongoing evolution and >> > change. Many home networks today are simplistic in nature, often >> > comprising of a single router/gateway. The expectation over time is >> > predicated on the notion that the home network will be more complex >> > servicing many in-home and Internet functions. The home network wil= l >> > evolve necessitating the replacement and update to current hardware >> > and software to more advanced devices and software capable of >> > operating in more complex environments. This document provides a >> > view on how the home network can progress from today's foundational >> > form, to a more advanced environment, using progressive technologica= l >> > capabilities. >> > >> > >> > >> > >> > >> > >> >The IETF Secretariat >> > >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --B_3456128603_7921057 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Lorenzo,

thanks for posting. A few responses and comment.

<= div>

From: Loren= zo Colitti <lorenzo@google.com>= ;

>First, some of the dra= ft, particularly the flowing prose in sections 1-3, or things like "will not= only act as an enabler but will also provide >criticality required trans= ition capabilities to ensure advanced phases can also be deployed seamlessly= to both customers and operators >with minimal disruption" is unnecessari= ly verbose and marketing-y for a technical document. Perhaps it could be sho= rtened.

[VK] Ok, we can review this to= address salient points.

>More importantly, I see issues with the message of = the draft itself. For a draft whose main proposal is an "incremental upgrade= path", I'm >surprised that no upgrade path is actually presented.

<= /div>

[VK] The goal of the draft was to desc= ribe (as other incrementals in the past) that path, but not spell out each d= etail. Details on how to move to a given technological phase should be= part of the work of a given technology. It would be a very long and t= edious task to deal with that on just one document. Also, given the fl= ux with some of the current work, I am not sure we know enough to spell that= out now anyway.

>A number of phases are described, but no actual upgrade pat= h is provided. I think >this is a real concern, because I see important w= ays in >which each the intermediate phases, instead of being an increment= al step, could >actually be a barrier to further progress.

[VK] It would be good to vet these potential b= arriers out. I would say that the first phase is actually today (what = we have in networks by virtue of 6402 or 6402-like code already in the wild)= . If we suggest the last phase (Posterus) is much of what many (in thi= s WG) think is the end state, then it's the second (medius) and third (prove= ctus) phase progressions which are in question.

To = that point, going from 6204 to phase 2 (of which HIPnet is an option) appear= s to be very achievable. So the question (in my mind) comes down to ho= w to progress from that to using routing protocols in the home (with our wit= hout it's prefix assignment capabilities).

I think = moving from 6204/6204-bis to homenet is as much a challenge as moving from h= ipnet to homenet., I would like to know how we had planned on moving from 62= 04 to phase 3/4. And, would still like to know what barriers phase 2 w= ould have on phase 3/4 (I.e. How would adding a routing protocol as an overl= ay [option] to an existing home network be problematic).

>A very basic exampl= e is ISPs delegating only a /64 to each home network. This is a barrier to e= volution, because home routers are often >written to the lowest common de= nominator. If ISPs hand out /64s, we might see widespread adoption of router= s that only support /64 >and choke when given anything else. At that poin= t, it becomes impossible for ISPs to hand out prefixes larger than /64s beca= use of the >fear of breaking customer connectivity. Fortunately this does= not appear to be the case because most ISPs started to provide larger than = >/64 prefixes from day one; but it would have been a real problem if most= ISPs had standardized on /64.

[VK]. I= note this, not as a design point, but a reality of what is in the wild. &nb= sp;I cannot ignore it. I think many operators had (past) chosen this a= s an initial step due to problems with CPE equipment that reacted poorly to = shorter (larger) prefixes. I suspect this will change once the risk is= lower (operators are not allowed to just impact customers willy nilly to ac= hieve technological advancement). I agree that long term use of a /64 = is problematic.. I don't like this – but I again will say I cannot ign= ore it as a potential in some networks and/or a condition of error at times.= Any solution needs to know what to do in such a case.

>Another example= is the fact that the draft proposes a tree topology ("Medius" and "Provectu= s") as intermediate between a flat one-link >topology and a fully meshed = topology. That sounds good in theory, but in practice things aren't that sim= ple, because as soon as you have >even just one device that doesn't suppo= rt meshing, the mesh doesn't work any more.

[VK] Well most home networks we see in our networks are actually= flat. Some use sub-tended equipment to achieve WiFi range extensions = and/or port count increases (I am speaking of people who may have full= router/gateway to extend WiFi and not a proper extender which is not a L3 p= oint in the topology).

[VK]Of those tandem devices,= they are often tree in nature (hanging off the main gateway). I know = we have spoken about meshes to date, and I agree this can happen, but I have= not seen any data suggesting it's a significant portion of the deployment b= ase. But this is a point of discussion.

Try p= utting an router that only supports EIGRP into >an OSPF or IS-IS based ne= twork - the whole thing falls over. So in fact, far from being an intermedia= te step, these phases actually >constitute barriers that make it harder t= o get to the end state.

[VK] For the routing piece,= I don't think anyone is suggesting that there is a mixed mode of routing pr= otocols. I think the draft did present some options. That said, = it is possible to run more then one Routing protocol in big networks (we do = it all the time), but I am not sure that's a good idea for a home network. &= nbsp;EIGRP was not discussed. There was some discussion of RIP, which = is still an option (some may disagree). RiP does have some advantages due to= simplicity and is widely used in circumstances where it makes sense (not sa= ying home net is one of them).

>As another example, in the "Provectus" phase,= it is stated that a routing protocol is "optional". How is this going to wo= rk? What happens >when some but not all routers speak the routing protoco= l? Which source of information will be authoritative? Who is going to = turn the >routing protocol on? And so on.

[VK] discussion around this is welcome. If you have gleaned rou= ting (form prefix assignment and default for north), then you don't need a f= ull complement of routes running routing protocols (the routing table my be = comprised of routes form different soruces). This may not be the most = efficient mode of operation, but again, we are talking about brown field. &n= bsp;To expect a full home network swap out of like-capable equipment is not = reasonable operationally (so all solutions need to deal with modes of operat= ion with previous-gen and current-gen functions operating together).

>So sayi= ng "we'll get there in phases" is well and good, but to do that the draft ne= eds to explain how to get from one phase to another, >and explain how dep= loying "intermediate" phases makes the end result easier, not more difficult= , to achieve.

[VK] I can only go w= ith experience here. I have had very few opportunities to build greenf= ield. Most of the networks we have in general are here based on progre= ssion. Mind you that was managed networks, but I think the principle s= till holds. In my mind, to suggest we don't need phases is more contra= ry to our experience and how we can get from A-Z in a single step is questio= nable. I can tell you today we spend most of our time as operators try= ing to get stuff upgraded (mobile and wireline) and making stuff work (not b= reak) while we do it. It's a difficult reality we deal with every day.=

Reg= ards,

Victor K

On Fri, Jul 5, 2013 at 11:48 = AM, Victor Kuarsingh <victor@jvknet.com> wrote:

Homenet WG,

A draft has been submitted (below) which outlines a home network
progression from current state (reference point RFC6204) to future
advanced states.

The progression is outlined as an incremental approach to achieve the full<= br> envisioned homenet architecture over a series of phases (additive
capabilities).

The progression outlined was envisioned such that the home network can be evolve in a controlled and feasible manner considering the realities of
= brownfield deployments in environments that must remain operational during the transition.

The WGs feedback is desired and requested.

Regards,

Victor K

On 2013-07-04 10:34 PM, "internet= -drafts@ietf.org"
<internet-drafts@ietf.org&= gt; wrote:

>
>A new version of I-D, draft-jvkjjmb-home-networking-incremental-00.txt<= br> >has been successfully submitted by Victor Kuarsingh and posted to the >IETF repository.
>
>Filename: draft-jvkjjmb-home-networking-incrementa= l
>Revision: 00
>Title: An incremental solution to adv= anced home networking
>Creation date: 2013-07-04
>Group: Individual Submission
>Number of pages: 24
>URL:
>http://www.ietf.org/internet-drafts/draft-jvkj= jmb-home-networking-incremen
>tal-00.txt
>Status:
>http://datatracker.ietf.org/doc/draft-jvkjjmb-h= ome-networking-incremental
>Htmlized:
>http://tools.ietf.org/html/draft-jvkjjmb-home-net= working-incremental-00
>
>
>Abstract:
> The home network is an environment subject to ongoing evolution= and
> change. Many home networks today are simplistic in nature= , often
> comprising of a single router/gateway. The expectation ov= er time is
> predicated on the notion that the home network will be more com= plex
> servicing many in-home and Internet functions. The home n= etwork will
> evolve necessitating the replacement and update to current hard= ware
> and software to more advanced devices and software capable of > operating in more complex environments. This document pro= vides a
> view on how the home network can progress from today's foundati= onal
> form, to a more advanced environment, using progressive technol= ogical
> capabilities.
>
>
>
>
>
>
>The IETF Secretariat
>

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

<= br>

--B_3456128603_7921057-- From jch@pps.univ-paris-diderot.fr Mon Jul 8 19:40:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6428311E8105 for ; Mon, 8 Jul 2013 19:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA6QLNUzYAXV for ; Mon, 8 Jul 2013 19:40:49 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 5080E21F9476 for ; Mon, 8 Jul 2013 19:40:46 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r692edtY006003; Tue, 9 Jul 2013 04:40:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5DE884F9EF; Tue, 9 Jul 2013 04:40:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id WMd4l_ag8bw2; Tue, 9 Jul 2013 04:40:38 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 36DFA4FA4A; Tue, 9 Jul 2013 04:40:38 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UwNr3-0001Ig-OZ; Tue, 09 Jul 2013 04:40:37 +0200 Date: Tue, 09 Jul 2013 04:40:37 +0200 Message-ID: <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 09 Jul 2013 04:40:40 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 02:40:55 -0000 > Does the algorithm you propose implement the conceptual forwarding > algorithm in [TROAN], then? I've refrained from criticising your draft, since I appreciate people taking the time to write legible, thought out drafts and thus sharing their work with others. However, I do not think that your "conceptual forwarding algorithm" is a suitable basis for further work on source-specific routing. While I am glad to acknowledge that this draft appears to be technically correct and was published before I even started seriously thinking about source-specific routing, I have no intention to base my work on what I believe is a flawed formalism. On the one hand, your "conceptual forwarding algorithm" is impossible to implement directly on any operating system known to me. On the other hand, it's expressed in operational terms, with uselessly complex data structures (two-level routing tables? eek!), which makes it more difficult to understand than a purely abstract specification. Look, given the right concepts, your "conceptual forwarding algorithm" can be defined in one sentence: (d, s) pairs are ordered according to the lexicographic product of the longer-prefix orderings This is a proper abstract formulation, and one that doesn't uselessly introduce data structures where they don't belong. This is what I've attempted to do (without using order-theoretic language) at the beginning of Section 2.2.2. Not only is your formalism clumsy, but you don't even explain in prose or justify the particular behaviour that you have chosen for source-specific routing. The reason for this particular behaviour was explained to me by Fred Baker by private mail, and a summary of our discussion appears in Section 2.2.2 (with proper credit given to Fred). Once again: I'm glad to cite your work, and I'm glad to recognise that you were there first. Please do not ask me, however, to reformulate my work to fit a formalism that I happen to find deficient. -- Juliusz From ek@google.com Mon Jul 8 20:10:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E211E8105 for ; Mon, 8 Jul 2013 20:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XatdXTwo2Mu for ; Mon, 8 Jul 2013 20:10:22 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1140321F8994 for ; Mon, 8 Jul 2013 20:10:21 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id lx15so4408105lab.35 for ; Mon, 08 Jul 2013 20:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H1jxSkdf30L3yIm/WOcWPJKkmhsaBcIZAZ7zgbXnr3k=; b=GFlKyIzchQ+achK2eDssVV/YQ7NihEx0UOP9N0kR1BObflAs8Evd65z4pCTlSXk2rh iZ4/1YCIlDmiwdMQm0JgJ5xQs5TvwieO3Fpfo0t6jibeKwoup4GPWM3RewkcQqEvIeP3 l+O5GoPiBF1TJ7MFHTAGTGUI1cG3jT2U0tzye3iH4sh/ko4vPZSmxtpvvKadwIhQ4hM7 j9JnfsNFsPyh4R8GWCGsvP5HaCpOm+b2Z9sef2YNkEpescmS5UEIo/F9+9T4YGkgOPg4 D5FVqJ8+hHZ32CGlseVHaaxlp1nhKZzY+SVLI7Y/4sI8/rmNOTc2l9JiHIvx9shVq7NB hEOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=H1jxSkdf30L3yIm/WOcWPJKkmhsaBcIZAZ7zgbXnr3k=; b=aOwA3rI/5nNe4xmTa93MTHYZv1O9Ur5pNqF5hUQ2RC1so1+dnrej5RFTLFPnQI31BQ 85pPS/TQtgvjYoCbIkfErVGA6aVM+IhRvjyFF/1OQET3C9Sou20Fbeuk5ieTy7OpD5T7 /DzXQzRcBaiRLgX3r6wjZUxYgUPOOHWKCo/+HPlnDDNH2FnZ4vIiFEGr82ytGT2E80Ln ONd/WHmC/iBMNAfRYJZPE3aqnhIlOnbonotXU7m3T8EZc0bPdGHl5ONYRe46ivqyu5Xg tD0J2dTCN8GeWTweQXopILaLxg+ozYv6iyQVqFj88DQMSG8PV5WEkFlO/v2oStzoGogw wWqg== X-Received: by 10.152.23.99 with SMTP id l3mr11578249laf.82.1373339419516; Mon, 08 Jul 2013 20:10:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.30.195 with HTTP; Mon, 8 Jul 2013 20:09:59 -0700 (PDT) In-Reply-To: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> From: Erik Kline Date: Tue, 9 Jul 2013 12:09:59 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkK/NrIJ0FCEUlNz0cm6tH1J74IOkCcgejzNg5HuAGpiaDYFDBw3QG8BUE8sRk4C/59b7czmaMRcRlgtANRw3iMXDUaX1jLRV/ycW3JRy/2nLfU/sEQqnIy3Q2KRzRS+DogBXSVLs69yggwyGDthW8UFXlI/t9iiH7JOEH/THNwAfRoZ5Aw/qmAM54ylk6zoACzfOIx Cc: "" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 03:10:23 -0000 On 4 July 2013 04:24, Juliusz Chroboczek wrote: > Dear group, dear chairs, > > Matthieu Boutier and myself have just submitted > > http://www.ietf.org/id/draft-boutier-homenet-source-specific-routing-00.txt Juliusz, A question and a few nits. [ Section 1, paragraph 2 ] I'm afraid I'm having a difficult time parsing the sentence, "First, since a router only controls the next hop, a route can only be selected by the network if it has a selected route as its suffix, which makes some forms of global optimisation difficult or impossible." I think "suffix" is tripping me up somehow. Can you clarify what that means? (possibly I just lack some essential context) [ Section 2.2.2, last paragraph ] "which in turn will send it back to B" --> "back to C", if I'm reading things correctly. [ Section 5, paragraph 2 ] I do not think you mean to say that OSPF/IS-IS are both distance vector and link state "within" areas. I think you mean s/within/(between|among)/ somewhere in there. From lorenzo@google.com Mon Jul 8 20:38:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8C11E8114 for ; Mon, 8 Jul 2013 20:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaZ7JkwQwf5A for ; Mon, 8 Jul 2013 20:38:29 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id CE3CB21F9AA4 for ; Mon, 8 Jul 2013 20:38:21 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so4351676wgh.30 for ; Mon, 08 Jul 2013 20:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eSVBxXaAQ/2fU3nHkiiWnwaj5FIJpUWttdMlF7Kg27Y=; b=nNX9Ua6c79sDPuurL3NZ+75cPpR5LlejYDLOgEuxT8P7JxjWoycvjHvwSeHaNL3Iue M4+FiY5ppZCiPS9WygKNSgbCrNovLeKC22vlbqsvCG0Mx0ysYBP0CXCLfLLOoB0AzlbH mmbDcLHvhsJesgay3h27uA/DnrhawSz7yYwS165U1CKS9+AmD2rQ1vuQofj1pJllL4O+ RD0aocrB+RDrigIBrSZJOt97qwRYE7WLr/GtW80t0vdrt0yRcb++qY9vZqUVOIJxUUE5 Pwz92Zdo/KYE+QlroRx0s6PSWW7q1KSQbtd/gCW1MoTQehk/ZWXEzUd4jBW9BeMzW4Oh AxXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=eSVBxXaAQ/2fU3nHkiiWnwaj5FIJpUWttdMlF7Kg27Y=; b=EUH1CsgGjntj2l2aOhkAyTmhcgpRl9QftIEUbtDUF09UkRLLUjGO1qpZqRENWJmKcF gj5yETq2odirq5xcGboN905TnOT6JwsIxf8/lBRwEhZFLKAZ8y4GcAYCfAhrvdpknoZ6 Fj3ZyIp9twXGiXzk4MSUieo6cT1oz3EZ6sXxzcYDhHrgoQA+8omx2TGkHR/YtjPy5XXl Jvi7BOfK3GCGDzlUKc480cIcaCdkZMSW89NrH+W8lI9CjkEDLlWJNxTe/XtFoUZqAx3u CEpvtMxAq2Meg69apRz7m7OJ3ukU9jxIR2UdGJv7JWN5xwgAemf+HjyvN4yS4GjwUFTv 2cuQ== X-Received: by 10.194.77.99 with SMTP id r3mr13919692wjw.5.1373341100801; Mon, 08 Jul 2013 20:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.125.138 with HTTP; Mon, 8 Jul 2013 20:38:00 -0700 (PDT) In-Reply-To: <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Tue, 9 Jul 2013 12:38:00 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=047d7bfd091878280a04e10be41d X-Gm-Message-State: ALoCoQm6SqbfJs7l12Wf7Yvmw6Bz0+Mj6nJ4aJEmxRH/KlVeIO4laSMsYrN9ezOKUBsayEjwoL8R5YzqnkQ8JyReBHybPCADk7nXM5YAbHq9hEGbs/Rxp2GN7Wx7XxUTFHD+Z6UZWKj0WQjZwYfS+UNp7R2xDCAuv8VTBU23GxyOIqvUR1ZxM0JXSttxs47O4jU1jv1PU6ot Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 03:38:30 -0000 --047d7bfd091878280a04e10be41d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 11:40 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > Does the algorithm you propose implement the conceptual forwarding > > algorithm in [TROAN], then? > > I've refrained from criticising your draft, since I appreciate people > taking the time to write legible, thought out drafts and thus sharing > their work with others. However, I do not think that your "conceptual > forwarding algorithm" is a suitable basis for further work on > source-specific routing. While I am glad to acknowledge that this > draft appears to be technically correct and was published before > I even started seriously thinking about source-specific routing, > I have no intention to base my work on what I believe is a flawed > formalism. > Ok, so we agree that the forwarding algorithm is conceptually the same, then. That's a start. The next step is putting that into one document. This document *must not* be a babel-specific or linux-specific document, because it needs to apply to more than just babel or linux (Which is why [TROAN] says "conceptual forwarding algorithm" instead of "forwarding algorithm", but that's not the point here.) On the one hand, your "conceptual forwarding algorithm" is impossible > to implement directly on any operating system known to me. On the > other hand, it's expressed in operational terms, with uselessly > complex data structures (two-level routing tables? eek!), which makes > it more difficult to understand than a purely abstract specification. > Since Ole wrote that text, I'll let him comment on it (when he comes back from vacation). This is the IETF, so you're certainly free (within reason) to trash him for writing something that you assert cannot be implemented, but please do note that he does work for a company known to implement things like this, and that he has, I believe, written implementations himself, so I would advise you not to write him off without good reason, because doing so might have the effect of lessening your credibility in the eyes of the working group. Look, given the right concepts, your "conceptual forwarding algorithm" > can be defined in one sentence: > > (d, s) pairs are ordered according to the lexicographic product of > the longer-prefix orderings > > This is a proper abstract formulation, and one that doesn't uselessly > introduce data structures where they don't belong. This is what I've > attempted to do (without using order-theoretic language) at the > beginning of Section 2.2.2. > Since we have now agreed that the two solutions are in fact the same, then any formulation that achieves the consensus of the working group is acceptable, as long as there is only one and not two. While I'm sure "lexicographic product of the longer-prefix orderings" is an elegant way of stating this, I doubt that the IETF would publish an RFC that says so, because its intended audience might not understand that language (I know I don't, and I would guess much of the working group does not either, and who knows about implementers). However, leaving things and unspecified - for example, introducing "disambiguation routes" without saying how they are calculated, is also unlikely to gain consensus because it is not implementable. I'm afraid that in order for people to understand what you are proposing (which is sort of required for them to agree with it), you will need to explain to them why "OSes" (by which I assume you mostly mean "Linux", though you don't say what they are) require these disambiguation routes - for example, by stating that the primitives available make a decision first on the source address and only then on the destination address, and thus you need to create extra routing table entries to make things work. You and I know this already, but I suspect there is very little chance of anyone understanding this based on your current text alone. > you don't even explain in prose or justify the particular behaviour that > you have chosen for source-specific routing. The reason for this > particular behaviour was explained to me by Fred Baker by private mail, and > a summary of our discussion appears in Section 2.2.2 (with proper credit > given to Fred). > Perhaps, but on the other hand, "this is the right thing to do because Fred Baker says so in private email" is not appropriate justification either. At least we get to say "we took it to the working group and consensus on the floor was that this is what we want to do". Once again: I'm glad to cite your work, and I'm glad to recognise that > you were there first. Please do not ask me, however, to reformulate > my work to fit a formalism that I happen to find deficient. > Oh no, I'm not asking you to reformulate your work. I will, however, make the suggestion that if you would like the working group to adopt your work, then you should write it in a way that the working group can understand and agree with, and that you avoid duplication of effort. If you do not do so, then it is likely that your work will not find adoption, with possibly little sympathy for that outcome. --047d7bfd091878280a04e10be41d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 9, 2013 at 11:40 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

> Does the= algorithm you propose implement the conceptual forwarding
> algorithm in [TROAN], then?

I've refrained from criticising your draft, since I appreciate pe= ople
taking the time to write legible, thought out drafts and thus sharing
their work with others. =A0However, I do not think that your "conceptu= al
forwarding algorithm" is a suitable basis for further work on
source-specific routing. =A0While I am glad to acknowledge that this
draft appears to be technically correct and was published before
I even started seriously thinking about source-specific routing,
I have no intention to base my work on what I believe is a flawed
formalism.

Ok, so we agree that the for= warding algorithm is conceptually the same, then. That's a start. The n= ext step is putting that into one document. This document *must not* be a b= abel-specific or linux-specific document, because it needs to apply to more= than just babel or linux (Which is why [TROAN] says "conceptual forwa= rding algorithm" instead of "forwarding algorithm", but that= 's not the point here.)

On the one hand, your "conceptual forw= arding algorithm" is impossible
to implement directly on any operating system known to me. =A0On the
other hand, it's expressed in operational terms, with uselessly
complex data structures (two-level routing tables? eek!), which makes
it more difficult to understand than a purely abstract specification.

Since Ole wrote that text, I'll let him = comment on it (when he comes back from vacation). This is the IETF, so you&= #39;re certainly free (within reason) to trash him for writing something th= at you assert cannot be implemented, but please do note that he does work f= or a company known to implement things like this, and that he has, I believ= e, written implementations himself, so I would advise you not to write him = off without good reason, because doing so might have the effect of lessenin= g your credibility in the eyes of the working group.

Look, given the right concepts, your "= conceptual forwarding algorithm"
can be defined in one sentence:

=A0 (d, s) pairs are ordered according to the lexicographic product of
=A0 the longer-prefix orderings

This is a proper abstract formulation, and one that doesn't uselessly introduce data structures where they don't belong. =A0This is what I= 9;ve
attempted to do (without using order-theoretic language) at the
beginning of Section 2.2.2.

Since we ha= ve now agreed that the two solutions are in fact the same, then any formula= tion that achieves the consensus of the working group is acceptable, as lon= g as there is only one and not two.

While I'm sure "lexicographic product of the l= onger-prefix orderings" is an elegant way of stating this, I doubt tha= t the IETF would publish an RFC that says so, because its intended audience= might not understand that language (I know I don't, and I would guess = much of the working group does not either, and who knows about implementers= ).

However, leaving things and unspecified - for example, = introducing "disambiguation routes" without saying how they are c= alculated, is also unlikely to gain consensus because it is not implementab= le.

I'm afraid that in order for people to understand w= hat you are proposing (which is sort of required for them to agree with it)= , you will need to explain to them why "OSes" (by which I assume = you mostly mean "Linux", though you don't say what they are) = require these disambiguation routes - for example, by stating that the prim= itives available make a decision first on the source address and only then = on the destination address, and thus you need to create extra routing table= entries to make things work. You and I know this already, but I suspect th= ere is very little chance of anyone understanding this based on your curren= t text alone.

=A0
you don't even explain in prose=A0or jus= tify the particular behaviour that you have chosen for=A0source-specific ro= uting. =A0The reason for this particular behaviour was=A0explained to me by= Fred Baker by private mail, and a summary of our=A0discussion appears in S= ection 2.2.2 (with proper credit given to=A0Fred).

Perhaps, but on the other hand, "this= is the right thing to do because Fred Baker says so in private email"= is not appropriate justification either. At least we get to say "we t= ook it to the working group and consensus on the floor was that this is wha= t we want to do".

Once again: I'm glad to cite your work,= and I'm glad to recognise that
you were there first. =A0Please do not ask me, however, to reformulate
my work to fit a formalism that I happen to find deficient.

Oh no, I'm not asking you to reformulate your work= . I will, however, make the suggestion that if you would like the working g= roup to adopt your work, then you should write it in a way that the working= group can understand and agree with, and that you avoid duplication of eff= ort. If you do not do so, then it is likely that your work will not find ad= option, with possibly little sympathy for that outcome.

--047d7bfd091878280a04e10be41d-- From simon.perreault@viagenie.ca Tue Jul 9 00:53:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BE421F9F6B for ; Tue, 9 Jul 2013 00:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZPjUYs540DU for ; Tue, 9 Jul 2013 00:53:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4811D21F9F42 for ; Tue, 9 Jul 2013 00:53:11 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c15b:51e7:d305:cc6c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9346F47131 for ; Tue, 9 Jul 2013 03:53:10 -0400 (EDT) Message-ID: <51DBC166.6090302@viagenie.ca> Date: Tue, 09 Jul 2013 09:53:10 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: homenet@ietf.org References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 07:53:11 -0000 Le 2013-07-09 04:40, Juliusz Chroboczek a �crit : > Look, given the right concepts, your "conceptual forwarding algorithm" > can be defined in one sentence: > > (d, s) pairs are ordered according to the lexicographic product of > the longer-prefix orderings I, for one, enjoy mathematical succinctness (in small doses). A merged draft having both that sentence and a longer explanation for implementers would make me happy. I agree that the merged document must not be protocol- or OS-specific, but short implementation notes in appendix are very often useful. Simon From jch@pps.univ-paris-diderot.fr Tue Jul 9 07:50:09 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB61E21F961F for ; Tue, 9 Jul 2013 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srMRkNL1qPEp for ; Tue, 9 Jul 2013 07:50:04 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id A092221F8265 for ; Tue, 9 Jul 2013 07:50:03 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r69EnwC0022606; Tue, 9 Jul 2013 16:49:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 965094FABD; Tue, 9 Jul 2013 16:49:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QNRmEjWm9xcv; Tue, 9 Jul 2013 16:49:57 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EAF534FAB8; Tue, 9 Jul 2013 16:49:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UwZEq-0001DM-EP; Tue, 09 Jul 2013 16:49:56 +0200 Date: Tue, 09 Jul 2013 16:49:56 +0200 Message-ID: <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 09 Jul 2013 16:49:58 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:50:10 -0000 > While I'm sure "lexicographic product of the longer-prefix > orderings" is an elegant way of stating this, I doubt that the IETF > would publish an RFC that says so, because its intended audience > might not understand that language Yes. I've tried to avoid mathematical jargon in our draft, but I was in a rush, and the formulation is somewhat clumsy (beginning of 2.2.2). I think I've done a better job in RFC 6126 paragraph 3.5.1, where I use a similar construction, we'll try to do something similar in the next version of draft-boutier-homenet-source-specific-routing. > This is the IETF, so you're certainly free (within reason) to trash > him for writing something that you assert cannot be implemented, This is not my objection. Either you are describing the visible behaviour of routers, in which case you should use a description sufficiently abstract to be useful to reason about forwarding behaviours. Or you're describing an existing implementation, in which case you should describe the actual algorithm. It appears to me that your draft does neither -- it uses fairly complex data structures while not claiming to describe an actual implementation. > Since we have now agreed that the two solutions are in fact the > same, then any formulation that achieves the consensus of the > working group is acceptable, as long as there is only one and not > two. We certainly don't want homenet routers to be too strongly constrained (e.g. by a concrete algorithm). There are three questions to ask: 1. Do different forwarding behaviours interoperate? The general answer is no -- incompatible forwarding behaviours cause persistent routing loops (Section 2.2.2). However, there are particular cases where everything works out, most importantly mixing source-specific and ordinary next-hop routing (Section 4.1). (Please do not underestimate the importance of this property -- what it says is that you can mix "legacy" routers with source-specific ones.) 2. Can we characterise a class of interoperable forwarding behaviours? The hard property -- which we're currently working on reformulating in a manner that avoids mathematical jargon -- is that a set of routers will interoperate without persistent routing loops as long as their forwarding behaviours have a common linearisation. (This is actually an equivalence -- you can construct topologies that yield a persistent routing loop unless there exists a linearisation. Which is a rather cool property.) The softer, engineering answer is given in Section 4.2. The formulation there is admittedly clumsy, we're working on it. 3. What class of forwarding behaviours do we want to allow in Homenet? Clearly, we want to allow both source-specific, destination first routing, and classical next-hop routing to live in the same routing domain. Do we want to allow TOS-specific and flow-id-specific? Do we want to allow doubly-specific strategies (e.g. both source- and TOS-specific)? (I call these "three-dimensional forwarding behaviours", you'll understand why when you see the pretty pictures I'm preparing for Berlin.) I hope we can define a class of interoperable forwarding behaviours that is both large enough to cover all of the above, and simple enough that it can be expressed in comprehensible RFC-ese. > Perhaps, but on the other hand, "this is the right thing to do because Fred > Baker says so in private email" is not appropriate justification either. This is a somewhat disingenious way of describing Section 2.2.2. > Oh no, I'm not asking you to reformulate your work. I will, however, make the > suggestion that if you would like the working group to adopt your work, I think there's a misunderstanding here. draft-boutier-homenet-source-specific-routing-00 is a description of a working implementation of source-specific routing, that has the "obviously right" behaviour, and that has been implemented over an off-the-shelf operating system. This draft was published in order to request a slot at the Berlin meeting where I want to present this work, describe a few of the remaining open problems, prompt further discussion, and hopefully convince people to attempt their own implementation. I am very much surprised at spending so much time justifying the existence of a draft outlining a working implementation of a technology that is badly needed for the Homenet effort. -- Juliusz From jch@pps.univ-paris-diderot.fr Tue Jul 9 07:53:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE4721F9B85 for ; Tue, 9 Jul 2013 07:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We7IEzZLz1cl for ; Tue, 9 Jul 2013 07:53:40 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACD221F9FCB for ; Tue, 9 Jul 2013 07:53:36 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r69ErZbp023770; Tue, 9 Jul 2013 16:53:35 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 325D74FABD; Tue, 9 Jul 2013 16:53:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id vCyTacY-YuTf; Tue, 9 Jul 2013 16:53:33 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C161B4FAB8; Tue, 9 Jul 2013 16:53:33 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UwZIL-0001DR-F3; Tue, 09 Jul 2013 16:53:33 +0200 Date: Tue, 09 Jul 2013 16:53:33 +0200 Message-ID: <87a9lvwzrm.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Simon Perreault In-Reply-To: <51DBC166.6090302@viagenie.ca> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <51DBC166.6090302@viagenie.ca> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 09 Jul 2013 16:53:35 +0200 (CEST) Cc: homenet@ietf.org Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:53:47 -0000 > > (d, s) pairs are ordered according to the lexicographic product of > > the longer-prefix orderings > > A merged draft having both that sentence and a longer explanation > for implementers would make me happy. Matthieu now has a formulation that is both declarative (it describes where a packet must go without mandating a particular algorithm) and expressed in fairly elementary terms (it uses the notion of more or less specific patterns). It's a little longer than the compact block of jargon above, but will hopefully remain abstract enough to allow reasoning. I'll run it through this list when we've frozen the terminology. -- Juliusz From jch@pps.univ-paris-diderot.fr Tue Jul 9 08:03:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B12711E8135 for ; Tue, 9 Jul 2013 08:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hW8E2ezwV1V for ; Tue, 9 Jul 2013 08:03:41 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 654E921F9EA3 for ; Tue, 9 Jul 2013 08:03:41 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r69F3eOK027219; Tue, 9 Jul 2013 17:03:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4C7E24FAC5; Tue, 9 Jul 2013 17:03:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2YiRWZhvgf7m; Tue, 9 Jul 2013 17:03:39 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 07CA24FABE; Tue, 9 Jul 2013 17:03:38 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UwZS6-0001Da-Hw; Tue, 09 Jul 2013 17:03:38 +0200 Date: Tue, 09 Jul 2013 17:03:38 +0200 Message-ID: <878v1fwzat.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Erik Kline In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 09 Jul 2013 17:03:40 +0200 (CEST) Cc: "" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:03:47 -0000 > I'm afraid I'm having a difficult time parsing the sentence, "First, > since a router only controls the next hop, a route can only be > selected by the network if it has a selected route as its suffix, > which makes some forms of global optimisation difficult or > impossible." Consider the following topology: C / \ / \ A -- B S \ / \ / D Suppose that B routes packets to S through C; then there is no way that A can possibly route its own packets to S through D. What happens here is that the route ABDS cannot be selected because nobody has selected its suffix BDS. This limitation doesn't occur with e.g. source routing or circuit switching. > [ Section 2.2.2, last paragraph ] > > "which in turn will send it back to B" --> "back to C", if I'm reading > things correctly. > > [ Section 5, paragraph 2 ] > > I do not think you mean to say that OSPF/IS-IS are both distance > vector and link state "within" areas. I think you mean > s/within/(between|among)/ somewhere in there. Noted, thanks. -- Juliusz From hrogge@googlemail.com Tue Jul 9 08:11:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1721F9EC5 for ; Tue, 9 Jul 2013 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUeiOsVYRtHa for ; Tue, 9 Jul 2013 08:11:50 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE521F9A17 for ; Tue, 9 Jul 2013 08:11:49 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so3025846qcx.12 for ; Tue, 09 Jul 2013 08:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fwNb1l2XsX8GHUgJ8kSWxfLUfatiq9+Qe7n/M0JiTps=; b=WJRTIA7NVeFzdXVWBInQFSVoCGZ/ZEbrQHpHTDQonfLn754Oc/3vIKYSbHcFkZGCIs i00mQamOAXvhR8snSpnBjQcbieeQV6yyGUXKJYcfQJjKWY5OpqSk8JOOppuAS9iXO8GA s4aTzrQx7pIin6VduzUsBcUH08fIjpE6vguiDJEgSJSOgQOLN3Thneb7F0iZZ99IoswJ OiKzrbVqTdLvQXx2Rxem9xENTpPuni6MFyfOS4lSPjN/lYmrQjqYW9hjEPOaeb03PQaX FDIkFQcXzXdhpqurfYFy7ihPnmRDG4h2WEaMXzeFXDIOa76f8v5hY1n16QRZGbJahby9 3YfA== X-Received: by 10.224.162.210 with SMTP id w18mr4563998qax.56.1373382709519; Tue, 09 Jul 2013 08:11:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.73 with HTTP; Tue, 9 Jul 2013 08:11:29 -0700 (PDT) In-Reply-To: <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Tue, 9 Jul 2013 17:11:29 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:11:50 -0000 On Tue, Jul 9, 2013 at 4:49 PM, Juliusz Chroboczek wrote: > 1. Do different forwarding behaviours interoperate? > > The general answer is no -- incompatible forwarding behaviours cause > persistent routing loops (Section 2.2.2). However, there are > particular cases where everything works out, most importantly mixing > source-specific and ordinary next-hop routing (Section 4.1). (Please > do not underestimate the importance of this property -- what it says > is that you can mix "legacy" routers with source-specific ones.) Having multiple source-specific default routes (0.0.0.0/0 or ::/0) are a good recipe for routing loops if some routers don't support source-specific routing. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From jch@pps.univ-paris-diderot.fr Tue Jul 9 08:14:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05321F9EDA for ; Tue, 9 Jul 2013 08:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqtTgy2t3FqJ for ; Tue, 9 Jul 2013 08:14:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6148321F9EC5 for ; Tue, 9 Jul 2013 08:14:16 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r69FEE7g032005; Tue, 9 Jul 2013 17:14:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 479BB4FACB; Tue, 9 Jul 2013 17:14:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id LhIBoMHrIMD2; Tue, 9 Jul 2013 17:14:13 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EFE404FAD1; Tue, 9 Jul 2013 17:14:12 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UwZcK-0001Dy-Jg; Tue, 09 Jul 2013 17:14:12 +0200 Date: Tue, 09 Jul 2013 17:14:12 +0200 Message-ID: <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 09 Jul 2013 17:14:14 +0200 (CEST) Cc: "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:14:22 -0000 > > The general answer is no -- incompatible forwarding behaviours cause > > persistent routing loops (Section 2.2.2). However, there are > > particular cases where everything works out, most importantly mixing > > source-specific and ordinary next-hop routing (Section 4.1). (Please > > do not underestimate the importance of this property -- what it says > > is that you can mix "legacy" routers with source-specific ones.) > Having multiple source-specific default routes (0.0.0.0/0 or ::/0) are > a good recipe for routing loops if some routers don't support > source-specific routing. See Section 4.1, notably the second paragraph. (And yes -- you get it wrong, you die.) -- Juliusz From lorenzo@google.com Tue Jul 9 08:21:43 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD6C21F9D5C for ; Tue, 9 Jul 2013 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X35S0fPZORKe for ; Tue, 9 Jul 2013 08:21:42 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 26A6021F9968 for ; Tue, 9 Jul 2013 08:21:41 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so4672949veb.22 for ; Tue, 09 Jul 2013 08:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AciJPDhRv/YHN9RBLC3FGZyjJhTsglxmiuBuNLd6KUs=; b=a26wMUgr9YMpi90vROIs4x3jnIT7jLgMcc/Tc3Nv79vglDr/GlL+cfE7+0mzPmQw2o tnCpMyr9Wwlt50+veNKxi0Kkqwbd61PlKAlrDfyfKb4HDQn+ntUa1MFhyPVb+9Oi9ELY KxenGREo3RNf//XiKGn/zT8oIdq0qQgiVzz4/kY1JLZYMkOX3zlFLFcvvabPXtsHKwWo RWaoRX+sz7qAKq8fGm1F95jaRYTZMNBbz7h9DSp9SnjZ7RBWzlBH2O1h5QXXF6ssNKbE dyd6BuaHZi26KpXwbdJDXjQLbD0u5qW2QwIXy27+OqAKpdjaQDUzI7FdNAD5dE1leXEV QSGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AciJPDhRv/YHN9RBLC3FGZyjJhTsglxmiuBuNLd6KUs=; b=Wv5WMLVdsAH0cM6IUZWUQ4pBAC/w3sxm7/5pSFhdTynUKvtM0ZiufWWgQ0pXIvdCUn 9s8Sbi+cm6yp2KoKeTCO0g59s4awNh3Sr66I2GJoWF47Vo60q9E8TgmVrO+4dhOXjU4b uwQm3mkArRmjUOprfMb1OmFmYjqn6KraS5QzKyyt5P4tNm+kdlHoflAzYvtjXdHbSAvP BRg8MMUPx/gGyzUlCOR20vaG/ZaC2V04TFWUmfZCpPBFkh7aEJhYoSL+A4UC035KCfKW /iov8tud56lt2lWdmlpk3uPAik7wVgcDv6xypZZk0Ob/KktlnEVODJ62ejsKczDvg7E6 VJLg== X-Received: by 10.220.68.144 with SMTP id v16mr16737271vci.76.1373383298917; Tue, 09 Jul 2013 08:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.217.141 with HTTP; Tue, 9 Jul 2013 08:21:18 -0700 (PDT) In-Reply-To: <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Wed, 10 Jul 2013 00:21:18 +0900 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=047d7b3a9386ac4c2304e115b744 X-Gm-Message-State: ALoCoQmtEyXz35yqMy8XoYuEf94p79RryPvlVwphovUsdoLwNoOqYYom/yu9yRDeqyTQlUMPymecCAH2FUxH1BRtA4CjnI2aXpxvH5P4IB2TBOLaeM0+IzHMcxPKILFMb8DQk8/yNb4maFBU7SMtWGapqFQ4ilxIJZqov+EkXuq15c/sFKoOd+kJVqxbPSZINX8G5cBaxULs Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:21:43 -0000 --047d7b3a9386ac4c2304e115b744 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 11:49 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > This is the IETF, so you're certainly free (within reason) to trash > > him for writing something that you assert cannot be implemented, > > This is not my objection. > > Either you are describing the visible behaviour of routers, in which > case you should use a description sufficiently abstract to be useful > to reason about forwarding behaviours. Or you're describing an > existing implementation, in which case you should describe the actual > algorithm. It appears to me that your draft does neither -- it uses > fairly complex data structures while not claiming to describe an > actual implementation. > The intent was to document something that did not unnecessarily constrain implementations but was detailed enough to be clear unambiguous. I agree it's not universe-harmonizingly elegant, but on the other hand, the documents have to be understood by implementers who aren't always experts in graph theory. I do think there's a decent balance there, but of course it could always be improved. We welcome suggestions. > 1. Do different forwarding behaviours interoperate? > > The general answer is no -- incompatible forwarding behaviours cause > persistent routing loops (Section 2.2.2). However, there are > particular cases where everything works out, most importantly mixing > source-specific and ordinary next-hop routing (Section 4.1). (Please > do not underestimate the importance of this property -- what it says > is that you can mix "legacy" routers with source-specific ones.) > 2. Can we characterise a class of interoperable forwarding behaviours? > > The hard property -- which we're currently working on reformulating in > a manner that avoids mathematical jargon -- is that a set of routers > will interoperate without persistent routing loops as long as their > forwarding behaviours have a common linearisation. (This is actually > an equivalence -- you can construct topologies that yield a persistent > routing loop unless there exists a linearisation. Which is a rather > cool property.) > > The softer, engineering answer is given in Section 4.2. The > formulation there is admittedly clumsy, we're working on it. > Personally, I think you're being a bit too optimistic on what is possible in the real world. I do think it's good to document the circumstances under which things are likely to work, but I fear that we won't actually be able to take advantage of them because we won't be able to know if we're in one of the working cases. So if we end up in a broken topology, most of the time routing is dead in the water anyway. > 3. What class of forwarding behaviours do we want to allow in Homenet? > > Clearly, we want to allow both source-specific, destination first > routing, and classical next-hop routing to live in the same routing > domain. If we can achieve this in a sufficiently large set of topologies. Otherwise, it's possible that it's better to explicitly not support this mode rather than attempt to support it only if the topology works. > Do we want to allow TOS-specific and flow-id-specific? Personally, I don't think so. I think source+destination routing is about as much as we can reasonably pull off in the real world. Others may disagree (and I know many people believe that even just src+dst is impossible to deploy in the real world). > > Perhaps, but on the other hand, "this is the right thing to do because > Fred > > Baker says so in private email" is not appropriate justification either. > > This is a somewhat disingenious way of describing Section 2.2.2. > I'm just repeating what you wrote. > I think there's a misunderstanding here. > draft-boutier-homenet-source-specific-routing-00 is a description of > a working implementation of source-specific routing, that has the > "obviously right" behaviour, and that has been implemented over an > off-the-shelf operating system. This draft was published in order to > request a slot at the Berlin meeting where I want to present this > work, describe a few of the remaining open problems, prompt further > discussion, and hopefully convince people to attempt their own > implementation. > Then perhaps the problem is that instead of an implementation report, it reads a bit like a scientific paper, with its own introduction and characterization of the problem (which overlap with the existing work in this working group), and partly like a specification (but an underspecified one - for example, it doesn't say what the disambiguation looks like). And the implementation report itself is unofrtunately lacking crucial details like what the limitations of current OSes are and what "disambiguation routes" need to look like, how often they appear in practice, etc.) I have no problem with the implementation report - in fact, I look forward to more details when you write them up. But I do think that the part of your draft that is the implementation report should its own document, separate from anything else, and I do think that the characterization part should be in a separate document, either [TROAN], to which the authors do welcome constructive criticism, or, if the working group thinks otherwise, something else. But putting everything in one document is not a good idea. It's true that this is not how most documents, including as scientific papers, are written, but on the other hand, IETF RFCs are a more collaborative environment than your average scientific journal. --047d7b3a9386ac4c2304e115b744 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 9, 2013 at 11:49 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

> This is the IETF, so = you're certainly free (within reason) to trash

> him for writing something that you assert cannot be implemented,

This is not my objection.

Either you are describing the visible behaviour of routers, in which
case you should use a description sufficiently abstract to be useful
to reason about forwarding behaviours. =A0Or you're describing an
existing implementation, in which case you should describe the actual
algorithm. =A0It appears to me that your draft does neither -- it uses
fairly complex data structures while not claiming to describe an
actual implementation.

The intent was t= o document something that did not unnecessarily constrain implementations b= ut was detailed enough to be clear unambiguous. I agree it's not univer= se-harmonizingly elegant, but on the other hand, the documents have to be u= nderstood by implementers who aren't always experts in graph theory.

I do think there's a decent balance there, but of c= ourse it could always be improved. We welcome suggestions.

=A0

1. Do different forwarding behavio= urs interoperate?

The general answer is no -- incompatible forwarding behaviours cause
persistent routing loops (Section 2.2.2). =A0However, there are
particular cases where everything works out, most importantly mixing
source-specific and ordinary next-hop routing (Section 4.1). =A0(Please
do not underestimate the importance of this property -- what it says
is that you can mix "legacy" routers with source-specific ones.)= =A0

2. Can we characterise a class of interoperable forwarding behaviours?

The hard property -- which we're currently working on reformulating in<= br> a manner that avoids mathematical jargon -- is that a set of routers
will interoperate without persistent routing loops as long as their
forwarding behaviours have a common linearisation. =A0(This is actually
an equivalence -- you can construct topologies that yield a persistent
routing loop unless there exists a linearisation. =A0Which is a rather
cool property.)

The softer, engineering answer is given in Section 4.2. =A0The
formulation there is admittedly clumsy, we're working on it.

Personally, I think you're being a bit too op= timistic on what is possible in the real world. I do think it's good to= document the circumstances under which things are likely to work, but I fe= ar that we won't actually be able to take advantage of them because we = won't be able to know if we're in one of the working cases. So if w= e end up in a broken topology, most of the time routing is dead in the wate= r anyway.

=A0
3. What class of forwarding behaviours do we= want to allow in Homenet?

Clearly, we want to allow both source-specific, destination first
routing, and classical next-hop routing to live in the same routing
domain.

If we can achieve this in a suffici= ently large set of topologies. Otherwise, it's possible that it's b= etter to explicitly not support this mode rather than attempt to support it= only if the topology works.

=A0
Do we want to allow TOS-specific and flow-id= -specific?

Personally, I don't think so. I think source+destin= ation routing is about as much as we can reasonably pull off in the real wo= rld. Others may disagree (and I know many people believe that even just src= +dst is impossible to deploy in the real world).

=A0
> Perhaps, but on the other hand, &q= uot;this is the right thing to do because Fred
> Baker says so in private email" is not appropriate justification = either.

This is a somewhat disingenious way of describing Section 2.2.2.
<= /blockquote>

I'm just repeating what you wrote.
=A0

I think there's a misunderstan= ding here.
draft-boutier-homenet-source-specific-routing-00 is a description of
a working implementation of source-specific routing, that has the
"obviously right" behaviour, and that has been implemented over a= n
off-the-shelf operating system. =A0This draft was published in order to
request a slot at the Berlin meeting where I want to present this
work, describe a few of the remaining open problems, prompt further
discussion, and hopefully convince people to attempt their own
implementation.

Then perhaps the proble= m is that instead of an implementation report, it reads a bit like a scient= ific paper, with its own introduction and characterization of the problem (= which overlap with the existing work in this working group), and partly lik= e a specification (but an underspecified one - for example, it doesn't = say what the disambiguation looks like). And the implementation report itse= lf is unofrtunately lacking crucial details like what the limitations of cu= rrent OSes are and what "disambiguation routes" need to look like= , how often they appear in practice, etc.)

I have no problem with the implementation report - in f= act, I look forward to more details when you write them up. But I do think = that the part of your draft that is the implementation report should its ow= n document, separate from anything else, and I do think that the characteri= zation part should be in a separate document, either [TROAN], to which the = authors do welcome constructive criticism, or, if the working group thinks = otherwise, something else.

But putting everything in one document is not a good id= ea. It's true that this is not how most documents, including as scienti= fic papers, are written, but on the other hand, IETF RFCs are a more collab= orative environment than your average scientific journal.

--047d7b3a9386ac4c2304e115b744-- From mike@mtcc.com Tue Jul 9 08:55:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E221F9C08 for ; Tue, 9 Jul 2013 08:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWl5ySWmnoOY for ; Tue, 9 Jul 2013 08:55:35 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9DF21F9974 for ; Tue, 9 Jul 2013 08:55:18 -0700 (PDT) Received: from michael-thomass-macbook.local (aric.mtcc.com [50.0.18.225] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r69FtGpH016799 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 9 Jul 2013 08:55:17 -0700 Message-ID: <51DC3261.1090404@mtcc.com> Date: Tue, 09 Jul 2013 08:55:13 -0700 From: mike User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: homenet@ietf.org References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDE9962@wds-exc1.okna.nominet.org.uk> <22885.1372946169@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1368; t=1373385317; x=1374249317; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20mike=20 |Subject:=20Re=3A=20[homenet]=20IETF=2087=20-=20call=20for= 20agenda=20items |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=kj2gsv1bhAGkBf9II+di0+Bor5QkggnADZk4drkr1NQ=; b=V1qUJ5vuqrVFNTkGqDtS//szKBwvkMvs9P00zuTGnCpmIivZzcFnmCKL4Z TeEfbXrywMJD/SJIp8r5VLtk+gKh1HeH+A8l2dZQSegTfOHbF6MyUa1ZSbqx bOziT+QBPHdI1PeGSjV8sNMGoELNfKhia5BhT1/a/yN/fbczGmMd4=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] IETF 87 - call for agenda items 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, 09 Jul 2013 15:55:40 -0000 On 7/5/13 12:59 AM, Lorenzo Colitti wrote: > > Far be it from me to object to people doing more work, but... isn't it premature to attempt to define a generic architecture to configure anything > that's possible to congfigure? That seems like it's a lot to bite off, and would take a while. Can we get away with a layered approach, where we > first build a network with working routing, and then we figure out how to run services on top of it? > Given the breadth of protocols and services, many lacking any network based configuration at all, and combine that permanent infrastructure mated with the ad hoc roaming on and off my homenet, I think that the idea there there is going to be a One True Configuration protocol is... well, pretty dubious. What I've been wondering is whether we need a meta layer that stimulates other configuration layers to initiate configuration/etc in their own native tongue. We have many protocols (eg IXFR, DHCP) but the coordination is either lacking in a littleconf situation (IXFR), or klunky and trying to go beyond its pay grade in a complicated topology (DHCP). The first step of getting things autoconfigured is to decide who arbitrates conflicts and how end devices react to the various authorities (eg, when I roam onto my neighbor's net). This strikes me as a very hard problem in general. Mike From dave.taht@gmail.com Tue Jul 9 10:30:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE73C21F9344 for ; Tue, 9 Jul 2013 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaHXvh9eKE7Y for ; Tue, 9 Jul 2013 10:30:43 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 439C321F9E38 for ; Tue, 9 Jul 2013 10:30:43 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so13051951iec.22 for ; Tue, 09 Jul 2013 10:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=89+AC7L/YACNLUw/9Ubq7oGpx0HO8K4KpeHuPwp+d+o=; b=TCGPl85SQN9X9QnKjfCEPNgmVxPluwYAHuDjcXcNkRkK291Ac+/y8vMDGkoZYavqZY d9VDpOXzQ1v3NGIkYX0XL3eyYhtx9Ar901imVS+KJZG8DPeFmfWYxlSlfV7vqjSVExvE mj1SReehSMaYKYJFwSwKCtDwwXA3EOnqhqMNeu11cdA4UNFhlnX3S3g/A9/8Z3o14k7B csNnT1kkJVovEPOgoiZlDNs4N69q4lz/HJsXkTv01A5nmNbkgW8bZ64tZvqIMiRNLTE/ OeKxUoxBS53kd+NBOlzbzskrWc06SxKPnzfZT41JadwBwY/bmoa+zxByVNRy7ZEoNFXI tVtw== MIME-Version: 1.0 X-Received: by 10.50.88.7 with SMTP id bc7mr34353330igb.37.1373391034688; Tue, 09 Jul 2013 10:30:34 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Tue, 9 Jul 2013 10:30:34 -0700 (PDT) In-Reply-To: <51DC3261.1090404@mtcc.com> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDE9962@wds-exc1.okna.nominet.org.uk> <22885.1372946169@sandelman.ca> <51DC3261.1090404@mtcc.com> Date: Tue, 9 Jul 2013 10:30:34 -0700 Message-ID: From: Dave Taht To: mike Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] IETF 87 - call for agenda items 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, 09 Jul 2013 17:30:46 -0000 On Tue, Jul 9, 2013 at 8:55 AM, mike wrote: > On 7/5/13 12:59 AM, Lorenzo Colitti wrote: >> >> >> Far be it from me to object to people doing more work, but... isn't it >> premature to attempt to define a generic architecture to configure anyth= ing >> that's possible to congfigure? That seems like it's a lot to bite off, a= nd >> would take a while. Can we get away with a layered approach, where we fi= rst >> build a network with working routing, and then we figure out how to run >> services on top of it? >> > > Given the breadth of protocols and services, many lacking any network bas= ed > configuration > at all, and combine that permanent infrastructure mated with the ad hoc > roaming on and > off my homenet, I think that the idea there there is going to be a One Tr= ue > Configuration > protocol is... well, pretty dubious. > > What I've been wondering is whether we need a meta layer that stimulates > other configuration > layers to initiate configuration/etc in their own native tongue. We have > many protocols > (eg IXFR, DHCP) but the coordination is either lacking in a littleconf > situation (IXFR), or klunky > and trying to go beyond its pay grade in a complicated topology (DHCP). = The > first step of > getting things autoconfigured is to decide who arbitrates conflicts and h= ow > end devices > react to the various authorities (eg, when I roam onto my neighbor's net)= . > > This strikes me as a very hard problem in general. I've been sort of waiting for the list to discover commonly deployed protocols like upnp and ssdp. Multicasting a little bit... http://en.wikipedia.org/wiki/Universal_Plug_and_Play http://tools.ietf.org/html/draft-bnss-v6ops-upnp-01 > > Mike > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From hrogge@googlemail.com Tue Jul 9 10:35:04 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7901D21F9F5E for ; Tue, 9 Jul 2013 10:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80-207seGNaQ for ; Tue, 9 Jul 2013 10:35:03 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 91CDF21F9F33 for ; Tue, 9 Jul 2013 10:35:03 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so3114198qcq.19 for ; Tue, 09 Jul 2013 10:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nwV5GIiZ8zD8OCllM4PZmQLCtzWokYPp9ZmNm46G4/k=; b=CVSca2F2l3y0TejicAz0DCJeqcG+m3Lt8pr+dR3NERRujtmBEhFeGwfM2rgUt0dvVO t9s3doCFYjQjfd3sBOhB87G7cyN3fHm8w/W6Es6b5n7H4ko3x1t/4ZzDu4uI+ZBcvmOj poddJC67pMV4jFiHXoloKNeN63ra3ay5A/Jybyx5jnTZ66armWMuHdKdlkQy7qYetIu+ PlHQWisF3hjR6ysfP9MvuJlJbuZK8Dhu4+d5sG0idQcAVv4gtYj8Cq+wfOvk3WsaOJEL b+JwAleGhUsuKWqOSnMzL7guOaKHobkllVRion21zz04sGhC6KAqfbyVIcVaddinS+pm AxIQ== X-Received: by 10.49.62.33 with SMTP id v1mr21561723qer.53.1373391303090; Tue, 09 Jul 2013 10:35:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.73 with HTTP; Tue, 9 Jul 2013 10:34:43 -0700 (PDT) In-Reply-To: <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Tue, 9 Jul 2013 19:34:43 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:35:04 -0000 I think the last paragraph of Section 4.1 is not necessarily true for all protocols. You might end up with "non-source route" aware routers that forward the source-route specific information. Still, as long as the different destinations for the source-routed default-routes are in a source-route aware subnet it should work. The "non source-routed" default route will push the traffic into the "source-route aware" subnet... and from there to the destination. It should work both with distance-vector and linkstate routing as long as there is also a "non-sourcerouted" default route. Henning Rogge On Tue, Jul 9, 2013 at 5:14 PM, Juliusz Chroboczek wrote: >> > The general answer is no -- incompatible forwarding behaviours cause >> > persistent routing loops (Section 2.2.2). However, there are >> > particular cases where everything works out, most importantly mixing >> > source-specific and ordinary next-hop routing (Section 4.1). (Please >> > do not underestimate the importance of this property -- what it says >> > is that you can mix "legacy" routers with source-specific ones.) > >> Having multiple source-specific default routes (0.0.0.0/0 or ::/0) are >> a good recipe for routing loops if some routers don't support >> source-specific routing. > > See Section 4.1, notably the second paragraph. > > (And yes -- you get it wrong, you die.) > > -- Juliusz -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From mike@mtcc.com Tue Jul 9 11:16:32 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C6621F9D01 for ; Tue, 9 Jul 2013 11:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 000nI7HUWDTb for ; Tue, 9 Jul 2013 11:16:28 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1763721F9C46 for ; Tue, 9 Jul 2013 11:16:28 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r69IGNNb031622 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 9 Jul 2013 11:16:24 -0700 Message-ID: <51DC5377.3070000@mtcc.com> Date: Tue, 09 Jul 2013 11:16:23 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Dave Taht References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DDE9962@wds-exc1.okna.nominet.org.uk> <22885.1372946169@sandelman.ca> <51DC3261.1090404@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2803; t=1373393785; x=1374257785; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20IETF=2087=20-=20call=20for= 20agenda=20items |Sender:=20 |To:=20Dave=20Taht=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=bVF/lWpUALNYmU+tlziNXimUsKFApwqOnlQyGPpqG08=; b=eH+/FiuHbPqaZ7UMpK/bYHNK/cBfZrrzy212Mtcn19RRg31K4tWj205eYj NPJpSRGz7viJEAa7bTKvFXso8HWN9erT3q415wLt0wGj51kbw9dhucjPlaCl jXBRcAQEiD67pS+V+pGRNeiDkbeLf6wxxGfZAn8RpWTYGqHFd7a0Y=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] IETF 87 - call for agenda items 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, 09 Jul 2013 18:16:32 -0000 On 07/09/2013 10:30 AM, Dave Taht wrote: > On Tue, Jul 9, 2013 at 8:55 AM, mike wrote: >> On 7/5/13 12:59 AM, Lorenzo Colitti wrote: >>> >>> Far be it from me to object to people doing more work, but... isn't it >>> premature to attempt to define a generic architecture to configure anything >>> that's possible to congfigure? That seems like it's a lot to bite off, and >>> would take a while. Can we get away with a layered approach, where we first >>> build a network with working routing, and then we figure out how to run >>> services on top of it? >>> >> Given the breadth of protocols and services, many lacking any network based >> configuration >> at all, and combine that permanent infrastructure mated with the ad hoc >> roaming on and >> off my homenet, I think that the idea there there is going to be a One True >> Configuration >> protocol is... well, pretty dubious. >> >> What I've been wondering is whether we need a meta layer that stimulates >> other configuration >> layers to initiate configuration/etc in their own native tongue. We have >> many protocols >> (eg IXFR, DHCP) but the coordination is either lacking in a littleconf >> situation (IXFR), or klunky >> and trying to go beyond its pay grade in a complicated topology (DHCP). The >> first step of >> getting things autoconfigured is to decide who arbitrates conflicts and how >> end devices >> react to the various authorities (eg, when I roam onto my neighbor's net). >> >> This strikes me as a very hard problem in general. > I've been sort of waiting for the list to discover commonly deployed > protocols like upnp and ssdp. Multicasting a little bit... > > http://en.wikipedia.org/wiki/Universal_Plug_and_Play > > http://tools.ietf.org/html/draft-bnss-v6ops-upnp-01 > I think that one of the things that has profoundly changed since all of these have been deployed is the challenges of mobility in the sense of roaming. It's dirt common these days to get on your friend's wireless with phones, but what does that really mean from a configuration standpoint for the homenet itself, and for the roamer? They only trust each other to a degree, and probably mostly on the bits level. But my neighbor's may really want to give me access to their display and speakers so I can show them a cool video I just shot, or what have you. It's yet another problem with pure zeroconf solutions: being able to discover something isn't enough: there is an implicit authz/enrollment problem to say whether I *can* use those services. It's just not enough to equate network admission with authorization these days. I don't see how you get around that without littleconf. Mike, in fact just giving out your guestnet password is "littleconf" in and of itself. From jch@pps.univ-paris-diderot.fr Wed Jul 10 06:00:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5E11E811F for ; Wed, 10 Jul 2013 06:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQkn+Lgc4OKt for ; Wed, 10 Jul 2013 06:00:08 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8027D11E81A1 for ; Wed, 10 Jul 2013 06:00:08 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r6AD006t012936; Wed, 10 Jul 2013 15:00:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 484444FB9B; Wed, 10 Jul 2013 15:00:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 7AnoKSzNOGBz; Wed, 10 Jul 2013 14:59:59 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E1A884FB9A; Wed, 10 Jul 2013 14:59:58 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1Uwtzy-0001RS-86; Wed, 10 Jul 2013 14:59:58 +0200 Date: Wed, 10 Jul 2013 14:59:58 +0200 Message-ID: <87ppuq7epd.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 10 Jul 2013 15:00:02 +0200 (CEST) Cc: "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 13:00:14 -0000 > I think the last paragraph of Section 4.1 is not necessarily true for > all protocols. You might end up with "non-source route" aware routers > that forward the source-route specific information. We're assuming here that "legacy" routers silently discard source-specific routes. This is the reason for the encoding we use for source-specific routes. > Still, as long as the different destinations for the source-routed > default-routes are in a source-route aware subnet it should work. Could you please clarify. Have you identified another case where everything works out? -- Juliusz From jch@pps.univ-paris-diderot.fr Wed Jul 10 06:14:23 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A63521E8054 for ; Wed, 10 Jul 2013 06:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2poOKrVf4b6E for ; Wed, 10 Jul 2013 06:14:17 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39021E804E for ; Wed, 10 Jul 2013 06:14:17 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r6ADEFvp022289; Wed, 10 Jul 2013 15:14:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9531B4FB9F; Wed, 10 Jul 2013 15:14:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 0cwcQ0oVFS3i; Wed, 10 Jul 2013 15:14:14 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2A46F4FB9C; Wed, 10 Jul 2013 15:14:14 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UwuDl-0001Tw-Qa; Wed, 10 Jul 2013 15:14:13 +0200 Date: Wed, 10 Jul 2013 15:14:13 +0200 Message-ID: <87obaa7e1m.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 10 Jul 2013 15:14:15 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: ,

--047d7b342fb28366e304e1374df0-- From hrogge@googlemail.com Thu Jul 11 03:45:07 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B8021F9F9E for ; Thu, 11 Jul 2013 03:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9WOo9bghdfz for ; Thu, 11 Jul 2013 03:45:06 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6B521F9FF3 for ; Thu, 11 Jul 2013 03:45:06 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so4263572qea.7 for ; Thu, 11 Jul 2013 03:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W6xkgdHosjIwkE5l2zw5Ud82xJd31KZkXZwIxaxnnj8=; b=ftT0th0AzpVbE942/6A+qdKBHeDeVWxhADPr8sn5OEpaD0AafPXTW9IJmuJMZ99RZP C02JS6dk4wmFLWQsbWMw/w4haDzcfGjdBN+Dea0NdJ9scPpvlX8gepmVZFuJ8YWkOwAT L6zRM3tkCeGod8w9K17jQ1MSeK2DjFBbUXutgVjm4qNSicOR44g6KhRoCkxWBVNG09zq I+no6hNeDjnxTaHcpmSiHXjwT8NcmwyhXyAizLBnMY8xxQY1o9q9wu94dixePX5HUvBY 7ds8rR5gXNED4/ds9h2Hi9ASUwXoX9UQyq2MhX9NY0N4Oph8f49P6HRM1Q9iw0pseAFt SBlA== X-Received: by 10.49.62.33 with SMTP id v1mr29243636qer.53.1373539504778; Thu, 11 Jul 2013 03:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.73 with HTTP; Thu, 11 Jul 2013 03:44:44 -0700 (PDT) In-Reply-To: <87d2qq75g6.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> <87ppuq7epd.wl%jch@pps.univ-paris-diderot.fr> <87hag2773v.wl%jch@pps.univ-paris-diderot.fr> <87d2qq75g6.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Thu, 11 Jul 2013 12:44:44 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:45:07 -0000 On Wed, Jul 10, 2013 at 6:19 PM, Juliusz Chroboczek wrote: > Consider this: > > -- A -- B -- > > Suppose that A announces (::/0, alpha), and B announces (::/0, beta) > (two source-specific default routes). Suppose further that, as you > suggest, both A and B announce default routes (::/0, ::/0). > > What happens when A receives a packet that's not sourced in either > alpha or beta? It will route it towards B (which, you will recall, is > announcing a non-specific default route). Now B will send the packet > back to A, and you're in trouble. I would assume that a packet that is not source-ip tagged for a specific gateway would just go out of any gateway. In this case gateway A. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From hrogge@googlemail.com Thu Jul 11 03:49:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCAA11E80D5 for ; Thu, 11 Jul 2013 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfjeI4mcjF2y for ; Thu, 11 Jul 2013 03:49:05 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 580BD11E80C5 for ; Thu, 11 Jul 2013 03:49:04 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so4236361qcz.14 for ; Thu, 11 Jul 2013 03:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WqxJFljay1UyEc2JbSP3Ru2IEschh8mBSluBSdj+DYY=; b=b5WgyTrDDek7/3+D0cHzGrngxtfGm4fVJPC6x/OeW/OElGSvo6WxblZOn0n+8I2BOj kwUbC3UmrA6XmVaSeh1+E7sp6GPUxKGbgg7hpdAQgE5pxVHCHlQhBwBwATOu7bxargZO n44dgRzj//LuKRF0cy43IiVzn3l0KSIMQjdbX1GOfly+m7rJseXIqzlCQww8JE/wEPKh oZ0Blzrifpe072oxUu4cNzgenq5PSGs3PcIdEeaTzY1jgzHnKWk7Xf7P+Dod/mI3zNIy VkiiDRSRqXWA3nFFGQCMyPn3rRfg18mISmygrpLgmTsDz8HqvdCjL1V0fy7XR2clvaB5 9lwA== X-Received: by 10.49.103.136 with SMTP id fw8mr29489367qeb.65.1373539744213; Thu, 11 Jul 2013 03:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.73 with HTTP; Thu, 11 Jul 2013 03:48:44 -0700 (PDT) In-Reply-To: <87bo6a755z.wl%jch@pps.univ-paris-diderot.fr> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> <87ppuq7epd.wl%jch@pps.univ-paris-diderot.fr> <87hag2773v.wl%jch@pps.univ-paris-diderot.fr> <87bo6a755z.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Thu, 11 Jul 2013 12:48:44 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:49:06 -0000 On Wed, Jul 10, 2013 at 6:26 PM, Juliusz Chroboczek wrote: > Consider the following topology: > > -- A -- X -- B -- > \ / > - Y - > > A is announcing (::/0, alpha), B is announcing (::/0, beta). X is > source-specific. Y is a legacy router. Okay. > Suppose now that rather than dropping the source-specific routes, Y is > casting them into non-specific default routes, and that it has > selected A as its next hop for the default route. Y is just announcing that it only does forward normal traffic, its not part of the "source-specific" topology. > Now X crashes: > > -- A B -- > \ / > - Y - > > A's routing table is now just (::/0, alpha) and (::/0, ::/0), with the > latter pointing at Y. But Y is still pointing its default route at A, > so you're in trouble. I think its the same issue/misunderstanding we had in the last post. The question if traffic for an unspecific source-address can go out of any gateway or not. If it can go out of any gateway, A will just take the traffic and forward it to the external gateway without asking Y. What do you think? Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From jch@pps.univ-paris-diderot.fr Thu Jul 11 05:46:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3E621F9A50 for ; Thu, 11 Jul 2013 05:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdLSjBB49tZf for ; Thu, 11 Jul 2013 05:46:39 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C0811E8127 for ; Thu, 11 Jul 2013 05:46:38 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r6BCkZfI017182; Thu, 11 Jul 2013 14:46:35 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3319D4FC3A; Thu, 11 Jul 2013 14:46:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id pXaxt0lFGSMw; Thu, 11 Jul 2013 14:46:33 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D762B4FC39; Thu, 11 Jul 2013 14:46:33 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UxGGX-00011o-EP; Thu, 11 Jul 2013 14:46:33 +0200 Date: Thu, 11 Jul 2013 14:46:33 +0200 Message-ID: <87li5dl0wm.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Henning Rogge In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> <87ppuq7epd.wl%jch@pps.univ-paris-diderot.fr> <87hag2773v.wl%jch@pps.univ-paris-diderot.fr> <87bo6a755z.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 11 Jul 2013 14:46:36 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 12:46:45 -0000 > Y is just announcing that it only does forward normal traffic, its not > part of the "source-specific" topology. How do you identify "normal traffic"? Recall that we're not "tagging" source-specific packets -- these are perfectly ordinary IP packets that happen to have a source address that matches a source-specific route. (If you start tagging packets with the gateway's address, then you're doing weak source routing -- which is a rather cool technology in itself, see reference [CLARK] in draft-boutier-tralala, but it is out of scope for this particular work.) > I think its the same issue/misunderstanding we had in the last post. > The question if traffic for an unspecific source-address can go out of > any gateway or not. If it can go out of any gateway, A will just take > the traffic and forward it to the external gateway without asking Y. Yeah, that's essentially equivalent to redistributing a non-specific default route from each gateway, perhaps a blackhole route, and perhaps with a high metric. I guess that's what we need to do, since it breaks routing loops in many cases. It makes me vaguely uncomfortable, but I'm not quite sure why. -- Juliusz From jch@pps.univ-paris-diderot.fr Thu Jul 11 06:12:04 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372F521F9AE3 for ; Thu, 11 Jul 2013 06:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGi69nhetVCK for ; Thu, 11 Jul 2013 06:11:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E70821F9F28 for ; Thu, 11 Jul 2013 06:11:58 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r6BDBuG3021359; Thu, 11 Jul 2013 15:11:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9CEE44FC38; Thu, 11 Jul 2013 15:11:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uWln6bBvvMft; Thu, 11 Jul 2013 15:11:50 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9E4CE4FC34; Thu, 11 Jul 2013 15:11:50 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UxGf0-00012G-7V; Thu, 11 Jul 2013 15:11:50 +0200 Date: Thu, 11 Jul 2013 15:11:50 +0200 Message-ID: <87ip0hkzqh.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Lorenzo Colitti In-Reply-To: References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> <87ppuq7epd.wl%jch@pps.univ-paris-diderot.fr>

User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 11 Jul 2013 15:11:56 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:12:04 -0000 > But isn't this an impossible requirement to meet in reality? I have no idea. We're just exploring the space of possible solutions right now -- hey, it's not like we've had a lot of operational experience with source-specific routing yet. We're playing with things, and looking what breaks. > What if users plug things in in such a way that there is no such > path between two given gateways? Things break. We make sure things break as gracefully as possible. Then we'll need to ask ourselves whether we want to support such hybrid topologies in the first place. (My gut instinct is to agree with you -- we'll probably want to forbid hybrid networks --, but I'm keeping an open mind until we learn more.) -- Juliusz From jch@pps.univ-paris-diderot.fr Thu Jul 11 07:07:35 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDF111E8171 for ; Thu, 11 Jul 2013 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN6kxsMMqHrN for ; Thu, 11 Jul 2013 07:07:29 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30911E817E for ; Thu, 11 Jul 2013 07:07:27 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/38117) with ESMTP id r6BE6wfe029245; Thu, 11 Jul 2013 16:06:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7166F4FC3D; Thu, 11 Jul 2013 16:06:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id NrMxo8ppRGfY; Thu, 11 Jul 2013 16:06:57 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1416B4FC38; Thu, 11 Jul 2013 16:06:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UxHWK-0001Ck-Km; Thu, 11 Jul 2013 16:06:56 +0200 Date: Thu, 11 Jul 2013 16:06:56 +0200 Message-ID: <878v1dkx6n.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <51DE5212.90405@globis.net> References: <7ippuz4fb8.wl%jch@pps.univ-paris-diderot.fr> <7ibo6iw7ch.wl%jch@pps.univ-paris-diderot.fr> <87ehbdi33a.wl%jch@pps.univ-paris-diderot.fr> <87wqp0lal6.wl%jch@pps.univ-paris-diderot.fr> <87bo6bwzxn.wl%jch@pps.univ-paris-diderot.fr> <8761wjwyt7.wl%jch@pps.univ-paris-diderot.fr> <87ppuq7epd.wl%jch@pps.univ-paris-diderot.fr> <87hag2773v.wl%jch@pps.univ-paris-diderot.fr> <87bo6a755z.wl%jch@pps.univ-paris-diderot.fr> <51DE5212.90405@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 11 Jul 2013 16:06:59 +0200 (CEST) Cc: "homenet@ietf.org" Subject: Re: [homenet] draft-boutier-homenet-source-specific-routing-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe:

Yeah, I haven't actually tried = listening on port 80 on my android when I happen
to be on v6 and = seeing if it's walled off. I was hoping that lazywebs would help
me = out here. *If* phones are not walled off now, I have no objection to = this section as
it's a stake in the ground that hosts can be their = own firewalls. But I'd like to have
some belief that that is true = before we declare homenet firewalls = obsolete.

The arch text doesn't declare = edge firewalls obsolete.

It talks about realms = and borders, and the need to have appropriate filtering between realms, = including the homenet and ISP.

The case for = border firewalls is reinforced by, for example, this paper: http://interne= tcensus2012.bitbucket.org/paper.html

The = text about the "value" of firewalls is merely noting that infections = picked up by activity from within the homenet should not be overlooked = (in part the driver for Eric Vyncke's advanced IPv6 security draft, = which he has subsequently = lapsed).

Tim

= --Apple-Mail=_7768CA48-908D-4EC3-AB7E-A0099346D99A-- From internet-drafts@ietf.org Mon Jul 15 07:17:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD7E21F9A37; Mon, 15 Jul 2013 07:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQRsS85Q9V5S; Mon, 15 Jul 2013 07:17:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D739421F999B; Mon, 15 Jul 2013 07:17:00 -0700 (PDT) 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: 4.51.p2 Message-ID: <20130715141700.26613.60339.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 07:17:00 -0700 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-09.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, 15 Jul 2013 14:17:01 -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) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-09.txt Pages : 49 Date : 2013-07-15 Abstract: This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jch@pps.univ-paris-diderot.fr Mon Jul 15 07:33:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C1C11E811E for ; Mon, 15 Jul 2013 07:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJhXZ5SEkjpN for ; Mon, 15 Jul 2013 07:33:57 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 40AED11E8118 for ; Mon, 15 Jul 2013 07:33:54 -0700 (PDT) Received: from pirx.pps.jussieu.fr (unknown [IPv6:2a01:e35:2ee4:9090:15c2:24a4:8e70:5a2d]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5F5F4940182; Mon, 15 Jul 2013 16:33:44 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UyjqQ-0001Y3-JQ; Mon, 15 Jul 2013 16:33:42 +0200 Date: Mon, 15 Jul 2013 16:33:42 +0200 Message-ID: <874nbv6gft.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: homenet@ietf.org In-Reply-To: <20130715141700.26613.60339.idtracker@ietfa.amsl.com> References: <20130715141700.26613.60339.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: ot@cisco.com, tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-09.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, 15 Jul 2013 14:33:58 -0000 Dear editors, Thanks for the hard work. I haven't had time to review the new document fully yet, but I'm still concerned about the second paragraph of 3.5: It is desirable, but not absolutely required, that the routing protocol be able to give a complete view of the network, and that it be able to pass around more than just routing information. This implies to me that we're recommending single-area link-state protocols, and in particular that we're outlawing route filtering (since link-state protocols can only filter at area boundaries, and since at any rate route filtering prevents having a complete view). We might still be allowing stub areas (the text doesn't say that the complete view must be available everywhere within the network), but we're definitely discouraging fully general multi-area operation. Could you please confirm that this is the expected meaning? Is there consensus on this list that route filtering is not useful in a homenet environment? If this is the case, perhaps this should be stated explicitly and justified. For the record, I still recommend that this sentence should be removed. Thanks, -- Juliusz From mike@mtcc.com Mon Jul 15 08:49:39 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570B021E80D2 for ; Mon, 15 Jul 2013 08:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCq0TvCOgTNU for ; Mon, 15 Jul 2013 08:49:34 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 40A4021E80C1 for ; Mon, 15 Jul 2013 08:49:34 -0700 (PDT) Received: from michael-thomass-macbook.local (aric.mtcc.com [50.0.18.225] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6FFnXCc020541 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 15 Jul 2013 08:49:33 -0700 Message-ID: <51E41A0A.5000203@mtcc.com> Date: Mon, 15 Jul 2013 08:49:30 -0700 From: mike User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: homenet@ietf.org References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DD5F5BF@wds-exc1.okna.nominet.org.uk> <877ghts5ko.wl%jch@pps.univ-paris-diderot.fr> <101FBDBE-2721-4CE1-B462-984AFB6DB467@employees.org> <8738shdjfc.wl%jch@pps.univ-paris-diderot.fr> <87y5a8dit5.wl%jch@pps.univ-paris-diderot.fr> <51BF037A.2040907@mtcc.com> <53F00E5CD8B2E34C81C0C89EB0B4FE732DDB7120@wds-exc1.okna.nominet.org.uk> <51BF0E63.9000503@mtcc.com> <51BF3D18.4070508@mtcc.com>

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=917; t=1373903373; x=1374767373; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20mike=20 |Subject:=20Re=3A=20[homenet]=20more=203.7 |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=3R9+8xPbyYNLSc2RgA6N+GZFNdEaPBkkDDsU70uK0gk=; b=aVEp84WkW7EQZ/PsbEQKQzOD3qjHmaaKH/0xM4L38KQ0JhWtsl8OGd/KCa yYacuvXvgYWPTQTRhDnD9mkSaspku8qKWlbeG4o/G0aue6dU92bFLVuUqYFj x/hE95LptLruOBbr1/nfqbCyFusu9ejAKqXIvL1faMDAYzA5VHBo4=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] more 3.7 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:49:39 -0000 On 7/15/13 4:14 AM, Tim Chown wrote: > On 17 Jun 2013, at 17:45, Michael Thomas wrote: >> 7) 3.7.7 >> >> I still don't understand what this section is trying to highlight. Is there a piece of code here >> that needs to be written or not? I'm sorry if I'm being dense. > This is about a host learning its own DNS resolver to use, when nested behind multiple routers. Jari pointed this out after his own homenet experiments. > This section might be opening the split horizon can of worms. Homes may in fact be subdivideable with, say, "Bobby's Room, Mom's Yankee Workshop", etc. So is there a single go-to naming authority? I think the answer is unfortunately no, especially when you consider that mDNS is its own creature. What the solution to this is, I'm not certain but it may be worth pointing out in the arch document to highlight that it is both out there and unresolved. Mike From mike@mtcc.com Mon Jul 15 08:51:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AEB11E8131 for ; Mon, 15 Jul 2013 08:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTDBIQ2BqVFe for ; Mon, 15 Jul 2013 08:51:06 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id AFB9A21E80D7 for ; Mon, 15 Jul 2013 08:51:02 -0700 (PDT) Received: from michael-thomass-macbook.local (aric.mtcc.com [50.0.18.225] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6FFRglv013359 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 15 Jul 2013 08:28:42 -0700 Message-ID: <51E414EB.8010902@mtcc.com> Date: Mon, 15 Jul 2013 08:27:39 -0700 From: mike User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: homenet@ietf.org References: <51BF7213.8040506@mtcc.com> <16772.1371514093@sandelman.ca> <51BFA71B.8010001@mtcc.com> <32443.1371517044@sandelman.ca> <51BFB2F9.20101@mtcc.com> <246AC4AC-2BB1-4D76-A142-B177BEDAC00B@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1447; t=1373902122; x=1374766122; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20mike=20 |Subject:=20Re=3A=20[homenet]=20section=203.6.3 |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=gQ68PZiQ4okfzY8P/Q0Lcp7lfU75UTa6nEdNiFwPa+k=; b=YDM1IltjEpxBL2gnOVdliu6yGszilac9vZ8oAovABlAeW4RTC6msAh2DB2 ZDqlcV08SHt9s2WhmMhyYPDAO+GVRUSsLGC3YszihfdHuE1lj7/yIFlGx3y/ PDPjjkzKs+33F4WcHHCNMzIC2wiLW7NydZb8ehHaZSbDMG3sQYNi4=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] section 3.6.3 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:51:15 -0000 On 7/15/13 4:19 AM, Tim Chown wrote: > On 18 Jun 2013, at 02:08, Michael Thomas > wrote: > >> Yeah, I haven't actually tried listening on port 80 on my android when I happen >> to be on v6 and seeing if it's walled off. I was hoping that lazywebs would help >> me out here. *If* phones are not walled off now, I have no objection to this section as >> it's a stake in the ground that hosts can be their own firewalls. But I'd like to have >> some belief that that is true before we declare homenet firewalls obsolete. > > The arch text doesn't declare edge firewalls obsolete. > > It talks about realms and borders, and the need to have appropriate filtering between realms, including the homenet and ISP. > > The case for border firewalls is reinforced by, for example, this paper: http://internetcensus2012.bitbucket.org/paper.html > > The text about the "value" of firewalls is merely noting that infections picked up by activity from within the homenet should not be overlooked (in > part the driver for Eric Vyncke's advanced IPv6 security draft, which he has subsequently lapsed). > I'm aware that firewalls more closely resemble Maginot Lines these days, but still the text is a little too glib IMO. I don't really think homenet needs to directly insert itself into that debate: it's every bit as true in enterprise, etc. Let them take the lead on the problem, I'd say. Mike From v6ops@globis.net Mon Jul 15 09:08:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DF521E80CC for ; Mon, 15 Jul 2013 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cql+TT42+0xf for ; Mon, 15 Jul 2013 09:08:11 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 72E1921E80C4 for ; Mon, 15 Jul 2013 09:08:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A143F8700E6; Mon, 15 Jul 2013 18:07:55 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeNuWHLwcRwP; Mon, 15 Jul 2013 18:07:55 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8073A8700D6; Mon, 15 Jul 2013 18:07:55 +0200 (CEST) Message-ID: <51E41E55.2060905@globis.net> Date: Mon, 15 Jul 2013 18:07:49 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Juliusz Chroboczek References: <20130715141700.26613.60339.idtracker@ietfa.amsl.com> <874nbv6gft.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <874nbv6gft.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ot@cisco.com, homenet@ietf.org, tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-09.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, 15 Jul 2013 16:08:12 -0000 Juliusz Chroboczek wrote: > Dear editors, > > Thanks for the hard work. > > I haven't had time to review the new document fully yet, but I'm still > concerned about the second paragraph of 3.5: > > It is desirable, but not absolutely required, that the routing > protocol be able to give a complete view of the network, and that > it be able to pass around more than just routing information. > > This implies to me that we're recommending single-area link-state > protocols, and in particular that we're outlawing route filtering > (since link-state protocols can only filter at area boundaries, and > since at any rate route filtering prevents having a complete view). > We might still be allowing stub areas (the text doesn't say that the > complete view must be available everywhere within the network), but > we're definitely discouraging fully general multi-area operation. > > Could you please confirm that this is the expected meaning? Is there > consensus on this list that route filtering is not useful in a homenet > environment? If this is the case, perhaps this should be stated > explicitly and justified. > > For the record, I still recommend that this sentence should be removed. > > Thanks, > > -- Juliusz > I think the current text is fine, and I don't agree with the suggested interpretation that this text implies a single link state protocol must be used and that route filtering may not be performed. Being capable of doing something is very different from always having to do it. regards RayH From jch@pps.univ-paris-diderot.fr Mon Jul 15 10:03:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB5711E816E for ; Mon, 15 Jul 2013 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnGOHtAUyMae for ; Mon, 15 Jul 2013 10:03:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id ADA0D11E818A for ; Mon, 15 Jul 2013 10:02:47 -0700 (PDT) Received: from pirx.pps.jussieu.fr (unknown [IPv6:2a01:e35:2ee4:9090:15c2:24a4:8e70:5a2d]) by smtp1-g21.free.fr (Postfix) with ESMTP id DE2979401BC; Mon, 15 Jul 2013 19:02:31 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UymAQ-00031c-Ia; Mon, 15 Jul 2013 19:02:30 +0200 Date: Mon, 15 Jul 2013 19:02:30 +0200 Message-ID: <87oba34uzd.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Hunter In-Reply-To: <51E41E55.2060905@globis.net> References: <20130715141700.26613.60339.idtracker@ietfa.amsl.com> <874nbv6gft.wl%jch@pps.univ-paris-diderot.fr> <51E41E55.2060905@globis.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: ot@cisco.com, homenet@ietf.org, tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-09.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, 15 Jul 2013 17:03:25 -0000 >> It is desirable, but not absolutely required, that the routing >> protocol be able to give a complete view of the network, and that >> it be able to pass around more than just routing information. >> This implies to me that we're recommending single-area link-state >> protocols, and in particular that we're outlawing route filtering > I think the current text is fine, and I don't agree with the suggested > interpretation that this text implies a single link state protocol must > be used and that route filtering may not be performed. Ok, then I'm missing something. What exactly does "a complete view" mean? Does it mean that every router in a homenet must be able to determine the complete topology of the homenet? Does it mean that there is at least one router that can determine the complete topology of the network? Does it mean something else? If you manage to explain exactly what is meant by this sentence, I'll try to craft a wording suitable for the draft. -- Juliusz From v6ops@globis.net Mon Jul 15 12:19:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FE121E8142 for ; Mon, 15 Jul 2013 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZB0DDJtSugB for ; Mon, 15 Jul 2013 12:19:47 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4C411E8220 for ; Mon, 15 Jul 2013 12:19:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1DDD78700EB; Mon, 15 Jul 2013 21:19:28 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfJyjlimZYp7; Mon, 15 Jul 2013 21:19:28 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E7B578700EA; Mon, 15 Jul 2013 21:19:27 +0200 (CEST) Message-ID: <51E44B39.3090300@globis.net> Date: Mon, 15 Jul 2013 21:19:21 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Juliusz Chroboczek References: <20130715141700.26613.60339.idtracker@ietfa.amsl.com> <874nbv6gft.wl%jch@pps.univ-paris-diderot.fr> <51E41E55.2060905@globis.net> <87oba34uzd.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87oba34uzd.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ot@cisco.com, homenet@ietf.org, tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-09.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, 15 Jul 2013 19:19:48 -0000 Juliusz Chroboczek wrote: >>> It is desirable, but not absolutely required, that the routing >>> protocol be able to give a complete view of the network, and that >>> it be able to pass around more than just routing information. > >>> This implies to me that we're recommending single-area link-state >>> protocols, and in particular that we're outlawing route filtering > >> I think the current text is fine, and I don't agree with the suggested >> interpretation that this text implies a single link state protocol must >> be used and that route filtering may not be performed. > > Ok, then I'm missing something. > > What exactly does "a complete view" mean? Does it mean that every > router in a homenet must be able to determine the complete topology of > the homenet? There's no must in the original text. > Does it mean that there is at least one router that can > determine the complete topology of the network? I don't think that's a necessary requirement, depending on which nodes are intending to use which upstream ISP connections. > Does it mean something > else? The following statements are not incompatible with the current text IMHO. The routing protocol SHOULD be able to transport more information than just routing information. The routing protocol SHOULD be capable of providing a Homenet device with a complete topological view of the network. A Homenet router MAY filter routing information where appropriate. > If you manage to explain exactly what is meant by this sentence, I'll > try to craft a wording suitable for the draft. > > -- Juliusz > From tjc@ecs.soton.ac.uk Mon Jul 15 14:20:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B05C11E819D for ; Mon, 15 Jul 2013 14:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5VVbkGaCgVF for ; Mon, 15 Jul 2013 14:20:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1021E8119 for ; Mon, 15 Jul 2013 14:20:53 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6FLKhXc024446; Mon, 15 Jul 2013 22:20:43 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r6FLKhXc024446 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1373923243; bh=dwS7XNj+qHqf+LyKxXJ+m6W4TJU=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=EJMzpwp+Y9tFem6plJTjL7Au1LL6Fc1wjshJ2ka4ruCCmaCfceOEU0KvrGDRMkdU1 ZyAQvd5SZ1advYbGcx52vPqRHUC1XDFzp/Q8AtownISzPJWC0dhYjkSyCi8p6SpxLp 5farzo8EaXY9u4UjUI9/+T6V7jlD4/skFcZO0RlI= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p6EMKh0544510922yR ret-id none; Mon, 15 Jul 2013 22:20:43 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6FLJPUV016857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Jul 2013 22:19:25 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Tim Chown In-Reply-To: <874nbv6gft.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 15 Jul 2013 22:19:27 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130715141700.26613.60339.idtracker@ietfa.amsl.com> <874nbv6gft.wl%jch@pps.univ-paris-diderot.fr> <00DB0A9B-2694-4AF7-B0C5-8A77774A0BB0@ecs.soton.ac.uk> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p6EMKh054451092200; tid=p6EMKh0544510922yR; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r6FLKhXc024446 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: ot@cisco.com, homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-09.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, 15 Jul 2013 21:20:57 -0000 On 15 Jul 2013, at 15:33, Juliusz Chroboczek = wrote: > Dear editors, >=20 > Thanks for the hard work. >=20 > I haven't had time to review the new document fully yet, but I'm still > concerned about the second paragraph of 3.5: >=20 > It is desirable, but not absolutely required, that the routing > protocol be able to give a complete view of the network, and that > it be able to pass around more than just routing information. >=20 > This implies to me that we're recommending single-area link-state > protocols, and in particular that we're outlawing route filtering > (since link-state protocols can only filter at area boundaries, and > since at any rate route filtering prevents having a complete view). > We might still be allowing stub areas (the text doesn't say that the > complete view must be available everywhere within the network), but > we're definitely discouraging fully general multi-area operation. >=20 > Could you please confirm that this is the expected meaning? Is there > consensus on this list that route filtering is not useful in a homenet > environment? If this is the case, perhaps this should be stated > explicitly and justified. >=20 > For the record, I still recommend that this sentence should be = removed. Julius, you wrote those precise words yourself last month, agreeing with = Ole that the wording was good. And I agreed with both of you. So I'm = confused as to why you've now chosen to change your mind. =20 I think you're inferring something that isn't written. The homenet = realms and borders section explains that policy can include potentially = any information at each border. Anyway, this is what you wrote: On 18 Jun 2013, at 22:46, Juliusz Chroboczek =

--e89a8f503b1611339404e2a97a7f-- From alexandru.petrescu@gmail.com Mon Jul 29 10:28:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0383D21F9998 for ; Mon, 29 Jul 2013 10:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzf+85r7zwra for ; Mon, 29 Jul 2013 10:28:34 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3CE11E8113 for ; Mon, 29 Jul 2013 10:24:41 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so6141744pad.33 for ; Mon, 29 Jul 2013 10:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=rfq9iY/o5fdMQsMuBbCmr342I2dDQsmm/NrKN4cUuGw=; b=o7bx/S7tzJg6TFktsJ8pq5MJd6/Sz3p+X4NyHv4X2O4u4uYHXy0wMM9hB3KNKuUZGq L+ANFkc3KvNJAJkG8p4wq1Orw3B3Su6YAAJT7qzvDLvS2dmi59S4vN4g/whrVUSFxWJA LvPmzYNNpiRrW8qwggRNfW1MXwg8BRyGtUaW41eA5BV1WX/i75i5eYkYnkcfNoQEC2oR ThS6zrlF1a9WHJEMspslQBsdiAQIMy3PS+Emmj3uQaIcLPYGXGIBV9h4wuXYpFP7OkiO RdOIIpBWC9uhG22GbQopdl84oGFBX7C4MBhjOby7xiRadLVNoCWz68hFK5J8bIkLG2E1 VgKw== X-Received: by 10.66.246.106 with SMTP id xv10mr54356716pac.100.1375118678067; Mon, 29 Jul 2013 10:24:38 -0700 (PDT) Received: from [130.129.19.105] (dhcp-1369.meeting.ietf.org. [130.129.19.105]) by mx.google.com with ESMTPSA id ue9sm21970854pab.7.2013.07.29.10.24.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 10:24:37 -0700 (PDT) Message-ID: <51F6A54F.50008@gmail.com> Date: Mon, 29 Jul 2013 19:24:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: homenet@ietf.org References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> <20130729143209.GL901145@jupiter.n2.diac24.net> In-Reply-To: <20130729143209.GL901145@jupiter.n2.diac24.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [homenet] longest-match (was: source routing requirements for routing protocols) 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, 29 Jul 2013 17:29:01 -0000 Le 29/07/2013 16:32, David Lamparter a �crit : [...] > RESULT (stop skipping here) ====== > > The non source specific routes keep working as intended. The source > specific routes work as intended, doing a longest-match on the > source. What _is_ longest match in detail? (regardless of src or dst). Alex From jch@pps.univ-paris-diderot.fr Mon Jul 29 10:34:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1821F9BF3 for ; Mon, 29 Jul 2013 10:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh0F4Fqf7EOr for ; Mon, 29 Jul 2013 10:34:48 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B18511E80D9 for ; Mon, 29 Jul 2013 10:33:29 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r6THXSep021617; Mon, 29 Jul 2013 19:33:28 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7EC0056668; Mon, 29 Jul 2013 19:33:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id L2DY5svpdveb; Mon, 29 Jul 2013 19:33:27 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dhcp-16db.meeting.ietf.org [130.129.22.219]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 47F8356665; Mon, 29 Jul 2013 19:33:27 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V3rK2-00019O-Q1; Mon, 29 Jul 2013 19:33:26 +0200 From: Juliusz Chroboczek Date: Mon, 29 Jul 2013 19:33:26 +0200 Message-ID: <87zjt5gtjt.wl%jch@pps.univ-paris-diderot.fr> To: Alexandru Petrescu In-Reply-To: <51F62B6B.4090709@gmail.com> References: <51F62B6B.4090709@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 29 Jul 2013 19:33:28 +0200 (CEST) X-Miltered: at korolev with ID 51F6A768.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 51F6A768.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 51F6A768.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: homenet@ietf.org Subject: Re: [homenet] Comments on src-based routing in general 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, 29 Jul 2013 17:34:54 -0000 > It is tempting to formalize the prefix and IPv6 addresses into sets and > subsets and relationships between them. But that relies on an > assumption that 'longest-prefix match' algorithm is precisely known. It > is not, there is no RFC about it AFAIK. It's not particularly explicit, but RFC 1519 Section 4.1 seems clear to me. RFC 4632 is somewhat less clear. > There are many fuzzy aspects in the implementation of longest-prefix > match (e.g. to disambiguate between ifaces). Please clarify. > Given that, it is next to impossible to come up with a specification > which is src-based routing (instead of dst-based). I most respectfully disagree. > About the problem: I heard said the problem being to ISPs present in the > same homenet, and need to forward the packet to the right ISP based on > the src address. If that is so, then a first step to realize it would > be to send _some_ traffic to an ISP and the rest to the other. That > could be still achieved with dst-based routing, but with specific routes > (i.e. for services specific to that ISP use that dst-based specific route). Noted. I'll try to make the difference clear in the next version of the draft. > About the question whether this shows up somewhere else than in > homenets. One other protocol which uses mandatory src-based routing is > Proxy Mobile IPv6 (the MAG needs it). One would make sure that way of > doing src-based routing is compatible to homenet. Thanks for the pointer. Do you have a reference I should check? -- Juliusz From jch@pps.univ-paris-diderot.fr Mon Jul 29 10:35:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B518E21F9FFF for ; Mon, 29 Jul 2013 10:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Dk6y-h3Tf13 for ; Mon, 29 Jul 2013 10:35:08 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6717321F9A4C for ; Mon, 29 Jul 2013 10:34:12 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r6THYBo9021858; Mon, 29 Jul 2013 19:34:11 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6195B56668; Mon, 29 Jul 2013 19:34:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 8UrfxXC-3Lhh; Mon, 29 Jul 2013 19:34:06 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dhcp-16db.meeting.ietf.org [130.129.22.219]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3B3E056665; Mon, 29 Jul 2013 19:34:06 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V3rKf-00019S-R1; Mon, 29 Jul 2013 19:34:05 +0200 From: Juliusz Chroboczek Date: Mon, 29 Jul 2013 19:34:05 +0200 Message-ID: <87y58pgtiq.wl%jch@pps.univ-paris-diderot.fr> To: Michael Richardson In-Reply-To: <10806.1375097238@sandelman.ca> References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 29 Jul 2013 19:34:11 +0200 (CEST) X-Miltered: at korolev with ID 51F6A793.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 51F6A793.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 51F6A793.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: homenet@ietf.org Subject: Re: [homenet] source routing requirements for routing protocols 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, 29 Jul 2013 17:35:25 -0000 > During Juliusz (or was it Matthieu speaking?) 'Twas me, Juliusz. > As an aside I want to point out again that IPsec RFC2401 and RFC4301 > detail this problem. They [force] the SPD to be explicitely ordered, > and mandating that the ordering knobs be available to > administrators, who have no idea what any of it means. Thanks for the pointer, I'll have a look. (Not that these are the most digestible RFCs ever.) > 1) if we are going to introduce a new route to deal with the > conflict, then the routing protocol must be able to express > what might appear to be multiple routes to the same dest/prefix. No. The disambiguation routes appear in the RIB only, they never appear in the FIB, let alone on the wire. > 2) while we might agree that the destination wins, so that we have > a consistent routing table across the homenet, the routing protocol > should have a way for a router to say, "yes, but I see a conflict" > such that someone or something can say, "oh. Well, I shall insert a > disambiguation route. I don't think that's necessary -- what issue are you trying to solve? > I haven't thought very hard yet if it's possible for one router to > see an ambiguity, while others would not. Yes, that's normal behaviour in the presence of filtering. It does not appear to cause any issues. > This should not occur with a link-state routing protocol Assuming a single area, you're right. -- Juliusz From jch@pps.univ-paris-diderot.fr Mon Jul 29 10:38:13 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F67E11E80F3 for ; Mon, 29 Jul 2013 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy1FrMvKzh9B for ; Mon, 29 Jul 2013 10:38:06 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C3E11E810F for ; Mon, 29 Jul 2013 10:37:19 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46333) with ESMTP id r6THahpx011184; Mon, 29 Jul 2013 19:36:43 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 04DB556672; Mon, 29 Jul 2013 19:36:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QcJuaJpj9D1C; Mon, 29 Jul 2013 19:36:41 +0200 (CEST) Received: from pirx.pps.jussieu.fr (dhcp-16db.meeting.ietf.org [130.129.22.219]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9123556668; Mon, 29 Jul 2013 19:36:41 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1V3rNB-00019j-52; Mon, 29 Jul 2013 19:36:41 +0200 Date: Mon, 29 Jul 2013 19:36:41 +0200 Message-ID: <87wqo9gtee.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: David Lamparter In-Reply-To: <20130729143209.GL901145@jupiter.n2.diac24.net> References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> <20130729143209.GL901145@jupiter.n2.diac24.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 29 Jul 2013 19:36:43 +0200 (CEST) X-Miltered: at potemkin with ID 51F6A82B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 51F6A82B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 51F6A82B.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "homenet@ietf.org" Subject: Re: [homenet] source routing requirements for routing protocols 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, 29 Jul 2013 17:38:13 -0000 > As regards the reason for existence of the routes themselves, David > Lamparter tells me that he has in fact gotten the Linux IPv6 source routing > code (the mythical CONFIG_IPV6_SUBTREES?) to work on 3.8. David, That's really weird, since we've tried and failed on Debian's 3.8. Perhaps it only works for forwarded packets, not for locally originated ones? Could you please try repeating the tests described in http://www.spinics.net/lists/netdev/msg235316.html and see if they work for you? -- Juliusz From lorenzo@google.com Mon Jul 29 10:42:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583B911E80E0 for ; Mon, 29 Jul 2013 10:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEYvApLuReFx for ; Mon, 29 Jul 2013 10:42:48 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DCD3921F9A3D for ; Mon, 29 Jul 2013 10:42:09 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id up14so1874894obb.11 for ; Mon, 29 Jul 2013 10:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CVTfh8y7ouYXL62nbwhg8yai9oHQ1qwICp8d/V4p1dM=; b=TS6UPA9XR4tRGQKouY4IaducfDX4fP9eY75Lk2SGQ7zERER5yQNJq+YIGo7Gq8j1iE 6giAXgZuq/uopUhFYzuRnNH+PNozyRCLu3coA9CdCoTkTAOFK8IXWHra5Z6uhEL8WcPU F6dPOPaYFuTLrk/Qq1N7v5wR3atyQfTum17A6Wq6GZzmVfHfUKN4gsk8ArFMfdqKpwDA XHpopOpm9aQtMgscunGvN8HCaYsRNAGqwcIwyhj7X1sQGIcyhFJ9nPCfoM2VyRHMfsKu wOFDNg+MaekLnLCaPC8H+7xTVCawSRHcqeeOnOz8YiUD1cYJIxlK2i7Ib/TmXZe/gOBv JEHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=CVTfh8y7ouYXL62nbwhg8yai9oHQ1qwICp8d/V4p1dM=; b=pxf+hncgWZ4OHA/yXXpL4mQO9duXJcQwUDk58qq9EMEuK/xOv9CBrPscE6W0buMGlm xavPTgiQlqdS9MqEIgBhye05Q+1S/0PH4e5oc852EQSXMnSMb0WPN+iABtv165Eb7A53 5JIJlaR7CfLNC62xRabBNj7XSH4SOygkoaYly2vaQDvlcD7uWAtKIfVKEAkij1w0PooV KD75gWp9qgZKsO12+vDtC+iIYGU1cOKdXh33GrrJsQl98iqWChrusxT49DW4bu0sasEh zteWZG4zjTP3vIWTT5ow9LSpcPygBCSSnl/GMXzKoMxsZfnYHiwtiKyIEZ/0yWYu3VdB Z1oQ== X-Received: by 10.43.181.136 with SMTP id pi8mr21110270icc.10.1375119729219; Mon, 29 Jul 2013 10:42:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 29 Jul 2013 10:41:48 -0700 (PDT) In-Reply-To: <87wqo9gtee.wl%jch@pps.univ-paris-diderot.fr> References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> <20130729143209.GL901145@jupiter.n2.diac24.net> <87wqo9gtee.wl%jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Mon, 29 Jul 2013 19:41:48 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a11c35008fbfdaa04e2aa02b0 X-Gm-Message-State: ALoCoQl7kA9+FbPwAQK7hR2xAxBLmSrcSLa42Dg2H0DNMSZpnXW/bTPu4R4KieE4qpBMiOeVCkM5XISShir9+kZ9JBEr7ydTT9C7Q8s3yPJzJ3uJo2jpKEQdNH7vqQMjpre0RjFjhpybkOitDZY2N4W1KixfX/pQzrehjKzbHKh5ShqT3JHsugek5OEWSAbK3CHnmLMeVP3d Cc: "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] source routing requirements for routing protocols 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, 29 Jul 2013 17:42:54 -0000 --001a11c35008fbfdaa04e2aa02b0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 29, 2013 at 7:36 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > That's really weird, since we've tried and failed on Debian's 3.8. > Perhaps it only works for forwarded packets, not for locally > originated ones? > Source-based routing will never work for locally originated packets because source address selection is done after routing. So at routing lookup time there is no source address to match. --001a11c35008fbfdaa04e2aa02b0 Content-Type: text/html; charset=ISO-8859-1

On Mon, Jul 29, 2013 at 7:36 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

That's really weird, since we've tried and failed on Debian's 3.8.

Perhaps it only works for forwarded packets, not for locally
originated ones?

Source-based routing will never work for locally originated packets because source address selection is done after routing. So at routing lookup time there is no source address to match.

--001a11c35008fbfdaa04e2aa02b0-- From alexandru.petrescu@gmail.com Mon Jul 29 10:46:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36811E80E9 for ; Mon, 29 Jul 2013 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.076 X-Spam-Level: X-Spam-Status: No, score=-10.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA7ZbGr4u8U4 for ; Mon, 29 Jul 2013 10:46:17 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id E1E0821F9A17 for ; Mon, 29 Jul 2013 10:46:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r6THkEDk020748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 19:46:14 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6THkE3c006544; Mon, 29 Jul 2013 19:46:14 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6THk1nP021985; Mon, 29 Jul 2013 19:46:13 +0200 Message-ID: <51F6AA59.5060801@gmail.com> Date: Mon, 29 Jul 2013 19:46:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juliusz Chroboczek References: <51F62B6B.4090709@gmail.com> <87zjt5gtjt.wl%jch@pps.univ-paris-diderot.fr> In-Reply-To: <87zjt5gtjt.wl%jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: homenet@ietf.org Subject: Re: [homenet] Comments on src-based routing in general 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, 29 Jul 2013 17:46:26 -0000 Le 29/07/2013 19:33, Juliusz Chroboczek a �crit : >> It is tempting to formalize the prefix and IPv6 addresses into >> sets and subsets and relationships between them. But that relies >> on an assumption that 'longest-prefix match' algorithm is >> precisely known. It is not, there is no RFC about it AFAIK. > > It's not particularly explicit, but RFC 1519 Section 4.1 seems clear > to me. RFC 4632 is somewhat less clear. Well yes, but they're both IPv4, not IPv6. We know yes IPv4 is same as IPv6 in certain respects, but in this as well? >> There are many fuzzy aspects in the implementation of >> longest-prefix match (e.g. to disambiguate between ifaces). > > Please clarify. For example if two routes of same prefix but different next-hops will need something to disambiguate, right? >> Given that, it is next to impossible to come up with a >> specification which is src-based routing (instead of dst-based). > > I most respectfully disagree. > >> About the problem: I heard said the problem being to ISPs present >> in the same homenet, and need to forward the packet to the right >> ISP based on the src address. If that is so, then a first step to >> realize it would be to send _some_ traffic to an ISP and the rest >> to the other. That could be still achieved with dst-based >> routing, but with specific routes (i.e. for services specific to >> that ISP use that dst-based specific route). > > Noted. I'll try to make the difference clear in the next version of > the draft. > >> About the question whether this shows up somewhere else than in >> homenets. One other protocol which uses mandatory src-based >> routing is Proxy Mobile IPv6 (the MAG needs it). One would make >> sure that way of doing src-based routing is compatible to homenet. > > Thanks for the pointer. Do you have a reference I should check? The NETEXT WG discussion would be good at it. The RFC is RFC5213. I know the details are intricate, but one of relevant text is the following: " The mobile access gateway acts as the default router on the point-to- point link shared with the mobile node. Any packet that the mobile node sends to any correspondent node will be received by the mobile access gateway and will be sent to its local mobility anchor through the bi-directional tunnel." To me, that means that when the MAG receives a packet from a certain address (MN's), it forwards that packet to a certain tunnel interface. That is src-based routing. Alex > > -- Juliusz > From wbeebee@cisco.com Mon Jul 29 11:53:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C0921F9FF7 for ; Mon, 29 Jul 2013 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9nJ+JvQRBcV for ; Mon, 29 Jul 2013 11:53:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D9ABB21F9E31 for ; Mon, 29 Jul 2013 11:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1141; q=dns/txt; s=iport; t=1375123928; x=1376333528; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=A/mOlqrn/NRswG/3Yd0w9JDWm82u70reGKP5qyHLpzI=; b=RHbrpyppJvoub0Y9Qa6+NpUubCIgXTl8tiycwRlxqDel4ZlMn/tvFJJH QoWmTq/wxcgO1kxXTazaIHESnQAAFoH6RTcVEklFV5zhk/x1AThPjLvLv ARE0/Ssvim7IdUEvsqERS9zoohcvTL3WpNV4lkEQXKAZGu7m6O4iyKhLP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACm59lGtJV2Z/2dsb2JhbABbgwY1UL1agRoWdIImAQQBAQFrHQEIIkUGCyUCBAESCId2Aw8Mr3MNiFoEjRWCNziDGG8DiHKNBI4PhSaBW4E5gio X-IronPort-AV: E=Sophos;i="4.89,771,1367971200"; d="scan'208";a="240931707" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2013 18:52:02 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6TIq2na005801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 18:52:02 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.40]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 13:52:02 -0500 From: "Wes Beebee (wbeebee)" To: Alexandru Petrescu , "homenet@ietf.org" Thread-Topic: [homenet] longest-match (was: source routing requirements for routing protocols) Thread-Index: AQHOjIFGhMVjDeny8UyPZEy5ngf68Zl8ESoA Date: Mon, 29 Jul 2013 18:52:01 +0000 Message-ID: <9515564336C5B442A00021645539CFCC2AF1E2BD@xmb-rcd-x08.cisco.com> In-Reply-To: <51F6A54F.50008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.131.71.105] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <27744DFE3A6A654BBF057B79F69E1A8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] longest-match (was: source routing requirements for routing protocols) 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, 29 Jul 2013 18:53:15 -0000 Longest match specifies that the longest prefix that matches a particular address should be used in looking up a leaf, and eventually an adjacency that specifies the L2 rewrite information and outgoing interface in standard destination lookup forwarding. For source/dest lookup, a source lookup is performed and then a dest lookup based on the source results. An example of longest match: When matching 1234:5678::1, three routes are found in the routing table: ::/0 1234::/16 1234:5678::/32 Longest match says 1234:5678::/32 will be chosen. - Wes On 7/29/13 1:24 PM, "Alexandru Petrescu" wrote: >Le 29/07/2013 16:32, David Lamparter a =E9crit : >[...] >> RESULT (stop skipping here) =3D=3D=3D=3D=3D=3D >> >> The non source specific routes keep working as intended. The source >> specific routes work as intended, doing a longest-match on the >> source. > >What _is_ longest match in detail? (regardless of src or dst). > >Alex >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From alexandru.petrescu@gmail.com Mon Jul 29 12:02:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716EF11E811F for ; Mon, 29 Jul 2013 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.087 X-Spam-Level: X-Spam-Status: No, score=-10.087 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF3eucBdxadi for ; Mon, 29 Jul 2013 12:02:18 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id EF3DF11E812D for ; Mon, 29 Jul 2013 12:02:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r6TJ23lS004598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 21:02:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6TJ23cK024246; Mon, 29 Jul 2013 21:02:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6TJ1rKq003243; Mon, 29 Jul 2013 21:02:02 +0200 Message-ID: <51F6BC21.9060505@gmail.com> Date: Mon, 29 Jul 2013 21:01:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Wes Beebee (wbeebee)" References: <9515564336C5B442A00021645539CFCC2AF1E2BD@xmb-rcd-x08.cisco.com> In-Reply-To: <9515564336C5B442A00021645539CFCC2AF1E2BD@xmb-rcd-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "homenet@ietf.org" Subject: Re: [homenet] longest-match (was: source routing requirements for routing protocols) 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, 29 Jul 2013 19:02:25 -0000 Le 29/07/2013 20:52, Wes Beebee (wbeebee) a �crit : > Longest match specifies that the longest prefix that matches a particular > address should be used in looking up a leaf, and eventually an adjacency > that specifies the L2 rewrite information and outgoing interface in > standard destination lookup forwarding. > > For source/dest lookup, a source lookup is performed and then a dest > lookup based on the source results. For dst-based longest-match there is this concept of "default" route: if longest-match fails then pick the default. Is there such concept with src-bsed longest-match? (if longest match on src fails then pick a default). Which of the 2 defaults would prime over the other? > An example of longest match: > > When matching 1234:5678::1, three routes are found in the routing table: > ::/0 > 1234::/16 > 1234:5678::/32 > > Longest match says 1234:5678::/32 will be chosen. Yes, but this is not specified. Alex > - Wes > > On 7/29/13 1:24 PM, "Alexandru Petrescu" > wrote: > >> Le 29/07/2013 16:32, David Lamparter a �crit : >> [...] >>> RESULT (stop skipping here) ====== >>> >>> The non source specific routes keep working as intended. The source >>> specific routes work as intended, doing a longest-match on the >>> source. >> >> What _is_ longest match in detail? (regardless of src or dst). >> >> Alex >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > From wbeebee@cisco.com Mon Jul 29 12:31:33 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250DD21E80B4 for ; Mon, 29 Jul 2013 12:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3HKTa1CjNgw for ; Mon, 29 Jul 2013 12:31:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7A73811E811E for ; Mon, 29 Jul 2013 12:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=601; q=dns/txt; s=iport; t=1375126182; x=1376335782; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uGfOdYloOd49n0G3vD38iw/BDF60Nzu55FxLbT8pD9A=; b=l3gnogDz+Jm9udoeaPZkK7AoxXD1vnJ/aDNy/xsSYZ0oPdSmZjwhFfc/ elfmEsLwHs1H5zdU2dzvBAVkfOfwtZ1F2+wkVRQHjmrENpDV3b2u3vM8H Bd8dQFz5QfrYe5Uon6SH6jP4EctL2g1VwRQoL4ZAow8CGm2KgduP63LQg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJjB9lGtJXHB/2dsb2JhbABbgwaBBb1hgRoWdIImAQR5EgEIIlYlAgQODYgIuGePSgIxB4MYbwOIcqA5gVuBOYIq X-IronPort-AV: E=Sophos;i="4.89,772,1367971200"; d="scan'208";a="240952152" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2013 19:29:41 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6TJTfhw024080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 19:29:41 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.40]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 14:29:41 -0500 From: "Wes Beebee (wbeebee)" To: Alexandru Petrescu Thread-Topic: [homenet] longest-match (was: source routing requirements for routing protocols) Thread-Index: AQHOjIFGhMVjDeny8UyPZEy5ngf68Zl8ESoAgABF0YD//8S0gA== Date: Mon, 29 Jul 2013 19:29:40 +0000 Message-ID: <9515564336C5B442A00021645539CFCC2AF1E4A2@xmb-rcd-x08.cisco.com> In-Reply-To: <51F6BC21.9060505@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.131.71.105] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3A6A16A0F3A0C24D88CC70402CCB2DA8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] longest-match (was: source routing requirements for routing protocols) 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, 29 Jul 2013 19:31:33 -0000 >For dst-based longest-match there is this concept of "default" route: if >longest-match fails then pick the default. > >Is there such concept with src-bsed longest-match? (if longest match on >src fails then pick a default). > >Which of the 2 defaults would prime over the other? A default route is simply a fancy name for the route with prefix ::/0. With src/dst routing, there is potentially a ::/0 destination prefix that corresponds to each source prefix. There is also potentially a whole destination lookup table that=B9s entirel= y devoted to the ::/0 source prefix. - Wes From teco@inf-net.nl Mon Jul 29 15:29:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BF521F9C99 for ; Mon, 29 Jul 2013 15:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5Mq0R723vdm for ; Mon, 29 Jul 2013 15:28:59 -0700 (PDT) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6A41C21F9C91 for ; Mon, 29 Jul 2013 15:28:58 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id q16so3202583ead.35 for ; Mon, 29 Jul 2013 15:28:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JtBP8I7QxJJRBb/UWuBRpnnmi/wLl1KC+/DuDg5Ck/E=; b=UxVu00eIaoFpTck3cpdy0vF2MKWwB7cPtF6ULIN0nPAgigIXlAZmtyZ9zvADSi4gUn 6diT9KpMj0w3PJRdJsrpaCZ88hvtv9QtOT8hbIC5iN8kvfY0gjfli3x3vFAfHlR59w0y 9LHqEAqGn9y3ZzFsGBQQeT58o9SUBrL3OklNzMIWkKGRXxbANAsgp77SnnOiW3C1S0YT wztp0MkAIbMrI23wuJRnE6lZBvp77nPsyqKCCRv0QhRVn0laeelc7f6/iVeW6sb3xC8n eoEGsXAgy72C+pRuHyFiZt23/qcHmGQPdSK4OcBvdMkNj+0muRfI8y4Lj4WmZDqx1cUD GaXA== X-Received: by 10.14.251.202 with SMTP id b50mr61680598ees.85.1375136937608; Mon, 29 Jul 2013 15:28:57 -0700 (PDT) Received: from [172.30.1.77] (pd95c0bae.dip0.t-ipconnect.de. [217.92.11.174]) by mx.google.com with ESMTPSA id p49sm105279500eeu.2.2013.07.29.15.28.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 15:28:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Teco Boot In-Reply-To: <20130729143209.GL901145@jupiter.n2.diac24.net> Date: Tue, 30 Jul 2013 00:28:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> <20130729143209.GL901145@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnmHnY/BhGU3DmeENHzXWIS0IvE8kZL+QwkQW3Dqgd8u01JR1U4XEfMkGJ83ehlTo4rlsEb Cc: Michael Richardson , "homenet@ietf.org" , Lorenzo Colitti Subject: Re: [homenet] source routing requirements for routing protocols 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, 29 Jul 2013 22:29:05 -0000 Op 29 jul. 2013, om 16:32 heeft David Lamparter het = volgende geschreven: > On Mon, Jul 29, 2013 at 03:35:41PM +0200, Lorenzo Colitti wrote: >> On Mon, Jul 29, 2013 at 1:27 PM, Michael Richardson >> wrote: >>=20 >>> 1) if we are going to introduce a new route to deal with the >>> conflict, then the routing protocol must be able to express >>> what might appear to be multiple routes to the same dest/prefix. >>>=20 >>=20 >> I believe the routes only need to be local and do not need to appear = on the >> wire and in the routing protocol (in fact, they don't even need to be >> stored locally; the draft claims that they can be recalculated when = adding >> / removing real routes from the FIB). >>=20 >> As regards the reason for existence of the routes themselves, David >> Lamparter tells me that he has in fact gotten the Linux IPv6 source = routing >> code (the mythical CONFIG_IPV6_SUBTREES?) to work on 3.8. Attempting = to CC >> a randomly-found email address I have for him so he can comment = directly. >> David? >=20 > (warning: wall of text. skip down to last paragraph for results.) >=20 > I've tested the following setup: >=20 > host A - router > # system: Linux 3.8.3 > # CONFIG_IPV6_SUBTREES=3Dy > # ip utility, iproute2-ss130221 >=20 > # (0) enable ipv6 forwarding (...) >=20 > # (1) set routes >=20 > ip link add name test0 type dummy > ip link add name test1 type dummy > ip link add name test2 type dummy > ip link add name test3 type dummy > ip link set test0 up > ip link set test1 up > ip link set test2 up > ip link set test3 up > ip -6 route add 2001:db8::/32 via fe80::1 dev test0 > ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:1::/64 via = fe80::1 dev test1 > ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:2::/64 via = fe80::1 dev test2 > ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:2::f00d/128 via = fe80::1 dev test3 > ip -6 route add 2001:db8:dead:beef::/64 dev test3 >=20 > # (2) connection to packet source - fix as needed > ip -6 link set veth0 up > ip -6 addr add fe80::1/64 dev veth0 > ip -6 addr add 2001:db8:cafe:0::1/64 dev veth0 > ip -6 addr add 2001:db8:cafe:1::1/64 dev veth0 > ip -6 addr add 2001:db8:cafe:2::1/64 dev veth0 >=20 > # (3) now start 4 tcpdumps/wiresharks/... on test0..3 >=20 >=20 > host B - packet source >=20 > # - interlude: shortcut to virtualise host B, skip if appropriate - > # unshare -n /bin/bash > # you now have a shell in a separate network namespace. now do: > # ip link set lo up > # ip link add name veth0 type veth peer name veth0 netns 1 > # you now have a "veth0" interface on both your host and your network > # namespace shell session. don't forget to set them "up". > # - end interlude - >=20 > # (0) default route over linklocal, persistent over tests > ip -6 route add ::/0 via fe80::1 dev veth0 >=20 > # (1) source 2001:db8:cafe:0::2, does not match sources > ip -6 addr add 2001:db8:cafe:0::2/64 dev veth0 > ping6 -c 3 2001:db8::1 # =3D> test0 on router > ping6 -c 3 2001:db8:dead::1 # =3D> unreachable, no route [*] > ping6 -c 3 2001:db8:dead:beef::1 # =3D> test3 on router > ip -6 addr del 2001:db8:cafe:0::2/64 dev veth0 >=20 > # (2) source 2001:db8:cafe:1::2, matches "test1" source spec > ip -6 addr add 2001:db8:cafe:1::2/64 dev veth0 > ping6 -c 3 2001:db8::1 # =3D> test0 on router > ping6 -c 3 2001:db8:dead::1 # =3D> test1 on router > ping6 -c 3 2001:db8:dead:beef::1 # =3D> test3 on router > ip -6 addr del 2001:db8:cafe:1::2/64 dev veth0 >=20 > # (3) source 2001:db8:cafe:2::2, matches "test1" source spec Typo? Would be:=20 # (3) source 2001:db8:cafe:2::2, matches "test2" source spec > ip -6 addr add 2001:db8:cafe:2::2/64 dev veth0 > ping6 -c 3 2001:db8::1 # =3D> test0 on router > ping6 -c 3 2001:db8:dead::1 # =3D> test2 on router > ping6 -c 3 2001:db8:dead:beef::1 # =3D> test3 on router > ip -6 addr del 2001:db8:cafe:2::2/64 dev veth0 >=20 > # (4) source 2001:db8:cafe:2::2, matches more-specific /128 source Typo? Would be:=20 # (4) source 2001:db8:cafe:2::food, matches more-specific /128 source > ip -6 addr add 2001:db8:cafe:2::f00d/64 dev veth0 > ping6 -c 3 2001:db8::1 # =3D> test0 on router > ping6 -c 3 2001:db8:dead::1 # =3D> test3 on router > ping6 -c 3 2001:db8:dead:beef::1 # =3D> test3 on router > ip -6 addr del 2001:db8:cafe:2::f00d/64 dev veth0 >=20 >=20 > so, for the 2001:db8:dead::1 destination, the following happens: > - source 2001:db8:cafe:0::2 - no source match - icmp unreachable > - source 2001:db8:cafe:1::2 - matches ...1::/64 dev test1 > - source 2001:db8:cafe:2::2 - matches ...2::/64 dev test2 > - source 2001:db8:cafe:2::f00d - matches ...2::f00d/128 dev test3 >=20 >=20 > RESULT (stop skipping here) > =3D=3D=3D=3D=3D=3D >=20 > The non source specific routes keep working as intended. The source > specific routes work as intended, doing a longest-match on the source. > The lookup also is "final", i.e. after not finding a route with a = source > match (=3D> first test case), Linux returns an "unreachable". >=20 > As far as I've been following, this is the desired effect? Al least it looks the right route :-) Teco >=20 > Cheers, >=20 >=20 > -David > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Mon Jul 29 23:01:38 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CDC11E81B7 for ; Mon, 29 Jul 2013 23:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdFMN3tU+QLl for ; Mon, 29 Jul 2013 23:01:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 3C18B21F9FD1 for ; Mon, 29 Jul 2013 23:01:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 37E602017B; Tue, 30 Jul 2013 03:07:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1169063A7C; Tue, 30 Jul 2013 02:00:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EECCC63A5E; Tue, 30 Jul 2013 02:00:04 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek In-Reply-To: <87y58pgtiq.wl%jch@pps.univ-paris-diderot.fr> References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> <87y58pgtiq.wl%jch@pps.univ-paris-diderot.fr> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] source routing requirements for routing protocols 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, 30 Jul 2013 06:01:39 -0000 --=-=-= Juliusz Chroboczek wrote: >> 2) while we might agree that the destination wins, so that we have >> a consistent routing table across the homenet, the routing protocol >> should have a way for a router to say, "yes, but I see a conflict" >> such that someone or something can say, "oh. Well, I shall insert a >> disambiguation route. > I don't think that's necessary -- what issue are you trying to solve? Different routers might have different sources of routing information. While the OSPF/BABEL/insert-new-one routes might be identical, a given specific router might have other routes from other places (RPL, VPNs, etc.) which would cause *it* to insert dis-ambiguation routes that other routes would not see a reason for. I think that I'd like all routers to be consistent. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUfdWYoqHRg3pndX9AQK1gAP+LrlH3vJ3Odc3LL7BKmXG/0yqb4kWkQAx aFwQEpQVr/1ns6Cz6tklMWp2FluIhMCxh8v3kNJ+nQBv+Who0+CYgwog882yGZug fshSxq4hYXg0Rcide/2RJjcY5TjfYA39T5wrdc/ZgQJGI5RslrSdgvVa8IT4NNB8 +wvAv4hoFFc= =Q0Yn -----END PGP SIGNATURE----- --=-=-=-- From C.Grundemann@cablelabs.com Wed Jul 31 05:02:34 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E099B21F8493 for ; Wed, 31 Jul 2013 05:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 0f0XFXKbAyJi for ; Wed, 31 Jul 2013 05:02:24 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B83F411E8172 for ; Wed, 31 Jul 2013 05:01:46 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r6VC1htX009188; Wed, 31 Jul 2013 06:01:43 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 31 Jul 2013 06:01:43 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Wed, 31 Jul 2013 06:01:43 -0600 From: Chris Grundemann To: Michael Richardson , "homenet@ietf.org" Thread-Topic: [homenet] how to avoid getting stuck at Medius: additional DHCPv6 (PD) options needed? Thread-Index: AQHOjeW4Zv0DX8i4EUOSqVwDB4wDpg== Date: Wed, 31 Jul 2013 12:01:42 +0000 Message-ID: In-Reply-To: <6856.1375095717@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Approved: ondar Subject: Re: [homenet] how to avoid getting stuck at Medius: additional DHCPv6 (PD) options needed? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:02:34 -0000 VGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgTWljaGFlbCwNCg0KT24gMjkvSnVsLzEzIDEzOjAxIEdN VCswMjowMCwgIk1pY2hhZWwgUmljaGFyZHNvbiIgPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NCndy b3RlOg0KDQo+DQo+MSkgSSB3b3VsZCBhc2sgdGhlIENhYmxlTGFicyBndXlzIHRvIG1vcmUgY2xl YXJseSBhcnRpY3VsYXRlIHdoYXQNCj4gICB0aGVpciB0aW1lbGluZSBpcywgYW5kIHdoYXQgZmVh dHVyZXMgYXJlIHJlYWxseSBpbiB0aGF0IHRpbWVsaW5lLg0KPiAgIChJdCBzZWVtcyB0byBtZSB0 aGF0IHdlIGNvdWxkIGJlIGRvbmUgYWxyZWFkeSBpZiB0aGUgSVNQcyBwdXNoZWQNCj4gICB0aGVp ciBzdXBwbGllcnMgb2YgQ1BFIGRldmljZXMgdG8gam9pbiB0aGUgaG9tZW5ldCBXRyBhbmQgcGFy dGljaXBhdGUsDQo+ICAgYW5kL29yIGhpcmVkIHByb3hpZXMgYW5kL29yIG9wZW4tc291cmNlIGF1 dGhvcnMgdG8gYWN0IGFzDQo+ICAgaW50ZXJtZWRpYXJpZXMvY29uc3VsdGFudHMuIEkgcmVhbGl6 ZSB0aGF0IHRvIGZpcnN0IG9yZGVyLCBDYWJsZUxhYnMNCj4gICAqaXMqIGZ1bGxmdWxsaW5nIHNv bWUgb2YgdGhhdCBleGFjdCByb2xlKQ0KDQpUaGUgdGltZWxpbmUgd2UgYXJlIHdvcmtpbmcgZnJv bSBpcyBBU0FQOyBub3QgaGF2aW5nIGZ1bGx5IGZ1bmN0aW9uYWwgSVB2Ng0KY2FwYWJsZSBob21l IHJvdXRlcnMgaXMgY3VycmVudGx5IGEgc2lnbmlmaWNhbnQgaHVyZGxlIHRvIHJlYWwgSVB2Ng0K YWRvcHRpb24gaW4gcmVzaWRlbnRpYWwgYnJvYWRiYW5kIG5ldHdvcmtzLg0KDQpUaGUga2V5IGZl YXR1cmVzIChmcm9tIG15IHBlcnNwZWN0aXZlKSBhcmUgdmVyeSBtdWNoIGluIGxpbmUgd2l0aCB0 aGUNCmhvbWVuZXQgYXJjaGl0ZWN0dXJlIGRvY3VtZW50cyBzdGF0ZWQgcHJpbmNpcGxlcywgbmFt ZWx5IGJhc2ljIG5ldHdvcmsNCmRldGVjdGlvbiAod2hlcmUncyB0aGUgSW50ZXJuZXQpLCBhZGRy ZXNzaW5nIG9mIGJvdGggZW5kLWNsaWVudHMgYW5kDQptdWx0aXBsZSBob21lIHJvdXRlcnMsIHJv dXRpbmcgYmV0d2VlbiBpbi1ob21lIENQRSAoSVB2NCBhbmQgSVB2NiksDQpyb3V0aW5nIGZyb20g aW4taG9tZSBDUEUgdG8gdGhlIEludGVybmV0IChJUHY0IHcvIE5BVCBhbmQgSVB2NiksIGluLWhv bWUNCm11bHRpY2FzdCBmb3J3YXJkaW5nIChwcmltYXJpbHkgaW4gc3VwcG9ydCBvZiBleGlzdGlu ZyBzZXJ2aWNlIGRpc2NvdmVyeQ0KcHJvdG9jb2xzKSwgYW5kIGJhc2ljIGZpcmUgd2FsbGluZyAo c2ltcGxlIHNlY3VyaXR5KSBvbiB0aGUgQ0VSLg0KDQpXaXRoaW4gdGhlIENhYmxlTGFicyAiZWNv c3lzdGVtIiB3ZSBhcmUgYWJzb2x1dGVseSB3b3JraW5nIHdpdGggc3VwcGxpZXJzDQphbmQgaGF2 ZSBpbmNsdWRlZCBhbGwgb2YgdGhlIGFib3ZlIGtleSBmZWF0dXJlcyBpbiB0aGUgZVJvdXRlcg0K c3BlY2lmaWNhdGlvbjogDQpodHRwczovL3d3dy5jYWJsZWxhYnMuY29tL2RvY3pvbmUvZG9jc2lz L3JlcXVpcmVtZW50cy9zcGVjcy9jdXJyZW50L2lzc3VlZC8NCmVyb3V0ZXIvRG9jWm9uZUZvbGRl cl92aWV3ICh0aGUgbm90YWJsZSBleGNlcHRpb24gaXMgZWRnZSBkZXRlY3Rpb24sIGFzIHdlDQpj dXJyZW50bHkgcmVseSBvbiB0aGUgaW5jbHVzaW9uIG9mIGEgQ2FibGUgTW9kZW0gKENNKSBhcyBp bmRpY2F0aW9uIG9mDQp3aGVyZSB0aGUvYW4gSVNQIGlzIGNvbm5lY3RlZCB0byB0aGUgSElQbmV0 KS4gVGhlIEhJUG5ldCBkcmFmdA0KKGRyYWZ0LWdydW5kZW1hbm4taGlwbmV0KSBpcyBvdXIgZWZm b3J0IHRvIHNoYXJlIHdoYXQgd2UgaGF2ZSBhbHJlYWR5DQpjb21wbGV0ZWQgd2l0aCB0aGUgd2lk ZXIgSUVURiBhdWRpZW5jZS4NCg0KPjIpIElmIGl0IGlzIGluZGVlZCB0aGUgY2FzZSB0aGF0IHRo ZSBNZWRpdXMgbmV0d29yayByZXF1aXJlcyBoaWVyYXJjaGljYWwNCj4gICBESENQdjYgUEQsIEkg d291bGQgbGlrZSB0byBzdWdnZXN0IHRoYXQgd2UgYWRkIHNvbWUgYWRkaXRpb25hbCBESENQDQo+ ICAgb3B0aW9ucyB0byB0aGlzIHNvIHRoYXQgdGhlIGludGVybmFsIHJvdXRlcnMgZXhwbGljaXRl bHkga25vdyB0aGF0IHRoZXkNCj4gICBhcmUgaW50ZXJuYWwgcm91dGVycywgYW5kIGZ1cnRoZXIs IHRoYXQgdGhlIGFiaWxpdHkgb2YgdGhlIHJvdXRlcnMgdG8NCj4gICBnbyB0byBmdWxsIGhvbWVu ZXQgaXMgbW9yZSBjbGVhcmx5IGFydGljdWxhdGVkLg0KDQpUaGUgSElQbmV0IHNvbHV0aW9uIGlz IHZlcnkgbXVjaCBmb2N1c2VkIG9uIHByb3ZpZGluZyBhIHNvbHV0aW9uIHRoYXQgaXMNCmFjdHVh bGx5IGltcGxhbnRhYmxlIHRvZGF5LCBhIGxhcmdlIHBhcnQgb2YgdGhhdCBpcyBub3QgYWRkaW5n IG5ldw0KcHJvdG9jb2xzIGFuZCBub3QgY2hhbmdpbmcgZXhpc3RpbmcgcHJvdG9jb2xzIHVubGVz cyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS4NCldlIGRpZCBpbmNsdWRlIHdoYXQgd2UgYXJlIGNhbGxp bmcgYSAiLzQ4IGNoZWNrIg0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncnVu ZGVtYW5uLWhpcG5ldC0wMCNzZWN0aW9uLTQuMSkgaW4NCnRoZSBISVBuZXQgZHJhZnQgdG8gYWxs b3cgSVJzIHRvIGRldGVybWluZSB0aGF0IHRoZXkgYXJlIElScyB3aXRob3V0DQpoYXZpbmcgdG8g Y3JlYXRlIGEgbmV3IGNvbW11bmljYXRpb24gcHJvdG9jb2wgKG9yIHVwZGF0ZSBhbiBleGlzdGlu ZyBvbmUpLg0KDQpDaGVlcnMsDQp+Q2hyaXMNCg0KPi0tDQo+XSAgICAgICAgICAgICAgIE5ldmVy IHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaA0KPm5ldHdvcmtz IFsNCj5dICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgICAg ICAgIHwgbmV0d29yaw0KPmFyY2hpdGVjdCAgWw0KPl0gICAgIG1jckBzYW5kZWxtYW4uY2EgIGh0 dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMNCj4gICBbDQo+ DQo+DQo+DQo+DQo+LS0NCj5NaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5j YT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPg0KPg0KDQo= From C.Grundemann@cablelabs.com Wed Jul 31 05:04:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D5B21F9A81 for ; Wed, 31 Jul 2013 05:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 kszPujVLFPcS for ; Wed, 31 Jul 2013 05:04:25 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 592CA21F9A3B for ; Wed, 31 Jul 2013 05:04:25 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r6VC4NSQ009490; Wed, 31 Jul 2013 06:04:24 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 31 Jul 2013 06:04:23 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Wed, 31 Jul 2013 06:04:23 -0600 From: Chris Grundemann To: Lorenzo Colitti , Michael Richardson Thread-Topic: [homenet] the problem of two DHCPv6 servers on the same link Thread-Index: AQHOecNs9xwgc98cvEy4gAFtaWNuU5lXU76AgCgLCQA= Date: Wed, 31 Jul 2013 12:04:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="utf-8" Content-ID: <14B83B3E5BD8144781047F0AD0C7945D@cablelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Approved: ondar Cc: "homenet@ietf.org" Subject: Re: [homenet] the problem of two DHCPv6 servers on the same link X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:04:30 -0000 T24gNS9KdWwvMTMgMjA6MzQgR01UKzAyOjAwLCAiTG9yZW56byBDb2xpdHRpIiA8bG9yZW56b0Bn b29nbGUuY29tPiB3cm90ZToNCg0KPk9uIFNhdCwgSnVsIDYsIDIwMTMgYXQgNjowNCBBTSwgTWlj aGFlbCBSaWNoYXJkc29uDQo+PG1jcitpZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+DQo+RG9l cyB0aGUgREhDUHY2IHNwZWMgd2hhdCBhIGhvc3QgaXMgc3VwcG9zZWQgdG8gZG8gaWYgaXQgZ2V0 cyB0d28gYW5zd2Vycw0KPndoZW4gaXQgZG9lcyBESENQdjY/DQo+DQo+DQo+DQo+DQo+SSBiZWxp ZXZlIHBlciBzcGVjIGl0IG11c3QgcGljayBvbmUgb2YgdGhlIG9mZmVycyBpdCByZWNlaXZlcy4N Cj5UZWNobmljYWxseSwgaXQncyBub3QgZm9yYmlkZGVuIGZyb20gaW5pdGlhdGluZyBhICpzZWNv bmQqIERIQ1B2Ng0KPnRyYW5zYWN0aW9uIHdoZXJlIGl0IGNhbiBwaWNrIGFub3RoZXIgcmVzdWx0 IGluIGFkZGl0aW9uIHRvIHRoZSBvbmUgaXQNCj5hbHJlYWR5IGhhcywgYnV0IEkgYmVsaWV2ZSBu byBpbXBsZW1lbnRhdGlvbiBkb2VzIHRoaXMuDQo+DQo+DQo+W09uZSBvZiB0aGUgbWFueSByZWFz b25zIHdoeSBESENQdjYgaXMgbm90IGEgZ29vZCBmaXQgZm9yIGxvb3NlbHktbWFuYWdlZA0KPmhv bWUgbmV0d29ya3MgbGlrZSBob21lbmV0Ll0NCg0KSGkgTG9yZW56bywNCg0KUGFyZG9uIG15IGln bm9yYW5jZSwgYnV0IHdoeSBpcyB0aGlzIChjYW4geW91IGV4cG91bmQgYSBiaXQpPyBJIHRoaW5r IEknbQ0KbWlzc2luZyBzb21ldGhpbmcgaGVyZS4uLg0KDQpQUyAtIEFwb2xvZ2llcyBmb3IgdGhl IGxhdGVudCByZXBseSwgSSBtaXNzZWQgdGhpcyBtZXNzYWdlIHdoZW4gaXQgZmlyc3QNCmNhbWUg YWNyb3NzLg0KDQpDaGVlcnMsDQp+Q2hyaXMNCg0KPg0KPg0KPg0KDQo= From lorenzo@google.com Wed Jul 31 05:38:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47E811E817E for ; Wed, 31 Jul 2013 05:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zWjBMF1Af8t for ; Wed, 31 Jul 2013 05:38:27 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C72EA11E81B3 for ; Wed, 31 Jul 2013 05:35:41 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so1230338obb.1 for ; Wed, 31 Jul 2013 05:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a1tocZ9oWylTE5g5na9tNgS0lMkf9575C87PQvgIn1c=; b=Oc0jwqpfdMbUZoYTeY+olaX5ucbfHFhqQG8IDgvxomwKRkRBSyXH3jLoK9bhjwoWM6 jKuyAdIIswku9po48NPqu87/1+vsTMi8z2+XilcU7Nfji4W0dBnq9vUiREEteA9jzjtc Rs/tgPMr/MelN3etGfsHpfIn6hd5Q04TrfOgRw5S9ghT2XKU7rVTQgbW/Ie2jPPY538Q gewtib3n+VLkoxcTSW7537PIt3waR5FrOLp3QC3gI/a7/XsXvFZ0iSud6OoBxw+0PPQK MNOANvU1JJhV7HNhhLTHFlH4u/LC00U9aj1JzychCAOAyOyJjz2vA2P8eDHdHBZgMNQ6 m0Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=a1tocZ9oWylTE5g5na9tNgS0lMkf9575C87PQvgIn1c=; b=DfaALUk/WrC7av60/4lJ+PlCNEkvsIHULNqmY2kOs4eWUooziqws7HRTQoDftl/1YY ewbJscpmkhzyEP/yJf7AaVfmpYRF4L+yPI2xCXnK97eRfWU7JHu6rbOkcExgxkR29gBv ETA5dstaYTid7VE52tKRdS9IQ9v80JT0dc8UNHxxfU35qY0wAuiGbYdzdrJxD2O4sPNh zrlGmk562JimfzL3IhKo9tgD4YEpZEsAKwBI3sNtmYPdj9nZDj1M8QIzyz4NwS1z29mU aGj68koWT9AW53FdxE+k5bHwwVYtSw9lziW5Gt8XgAUoUl8+CbVsU/yQClfDzxeXujWL gvAA== X-Received: by 10.50.18.5 with SMTP id s5mr692942igd.6.1375274124803; Wed, 31 Jul 2013 05:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Wed, 31 Jul 2013 05:35:04 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 31 Jul 2013 14:35:04 +0200 Message-ID: To: Chris Grundemann Content-Type: multipart/alternative; boundary=089e013cc1c4adae7804e2cdf5bc X-Gm-Message-State: ALoCoQn+oNSFCZx4Nze9QuiGjweLSYsfkWvJ8k9VJLw7FSvrMCyi0jCIf4UIqu/XkfALsZQxYmvolP5TuNR0kTnbwB/0rfxWxuGHg4kUJAtMGqsMQrDzsoNhgXBSUdqJ6GP0LsbDJ5PFVlNITZ6rXk07qV/8hc5MZRQLFAZnUkPu7ksxLzDxXLunXOsQrPqlzcgNl5HeuB6Q Cc: Michael Richardson , "homenet@ietf.org" Subject: Re: [homenet] the problem of two DHCPv6 servers on the same link X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:38:27 -0000 --089e013cc1c4adae7804e2cdf5bc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 31, 2013 at 2:04 PM, Chris Grundemann < C.Grundemann@cablelabs.com> wrote: > >I believe per spec it must pick one of the offers it receives. > >Technically, it's not forbidden from initiating a *second* DHCPv6 > >transaction where it can pick another result in addition to the one it > >already has, but I believe no implementation does this. > > > > > >[One of the many reasons why DHCPv6 is not a good fit for loosely-managed > >home networks like homenet.] > > Hi Lorenzo, > > Pardon my ignorance, but why is this (can you expound a bit)? I think I'm > missing something here... > Examples: - It only supports choosing one lease in a given transaction, and not merging multiple sources of information (i.e., the problem mentioned above). - It's not suited to supporting arbitrary topologies because it only supports one-directional leases, from up to down. - It's not suited to supporting dynamic topologies. Information received via DHCP is hard to change. It requires that the client support dynamic reconfiguration, and even that doesn't work if the DHCPv6 server crashes or is unplugged. It's likely that the above can be worked around with varying degrees of hackiness and reliability, but the end result is likely to remain hacky and unreliable. Cheers, Lorenzo --089e013cc1c4adae7804e2cdf5bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 31, 2013 at 2:04 PM, Chris Grundemann <C.Grundemann@cablelabs.com> wrote:

>I believe per spec it must pick one of the offers it receives.
>Technically, it's not forbidden from initiating a *second* DHCPv6 >transaction where it can pick another result in addition to the one it<= br> >already has, but I believe no implementation does this.
>
>
>[One of the many reasons why DHCPv6 is not a good fit for loosely-manag= ed
>home networks like homenet.]

Hi Lorenzo,

Pardon my ignorance, but why is this (can you expound a bit)? I think I'= ;m
missing something here...

Examples:

It only supports choosing one lease in a given transact= ion, and not merging multiple sources of information (i.e., the problem men= tioned above).
It's not suited to supporting arbitrary topologies because it only = supports one-directional leases, from up to down.
It's not suit= ed to supporting dynamic topologies. Information received via DHCP is hard = to change. It requires that the client support dynamic reconfiguration, and= even that doesn't work if the DHCPv6 server crashes or is unplugged.

It's likely that the above can be worked around with varying= degrees of hackiness and reliability, but the end result is likely to rema= in hacky and unreliable.

Cheers,

Lorenzo=

--089e013cc1c4adae7804e2cdf5bc-- From C.Grundemann@cablelabs.com Wed Jul 31 06:29:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A130B21F9298 for ; Wed, 31 Jul 2013 06:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 20aq7QhGgKJd for ; Wed, 31 Jul 2013 06:29:18 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8082321F9D44 for ; Wed, 31 Jul 2013 06:29:18 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r6VDTE3c018754; Wed, 31 Jul 2013 07:29:14 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 31 Jul 2013 07:29:14 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Wed, 31 Jul 2013 07:29:14 -0600 From: Chris Grundemann To: Lorenzo Colitti Thread-Topic: DHCP considerations [was: Re: [homenet] the problem of two DHCPv6 servers on the same link] Thread-Index: AQHOjfHyzOnysrQpr0W5/uxiLNBEMg== Date: Wed, 31 Jul 2013 13:29:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="utf-8" Content-ID: <67DB569242F49B459D1973F75BFAE617@cablelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Approved: ondar Cc: "homenet@ietf.org" Subject: [homenet] DHCP considerations [was: Re: the problem of two DHCPv6 servers on the same link] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:29:22 -0000 T24gMzEvSnVsLzEzIDE0OjM1IEdNVCswMjowMCwgIkxvcmVuem8gQ29saXR0aSIgPGxvcmVuem9A Z29vZ2xlLmNvbT4gd3JvdGU6DQoNCj5FeGFtcGxlczoNCg0KVGhhbmtzISBJIGFzc3VtZSB3ZSBk aXNhZ3JlZSwgYnV0IG15IHF1aWNrIHRob3VnaHRzIGFueXdheToNCg0KPiogSXQgb25seSBzdXBw b3J0cyBjaG9vc2luZyBvbmUgbGVhc2UgaW4gYSBnaXZlbiB0cmFuc2FjdGlvbiwgYW5kIG5vdA0K Pm1lcmdpbmcgbXVsdGlwbGUgc291cmNlcyBvZiBpbmZvcm1hdGlvbiAoaS5lLiwgdGhlIHByb2Js ZW0gbWVudGlvbmVkDQo+YWJvdmUpLg0KDQpUaGF0J3MgYWN0dWFsbHkgYSBmZWF0dXJlIGZvciBI SVBuZXQsIG5vdCBhIGJ1Zy4gSW4gdGhlIGNhc2Ugd2hlcmUgYSBDUEUNCmlzIGNvbm5lY3RlZCB0 byB0d28gKG9yIG1vcmUpIEhJUG5ldCByb3V0ZXJzIChkdWUgdG8gYXJiaXRyYXJ5IHRvcG9sb2d5 KSwNCml0IHVzZXMgb25seSBvbmUuIEZvciB0aGUgcm91dGVycyB0aGVtc2VsdmVzLCB3ZSB1c2Ug dGhlICJMaW5rIElEIg0KYXBwcm9hY2ggdG8gcm91dGUgbXVsdGlwbGUgZGlzdGluY3QgcHJlZml4 ZXMgaW4gdGhlIGhvbWUNCihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3J1bmRl bWFubi1oaXBuZXQtMDAjc2VjdGlvbi01LjMpIC0gWW91DQptaWdodCBjYWxsIHRoaXMgYSBoYWNr LCBJIHRoaW5rIGl0J3MgYSByZWxpYWJsZSwgYW5kIGV4dGVuc2libGUsIHNvbHV0aW9uLg0KDQo+ KiBJdCdzIG5vdCBzdWl0ZWQgdG8gc3VwcG9ydGluZyBhcmJpdHJhcnkgdG9wb2xvZ2llcyBiZWNh dXNlIGl0IG9ubHkNCj5zdXBwb3J0cyBvbmUtZGlyZWN0aW9uYWwgbGVhc2VzLCBmcm9tIHVwIHRv IGRvd24uDQoNCldoZW4gY29tYmluZWQgd2l0aCAidXAgZGV0ZWN0aW9uIiAodGhlIGxhY2sgb2Yg YW4gYXJiaXRyYXJ5ICJJbnRlcm5ldC9XQU4iDQpwb3J0LCBlLmc6IA0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdydW5kZW1hbm4taGlwbmV0LTAwI3NlY3Rpb24tNC4yKSB0bw0K cmVkdWNlIGFueS9hbGwgYXJiaXRyYXJ5IHRvcG9sb2d5IHRvIGEgaGllcmFyY2h5IChldmVuIGlm IG9ubHkgZm9yIGFkZHJlc3MNCnByb3Zpc2lvbmluZykgSSBkb24ndCBzZWUgdGhpcyBhcyBhIHBy b2JsZW0uDQoNCj4qIEl0J3Mgbm90IHN1aXRlZCB0byBzdXBwb3J0aW5nIGR5bmFtaWMgdG9wb2xv Z2llcy4gSW5mb3JtYXRpb24gcmVjZWl2ZWQNCj52aWEgREhDUCBpcyBoYXJkIHRvIGNoYW5nZS4g SXQgcmVxdWlyZXMgdGhhdCB0aGUgY2xpZW50IHN1cHBvcnQgZHluYW1pYw0KPnJlY29uZmlndXJh dGlvbiwgYW5kIGV2ZW4gdGhhdCBkb2Vzbid0IHdvcmsgaWYgdGhlIERIQ1B2NiBzZXJ2ZXIgY3Jh c2hlcw0KPm9yIGlzIHVucGx1Z2dlZC4NCg0KVHJ1ZSwgYnV0IHdoYXQgcGVyY2VudGFnZSBvZiBh Y3R1YWwgcmVzaWRlbnRpYWwgYnJvYWRiYW5kIChvciBldmVuIFNPSE8pDQpzdWJzY3JpYmVycyBh cmUgY2hhbmdpbmcgdGhlaXIgbmV0d29yayB0b3BvbG9neSAoZnJvbSBhIHJvdXRlciwgbm90IGNs aWVudA0KZGV2aWNlLCBwZXJzcGVjdGl2ZSkgYW55d2hlcmUgbmVhciBvZnRlbj8gSSBiZWxpZXZl IHRoZSBhbnN3ZXIgaXMgdmVyeQ0Kc21hbGwuIE1vc3QgaG9tZSBuZXR3b3JrcyBhcmUgYnVpbHQg YW5kIHF1aWNrbHkgZm9yZ290dGVuIGluIG15DQpleHBlcmllbmNlLCBvZnRlbiBmb3IgeWVhcnMg KGFkZGluZyBhIG5ldyByb3V0ZXIgaXMgbm90IGEgcHJvYmxlbSB3aXRoDQpISVBuZXQncyB1c2Ug b2YgREhDUCkuDQoNCj5JdCdzIGxpa2VseSB0aGF0IHRoZSBhYm92ZSBjYW4gYmUgd29ya2VkIGFy b3VuZCB3aXRoIHZhcnlpbmcgZGVncmVlcyBvZg0KPmhhY2tpbmVzcyBhbmQgcmVsaWFiaWxpdHks IGJ1dCB0aGUgZW5kIHJlc3VsdCBpcyBsaWtlbHkgdG8gcmVtYWluIGhhY2t5DQo+YW5kIHVucmVs aWFibGUuDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCB5b3VyIGZlZWRi YWNrIGlzIGFsd2F5cyB2ZXJ5IGhlbHBmdWwuDQoNCkNoZWVycywNCn5DaHJpcw0KDQo+Q2hlZXJz LA0KPkxvcmVuem8NCj4NCj4NCj4NCg0K From lorenzo@google.com Wed Jul 31 06:32:28 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A48821F9E9E for ; Wed, 31 Jul 2013 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU-H8PoGyyZv for ; Wed, 31 Jul 2013 06:32:27 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id A08B621F9E99 for ; Wed, 31 Jul 2013 06:32:27 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so1498632oag.14 for ; Wed, 31 Jul 2013 06:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=clxpNnZJhMr4Hann/7k8Sg7I/4VHvsSexrBkrYRNJ90=; b=Auf6waZTMBq6Xz2+6Z+7VoX+o/GoZ3o10qHHDh59Fs/zA5w+WvDTIakvSR5AlaRibu ZLwqwwu3zQsnOIwO1MgbE0btZ7nQWachHgL6qkRLJxErnOcjrss5USIBK0DiI0fhiKHt Gg5HoLY141gqj9/y9onW9Auft3eHsi0+1jaEhZ8+Zv0/bTXFnARIAS4dd9PB5PZOJr7T YkhtZsR90cvIfYSbevPsZvtxnDVDUv4OQvSSODzeKverGTX1bYcSDiCo1cjc9eyqxsdD rh0n0AnQUGOn1vmsU0PTCzCdWJOz3jSfEYk1cYgOaISLlOvD7Oj/b4VqCAYXEZL1MPSQ +Fhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=clxpNnZJhMr4Hann/7k8Sg7I/4VHvsSexrBkrYRNJ90=; b=l5wSDzVDprXezZ/ccg2S36NT4u/wlU1zQZGr72crto2s75BTQFdK8AO6ans1mo5vHq 12TiPrrYnj2sk3VZJfJnCg1ceSxNrqS8nxvTMdWutES3cjqldgyKvF55mrapIrkMgRDJ jIChYMospKINdJHahzpcpOrbvP33Cpb3dCs+2ah5gYOP/zvsoQpkN1JjZmRyo4AqruMj M9sgSxrTcCkAasuqRr2y0fNV6n0JE+/sfHTKe2GE43zLp4ePEy3JdMlE636hOfYveka/ DCQWiw6KsKv7AtIoSVIiycavmz3F4/x1qrG8AxnxqKt/axizmTFwyDiQ9ILM7zkaJe6l TpHQ== X-Received: by 10.50.119.42 with SMTP id kr10mr706386igb.20.1375277546888; Wed, 31 Jul 2013 06:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Wed, 31 Jul 2013 06:32:06 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 31 Jul 2013 15:32:06 +0200 Message-ID: To: Chris Grundemann Content-Type: multipart/alternative; boundary=089e013c64aaa69b2804e2cec1ab X-Gm-Message-State: ALoCoQmT0g8xdVZ9KUPKXEqJuyRd2XaX90r4VHFG2xds96AWKC94/Lly0gonYEIXdwBlU+FXB73+uLhoFFrIBPpbfQJIkPlaodsDDte4L4YIS9ObolUOe6v1fYVdwjxcmn1/pBUXc1kfMx1YBuO/3/fs0qC1Y6+V2JWJfY5rBQjiVjgOtHgI6yeXVHNbvW9qEGyH1gWn2QF8 Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP considerations [was: Re: the problem of two DHCPv6 servers on the same link] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:32:28 -0000 --089e013c64aaa69b2804e2cec1ab Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 31, 2013 at 3:29 PM, Chris Grundemann < C.Grundemann@cablelabs.com> wrote: > Thanks! I assume we disagree, but my quick thoughts anyway: > Yes, and I thought we had already had this conversation before. --089e013c64aaa69b2804e2cec1ab Content-Type: text/html; charset=ISO-8859-1

On Wed, Jul 31, 2013 at 3:29 PM, Chris Grundemann <C.Grundemann@cablelabs.com> wrote:

Thanks! I assume we disagree, but my quick thoughts anyway:

Yes, and I thought we had already had this conversation before.

--089e013c64aaa69b2804e2cec1ab-- From lorenzo@google.com Wed Jul 31 06:37:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC221E804B for ; Wed, 31 Jul 2013 06:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI1YnuL5Owbh for ; Wed, 31 Jul 2013 06:37:24 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 141AC11E8170 for ; Wed, 31 Jul 2013 06:37:22 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so1362420obb.30 for ; Wed, 31 Jul 2013 06:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QTX+b0lshukUZy+cawxF9i8hbGlneJwbowx4x9oMCoE=; b=ZNduYUR/FZIyuu6F2sAoLzShqrl9iDxmJadxeeCcfGDi47BFks4ylHL1eKPdKQXXbc 9WGAxIeobV29q8Xn0FeHv/Y/zfh2WVu0egM+iPFKjQreQ8tnZ85K3L0RfH4jbjucLSP6 oI40MskV9vdOkF/jtrd6xxj9sgXdJXkcjG+qTBnxHELO4KfyUeLZqNExJnynV7CAvNGG dvM5img5NGCY/jcEo8EcfHs++avNdgvdlqcIR8mt5LUUCIm6TjxS2onneuDG/Jsk5lS5 lhOjSBIXsOTr0k0NOlub0r76tUxHZO8Gm3zA5aFhuBOBqdJFrh4bxQwOEHujJlCQYqc5 opEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=QTX+b0lshukUZy+cawxF9i8hbGlneJwbowx4x9oMCoE=; b=m8HJno0OBTLuYS1LlSl/6TIGDcmc4L8/wcwhD5UVnAx/CXNDLcYyc45HBcZgDWZ/dU 2A0RrFmEwokyAocrBR2QD6dUEeyIHBkCbHY3ZswR2EnVUW+GnWEWninHW9aiWc5EfwwT hzFCiUMeCcNYx2dVb6l1ph+1zw3RuWDfW7qpizqEHOmjRidy9I+yNKRM8anS5o3o0rCG 00fsDECgLBtqgCQwnd+9CCJMTv3u3xRxXkGTr8pPEcqCEIgzIDDS7DfJkB7NGkA8sBCr FSMIyJERMHEaumvGAhexZC5gw5IBQ61pZ5+rNAdvVyFGZPU1uduwhHmjXeTbs+kSzQcm SM2Q== X-Received: by 10.50.126.74 with SMTP id mw10mr711759igb.20.1375277841537; Wed, 31 Jul 2013 06:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Wed, 31 Jul 2013 06:37:01 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 31 Jul 2013 15:37:01 +0200 Message-ID: To: Chris Grundemann Content-Type: multipart/alternative; boundary=047d7b41417636a1e204e2ced3c9 X-Gm-Message-State: ALoCoQkWESPdHFPcCLDMpTiZUr7zyB6HrEcD2PKYYRxxzbxMFA7KDEFFkibohZt/q6w7Mr5nT9luf18W8oF8lTpCXPrhUERfHARZRALEaFUWGdyQ/64yfoWRX/cy5Ksoegra6AkNjOtUp0DIdSJDlKP+E1OWy94SvVqN8eMs1w1fLFUYo0N/RYZaQTb21GaoNwNgRzqrnD3C Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP considerations [was: Re: the problem of two DHCPv6 servers on the same link] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:37:25 -0000 --047d7b41417636a1e204e2ced3c9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 31, 2013 at 3:32 PM, Lorenzo Colitti wrote: > >> Thanks! I assume we disagree, but my quick thoughts anyway: >> > > Yes, and I thought we had already had this conversation before. > To expand on that: I thought your question was about general usage of DHCP in the homenet. I didn't think you wanted to comment on how hipnet attempts to solves those problems and how well it succeeds; we've already had that conversation before (e.g., at the homenet session in IETF 86) and if the documents have not changed since then, then there's likely not much point in having it again. --047d7b41417636a1e204e2ced3c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 31, 2013 at 3:32 PM, Lorenzo Colitti <lorenz= o@google.com> wrote:

=

Thanks! I assume we disagree, but my quick thoughts anyway:

Yes, and I thought we had already had this conversation before.
=

To expand on that: I thought y= our question was about general usage of DHCP in the homenet. I didn't t= hink you wanted to comment on how hipnet attempts to solves those problems = and how well it succeeds; we've already had that conversation before (e= .g., at the homenet session in IETF 86) and if the documents have not chang= ed since then, then there's likely not much point in having it again.

--047d7b41417636a1e204e2ced3c9-- From C.Grundemann@cablelabs.com Wed Jul 31 06:42:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900FA11E8178 for ; Wed, 31 Jul 2013 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 avcFYO0qT2wQ for ; Wed, 31 Jul 2013 06:42:05 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 61C3D21F87BB for ; Wed, 31 Jul 2013 06:42:05 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r6VDg2KR020186; Wed, 31 Jul 2013 07:42:02 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 31 Jul 2013 07:42:02 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Wed, 31 Jul 2013 07:42:02 -0600 From: Chris Grundemann To: Lorenzo Colitti Thread-Topic: DHCP considerations [was: Re: [homenet] the problem of two DHCPv6 servers on the same link] Thread-Index: AQHOjfHyzOnysrQpr0W5/uxiLNBEMpl/LWMAgAAkTYA= Date: Wed, 31 Jul 2013 13:42:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Approved: ondar Cc: "homenet@ietf.org" Subject: Re: [homenet] DHCP considerations [was: Re: the problem of two DHCPv6 servers on the same link] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:42:10 -0000 DQoNCk9uIDMxL0p1bC8xMyAxNTozMiBHTVQrMDI6MDAsICJMb3JlbnpvIENvbGl0dGkiIDxsb3Jl bnpvQGdvb2dsZS5jb20+IHdyb3RlOg0KPg0KPlllcywgYW5kIEkgdGhvdWdodCB3ZSBoYWQgYWxy ZWFkeSBoYWQgdGhpcyBjb252ZXJzYXRpb24gYmVmb3JlLg0KDQpQZXJoYXBzLCBhcG9sb2dpZXMg aWYgdGhhdCB3YXMgYWxsIGEgcmUtaGFzaCwgSSB3YXMgdHJpZ2dlcmVkIGJ5IHRoZQ0Kc3RhdGVt ZW50IHRoYXQgY2xpZW50cyBjaG9vc2luZyBhIHNpbmdsZSBESENQIHNlcnZlciB3YXMgYSBiYWQg dGhpbmcsDQpzaW5jZSBJIGNvbnNpZGVyIGl0IGEgc3RyZW5ndGguIEluIGFueSBjYXNlLCB0aGFu a3MgYWdhaW4gZm9yIGdvaW5nDQp0aHJvdWdoIHRoaXMgb25lIG1vcmUgdGltZS4NCg0K From C.Grundemann@cablelabs.com Wed Jul 31 06:44:32 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E9D21E80D1 for ; Wed, 31 Jul 2013 06:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wIrTTWEy6hXJ for ; Wed, 31 Jul 2013 06:44:26 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 161BA21E80B1 for ; Wed, 31 Jul 2013 06:44:26 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r6VDiNGf020414; Wed, 31 Jul 2013 07:44:23 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 31 Jul 2013 07:44:23 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Wed, 31 Jul 2013 07:44:23 -0600 From: Chris Grundemann To: Lorenzo Colitti

I'm not sure about how it should be done but I can = say how Linux seems to do it.

* Those = affirmation came by looking at the code... That I didn't wrote. So I = cannot be 100% sure *

Linux uses a tree = structure in order to perform the longest prefix lookup on the = destination address first.

The found node (which has the = longest prefix for the source address), CAN have a = subtree.

This subtree has the same structure as a = regular routing table, but is used with the source = address.

This means that each node in a routing = table has its own source routing table. There is = no

destination lookup first and then a source lookup in a = global table.

--> See

Pierre

= --Apple-Mail-1--300673013-- From mcr@sandelman.ca Wed Jul 31 11:15:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70C11E81B1 for ; Wed, 31 Jul 2013 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiBWDHGIuqym for ; Wed, 31 Jul 2013 11:15:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id EAB2511E81A5 for ; Wed, 31 Jul 2013 11:15:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 061DF20171; Wed, 31 Jul 2013 15:21:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EB91763A7C; Wed, 31 Jul 2013 14:14:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DF781636AD; Wed, 31 Jul 2013 14:14:17 -0400 (EDT) From: Michael Richardson to: "homenet\@ietf.org" In-Reply-To: <26364.1375279358@sandelman.ca> References: <26364.1375279358@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Chris Grundemann Subject: Re: [homenet] timescale for HIPnet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:15:55 -0000 --=-=-= Michael Richardson wrote: > Not having compared your list to the arch document, I think that the only > thing you left out is multiple ISPs. >> Within the CableLabs "ecosystem" we are absolutely working with suppliers >> and have included all of the above key features in the eRouter >> specification: >> https://www.cablelabs.com/doczone/docsis/requirements/specs/current/issued/ >> erouter/DocZoneFolder_view (the notable exception is edge detection, as > It requires a login.... I've asked for one. But, it requires an NDA to be executed. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUflT94qHRg3pndX9AQLBKAP+ICU1BgKI/9+A4RqLenjIcR4dpllyBsNq AUlM5qENXg+4nKKKbWjLEqtQx2ghd9Ae+o1Fov2bOdjYsAvu7gtJaGgkVbIwc6sk 366bJecKTU3MzcE4jvKIMGT5dZYVfuXAa7ESIYcIEFcgdmoF7nAQRL0bFC5yMbnX xZ4kpYIjIUE= =sHYp -----END PGP SIGNATURE----- --=-=-=-- From C.Grundemann@cablelabs.com Wed Jul 31 11:52:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D7D21F8F4F for ; Wed, 31 Jul 2013 11:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 7F-yRJo16LeW for

= --Apple-Mail-9--251414790--