From architecture-discuss-bounces@ietf.org Tue Nov 07 01:41:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKaw-0000ZW-Ap; Tue, 07 Nov 2006 01:38:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKav-0000ZR-PX for architecture-discuss@ietf.org; Tue, 07 Nov 2006 01:38:01 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhKas-0002ww-2m for architecture-discuss@ietf.org; Tue, 07 Nov 2006 01:38:01 -0500 Received: (eyou send program); Tue, 07 Nov 2006 14:37:44 +0800 Message-ID: <362881464.16373@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [10.71.2.166]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 07 Nov 2006 14:37:44 +0800 Message-ID: <455029BC.9000701@cnnic.cn> Date: Tue, 07 Nov 2006 14:37:48 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: David Meyer Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting References: <4B91E89056EE014A8F1AA3FB8648A0CA4D835F@idc1exc0002.corp.global.level3.com> <20061024045747.GA26917@vaf-lnx1.cisco.com> <20061024143219.GA18785@1-4-5.net> <20061024184614.GD3778@blackrose.org> <20061024201616.GA31322@1-4-5.net> <453E8C31.8000502@piuha.net> <361727477.03524@cnnic.cn> In-Reply-To: <361727477.03524@cnnic.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Dvaid, Can you show more about the ideas from the workshop? I am very interested on such kind of things, especially on routing issues. Regards! -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn David Meyer wrote: > On Wed, Oct 25, 2006 at 12:57:05AM +0300, Jari Arkko wrote: > >> Dave, >> >>> [cc'ing architecture-discuss@ietf.org in an attempt to >>> get that going...] >>> >>> >> People on this list probably need more context >> to figure out what problem you are trying >> to solve. >> > > Yeah, my mistake (and I've had a few private emails to > that effect). > > So just to try to clear that up: I'm hoping we can use > this list for discussion of ideas that came out of the > IAB workshop on routing and addressing last week, in the > hope that we will be reaching a wider and more inclusive > audience. > > ` --dmm > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 02:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKw7-0007IT-Fp; Tue, 07 Nov 2006 01:59:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKw6-0007CM-H7 for architecture-discuss@ietf.org; Tue, 07 Nov 2006 01:59:54 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhKw2-0005BI-27 for architecture-discuss@ietf.org; Tue, 07 Nov 2006 01:59:52 -0500 Received: from webmail05.lax.untd.com (webmail05.lax.untd.com [10.131.27.145]) by smtpout05.lax.untd.com with SMTP id AABCXAMYXAP4TW5J for (sender ); Mon, 6 Nov 2006 22:59:33 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeK+M+Y42ih+0w8JSRwHr/bfA== Received: (from fergdawg@netzero.net) by webmail05.lax.untd.com (jqueuemail) id L6KAGDR3; Mon, 06 Nov 2006 22:59:04 PST Received: from [67.111.99.2] by webmail05.lax.untd.com with HTTP: Tue, 7 Nov 2006 06:58:21 GMT X-Originating-IP: [67.111.99.2] Mime-Version: 1.0 From: "Fergie" Date: Tue, 7 Nov 2006 06:58:21 GMT To: lee@cnnic.cn Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061106.225904.3967.1389770@webmail05.lax.untd.com> X-ContentStamp: 22:11:2302864025 X-MAIL-INFO: 4f8481591d54d43465fded657554fd6d6db480a4ed114409f54da509a5a5914410e5cd407d7d0415557da185e5389d017905606009f0710df5e941899d4dbd05d1051095a509658191 X-UNTD-Peer-Info: 10.131.27.145|webmail05.lax.untd.com|webmail05.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Lee, I think most of the issues in question came out during the v6ops meeting today here in San Diego. It was a composite of issues which have emerged in various operational forums (namely, NANOG) and also (from what I understand), the IAB architecture meeting a couple of weeks ago in Amsterdam Instead of me going into any detail on the data points which were presented this morning (and which should eventually end up being posted somewhere?), I'll just say that perhaps the most controversial (?) issue(s) that came up was w.r.t. how v6 actually complicates operational aspects of the global routing system -- or in other words: it doesn't help, it actually contributes to the existing problem. If someone else could provide a pointer to the slides/presentation from this morning's meeting... - ferg -- Xiaodong Lee wrote: Dear Dvaid, Can you show more about the ideas from the workshop? I am very interested on such kind of things, especially on routing issues. Regards! -- = -- Xiaodong LEE [The best answer is doing] +86-10-58813020 = mailto:lee@cnnic.cn http://www.lixiaodong.cn David Meyer wrote: > On Wed, Oct 25, 2006 at 12:57:05AM +0300, Jari Arkko wrote: > = >> Dave, >> = >>> [cc'ing architecture-discuss@ietf.org in an attempt to >>> get that going...] >>> = >>> = >> People on this list probably need more context >> to figure out what problem you are trying >> to solve. >> = > > Yeah, my mistake (and I've had a few private emails to > that effect). = > > So just to try to clear that up: I'm hoping we can use > this list for discussion of ideas that came out of the > IAB workshop on routing and addressing last week, in the > hope that we will be reaching a wider and more inclusive > audience. = > > ` --dmm > = > -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 08:53:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRN1-0002kx-RL; Tue, 07 Nov 2006 08:52:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRN0-0002kq-6A for architecture-discuss@ietf.org; Tue, 07 Nov 2006 08:52:06 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhRMy-0001XM-0B for architecture-discuss@ietf.org; Tue, 07 Nov 2006 08:52:06 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A100D86AEE; Tue, 7 Nov 2006 08:52:03 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Message-Id: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> Date: Tue, 7 Nov 2006 08:52:03 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Fergie" > perhaps the most controversial (?) issue(s) that came up was w.r.t. how > v6 actually complicates operational aspects of the global routing > system ... it actually contributes to the existing problem. Just briefly, since this is the point that's relevant here (not the rest of the v6Ops stuff), what are the things about v6 that make the routing problem worse? The nitwitted Provider-Independent addresses, of course, but that's obvious. Other than that, I thought v6 was pretty similar to v4 (from the point of view of the routing), so I'm curious as to what else makes it worse. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 10:11:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhSZT-00006a-IC; Tue, 07 Nov 2006 10:09:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhSZS-00006Q-Ev for architecture-discuss@ietf.org; Tue, 07 Nov 2006 10:09:02 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhSZN-0000Xt-0c for architecture-discuss@ietf.org; Tue, 07 Nov 2006 10:09:02 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kA7F8rtu017435; Tue, 7 Nov 2006 07:08:53 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kA7F8mKw017434; Tue, 7 Nov 2006 07:08:48 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 7 Nov 2006 07:08:48 -0800 From: David Meyer To: Fergie Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Message-ID: <20061107150848.GA17425@1-4-5.net> References: <20061106.225904.3967.1389770@webmail05.lax.untd.com> Mime-Version: 1.0 In-Reply-To: <20061106.225904.3967.1389770@webmail05.lax.untd.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500443595==" Errors-To: architecture-discuss-bounces@ietf.org --===============1500443595== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All, We have a draft workshop report almost done, and we'll post it here when its in reasonable shape. --dmm On Tue, Nov 07, 2006 at 06:58:21AM +0000, Fergie wrote: > Lee, >=20 > I think most of the issues in question came out during the > v6ops meeting today here in San Diego. It was a composite of > issues which have emerged in various operational forums (namely, > NANOG) and also (from what I understand), the IAB architecture > meeting a couple of weeks ago in Amsterdam >=20 > Instead of me going into any detail on the data points which > were presented this morning (and which should eventually end > up being posted somewhere?), I'll just say that perhaps the most > controversial (?) issue(s) that came up was w.r.t. how v6 actually > complicates operational aspects of the global routing system -- or > in other words: it doesn't help, it actually contributes to the > existing problem. >=20 > If someone else could provide a pointer to the slides/presentation > from this morning's meeting... >=20 > - ferg >=20 >=20 >=20 > -- Xiaodong Lee wrote: >=20 > Dear Dvaid, >=20 > Can you show more about the ideas from the workshop? > I am very interested on such kind of things, especially on routing > issues. >=20 > Regards! >=20 > --=20 > -- Xiaodong LEE [The best answer is doing] > +86-10-58813020=20 > mailto:lee@cnnic.cn > http://www.lixiaodong.cn >=20 >=20 >=20 > David Meyer wrote: > > On Wed, Oct 25, 2006 at 12:57:05AM +0300, Jari Arkko wrote: > > =20 > >> Dave, > >> =20 > >>> [cc'ing architecture-discuss@ietf.org in an attempt to > >>> get that going...] > >>> =20 > >>> =20 > >> People on this list probably need more context > >> to figure out what problem you are trying > >> to solve. > >> =20 > > > > Yeah, my mistake (and I've had a few private emails to > > that effect).=20 > > > > So just to try to clear that up: I'm hoping we can use > > this list for discussion of ideas that came out of the > > IAB workshop on routing and addressing last week, in the > > hope that we will be reaching a wider and more inclusive > > audience.=20 > > > > ` --dmm > > =20 > > >=20 >=20 > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net > ferg's tech blog: http://fergdawg.blogspot.com/ >=20 --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFUKGAORgD1qCZ2KcRAntOAJ0QfqPZYX6sZa31g/kdkm7oi2WgHgCcCiub yuT7vzJZbqruiMs/iWKZ6yI= =7Ocd -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- --===============1500443595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1500443595==-- From architecture-discuss-bounces@ietf.org Tue Nov 07 10:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhSgo-00023u-MY; Tue, 07 Nov 2006 10:16:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhSgn-00023o-I6 for architecture-discuss@ietf.org; Tue, 07 Nov 2006 10:16:37 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhSgm-0001xt-5a for architecture-discuss@ietf.org; Tue, 07 Nov 2006 10:16:37 -0500 Received: from webmail47.lax.untd.com (webmail47.lax.untd.com [10.131.27.187]) by smtpout01.lax.untd.com with SMTP id AABCXBJ2NADCBWKS for (sender ); Tue, 7 Nov 2006 07:15:24 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKCbMjSpse4rfFo3jHI0dpiA== Received: (from fergdawg@netzero.net) by webmail47.lax.untd.com (jqueuemail) id L6K6TTQ8; Tue, 07 Nov 2006 07:14:39 PST Received: from [67.111.99.2] by webmail47.lax.untd.com with HTTP: Tue, 7 Nov 2006 15:14:22 GMT X-Originating-IP: [67.111.99.2] Mime-Version: 1.0 From: "Fergie" Date: Tue, 7 Nov 2006 15:14:22 GMT To: jnc@mercury.lcs.mit.edu Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061107.071439.6411.1390519@webmail47.lax.untd.com> X-ContentStamp: 7:3:3267230304 X-MAIL-INFO: 424915e971691569690049214d0d94cdcd90fd9dcdc0e44d41806005d9e5e5158dadbde9 X-UNTD-Peer-Info: 10.131.27.187|webmail47.lax.untd.com|webmail47.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org That's pretty much it in a nutshell. - ferg -- jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: = > perhaps the most controversial (?) issue(s) that came up was w.r.t. how > v6 actually complicates operational aspects of the global routing > system ... it actually contributes to the existing problem. Just briefly, since this is the point that's relevant here (not the rest= of the v6Ops stuff), what are the things about v6 that make the routing problem worse? The nitwitted Provider-Independent addresses, of course, but that= 's obvious. Other than that, I thought v6 was pretty similar to v4 (from th= e point of view of the routing), so I'm curious as to what else makes it worse. Noel -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 11:10:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTVm-0005JW-Os; Tue, 07 Nov 2006 11:09:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTVl-0005JF-8q for architecture-discuss@ietf.org; Tue, 07 Nov 2006 11:09:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTVi-000309-OH for architecture-discuss@ietf.org; Tue, 07 Nov 2006 11:09:17 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2006 08:07:48 -0800 X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208"; a="340339089:sNHT5443897730" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7G7lbo018061; Tue, 7 Nov 2006 08:07:47 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7G7jB6011119; Tue, 7 Nov 2006 08:07:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 08:07:36 -0800 Received: from [12.105.247.158] ([10.21.96.77]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 08:07:36 -0800 In-Reply-To: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> References: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <816CCB36-C43B-4937-9F40-F2AA020947A4@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Date: Tue, 7 Nov 2006 08:07:32 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Nov 2006 16:07:36.0634 (UTC) FILETIME=[D76B11A0:01C70286] DKIM-Signature: a=rsa-sha1; q=dns; l=3615; t=1162915668; x=1163779668; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Re=3A=20Notes=20From=20Monday=20Nights=20Meeting; X=v=3Dcisco.com=3B=20h=3DsrjoLQgNqzT6YF9J0lvOW6qDKpU=3D; b=iPaypJkuTpoIiWFE5b3o8zzqCq+TApqBUj7t5Q1X8O9thScUi88w3AD1inaxF5SLEk4u3Jzp r8NbHDi2E5f2Boqkgodh9CPKfv/vJACvEUguOKE8Xi4xn9/vSvO1Uoqz; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 7, 2006, at 5:52 AM, Noel Chiappa wrote: > Just briefly, since this is the point that's relevant here (not the > rest of the v6Ops stuff), what are the things about v6 that make > the routing problem worse? the PI address is just as PI as the IPv4 PI address. No change. There is a ringer in PA space - there are some issues that can arise if one gets a PA prefix from one provider and advertises it to another. That provider or its upstream may not accept the prefix in routing, and the original ISP is forced to advertise it into the backbone in order to not have a working alternate path get all the traffic. PA in that sense becomes PI. The big thing that makes routing screwey is ingress filtering - BCP 38. If the prefix in use is supposed to be the one delegated by the ISP, then the enterprise is nominally on the hook to ensure that the source address that crosses its DMZ is for the right ISP. But the host has no idea which DMZ the routing system will use or what prefixes are sited there. So it essentially selects a source address at random and the routing system is nominally on the hook to tunnel the packet to the right DMZ. The other side of that is the fact that a multihomed destination also has multiple addresses and there isn't necessarily real good guidance on which to use. The cross product of the two sets of addresses is essentially a random selector among M*N routes (which DMZ will it go out of my network, through which pair-or- more of ISPs, and which DMZ will provide the ingress to the peer network?), which may have very different characteristics. There is a mechanism to configure policy of this kind, in RFC 3484. The discussion in v6ops yesterday was to the effect that we wanted to look at this, though, as it may not be a adequate solution. SCTP and shim6 also have ways to mitigate the M*N routes, through some combination of cached history and probing during the session. There is renewed discussion of GSE and an ID/Locator split. GSE solves the above issue, at least for the source address, by allowing the egress DMZ to write its prefix into the IPv6 header, eliminating the question of tunneling to a randomly selected DMZ. There is some possibility that a bad choice of destination address on the SYN-or- equivalent can be fixed by GSE on the SYN-ACK path - if the routing in the remote system picks a different DMZ, it will pick a different prefix according to it. So GSE actively helps, although it doesn't fully optimize the solution and Mike's initial ID is best described as an initial ID. The discussion of GSE is couched in language related to the ID/ Locator split. As you discussed in 1993 and earlier, this would be a good thing for various architectural reasons. I can't say that it automatically improves routing, or the scaling of addressing though. To my small mind, it enables the address overwrite done in GSE to be done safely, and it is the address overwrite that actually helps. There is a wrinkle with the address overwrite, but it is solvable. It makes AH not work as specified - one has to restrict the "immutable or predictable" fields to the locator as opposed to the address. It also has some issues with IKEv2 in setting up ESP sessions (although ESP is not itself affected). Steve Bellovin tells me that both are fixable and has offered to help. I will have the presentations that were given posted in the v6ops IETF67 proceedings site later today. I'll post the URL at the time. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 12:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUnV-0007ZM-N7; Tue, 07 Nov 2006 12:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUnV-0007ZG-9r for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:31:41 -0500 Received: from [2001:630:d0:f102:230:48ff:fe77:96e] (helo=owl.ecs.soton.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUnO-0000Ji-HS for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:31:41 -0500 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id kA7HVA7A006845 for ; Tue, 7 Nov 2006 17:31:10 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id kA7HV0xv015881 for ; Tue, 7 Nov 2006 17:31:00 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id kA7HUvx1010417 for architecture-discuss@ietf.org; Tue, 7 Nov 2006 17:30:57 GMT Date: Tue, 7 Nov 2006 17:30:57 +0000 From: Tim Chown To: architecture-discuss@ietf.org Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Message-ID: <20061107173057.GB9130@login.ecs.soton.ac.uk> References: <20061106.225904.3967.1389770@webmail05.lax.untd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061106.225904.3967.1389770@webmail05.lax.untd.com> User-Agent: Mutt/1.4i X-Null-Tag: 45ae0f54f852b2ce6805b3ecb8c35910 X-Null-Tag: e99465b88515854e53d185b1a9ffa40a X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Tue, Nov 07, 2006 at 06:58:21AM +0000, Fergie wrote: > > Instead of me going into any detail on the data points which > were presented this morning (and which should eventually end > up being posted somewhere?), I'll just say that perhaps the most > controversial (?) issue(s) that came up was w.r.t. how v6 actually > complicates operational aspects of the global routing system -- or > in other words: it doesn't help, it actually contributes to the > existing problem. > > If someone else could provide a pointer to the slides/presentation > from this morning's meeting... For those asking for Vince's slides, they are here: http://www.vaf.net/~vaf/iepg.pdf These were presented in v6ops and IEPG. I think one of the aspects of 'contribbuting to the problem' was simply that if v6 is turned on where v4 already exists today the routing tables would grow bigger than many FIBs can handle. The numbers are in the slides, from around slide 16 onwards. But there are also comments on difference on IPv6 TE etc. -- Tim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 12:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUq4-0008Mp-9L; Tue, 07 Nov 2006 12:34:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUq3-0008Mk-Ls for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:34:19 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUq1-0000tL-CC for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:34:19 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2006 09:34:17 -0800 X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208"; a="86763555:sNHT50479776" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7HYGnq002337; Tue, 7 Nov 2006 09:34:16 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7HYGAo023150; Tue, 7 Nov 2006 09:34:16 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 09:34:16 -0800 Received: from [130.129.68.140] ([10.21.120.250]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 09:34:15 -0800 In-Reply-To: <20061106.225904.3967.1389770@webmail05.lax.untd.com> References: <20061106.225904.3967.1389770@webmail05.lax.untd.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Date: Tue, 7 Nov 2006 09:34:14 -0800 To: Fergie X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Nov 2006 17:34:15.0620 (UTC) FILETIME=[F2416040:01C70292] DKIM-Signature: a=rsa-sha1; q=dns; l=737; t=1162920856; x=1163784856; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Re=3A=20Notes=20From=20Monday=20Nights=20Meeting; X=v=3Dcisco.com=3B=20h=3DsrjoLQgNqzT6YF9J0lvOW6qDKpU=3D; b=EzeSlpmq7F3mC/+BuRALo1YEqKUmLwZ4Pm2KCkGKlyCN/LWTQMloonj5BhCH/NsB/Zk3BtXd O2mq765hZMb9OR26FpMhNknWYGYaYXXi0b4TVqaR6fsRX6nT1QiQ+2ki; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 7, 2006, at 6:58 AM, Fergie wrote: > If someone else could provide a pointer to the slides/presentation > from this morning's meeting... OK, our proceedings are all uploaded, but not the minutes, which I haven't received yet from the guy who was taking them. It turns out that there is some delay in making them visible; I guess that might be tomorrow. The minutes of this part of the meeting are "Dave Meyer, Vince Fuller, and Marla Azinger talked. They all think we have a scaling problem with every approach that is on the table. They also think maybe it should be fixed." Some files are PDF, and at this point some are powerpoint. The proceedings people will turn them all into PDF later on. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 12:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUvU-0003pV-3B; Tue, 07 Nov 2006 12:39:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUvT-0003pG-1F for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:39:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUvP-0002An-2J for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:39:55 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Nov 2006 09:39:50 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7HdoD5013712; Tue, 7 Nov 2006 09:39:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA7HdoOj013249; Tue, 7 Nov 2006 09:39:50 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 09:39:50 -0800 Received: from [130.129.68.140] ([10.21.120.250]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 09:39:49 -0800 In-Reply-To: <816CCB36-C43B-4937-9F40-F2AA020947A4@cisco.com> References: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> <816CCB36-C43B-4937-9F40-F2AA020947A4@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F4FA882-640A-4C94-84C3-79F50A310F04@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Date: Tue, 7 Nov 2006 09:39:47 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Nov 2006 17:39:49.0749 (UTC) FILETIME=[B9696A50:01C70293] DKIM-Signature: a=rsa-sha1; q=dns; l=957; t=1162921190; x=1163785190; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Re=3A=20Notes=20From=20Monday=20Nights=20Meeting; X=v=3Dcisco.com=3B=20h=3DsrjoLQgNqzT6YF9J0lvOW6qDKpU=3D; b=B9OT1RPfFVFKgXCZLrnQaBZ6LRl5Cgvor3sQb7Y6YJiwGoV+EgHXwZvGAmE6glE4cEsmGZiH YF/o9n6jFEWVyCMS8Q7WUS1A8l2DaIlpTSNibFZ8wHYmPf3vH24UaK+2; Authentication-Results: sj-dkim-6.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 7, 2006, at 8:07 AM, Fred Baker wrote: > There is a wrinkle with the address overwrite, but it is solvable. > It makes AH not work as specified - one has to restrict the > "immutable or predictable" fields to the locator as opposed to the > address. It also has some issues with IKEv2 in setting up ESP > sessions (although ESP is not itself affected). Steve Bellovin > tells me that both are fixable and has offered to help. for completeness, I should note that there is another ringer in the address overwrite. SCTP has the ability for one end to announce alternative addresses to its peer, and in shim6 a similar capability is added to TCP and UDP. The mutability of addresses makes recognizing packets in the session depend on this. GSE, in proposing a locator, allows the endpoint transport to look only at the locator. That means, however, changing every transport implementation running atop IPv6. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 12:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVB8-0004qU-8X; Tue, 07 Nov 2006 12:56:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVB6-0004py-E5 for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:56:04 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVB5-0005CT-7k for architecture-discuss@ietf.org; Tue, 07 Nov 2006 12:56:04 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 11:56:00 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting Date: Tue, 7 Nov 2006 11:57:38 -0600 Message-ID: In-Reply-To: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Re: Notes From Monday Nights Meeting Thread-Index: AccCdN1Q92ZaMsThTFu8rDiJ3BCOJwAFYQBw From: "Schliesser, Benson" To: X-OriginalArrivalTime: 07 Nov 2006 17:56:00.0870 (UTC) FILETIME=[FC3EB860:01C70295] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Just briefly, since this is the point that's relevant here (not the rest > of the v6Ops stuff), what are the things about v6 that make the routing > problem worse? The nitwitted Provider-Independent addresses, of course, > but that's obvious. Other than that, I thought v6 was pretty similar to v4 > (from the point of view of the routing), so I'm curious as to what else > makes it worse. I'm also curious about what makes it worse. I wasn't able to attend v6ops yesterday, but from past discussions I've gathered that the scaling complaints against v6 can be summarized as "it scales like v4, but with a higher limit on table size". Would somebody making this argument view v4 address-exhaustion as a feature? It seems to me that, leaving traffic-engineering aside, v6 can scale better than v4 with proper allocation rules. That is, if each AS gets a single prefix large enough to satisfy all of their current and future needs (pretend that we can perfectly predict future needs for a moment) then table size should be much smaller than today. What am I missing? Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 13:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVZ0-00011T-Op; Tue, 07 Nov 2006 13:20:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVYz-00011B-MK for architecture-discuss@ietf.org; Tue, 07 Nov 2006 13:20:45 -0500 Received: from neo-u2.ops-netman.net ([2001:408:1009:1:2d0:a8ff:fe00:4bc4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVYs-0001Gh-5L for architecture-discuss@ietf.org; Tue, 07 Nov 2006 13:20:45 -0500 Received: from localhost (localhost [127.0.0.1]) by neo-u2.ops-netman.net (Postfix) with ESMTP id AC537143; Tue, 7 Nov 2006 18:20:25 +0000 (GMT) Date: Tue, 7 Nov 2006 18:20:25 +0000 (GMT) From: Chris Morrow To: Fred Baker Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting In-Reply-To: <6F4FA882-640A-4C94-84C3-79F50A310F04@cisco.com> Message-ID: References: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> <816CCB36-C43B-4937-9F40-F2AA020947A4@cisco.com> <6F4FA882-640A-4C94-84C3-79F50A310F04@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Tue, 7 Nov 2006, Fred Baker wrote: > this. GSE, in proposing a locator, allows the endpoint transport to look only > at the locator. That means, however, changing every transport implementation > running atop IPv6. which, with ipv6 'infancy' might still be a decent idea... doing it 'right' this time could lead to a better long term solution? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 13:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVfA-0005YC-RE; Tue, 07 Nov 2006 13:27:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVf9-0005Y4-Mr for architecture-discuss@ietf.org; Tue, 07 Nov 2006 13:27:07 -0500 Received: from neo-u2.ops-netman.net ([2001:408:1009:1:2d0:a8ff:fe00:4bc4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVf6-0002Jl-Ms for architecture-discuss@ietf.org; Tue, 07 Nov 2006 13:27:07 -0500 Received: from localhost (localhost [127.0.0.1]) by neo-u2.ops-netman.net (Postfix) with ESMTP id C671C95; Tue, 7 Nov 2006 18:27:03 +0000 (GMT) Date: Tue, 7 Nov 2006 18:27:03 +0000 (GMT) From: Chris Morrow To: "Schliesser, Benson" Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Tue, 7 Nov 2006, Schliesser, Benson wrote: > It seems to me that, leaving traffic-engineering aside, v6 can scale > better than v4 with proper allocation rules. That is, if each AS gets a I can't really scale 'better' if you want multihoming... If you think of multihoming as you would today in the current v4 world. It scales about the same in that case, which with a higher top end means more trouble :( > single prefix large enough to satisfy all of their current and future > needs (pretend that we can perfectly predict future needs for a moment) > then table size should be much smaller than today. > table size will grow... I'm not sure you can say it'll be smaller than today, since tomorrow there are likely many, many more things being connected to the Internet. Also, keep in mind that the 'global table' isn't all that is the problem here, there are internal routes for ISP/NSP folks to carry, and overlay routes for 'services'... > What am I missing? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 13:44:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVue-0000Aq-Dd; Tue, 07 Nov 2006 13:43:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVuc-00009r-Uv for architecture-discuss@ietf.org; Tue, 07 Nov 2006 13:43:06 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVtm-0004la-BR for architecture-discuss@ietf.org; Tue, 07 Nov 2006 13:42:35 -0500 Received: from [10.0.1.25] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20061107184213b12007hrf2e>; Tue, 7 Nov 2006 18:42:13 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 7 Nov 2006 13:35:51 -0500 To: Chris Morrow , "Schliesser, Benson" From: John Day Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 18:27 +0000 2006/11/07, Chris Morrow wrote: >On Tue, 7 Nov 2006, Schliesser, Benson wrote: > >>It seems to me that, leaving traffic-engineering aside, v6 can scale >>better than v4 with proper allocation rules. That is, if each AS gets a > >I can't really scale 'better' if you want multihoming... If you >think of multihoming as you would today in the current v4 world. It >scales about the same in that case, which with a higher top end >means more trouble :( > >>single prefix large enough to satisfy all of their current and future >>needs (pretend that we can perfectly predict future needs for a moment) >>then table size should be much smaller than today. >> > >table size will grow... I'm not sure you can say it'll be smaller >than today, since tomorrow there are likely many, many more things >being connected to the Internet. > >Also, keep in mind that the 'global table' isn't all that is the >problem here, there are internal routes for ISP/NSP folks to carry, >and overlay routes for 'services'... > >>What am I missing? > > A complete architecture. ;-) Sorry I couldn't resist. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 14:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWCb-0006S5-D4; Tue, 07 Nov 2006 14:01:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWCa-0006Ru-Ke for architecture-discuss@ietf.org; Tue, 07 Nov 2006 14:01:40 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWCX-0007Um-As for architecture-discuss@ietf.org; Tue, 07 Nov 2006 14:01:40 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2006 11:01:37 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7J1aBA027935; Tue, 7 Nov 2006 11:01:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7J1aAo017952; Tue, 7 Nov 2006 11:01:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 11:01:36 -0800 Received: from [12.105.247.158] ([10.21.120.194]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 11:01:35 -0800 In-Reply-To: References: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> <816CCB36-C43B-4937-9F40-F2AA020947A4@cisco.com> <6F4FA882-640A-4C94-84C3-79F50A310F04@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A519401-0A28-4CEE-8EE9-6C97994B983E@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Date: Tue, 7 Nov 2006 11:01:34 -0800 To: Chris Morrow X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Nov 2006 19:01:36.0000 (UTC) FILETIME=[25C3E800:01C7029F] DKIM-Signature: a=rsa-sha1; q=dns; l=533; t=1162926096; x=1163790096; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Re=3A=20Notes=20From=20Monday=20Nights=20Meeting; X=v=3Dcisco.com=3B=20h=3DsrjoLQgNqzT6YF9J0lvOW6qDKpU=3D; b=qWv/aMy8yLcKeINL5AHcReAmQhB+PPlLWvS9/dxGz2YLxHjA24UPmrnWXeRMU0Ew5NJsnQw+ idP6sUsbOhWegQiVi1rOWzzsRQLMtqYfy0Wr2L9tObMZFEpBl1PjTgGi; Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I would agree, and agreed ten years ago. But if we're going to do it now, there is no time to waste. On Nov 7, 2006, at 10:20 AM, Chris Morrow wrote: > > On Tue, 7 Nov 2006, Fred Baker wrote: >> this. GSE, in proposing a locator, allows the endpoint transport >> to look only at the locator. That means, however, changing every >> transport implementation running atop IPv6. > > which, with ipv6 'infancy' might still be a decent idea... doing it > 'right' this time could lead to a better long term solution? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 07 14:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWbR-0002xD-Tf; Tue, 07 Nov 2006 14:27:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWbQ-0002x8-UW for architecture-discuss@ietf.org; Tue, 07 Nov 2006 14:27:20 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWbN-0001qm-H2 for architecture-discuss@ietf.org; Tue, 07 Nov 2006 14:27:20 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kA7JRHUY029631; Tue, 7 Nov 2006 11:27:17 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kA7JRHjt029630; Tue, 7 Nov 2006 11:27:17 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 7 Nov 2006 11:27:17 -0800 From: David Meyer To: Noel Chiappa Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Message-ID: <20061107192717.GA29619@1-4-5.net> References: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20061107135203.A100D86AEE@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1160456617==" Errors-To: architecture-discuss-bounces@ietf.org --===============1160456617== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 07, 2006 at 08:52:03AM -0500, Noel Chiappa wrote: > > From: "Fergie" >=20 > > perhaps the most controversial (?) issue(s) that came up was w.r.t.= how > > v6 actually complicates operational aspects of the global routing > > system ... it actually contributes to the existing problem. >=20 > Just briefly, since this is the point that's relevant here (not the rest = of > the v6Ops stuff), what are the things about v6 that make the routing prob= lem > worse? The nitwitted Provider-Independent addresses, of course, but that's > obvious. Other than that, I thought v6 was pretty similar to v4 (from the > point of view of the routing), so I'm curious as to what else makes it > worse. More rope (address space). --dmm --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFUN4UORgD1qCZ2KcRAmsQAJ9sic3P67YNc5o6RIWx3e6vpGnChACdFjfZ f8hW8AKIsHEkDpdhy07JEdA= =9ekV -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- --===============1160456617== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1160456617==-- From architecture-discuss-bounces@ietf.org Tue Nov 07 21:54:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdXo-00020l-0e; Tue, 07 Nov 2006 21:52:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdV6-0001Ku-O1 for architecture-discuss@ietf.org; Tue, 07 Nov 2006 21:49:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhdV1-0007Pe-KB for architecture-discuss@ietf.org; Tue, 07 Nov 2006 21:49:16 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2006 18:49:11 -0800 X-IronPort-AV: i="4.09,399,1157353200"; d="scan'208"; a="340543021:sNHT52607672" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA82nA90002383; Tue, 7 Nov 2006 18:49:10 -0800 Received: from cisco.com (vaf-lnx1.cisco.com [171.71.142.83]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA82nAOV016975; Tue, 7 Nov 2006 18:49:10 -0800 (PST) Received: from vaf-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.13.1/8.13.1) with ESMTP id kA82n5fV018474; Tue, 7 Nov 2006 18:49:05 -0800 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.13.1/8.13.1/Submit) id kA82n56x018473; Tue, 7 Nov 2006 18:49:05 -0800 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Tue, 7 Nov 2006 18:49:05 -0800 From: Vince Fuller To: Tim Chown Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Message-ID: <20061108024905.GA18035@vaf-lnx1.cisco.com> References: <20061106.225904.3967.1389770@webmail05.lax.untd.com> <20061107173057.GB9130@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061107173057.GB9130@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i DKIM-Signature: a=rsa-sha1; q=dns; l=2293; t=1162954150; x=1163818150; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:Vince=20Fuller=20 |Subject:Re=3A=20[arch-d]=20Re=3A=20Notes=20From=20Monday=20Nights=20Meeting; X=v=3Dcisco.com=3B=20h=3D9b4jQ0yUKpP482nfGZKhVc7A3pk=3D; b=gEoJfjntRaRnvxiSibUcXS1p2TtlOTjxq+LKoBXYvEpHQrq02fDbZ+d/JQynvkJCioISln4o LW3MwyMNzrVEUAFhTop0fZ0U2beYWiLYd3pwKK0hgEm/+j4V4wpyfinP; Authentication-Results: sj-dkim-7.cisco.com; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Tue, Nov 07, 2006 at 05:30:57PM +0000, Tim Chown wrote: > On Tue, Nov 07, 2006 at 06:58:21AM +0000, Fergie wrote: > > > > Instead of me going into any detail on the data points which > > were presented this morning (and which should eventually end > > up being posted somewhere?), I'll just say that perhaps the most > > controversial (?) issue(s) that came up was w.r.t. how v6 actually > > complicates operational aspects of the global routing system -- or > > in other words: it doesn't help, it actually contributes to the > > existing problem. > > > > If someone else could provide a pointer to the slides/presentation > > from this morning's meeting... > > For those asking for Vince's slides, they are here: > http://www.vaf.net/~vaf/iepg.pdf > > These were presented in v6ops and IEPG. Those are the slides from IEPG - the "long" version. The "short" version was presented in v6ops: http://www.vaf.net/~vaf/v6ops.pdf As for what makes ipv6 scaling "worse" - the presentations talk about this but to summarize: multihoming is implemented in the same way in ipv6 as in IPv4; there is reason to believe that the biggest driver for routing state growth is multihoming and that the trend is for more multihoming as time goes by (in other words, the amount of state is not only growing but the rate that it is growing is also increasing; the growth curve approximates something like a polynomial or exponential). In addition, IPv4 is going to be around for the indefinite future even if everyone cuts over to ipv6 today. That means that projections of routing state need to *add* ipv6 prefixes to the growing total for IPv4. As for one prefix per AS for ipv6 (replying to another message) - the projections in my presentation actually assume that though it that is almost certainly an unreasonably low assumption. While, in priciple, most AS's should be able to satisfy all of their address space needs out of a single prefix, there quite a few reasons to expect that reality will not be so clean (consider sites/providers that want to deploy one ipv6 prefix to replace each IPv4 prefix for simplicity of management, those that span multiple geographic areas that would like to assign one prefix to each, etc, etc.) --Vince _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 02:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhr7-0005wP-5r; Wed, 08 Nov 2006 02:28:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhr6-0005wH-FL for architecture-discuss@ietf.org; Wed, 08 Nov 2006 02:28:16 -0500 Received: from outmail136021.authsmtp.net ([62.13.136.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghhr0-0008R0-QJ for architecture-discuss@ietf.org; Wed, 08 Nov 2006 02:28:16 -0500 Received: from outmail128181.authsmtp.net (outmail128181.authsmtp.net [62.13.128.181]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id kA87S5ff023981 for ; Wed, 8 Nov 2006 07:28:05 GMT Received: from IAN (203-206-240-149.dyn.iinet.net.au [203.206.240.149]) (authenticated bits=0) by mail.authsmtp.com (8.13.6/8.13.6/Kp) with ESMTP id kA87S1Hw094745 for ; Wed, 8 Nov 2006 07:28:03 GMT From: "Ian Peter" To: Date: Wed, 8 Nov 2006 18:26:05 +1100 Message-ID: <01e701c70307$28e466a0$4a02a8c0@IAN> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccDBDu3G0Eg9fHTTkKhFy6eSyYUOQAAqxyg X-Server-Quench: ac4fe4fd-6efa-11db-b4dc-001185d377ca X-AuthRoute: OCdyZgEQClZURQJc Ei4YATVoSAwjPhBQ DAVFJgxfNlMTXgRQ LktRMkdJPRgQREpS RiVIKw0BFAtvBiEi JQpZcnsCJFVMXwVs QEhOSFBaHgVsTx4B BQAcUh9sdQFGZn90 bFlgW3JeQ0Q0Ljd1 RS1VbSoGbGNnbGVR VkJdcE0FIwccKxsT Pk15ASVcfGQGMih9 FVM/NHVpZWwGeHlZ GV5SJlsEb3lZVg0d fSwsWBwpG0oYQS4+ GlQAJ0FUPXwtHA0I HhMqWVsCLxIIBwEM V2xLDGp8JlUNQydu IAVWFXQTCzBUWyxc SjIyJQJQamVd X-Authentic-SMTP: 61633136393539.squirrel.dmpriest.net.uk:281/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [arch-d] FW: [IRTF-Announce] New IRTF RG chartered: End-Middle-End Research Group X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This may be related...... Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: Aaron Falk [mailto:falk@ISI.EDU] Sent: 08 November 2006 17:44 To: IRTF Announcements Subject: [IRTF-Announce] New IRTF RG chartered: End-Middle-End Research Group A new IRTF research group, End-Middle-End (EME) Research Group, has been created with the appended charter. The full RG charter is at http://www.irtf.org/eme The RG web page/wiki is at: http://www1.tools.ietf.org/group/irtf/trac/wiki/EME Subscribe to the mailing list: https://www1.ietf.org/mailman/listinfo/eme. Aaron Falk IRTF Chair ==================================================== In the original Internet end-to-end architecture, a transport connection linked a pair of hosts and was bound to a globally unique IP address and locally meaningful transport port at each end host. This architecture has been progressively eroded, most notably by the use of NATs, which modify addresses, and firewalls and other middle boxes, which expect to understand the semantics behind any given port number (for instance to block or differentially handle a flow). As a result, end hosts are often not able to connect even when security policies would otherwise allow such connections. This problem will only be exacerbated with the emerging need for IPv4-IPv6 translation. Beyond this, other changes in the way the Internet is used has stressed the original unique-address:port model of transport connections. For instance, the need for robustness has resulted in a rise in multi-homing, which has led to scaling issues in BGP. The use of multiple addresses at hosts is known to alleviate this problem, but the architecture provides no good way to manage multiple addresses, either at connection establishment or when the active address has to be changed. Mobility across access networks similarly results in the need to cope with changing IP addresses during a connection. In addition, DoS attacks are increasingly a concern. There is a need for hosts to be able to control which other hosts can send packets to it, and to exercise that control deep in the network (i.e. near the attacker). The common roots of this seemingly diverse set of problems are the following: 1. The IP address is no longer globally unique, is no longer intact end-to-end, and is no longer stable over even short time periods. 2. The transport port number has no clear semantics outside of the end-host that opened the socket. 3. End hosts are often not explicitly aware of middle boxes, especially middle boxes far away from them, and therefore cannot control them much less be aware of what they are doing. Beyond the specific problems mentioned above, this erosion of the original E2E Internet mechanisms broadly results in greater application-level complexity (to cope with the erosion), network fragility and lack of robustness, poor security, and difficulty in debugging the resulting problems. While this group is not the first to identify these problems, we do recognize that there may be a single architectural enhancement that solves them all. Namely, a higher-level DNS-based naming scheme (i.e. URIs) coupled with signaling protocols used to initiate and modify transport-level connections such as TCP, UDP, SCTP or DCCP flows. Such a protocol could provide a way for end-to-end communication to explicitly address middleboxes, so that their behavior can be understood, monitored and controlled. Such a protocol might also be used to move connections between IP addresses, as with mobility and multihoming, and to shut down unwanted communication, as with DoS attacks. The goal of the End-Middle-End Research Group (EME) is to evaluate the feasibility and desirability of such an architectural change to the Internet. The aim is first to investigate possible designs for a strawman experimental protocol that can perform these tasks (the so-called "ideal" design) without being overly constrained by overlapping work happening in the IETF and elsewhere. Should one or more designs appear viable, then issues such as related work and incremental deployment should be considered. Should this work still appear viable, then the IESG will be consulted with regards to whether and how this should be brought into the IETF for standardization. There are many questions that need to be answered along the way. These issues include precisely which architectural problems should be tackled and which should not, the degree to which such signaling should be on-path vs off-path and the balance between flexibility vs simplicity and efficiency. There are clear concerns about such a track that need to be evaluated. Candidate protocols should avoid falling into the virtual circuit trap, where routers lose the ability to remedy failures locally, and avoid building a mechanism that encourages the construction of walled gardens to the detriment of the Internet as a whole. _______________________________________________ IRTF-Announce mailing list IRTF-Announce@irtf.org https://www1.ietf.org/mailman/listinfo/irtf-announce -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.32/523 - Release Date: 07/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.32/523 - Release Date: 07/11/2006 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 03:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhijF-0005EM-AK; Wed, 08 Nov 2006 03:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhijD-0005EG-KZ for architecture-discuss@ietf.org; Wed, 08 Nov 2006 03:24:11 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhijC-0000mn-6z for architecture-discuss@ietf.org; Wed, 08 Nov 2006 03:24:11 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA88No5r013798; Wed, 8 Nov 2006 10:24:04 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:24:02 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:24:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting Date: Wed, 8 Nov 2006 10:24:01 +0200 Message-ID: In-Reply-To: <20061107192717.GA29619@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Re: Notes From Monday Nights Meeting Thread-Index: AccCqEmqFBGtpTuzTJuC0M5mqu4SVwAZsl5g From: To: , X-OriginalArrivalTime: 08 Nov 2006 08:24:02.0017 (UTC) FILETIME=[3F071510:01C7030F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061108102404-32F9CBB0-384DFDCD/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Meyer [mailto:dmm@1-4-5.net] wrote: >Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting > >> Just briefly, since this is the point that's relevant here (not the=20 >> rest of the v6Ops stuff), what are the things about v6 that make the=20 >> routing problem worse? The nitwitted Provider-Independent addresses,=20 >> of course, but that's obvious. Other than that, I thought v6 was=20 >> pretty similar to v4 (from the point of view of the routing), so I'm=20 >> curious as to what else makes it worse. > > More rope (address space). > Or "more tunnel" :-? Jarno Rajahalme _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 03:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj7D-0007YB-C5; Wed, 08 Nov 2006 03:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj7B-0007Xq-En for architecture-discuss@ietf.org; Wed, 08 Nov 2006 03:48:57 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghj7A-0004yv-00 for architecture-discuss@ietf.org; Wed, 08 Nov 2006 03:48:57 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA88ma5x032370; Wed, 8 Nov 2006 10:48:53 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:48:50 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:48:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting Date: Wed, 8 Nov 2006 10:48:49 +0200 Message-ID: In-Reply-To: <6F4FA882-640A-4C94-84C3-79F50A310F04@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Re: Notes From Monday Nights Meeting Thread-Index: AccCk/DcDUhvAv4rRAmPcLawwZ6xpgAe79Dg From: To: , X-OriginalArrivalTime: 08 Nov 2006 08:48:49.0741 (UTC) FILETIME=[B5C7BFD0:01C70312] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061108104853-7A8A3BB0-16AD124D/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred Baker [mailto:fred@cisco.com] wrote: >On Nov 7, 2006, at 8:07 AM, Fred Baker wrote: > >> There is a wrinkle with the address overwrite, but it is solvable. =20 >> It makes AH not work as specified - one has to restrict the=20 >"immutable=20 >> or predictable" fields to the locator as opposed to the address. It=20 >> also has some issues with IKEv2 in setting up ESP sessions (although=20 >> ESP is not itself affected). Steve Bellovin tells me that both are=20 >> fixable and has offered to help. > >for completeness, I should note that there is another ringer=20 >in the address overwrite. SCTP has the ability for one end to=20 >announce alternative addresses to its peer, and in shim6 a=20 >similar capability is added to TCP and UDP. The mutability of=20 >addresses makes recognizing packets in the session depend on=20 >this. GSE, in proposing a locator, allows the endpoint=20 >transport to look only at the locator. =20 >That means, however, changing every transport implementation=20 >running atop IPv6. > Existing transport stacks could be fooled by masking the LOC part to some fixed value, so that they would effectively only see the ID? Also, the Locators could be assigned from a different address block than the currently standardized unicast addresses so that routers would know which are which? Then some encouraging policy to make networks that want to multihome to migrate to LOC/ID split? IMO the ID part should be allowed to be cryptographically generated. Then about the perceived layer violation: Optimally the RG/LOC stuff should live in it's own header (internetworking header), while the ID should be in its own header, effectively taking the pseudo-header used by transports away from the internetworking header. Something like this could be possible with the existing IPv6 header structure with option headers. Separating the headers would also allow for different sizes than 64 bits for both LOC and ID. Maybe something like this should be specified. But I would not mind also settling a mapping to the current IPv6 header with 64-bit ID & LOC for the benefit of current and in-development forwarding HW being able to effectively operate on these. Also strongly agree that there is no time to waste on doing this right, now.=20 Regs, Jarno Rajahalme _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 14:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtP7-0004KX-SE; Wed, 08 Nov 2006 14:48:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtP6-0004J3-Fx for architecture-discuss@ietf.org; Wed, 08 Nov 2006 14:48:08 -0500 Received: from web31808.mail.mud.yahoo.com ([68.142.207.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhtP2-0007he-5k for architecture-discuss@ietf.org; Wed, 08 Nov 2006 14:48:08 -0500 Received: (qmail 37353 invoked by uid 60001); 8 Nov 2006 19:48:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KHEtrsm8aABgRp9Pidnlx35/k8ifXoYvnwQz0THBndaRQlMs9UdFQNmG3mbZugTy4VTVgJ/Cbe7LSKJyKunt8AdIcFEYR5eBIf4HuUwSoi/AG9GgCGiCP9pb+qCBKkdlPrKOZtEQMLDduIGGJIs0J9iK2wvanXM93/GO6ngHd8I= ; Message-ID: <20061108194803.37351.qmail@web31808.mail.mud.yahoo.com> X-YMail-OSG: g7Mg.MQVM1mEFAXlrPDSMUUn18koTkDbbhrY1nu3xYnfYvSRm4IEsONhhtmvt0.KfpEIPDoEtw6zXyQjxuJNSARmKqInSut0VyxigX94XtFyGohUT7FwglcklOw7OL_m0cKJq4wiUY6MxjCrYMBDLDswR4M0sMAJF9XoDJrNN.xtVG_Xdy8NY1BKnL_2 Received: from [68.34.60.18] by web31808.mail.mud.yahoo.com via HTTP; Wed, 08 Nov 2006 11:48:03 PST Date: Wed, 8 Nov 2006 11:48:03 -0800 (PST) From: David Barak Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting To: architecture-discuss@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org --- Chris Morrow wrote: > On Tue, 7 Nov 2006, Schliesser, Benson wrote: > > > It seems to me that, leaving traffic-engineering > aside, v6 can scale > > better than v4 with proper allocation rules. That > is, if each AS gets a > > I can't really scale 'better' if you want > multihoming... If you think of > multihoming as you would today in the current v4 > world. It scales about > the same in that case, which with a higher top end > means more trouble :( Valid point, but if our allocation rules are sensible, then the vast majority of non-transit providers should be fine with a single block. Even at maximum CIDR aggregation nowadays, we'd have multiple times the number of routes as ASNs. If we can keep the number of routes < 2x number of ASNs, that'd still be better. > > > single prefix large enough to satisfy all of their > current and future > > needs (pretend that we can perfectly predict > future needs for a moment) > > then table size should be much smaller than today. > > > > table size will grow... I'm not sure you can say > it'll be smaller than > today, since tomorrow there are likely many, many > more things being > connected to the Internet. It's not the things connected to the Internet which necessarily causes table growth: it's the things which are connected to multiple Internet providers. Singly-homed devices should be aggregatible inside the provider's block. As long as the allocation process does not permit singly-homed sites to obtain PI space, there shouldn't be an additional scale effect. > Also, keep in mind that the 'global table' isn't all > that is the problem > here, there are internal routes for ISP/NSP folks to > carry, and overlay > routes for 'services'... But at the very least, those internal routes need not be known by anyone else, and each route should represent some process or service for which the ISP is being paid... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com ____________________________________________________________________________________ Sponsored Link Try Netflix today! With plans starting at only $5.99 a month what are you waiting for? http://www.netflix.com/Signup?mqso=80010030 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 19:15:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxXQ-00067J-66; Wed, 08 Nov 2006 19:13:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxXO-00067D-M5 for architecture-discuss@ietf.org; Wed, 08 Nov 2006 19:12:58 -0500 Received: from neo-u2.ops-netman.net ([2001:408:1009:1:2d0:a8ff:fe00:4bc4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhxXN-0004Cd-5h for architecture-discuss@ietf.org; Wed, 08 Nov 2006 19:12:58 -0500 Received: from [IPv6?2001?df8??64?211?24ff?fea9?7105] (unknown [IPv6:2001:df8:0:64:211:24ff:fea9:7105]) by neo-u2.ops-netman.net (Postfix) with ESMTP id B5E0198; Thu, 9 Nov 2006 00:12:37 +0000 (GMT) In-Reply-To: <20061108194803.37351.qmail@web31808.mail.mud.yahoo.com> References: <20061108194803.37351.qmail@web31808.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chris Morrow Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Date: Wed, 8 Nov 2006 19:12:35 -0500 To: David Barak X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 8, 2006, at 2:48 PM, David Barak wrote: > > --- Chris Morrow wrote: >> On Tue, 7 Nov 2006, Schliesser, Benson wrote: >> >>> It seems to me that, leaving traffic-engineering >> aside, v6 can scale >>> better than v4 with proper allocation rules. That >> is, if each AS gets a >> >> I can't really scale 'better' if you want >> multihoming... If you think of >> multihoming as you would today in the current v4 >> world. It scales about >> the same in that case, which with a higher top end >> means more trouble :( > > Valid point, but if our allocation rules are sensible, > then the vast majority of non-transit providers should > be fine with a single block. Even at maximum CIDR > aggregation nowadays, we'd have multiple times the > number of routes as ASNs. If we can keep the number > of routes < 2x number of ASNs, that'd still be better. > sure... there are cases where more than 2x might happen, but an average ov 2x, perhaps that's doable. > >> >>> single prefix large enough to satisfy all of their >> current and future >>> needs (pretend that we can perfectly predict >> future needs for a moment) >>> then table size should be much smaller than today. >>> >> >> table size will grow... I'm not sure you can say >> it'll be smaller than >> today, since tomorrow there are likely many, many >> more things being >> connected to the Internet. > > It's not the things connected to the Internet which > necessarily causes table growth: it's the things which > are connected to multiple Internet providers. > Singly-homed devices should be aggregatible inside the > provider's block. As long as the allocation process > does not permit singly-homed sites to obtain PI space, > there shouldn't be an additional scale effect. > part of this problems/solution might be a dissolution of 'pi'... If I understand the ID/Loc split concept I can have a single 'ip address' forever on a single device, indepenedent of the attachment to the network(s). >> Also, keep in mind that the 'global table' isn't all >> that is the problem >> here, there are internal routes for ISP/NSP folks to >> carry, and overlay >> routes for 'services'... > > But at the very least, those internal routes need not > be known by anyone else, and each route should > represent some process or service for which the ISP is > being paid... Internal table growth to support services is impacting today's networks. It's one of the major contributing factor to pain in route- scaling today. It is likely that tomorrow that problem will continue, at the very least it won't disappear. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 19:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyC7-0004U7-NC; Wed, 08 Nov 2006 19:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyC7-0004U2-B4 for architecture-discuss@ietf.org; Wed, 08 Nov 2006 19:55:03 -0500 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhyC6-0002eo-1d for architecture-discuss@ietf.org; Wed, 08 Nov 2006 19:55:03 -0500 Received: from petal.blackrose.org (petal.blackrose.org [127.0.0.1]) by petal.blackrose.org (8.13.7/8.12.4) with ESMTP id kA90slwM027885; Wed, 8 Nov 2006 19:54:47 -0500 Received: (from dorian@localhost) by petal.blackrose.org (8.13.7/8.13.7/Submit) id kA90sll8027884; Wed, 8 Nov 2006 19:54:47 -0500 Date: Wed, 8 Nov 2006 19:54:47 -0500 From: Dorian Kim To: Chris Morrow Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Message-ID: <20061109005446.GC24751@blackrose.org> References: <20061108194803.37351.qmail@web31808.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0rc3 (petal.blackrose.org [127.0.0.1]); Wed, 08 Nov 2006 19:54:47 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Wed, Nov 08, 2006 at 07:12:35PM -0500, Chris Morrow wrote: > > On Nov 8, 2006, at 2:48 PM, David Barak wrote: > > > > >--- Chris Morrow wrote: > >>On Tue, 7 Nov 2006, Schliesser, Benson wrote: > >> > >>>It seems to me that, leaving traffic-engineering > >>aside, v6 can scale > >>>better than v4 with proper allocation rules. That > >>is, if each AS gets a > >> > >>I can't really scale 'better' if you want > >>multihoming... If you think of > >>multihoming as you would today in the current v4 > >>world. It scales about > >>the same in that case, which with a higher top end > >>means more trouble :( > > > >Valid point, but if our allocation rules are sensible, > >then the vast majority of non-transit providers should > >be fine with a single block. Even at maximum CIDR > >aggregation nowadays, we'd have multiple times the > >number of routes as ASNs. If we can keep the number > >of routes < 2x number of ASNs, that'd still be better. > > sure... there are cases where more than 2x might happen, but an > average ov 2x, perhaps that's doable. As it was observed by Vince earlier in the thread, we are going to most likely have to deal with coexistance of IPv4 and IPv6, for some reasonable period of time regardless of things play out, so IPv6 having a bit better RIB growth characteristics is likely insufficient to address the problem we are facing. Furthmore, given the market demand for multihoming and traffic engineering we don't know how many prefixes an ASN will announce even when we can assuming something close to 1 allocation per ASN. I also think that allocation policy is not sufficient a check on future table growth if there are financial incentives that are pitted against any type of allocation policy. -dorian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 20:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyIm-00086G-Gf; Wed, 08 Nov 2006 20:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyIl-00086A-6y for architecture-discuss@ietf.org; Wed, 08 Nov 2006 20:01:55 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhyIj-0003WF-Tg for architecture-discuss@ietf.org; Wed, 08 Nov 2006 20:01:55 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 19:01:53 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting Date: Wed, 8 Nov 2006 19:01:53 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Re: Notes From Monday Nights Meeting Thread-Index: AccCmlQDk3LHaXOUQBipDkSwetw1GwAASTnQ From: "Schliesser, Benson" To: X-OriginalArrivalTime: 09 Nov 2006 01:01:53.0608 (UTC) FILETIME=[A546DC80:01C7039A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I just read through Vince's slides at http://www.vaf.net/~vaf/iepg.pdf and some of his references. If I may summarize (oversimplify?) the primary objections, they come down to 1) adding more address space might lead to routing table growth beyond what humanity are capable of handling, and 2) if we lock ourselves into IPv6 right now then we might have difficulty implementing a locator/id split later. Both of these are legitimate considerations of course, and I'd like to address them in a moment. But first I want to ask, do we think it's possible, even with the weight of these concerns, to change the course of IPv6 at this point and still alleviate address exhaustion in time? As Vince points out, these concerns have been a topic of discussion for the past 20 years. Can we introduce a new architecture that addresses them and get it implemented to the same degree (coverage and maturity) as IPv6 today, quickly? I'm doubtful, and I'd rather have an imperfect routing system than face disruption from critical resource exhaustion. That said, I still want to comment on the concerns mentioned above. The first concern, that routing tables will grow beyond what we can handle, is of course a possibility. I'm not particularly swayed by the argument that we have to protect the world from the need to upgrade--this is a natural part of technology growth, and will often be a requirement to support new protocols in any case. On the other hand the argument that the routing system might grow beyond what technology can keep up with is a scary thought. But is it realistic? I understand the potential for 6M businesses to multihome (and use PI or deaggregated space), but as of yet we haven't seen even a fraction of that number. Looking at a recent Routing Report (http://thyme.apnic.net/oix-data/2006/11/08/mail-global) it appears that there are around 20k origin-only ASs. It would take an incredible change in the economics of network connectivity for this number to jump by several orders of magnitude, so I see this worst-case as unlikely. A more realistic case might be Jason Schiller's example of global IPv6 deployment in today's environment, where a Tier 1 service provider could have >500k routes and a "normal" full table (i.e. not including provider internal routes) is around 300k. This shouldn't be an issue for todays core routers. But subsequent growth from that point should be better than the projections based on the current rate. Clearly better multihoming methods, locator/id split, etc, will play an important part of this. (i.e. removing 20k origin-only ASs from the routing system would be a boon--then I'd only have to maintain routes for my competitor service providers...) But additionally we will benefit from allocation policy such as limiting v4 availability once v6 is predominantly available, giving out adequate v6 space to limit (eliminate?) the need for multiple networks per AS, etc. This alone may be enough to reduce growth rates to a supportable target. The second concern, about difficulty in implementing a locator/id split, is not an area I can claim expertise. Is there any reason why IPv6 would make a poor locator? (It seems to do that job today...) Is there a reason why it would make an ID split more difficult? If not then we should continue to encourage IPv6 deployment and plan to use it as a locator when we settle on the ID protocol some day. After all, it does solve some large and relatively short-term problems. Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 08 21:26:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhzaZ-0001BA-F2; Wed, 08 Nov 2006 21:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhzaX-0001B4-IP for architecture-discuss@ietf.org; Wed, 08 Nov 2006 21:24:21 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhzaV-0004Gt-BO for architecture-discuss@ietf.org; Wed, 08 Nov 2006 21:24:21 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 01CA2872DD; Wed, 8 Nov 2006 21:24:18 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting Message-Id: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> Date: Wed, 8 Nov 2006 21:24:18 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Schliesser, Benson" > do we think it's possible, even with the weight of these concerns, to > change the course of IPv6 at this point and still alleviate address > exhaustion in time? Look, the IPv4 ran out of addresses a decade ago (or more, I can't be bothered to work it out). NAT boxes exist in large part because of the unavailability of IPv4 address space (and in part to insulate sites from addressing changes, but I'll get to that in a second). A different kind of "running out of IPv4 addresses" is approaching, but the market will find a way to muddle through that one too (probably a market in IPv4 address space, as well as more NAT boxes), just as they decided that IPv4+NAT, ugly and imperfect as it was, was more cost-effective than an IPv6 transition. > I'd rather have an imperfect routing system than face disruption from > critical resource exhaustion. If the routing tables blow up, it won't matter how big the addresses in the packets are. > we should continue to encourage IPv6 deployment and plan to use it as a > locator when we settle on the ID protocol some day. After all, it does > solve some large and relatively short-term problems. It's precisely because IPv6 does not, in fact, solve any decent number of real problems (see comment about about insulating sites from address changes when e.g. changing ISP's, and the current discussion about multihoming, etc, etc, etc, etc) that it has spent over a decade hanging around without any real progress in terms of actual deployment. Until the IETF faces the reality, which is that customers aren't buying the IPv6 KoolAid, and makes radical changes to it to actually make it worthwhile, that state of affairs will continue. It's deeply ironic that the ID/location split, which the original IPv6 architect(s) fought bitterly against, could have been a major selling point for IPv6. A more advanced routing architecture (hell, any different routing architecture) would have helped too. Oh well, water under the bridge. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 01:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3oS-0001TP-Fa; Thu, 09 Nov 2006 01:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3oR-0001TG-7a for architecture-discuss@ietf.org; Thu, 09 Nov 2006 01:54:59 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi3oH-0007v2-Hn for architecture-discuss@ietf.org; Thu, 09 Nov 2006 01:54:59 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DA086212DFC for ; Thu, 9 Nov 2006 08:54:32 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3559A212DCA for ; Thu, 9 Nov 2006 08:54:32 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Thu, 9 Nov 2006 08:54:31 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 9, 2006, at 4:24, Noel Chiappa wrote: > Until the IETF faces the reality, > which is that customers aren't buying the IPv6 KoolAid, and makes > radical > changes to it to actually make it worthwhile, that state of affairs > will > continue. This brought to my mind something that I read recently. In the systems theory or systems dynamics, there is a behavioural pattern called "Shifting the Burden". That pattern has been known for at least a decade, probably much longer; I'm sure some of you must be familiar with it. I just haven't happened to be aware of the results the systems theory people have. Anyway, here are a couple of articles that explain the pattern: http://www.systems-thinking.org/theWay/ssb/sb.htm http://www.worldtrans.org/essay/shiftingburden.html Looking at the pattern, to me it looks pretty clear that the IETF has been stuck to the "symptomatic solution", failing to address the more fundamental problems, thereby allowing the side effects to accumulate. Yes, that in itself is nothing new; it has been argued several times with different terms. What was new to me is that the behaviour that we are seeing is common to human beings and human organisations, and well known in the systems theory. What is perhaps more worrisome, at least to me, is that the "shifting of burden" pattern easily leads to an "addiction" pattern, where there becomes a dependency to the symptomatic behaviour pattern that further inhibits the fundamental solution; see: http://www.systems-thinking.org/theWay/sad/ad.htm According to systems theory, such an addiction "make the real source of the problem, in time, even more difficult to resolve." Sad. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 08:21:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9na-0002vB-KB; Thu, 09 Nov 2006 08:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi9nZ-0002uQ-0r for architecture-discuss@ietf.org; Thu, 09 Nov 2006 08:18:29 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi9nS-0003oj-QA for architecture-discuss@ietf.org; Thu, 09 Nov 2006 08:18:28 -0500 Received: from [10.0.1.25] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20061109131816m12000bq35e>; Thu, 9 Nov 2006 13:18:21 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> Date: Thu, 9 Nov 2006 08:18:06 -0500 To: Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Thank you. I was tied up yesterday and was going to respond to the discussion going to say: Stop! Please stop this right now. We don't need yet another patch. We have been avoiding fundamentally resolving anything for the past 30 years. We are long past needing solutions. The constant patching is doing far more harm than good. People try to rationalize it as "small incremental change." Small incremental change can work, IF there is a goal. If each change is progress toward that goal. There is none here. The only goal is make the pain go away for now. Incremental change here bears more resemblance to evolution than to science and engineering. Before many of you say yes, we want things to evolve, this is good, Remember in evolution 95% of all species go extinct because their sequence of changes leads to a dead end. For evolution, this doesn't matter there are millions of species all trying different paths. Life goes on. We only have one. Which means there is a high probability we are already fairly far down a dead end path. The IETF is doing an imitation of the Faber Marching Band. But we have to quit entertaining patches. Yes, we can come up with ways to "make it work." Actually that is fairly easy. But they don't contribute to reaching a desired end state. In fact, we don't really know where each of them takes us and it is probably deeper into the woods. Remember the advice if you are lost in the woods. Stay put and let people find you! Don't wander off aimlessly. We need to establish what the solutions are and the steps we take to get there. There is more bad news. It is virtually impossible for organizations to change culture. This is well known for corporate organizations. It is even harder in committees where power is bottom up not top down. Not only is it hard to change the mind set, but there is too much vested interest in the status quo to allow a successful change. I am afraid the IETF may have become the new bell heads. Sorry to be on such a downer this morning. Take care, John At 8:54 +0200 2006/11/09, Pekka Nikander wrote: >On Nov 9, 2006, at 4:24, Noel Chiappa wrote: >>Until the IETF faces the reality, >>which is that customers aren't buying the IPv6 KoolAid, and makes radical >>changes to it to actually make it worthwhile, that state of affairs will >>continue. > >This brought to my mind something that I read recently. > >In the systems theory or systems dynamics, there is a behavioural >pattern called "Shifting the Burden". That pattern has been known >for at least a decade, probably much longer; I'm sure some of you >must be familiar with it. I just haven't happened to be aware of >the results the systems theory people have. Anyway, here are a >couple of articles that explain the pattern: > >http://www.systems-thinking.org/theWay/ssb/sb.htm >http://www.worldtrans.org/essay/shiftingburden.html > >Looking at the pattern, to me it looks pretty clear that the IETF >has been stuck to the "symptomatic solution", failing to address the >more fundamental problems, thereby allowing the side effects to >accumulate. Yes, that in itself is nothing new; it has been argued >several times with different terms. What was new to me is that the >behaviour that we are seeing is common to human beings and human >organisations, and well known in the systems theory. > >What is perhaps more worrisome, at least to me, is that the >"shifting of burden" pattern easily leads to an "addiction" pattern, >where there becomes a dependency to the symptomatic behaviour >pattern that further inhibits the fundamental solution; see: > >http://www.systems-thinking.org/theWay/sad/ad.htm > >According to systems theory, such an addiction "make the real source >of the problem, in time, even more difficult to resolve." > >Sad. > >--Pekka Nikander > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 09:23:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiAn6-00009K-LH; Thu, 09 Nov 2006 09:22:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiAn4-00008i-CF for architecture-discuss@ietf.org; Thu, 09 Nov 2006 09:22:02 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiAmz-0006wK-UK for architecture-discuss@ietf.org; Thu, 09 Nov 2006 09:22:00 -0500 Received: from 97.17.224.10.in-addr.arpa (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kA9EIArG012943; Thu, 9 Nov 2006 06:18:30 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by 97.17.224.10.in-addr.arpa (PGP Universal service); Thu, 09 Nov 2006 06:21:06 -0800 X-PGP-Universal: processed; by 97.17.224.10.in-addr.arpa on Thu, 09 Nov 2006 06:21:06 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0F616716-A1EA-4DEC-8E57-91303E4E6B13@virtualized.org> From: David Conrad Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting Date: Thu, 9 Nov 2006 06:20:43 -0800 To: X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jarno, On Nov 8, 2006, at 12:48 AM, wrote: > Existing transport stacks could be fooled by masking the LOC part to > some fixed value, so that they would effectively only see the ID? Doesn't solve the problem of higher layer protocols encoding the address they are using into their protocol stream. > Also, > the Locators could be assigned from a different address block than the > currently standardized unicast addresses so that routers would know > which are which? Yep. > Then some encouraging policy to make networks that want > to multihome to migrate to LOC/ID split? I suspect market forces will be sufficient to encourage the movement. After all, if you are an enterprise customer, wouldn't you want the ability to change ISPs without renumbering? > IMO the ID part should be allowed to be cryptographically generated. From the perspective of the routing system, the ID is opaque so it shouldn't matter how it is generated/assigned. > Something like this > could be possible with the existing IPv6 header structure with option > headers. Separating the headers would also allow for different sizes > than 64 bits for both LOC and ID. Maybe something like this should be > specified. One question that needs to be answered is "how much do we want to change?" There are several options: a) Change both the end points and the infrastructure (I call this the IPv7 approach) b) Change only the end points (every host IPv6 stack deployed to date) c) Change only the infrastructure (all routers deployed for IPv6 service) d) Change the junction between the hosts and the infrastructure (e.g., the point between the "core" and the "edge"). My personal feeling is that in terms of feasibility (that is, getting people to actually change), you'll want to minimize cost (both in financial terms as well as in deploying new technology). I'd argue option (d) is likely to be the least expensive and thus, the most likely to be deployable. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 10:13:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBZJ-00004t-7k; Thu, 09 Nov 2006 10:11:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBZH-0008WO-7q for architecture-discuss@ietf.org; Thu, 09 Nov 2006 10:11:51 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiBZF-0004Wj-Ve for architecture-discuss@ietf.org; Thu, 09 Nov 2006 10:11:51 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8A5CB872E5; Thu, 9 Nov 2006 10:11:47 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Message-Id: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> Date: Thu, 9 Nov 2006 10:11:47 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day > We have been avoiding fundamentally resolving anything for the past 30 > years. .. The constant patching is doing far more harm than good. > People try to rationalize it as "small incremental change." Small > incremental change can work, IF there is a goal. ... Yes, we can come > up with ways to "make it work." Actually that is fairly easy. But they > don't contribute to reaching a desired end state. In fact, we don't > really know where each of them takes us and it is probably deeper into > the woods. I agree wholeheartedly with all this. However... > It is virtually impossible for organizations to change culture. .. It > is even harder in committees where power is bottom up not top down. Not > only is it hard to change the mind set, but there is too much vested > interest in the status quo to allow a successful change. After the IPv6 debacle (picking a solution which was, proudly, the exact same architecture as IPv4, when, manifestly, "more of the same, just with one field bigger" was *NOT* the solution), one of my comrades-in-arms and I sat down and had a long post-mortem, the subject of which was "we failed, and not just ourselves, we failed in our duty to the network community as a whole - how did we screw up, and what could/should we have done different to have had a different outcome". The sad conclusion we came to (and if some want to say it was just rationalizing/excusing our failure, feel free, I don't give a rat's posterior any more) was that the task was, by definition, impossible. You don't get large consensus-based communities to take big leaps into the dark - and a radical architectural change is, by definition, a big leap into the dark. Yes, to a great architect, it's not a big leap - but not everyone has that kind of architectural vision. To most people, it just looks like a big, risky step into unknown territory, and they just aren't comfortable going there. So you're *never* going to get a large consensus-based group to take a big architectural step. Sorry. "An important scientific innovation rarely makes its way by gradually winning over and converting its opponents: it rarely happens that Saul becomes Paul." -- Max Planck, "The Philosophy of Physics" I expect the next big revolution in computer communications too come from some group outside the IETF, a group which is small, and designs, builds and deploys some new thing which can utilize/interoperate with the existing Internet, but is fundamentally different. Once it is seen to be good, others will take it up. Most everyone can see reality, only a few people can see visions with as much clarity as they see reality. > I am afraid the IETF may have become the new bell heads. Your conclusion is basically correct - except that I would call them the new ISO. The corollaries are amazing. The Tuba designers couldn't get the CLNP community to sign on to TUBA "because we have deployed base already, even though there's very little of it in total, and this subset of CLNP is incompatible with that base". Now we hear "we can't make what are obviously badly-needed changes to IPv6 because we already have some deployed base, although it's really very small, and this is incompatible with that base". Oh well.... > Sorry to be on such a downer this morning. "CYNIC, n. A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic's eyes to improve his vision." - Ambrose Bierce, 'The Devil's Dictionary' I don't wish to discourage people who want to try and change/improve things. I wish them well, and hope they succeed. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 10:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiC34-0006A5-Rk; Thu, 09 Nov 2006 10:42:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiC33-00069o-DD for architecture-discuss@ietf.org; Thu, 09 Nov 2006 10:42:37 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiC30-0007yL-HH for architecture-discuss@ietf.org; Thu, 09 Nov 2006 10:42:37 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kA9FgYke015441; Thu, 9 Nov 2006 07:42:34 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kA9FgYX7015440; Thu, 9 Nov 2006 07:42:34 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 9 Nov 2006 07:42:34 -0800 From: David Meyer To: Noel Chiappa Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Message-ID: <20061109154233.GA15125@1-4-5.net> References: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1451075994==" Errors-To: architecture-discuss-bounces@ietf.org --===============1451075994== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > I am afraid the IETF may have become the new bell heads. >=20 > Your conclusion is basically correct - except that I would call them the > new ISO. So...its not that I disagree here (and I understand the history/frustration/... of the whole debacle), but what I can say that I have been impressed by the desire of folks in the IETF (and the I* in particular) to take a look at what can be done in this space. I think many of the folks who were at the AMS workshop (and here, SAN IETF) might agree with me on this point. In any event, as I said in AMS, lets "give peace a chance" and see if we can't make some progress. Yeah, things were/are broken. But that's the past. Let's look forward where we can. And lets also note well that the "proof" will be in what we produce (and more importantly, what we deploy).=20 --dmm --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFU0xpORgD1qCZ2KcRAvXdAJ9sotQs/QjQ4Dw0XgiyIwZHeu/3wQCfXEc5 zkNVBLdxhVOCy9jqRHxig+w= =PqKy -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- --===============1451075994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1451075994==-- From architecture-discuss-bounces@ietf.org Thu Nov 09 11:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCTo-0003Io-6G; Thu, 09 Nov 2006 11:10:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCTn-0003Ii-38 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:10:15 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCTi-000216-JJ for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:10:15 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2006 08:07:45 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="1863344889:sNHT4798729570" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kA9G7icM015497 for ; Thu, 9 Nov 2006 08:07:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA9G7iW4024756 for ; Thu, 9 Nov 2006 08:07:44 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 08:07:44 -0800 Received: from [12.105.242.217] ([10.21.123.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 08:07:44 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Date: Thu, 9 Nov 2006 08:07:39 -0800 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Nov 2006 16:07:44.0441 (UTC) FILETIME=[30E5D290:01C70419] DKIM-Signature: a=rsa-sha1; q=dns; l=2530; t=1163088464; x=1163952464; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Systems=20theory=3A=20The=20IETF=20=22addi cted=22=20to=20=22symptomatic=20solutions=22=20aka=20=22point=20solutions= 22? |Sender:; X=v=3Dcisco.com=3B=20h=3DTXDu5A4zABM0R4nq/se2PdaNPQ0=3D; b=k/CwdyKKAy4aRcfloQ5GgoHaPuIsy3Ca0tzqRwXalkX/IkRt/tGc1qxmH+38ByBIOoo+CyWR mM2do3+vz5OLfVHQHBxqEEMGu8AzgzZ1gTD/0JKV6YBwSdNYPfpY6Mec; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Guys, maybe we should set up a different list for this discussion. I'm sure it's a very interesting and important discussion for the IETF to have about itself. That said, we have cycles for one thing. We can navel-gaze and wonder whether we need a counsellor, or we can go solve the IPv6 addressing problem. This list is for technical discussions, and right now we really need to be thinking about the technical topic. Please? On Nov 8, 2006, at 10:54 PM, Pekka Nikander wrote: > On Nov 9, 2006, at 4:24, Noel Chiappa wrote: >> Until the IETF faces the reality, >> which is that customers aren't buying the IPv6 KoolAid, and makes >> radical >> changes to it to actually make it worthwhile, that state of >> affairs will >> continue. > > This brought to my mind something that I read recently. > > In the systems theory or systems dynamics, there is a behavioural > pattern called "Shifting the Burden". That pattern has been known > for at least a decade, probably much longer; I'm sure some of you > must be familiar with it. I just haven't happened to be aware of > the results the systems theory people have. Anyway, here are a > couple of articles that explain the pattern: > > http://www.systems-thinking.org/theWay/ssb/sb.htm > http://www.worldtrans.org/essay/shiftingburden.html > > Looking at the pattern, to me it looks pretty clear that the IETF > has been stuck to the "symptomatic solution", failing to address > the more fundamental problems, thereby allowing the side effects to > accumulate. Yes, that in itself is nothing new; it has been argued > several times with different terms. What was new to me is that the > behaviour that we are seeing is common to human beings and human > organisations, and well known in the systems theory. > > What is perhaps more worrisome, at least to me, is that the > "shifting of burden" pattern easily leads to an "addiction" > pattern, where there becomes a dependency to the symptomatic > behaviour pattern that further inhibits the fundamental solution; see: > > http://www.systems-thinking.org/theWay/sad/ad.htm > > According to systems theory, such an addiction "make the real > source of the problem, in time, even more difficult to resolve." > > Sad. > > --Pekka Nikander > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 11:18:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCbn-0001gL-SO; Thu, 09 Nov 2006 11:18:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCbl-0001cS-Sd for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:18:29 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCbj-0002sX-Lb for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:18:29 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:18:27 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [CONTENT] RE: [arch-d] Re: Notes From Monday Nights Meeting Date: Thu, 9 Nov 2006 10:20:06 -0600 Message-ID: In-Reply-To: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CONTENT] RE: [arch-d] Re: Notes From Monday Nights Meeting Thread-Index: AccDpinSITjg5gCCSt6owqJYUEfEbAAbgL5w From: "Schliesser, Benson" To: X-OriginalArrivalTime: 09 Nov 2006 16:18:27.0461 (UTC) FILETIME=[B02AE350:01C7041A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] wrote: > A different kind of "running out of IPv4 > addresses" is approaching, but the market will find a way to muddle > through that one too (probably a market in IPv4 address space, > as well as more NAT boxes) Or perhaps the market will muddle through by using IPv6, imperfect as it may be. > Until the IETF faces the reality, > which is that customers aren't buying the IPv6 KoolAid, and makes radical > changes to it to actually make it worthwhile, that state of affairs will > continue. I don't want to give the impression that radical changes are undesirable. Quite the opposite, I fully endorse ongoing work towards a complete architecture. (this seems almost silly to say, it's so obviously needed) My contention is that in a sense we've missed an opportunity, and delaying a solution to our impending crisis so that we can use the crisis to motivate further change is risky. This feels like feature-creep to me, when the business really needs us to just ship a product. That is, unless shipping the product would lead to massive recalls etc, but I haven't heard any real argument to that end yet. Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 11:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCd3-0002dh-Cm; Thu, 09 Nov 2006 11:19:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCd2-0002Xw-60 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:19:48 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCcz-00030E-Tj for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:19:48 -0500 Received: from [10.0.1.25] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061109161944b1400csh84e>; Thu, 9 Nov 2006 16:19:45 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> References: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> Date: Thu, 9 Nov 2006 11:19:39 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > > I am afraid the IETF may have become the new bell heads. > >Your conclusion is basically correct - except that I would call them the >new ISO. I will have to disagree, Noel and I think the details are quite instructive. You saw it from the outside. I was there. When OSI began in March 1978 it came out of computer companies and the IFIPWG 6.1 efforts to push the connectionless approach to networking further. OSI's mistake was inviting the phone companies into the game. (This occurred in late 79 or early 80 if memory serves. Up to that time, CCITT had their own competing effort. Also remember that at this point IBM had SNA which was hierarchical. Which they understood to be completely incompatible with the peer design of packet networks. They knew their only strategy was to stall, which they did. So by 1980, OSI had 3 major poles pulling it in very different and incompatible directions.) Without deregulation it was probably impossible for the Europeans not to try to coopt the PTTs. The PTTs brought a complete incompatible view of the world and there was no way to reconcile the differences. So it ended up being two incompatible architectures. OSI's destruction was seeded entirely by its own internal contradictions. By inviting in the PTTs, there was no way that an effective result was going to emerge. The PTTs were going to do all they could to protect their status quo and were not going to allow the kind of results that would have allowed a clean effective break. Had the ISO OSI developed alone there is a good chance that significant progress would have been made and been visible to the outside world. As it was, progress was made, but it so piled up with PTT garbage that you had to know where to look. I am not arguing that OSI got it right. Because I don't think they did. It might have been a step on the path to getting it right. More data for how to get it right. There was still major things we didn't know, and even a better OSI would have been solidified before they were known and could have affected the structure. But no, to have the IETF involved in developing a new architecture is much more like OSI inviting the phone companies to participate. There is far too much vested interested in status quo to allow another consensus group to make a clean break and do what needs to be done. So the IETF are more like the new bellheads, not a new ISO. More later, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 11:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiChY-0005mA-5R; Thu, 09 Nov 2006 11:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiChW-0005lz-Tg for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:24:26 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiChV-0003SM-D3 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:24:26 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GiChF-0004S0-72 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 08:24:09 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Nov 2006 17:24:14 +0100 To: David Conrad , From: Jefsey_Morfin Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting In-Reply-To: <0F616716-A1EA-4DEC-8E57-91303E4E6B13@virtualized.org> References: <0F616716-A1EA-4DEC-8E57-91303E4E6B13@virtualized.org> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1870240436==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1870240436== Content-Type: multipart/alternative; boundary="----MTkfupcqyoilferzqroctdgwslzebeajkj" ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-729D5F40 At 15:20 09/11/2006, David Conrad wrote: One question that needs to be answered is "how much do we want to >change?" There are several options: > >a) Change both the end points and the infrastructure (I call this the >IPv7 approach) >b) Change only the end points (every host IPv6 stack deployed to date) >c) Change only the infrastructure (all routers deployed for IPv6 >service) >d) Change the junction between the hosts and the infrastructure >(e.g., the point between the "core" and the "edge"). > >My personal feeling is that in terms of feasibility (that is, getting >people to actually change), you'll want to minimize cost (both in >financial terms as well as in deploying new technology). I'd argue >option (d) is likely to be the least expensive and thus, the most >likely to be deployable. I am sorry, this is a "mono-Internet" rough consensus oriented comment! The response is not to get a rough consensus between IETF co-users for the academic 1983 Internet to roughly perform, but to document the a, b, c, d, etc. diversity and the way they are to interoperate to permit everyone to survive from the multiple messes of the mono-internet and get to the unique top quality of the Multi-Internet. The problem discussed here about IPv6 is equivalent in nature, origin, and result to the IDN in the DNS area. IPv4/DN, IPv6/IDN are equivalent problems where one hopes that details will solve universal issue. Please remember the reality is always more complex than models, and that frozen models do not escalate. All the more if they do not exist! The IETF is built on the rough consensus culture. It permitted to deploy a supernetwork over the telecom infrastructure. Great. The Catenet network of the networks. We need now a concerted consensus culture where each proposition is consensually documented by its supporters and their interoperability is rough consensually discussed. To obtain a networks of the network of networks architecture. To support brain2brain metacoms, over the end2end datacoms, over the plug2plug telecoms. Interconnectibility supporting interoperability supporting interintelligibility. Plugs are usually fixed. Ends are more and more moving. Brains are ubiquitous. Multilingualisation, multihoming, multimodes, multilateral relations are requiring solutions that the lingualised IPv4 can only support as internationalised and IPv6 options. They need more. Much more. Multi-homed, -lingual, -modal, -technology, -lateral, etc. Internet. Is this to stay an unique protocol pile, or can it benefit from uncoupling? The Internet technology managed end to end links over plug to plug lines. IMHO this is to be cleaned; and the metacom layer to be identified and developed, as such. With a different cultural approach: hardware, software, brainware. The need is building a smart IP addressing plan over a dumb stupid network numbering scheme, in devising an intelligent language management over a dumb stupid internationalisation (Unicode). Also, let stop thinking network/applications and let think continuity/services/organisation. Let stop thinking centralisation (IANA) and let start thinking distributed architecture (ex. let suppress the DNS root server system, the decentralisation of a centralised file to serve a distributed network - a pile of layer violations). This is what I understand John Day calls an operating system. Something diversified which delivers commonly accepted intelligent usages of relational services over the Internet, NGN, GENI, etc.: all these software technologies being used on the hardware of the world's digital ecosystem. The time when you said "you do what you want with the Internet, as long as it is the unique way I wrote in an RFC" is over for a long time. The problem is that the IETF did not know it, and has now to adapt before we crash. IMHO the addressing plan core is: there are 16 possible upstream and 16 downstream addresses in a switcher using an hexadecimal numbering plan. How do we best organise that routing atom/lego to best support IPv4, IPv6, IPv7, IPv8, IPv10, etc? jfc ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/html At 15:20 09/11/2006, David Conrad wrote:
One question that needs to be answered is "how much do we want to
>change?"  There are several options:
>
>a) Change both the end points and the infrastructure (I call this the
>IPv7 approach)
>b) Change only the end points (every host IPv6 stack deployed to date)
>c) Change only the infrastructure (all routers deployed for IPv6
>service)
>d) Change the junction between the hosts and the infrastructure
>(e.g., the point between the "core" and the "edge").
>
>My personal feeling is that in terms of feasibility (that is, getting
>people to actually change), you'll want to minimize cost (both in
>financial terms as well as in deploying new technology).  I'd argue
>option (d) is likely to be the least expensive and thus, the most
>likely to be deployable.

I am sorry, this is a "mono-Internet" rough consensus oriented
comment! The response is not to get a rough consensus between IETF
co-users for the academic 1983 Internet to roughly perform, but to
document the a, b, c, d, etc. diversity and the way they are to
interoperate to permit everyone to survive from the multiple messes
of the mono-internet and get to the unique top quality of the Multi-Internet.

The problem discussed here about IPv6 is equivalent in nature,
origin, and result to the IDN in the DNS area. IPv4/DN, IPv6/IDN are
equivalent problems where one hopes that details will solve universal
issue. Please remember the reality is always more complex than
models, and that frozen models do not escalate. All the more if they
do not exist!

The IETF is built on the rough consensus culture. It permitted to
deploy a supernetwork over the telecom infrastructure. Great. The
Catenet network of the networks. We need now a concerted consensus
culture where each proposition is consensually documented by its
supporters and their interoperability is rough consensually
discussed. To obtain a networks of the network of networks
architecture. To  support brain2brain metacoms, over the end2end
datacoms, over the plug2plug telecoms. Interconnectibility supporting
interoperability supporting interintelligibility. Plugs are usually
fixed. Ends are more and more moving. Brains are ubiquitous.

Multilingualisation, multihoming, multimodes, multilateral relations
are requiring solutions that the lingualised IPv4 can only support as
internationalised and IPv6 options. They need more. Much more.
Multi-homed, -lingual, -modal, -technology, -lateral, etc. Internet.

Is this to stay an unique protocol pile, or can it benefit from
uncoupling? The Internet technology managed end to end links over
plug to plug lines. IMHO this is to be cleaned; and the metacom layer
to be identified and developed, as such. With a different cultural
approach: hardware, software, brainware. The need is building a smart
IP addressing plan over a dumb stupid network numbering scheme, in
devising an intelligent language management over a dumb stupid
internationalisation (Unicode). Also, let stop thinking
network/applications and let think continuity/services/organisation.
Let stop thinking centralisation (IANA) and let start thinking
distributed architecture (ex. let suppress the DNS root server
system, the decentralisation of a centralised file to serve a
distributed network - a pile of layer violations).

This is what I understand John Day calls an operating system.
Something diversified which delivers commonly accepted intelligent
usages of relational services over the Internet, NGN, GENI, etc.: all
these software technologies being used on the hardware of the world's
digital ecosystem.

The time when you said "you do what you want with the Internet, as
long as it is the unique way I wrote in an RFC" is over for a long
time. The problem is that the IETF did not know it, and has now to
adapt before we crash.

IMHO the addressing plan core is: there are 16 possible upstream and
16 downstream addresses in a switcher using an hexadecimal numbering
plan. How do we best organise that routing atom/lego to best support
IPv4, IPv6, IPv7, IPv8, IPv10, etc?

jfc













   

------MTkfupcqyoilferzqroctdgwslzebeajkj-- --===============1870240436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1870240436==-- From architecture-discuss-bounces@ietf.org Thu Nov 09 11:27:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCj9-00075Y-5g; Thu, 09 Nov 2006 11:26:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCj7-00075M-MV for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:26:05 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCj6-0003es-Ft for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:26:05 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:26:02 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Date: Thu, 9 Nov 2006 10:27:40 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Thread-Index: AccEAec9/rJD4jlCS/23Dvwub3MWAgAFypBg From: "Schliesser, Benson" To: X-OriginalArrivalTime: 09 Nov 2006 16:26:02.0292 (UTC) FILETIME=[BF449740:01C7041B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John Day [mailto:jeanjour@comcast.net] wrote: > there is a high probability we are already fairly far down a dead > end path. > [...] > Remember the advice if you are lost in the woods. > Stay put and let people find you! Don't wander off aimlessly. Except there is a bear marching toward us, and while getting out of the woods is the goal getting away from the bear is the imperative. Of course as you point out, if we run away down a dead-end path (into the bear's cave?), then we are in an even worse condition. Is IPv6 this dead-end path, or just an imperfect solution? David Meyer [mailto:dmm@1-4-5.net] wrote: > In any event, as I said in AMS, lets "give peace a > chance" and see if we can't make some progress. Yeah, > things were/are broken. But that's the past. Let's look > forward where we can. And lets also note well that the > "proof" will be in what we produce (and more importantly, > what we deploy). That is well said--thank you, David. Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 11:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCjv-0007MV-OP; Thu, 09 Nov 2006 11:26:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCju-0007MP-Ip for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:26:54 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCjs-0003ki-7R for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:26:54 -0500 Received: from [10.0.1.25] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061109162651b1400d1j03e>; Thu, 9 Nov 2006 16:26:51 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> Date: Thu, 9 Nov 2006 11:26:47 -0500 To: Fred Baker , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I couldn't disagree more. This is an architecture-discuss list, which I take to mean that how to do architecture is part and parcel of that effort. This is precisely what this list should be discussing. Your plea is that we return to precisely the behavior pattern that has gotten us in this mess. I would even suggest that your suggestion merely serves to illustrate the point I just made in my reply to Noel. if we are going to finally start solving problems. It can't be business as usual. Perhaps the discussion of this technical point should be another list. On this list, this technical problem should be viewed from the point of view of what does this tell us about what the architecture should look like. Take care, John At 8:07 -0800 2006/11/09, Fred Baker wrote: >Guys, maybe we should set up a different list for this discussion. >I'm sure it's a very interesting and important discussion for the >IETF to have about itself. > >That said, we have cycles for one thing. We can navel-gaze and >wonder whether we need a counsellor, or we can go solve the IPv6 >addressing problem. This list is for technical discussions, and >right now we really need to be thinking about the technical topic. > >Please? > >On Nov 8, 2006, at 10:54 PM, Pekka Nikander wrote: > >>On Nov 9, 2006, at 4:24, Noel Chiappa wrote: >>>Until the IETF faces the reality, >>>which is that customers aren't buying the IPv6 KoolAid, and makes radical >>>changes to it to actually make it worthwhile, that state of affairs will >>>continue. >> >>This brought to my mind something that I read recently. >> >>In the systems theory or systems dynamics, there is a behavioural >>pattern called "Shifting the Burden". That pattern has been known >>for at least a decade, probably much longer; I'm sure some of you >>must be familiar with it. I just haven't happened to be aware of >>the results the systems theory people have. Anyway, here are a >>couple of articles that explain the pattern: >> >>http://www.systems-thinking.org/theWay/ssb/sb.htm >>http://www.worldtrans.org/essay/shiftingburden.html >> >>Looking at the pattern, to me it looks pretty clear that the IETF >>has been stuck to the "symptomatic solution", failing to address >>the more fundamental problems, thereby allowing the side effects to >>accumulate. Yes, that in itself is nothing new; it has been argued >>several times with different terms. What was new to me is that the >>behaviour that we are seeing is common to human beings and human >>organisations, and well known in the systems theory. >> >>What is perhaps more worrisome, at least to me, is that the >>"shifting of burden" pattern easily leads to an "addiction" >>pattern, where there becomes a dependency to the symptomatic >>behaviour pattern that further inhibits the fundamental solution; >>see: >> >>http://www.systems-thinking.org/theWay/sad/ad.htm >> >>According to systems theory, such an addiction "make the real >>source of the problem, in time, even more difficult to resolve." >> >>Sad. >> >>--Pekka Nikander >> >> >>_______________________________________________ >>Architecture-discuss mailing list >>Architecture-discuss@ietf.org >>https://www1.ietf.org/mailman/listinfo/architecture-discuss > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 11:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCla-00081n-3M; Thu, 09 Nov 2006 11:28:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiClY-00081a-SL for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:28:36 -0500 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiClX-0003vr-KM for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:28:36 -0500 Received: from petal.blackrose.org (petal.blackrose.org [127.0.0.1]) by petal.blackrose.org (8.13.7/8.12.4) with ESMTP id kA9GSQaw003184; Thu, 9 Nov 2006 11:28:27 -0500 Received: (from dorian@localhost) by petal.blackrose.org (8.13.7/8.13.7/Submit) id kA9GSQqG003183; Thu, 9 Nov 2006 11:28:26 -0500 Date: Thu, 9 Nov 2006 11:28:26 -0500 From: Dorian Kim To: "Schliesser, Benson" Subject: Re: [CONTENT] RE: [arch-d] Re: Notes From Monday Nights Meeting Message-ID: <20061109162826.GB2845@blackrose.org> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0rc3 (petal.blackrose.org [127.0.0.1]); Thu, 09 Nov 2006 11:28:27 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Thu, Nov 09, 2006 at 10:20:06AM -0600, Schliesser, Benson wrote: > My contention is that in a sense we've missed an opportunity, and > delaying a solution to our impending crisis so that we can use the > crisis to motivate further change is risky. Counter contention could be that we've been hearing this for the last 10+ years and how do we know it's too late until we try and see if we can make changes fly? -dorian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 11:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCx6-0005AI-AP; Thu, 09 Nov 2006 11:40:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCx4-00055s-C4 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:40:30 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiCx3-0005NM-2E for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:40:30 -0500 Received: from [10.0.1.25] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20061109164027m1300m07qbe>; Thu, 9 Nov 2006 16:40:27 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061109162826.GB2845@blackrose.org> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <20061109162826.GB2845@blackrose.org> Date: Thu, 9 Nov 2006 11:40:21 -0500 To: Dorian Kim , "Schliesser, Benson" From: John Day Subject: Re: [CONTENT] RE: [arch-d] Re: Notes From Monday Nights Meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 11:28 -0500 2006/11/09, Dorian Kim wrote: >On Thu, Nov 09, 2006 at 10:20:06AM -0600, Schliesser, Benson wrote: >> My contention is that in a sense we've missed an opportunity, and >> delaying a solution to our impending crisis so that we can use the >> crisis to motivate further change is risky. > >Counter contention could be that we've been hearing this for the last >10+ years and how do we know it's too late until we try and see if we >can make changes fly? Please remember that the "it is too late to change" or the "Internet is too large to change" are standard ploys of those trying to protect the status quo. As Noel indicated they have been used for a long time. 25 years in the Internet, that I know of! My response is the only reason not to change is if you believe that the Internet is near the end of its growth. I don't believe that. I don't believe that we are even close. I don't even think we are as close to it now than 1980 (roughly when I heard it first) was to where we are now. But then I always have been an optimist. ;-) (And as far as giving peace a chance. How long do they want? They have had 14 years!) Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 12:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDFi-0000RO-Nx; Thu, 09 Nov 2006 11:59:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDFh-0000R3-IV for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:59:45 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDFf-0007Or-4O for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:59:45 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2006 08:52:48 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="1863398497:sNHT1641226316" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kA9GqjT1000753; Thu, 9 Nov 2006 08:52:45 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA9GqjW4008825; Thu, 9 Nov 2006 08:52:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 08:52:45 -0800 Received: from [12.105.242.217] ([10.21.123.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 08:52:45 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [CONTENT] RE: [arch-d] Re: Notes From Monday Nights Meeting Date: Thu, 9 Nov 2006 08:52:43 -0800 To: "Schliesser, Benson" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Nov 2006 16:52:45.0225 (UTC) FILETIME=[7AB0C190:01C7041F] DKIM-Signature: a=rsa-sha1; q=dns; l=3173; t=1163091165; x=1163955165; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[CONTENT]=20RE=3A=20[arch-d]=20Re=3A=20Notes=20From=2 0Monday=20Nights=20Meeting |Sender:; X=v=3Dcisco.com=3B=20h=3D7iAECxI2uSwLSqIzBNOfSywqb00=3D; b=Bub38fj9YsayrydPAONlc/I+FTDdOZpjRzm/lyJ9PHyfOrj58KS8TktarqwTR724G0Ho2QmK Wq5yvnGrOCuws1uRXR644zJ5GZWj9YODhM6chVxCYJOmWPgvHAMFYfqC; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 9, 2006, at 8:20 AM, Schliesser, Benson wrote: > This feels like feature-creep to me, when the business really needs > us to just ship a product. That is, unless shipping the product > would lead to massive recalls etc, but I haven't heard any real > argument to that end yet. I'll suggest that you look through http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr http://www.vaf.net/~vaf/v6ops.pdf or (longer) http://www.vaf.net/ ~vaf/iepg.pdf Bottom line, I didn't look at GSE in the draft above, but I looked at what we're doing now, and I looked at two other things that the IETF has looked at, and compared them to the stated requirements for the problem in RFC 3582. What I came up with is that PI addressing as practiced today is very likely to put O(10^7) routes into the backbone by 2050, and by a different analysis Vince Fuller reports a similar number within 15 years. Compared to our present O(10^5) routes, that's a lot, and it drives - equipment cost: recalling that the route table is replicated in many memory systems on each high end router, how much did you want to pay for the equipment? - service delivery cost: power, cooling, ... Recall that Google is siting plants by rivers to address power and cooling now... - route scalability: BCP 38, as I discussed a few days ago, imposes some interesting issues in IPv6 routing I'm told that traffic engineering is a big deal as well, which leads me to believe that we don't have all the requirements on the table, and to be frank I'm a little peeved that after ten years of bickering and dismissive slamming of each other both IETF->ISPs and ISPs->IETF we haven't managed to get that basic step done. It's not feature-creep. There is a very expert set of people who stated up front that this problem needed to be addressed (among others), and it hasn't gotten addressed. This is kind of their last chance to get it addressed, and they really want to do so. I think it is better for us that we take the step and have an honest and non- combative discussion on the topic. The biggest problem, frankly, is that we have conflicting requirements and two communities that are willing to hurl insults rather than listen and help. An example of the conflicting requirements is that Vince and others, and many in the enterprise community, want IP addressing without the requirement to renumber when you leave a service provider, and consider that a fundamental need, while many in the ISP community see IPv6 PA addressing as a market lock and therefore something advantageous to them. Yes, I have heard those words from ISP mouths. We can't both create and not create a market lock, and whichever group we fail to please is guaranteed to be wandering around making pretty strong statements about the unresponsiveness and stupidity of the IETF community. shim6 right now creates a market lock for any customer that abhors renumbering. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 12:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDFf-0000PX-Gh; Thu, 09 Nov 2006 11:59:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDFe-0000NJ-7B for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:59:42 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDFc-0007Oa-RU for architecture-discuss@ietf.org; Thu, 09 Nov 2006 11:59:42 -0500 Received: from [10.0.1.25] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc11) with ESMTP id <20061109165936b1100fo7nie>; Thu, 9 Nov 2006 16:59:40 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> References: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> Date: Thu, 9 Nov 2006 11:59:24 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:11 -0500 2006/11/09, Noel Chiappa wrote: > > From: John Day > > > We have been avoiding fundamentally resolving anything for the past 30 > > years. .. The constant patching is doing far more harm than good. > > People try to rationalize it as "small incremental change." Small > > incremental change can work, IF there is a goal. ... Yes, we can come > > up with ways to "make it work." Actually that is fairly easy. But they > > don't contribute to reaching a desired end state. In fact, we don't > > really know where each of them takes us and it is probably deeper into > > the woods. > >I agree wholeheartedly with all this. However... > > > > It is virtually impossible for organizations to change culture. .. It > > is even harder in committees where power is bottom up not top down. Not > > only is it hard to change the mind set, but there is too much vested > > interest in the status quo to allow a successful change. > >After the IPv6 debacle (picking a solution which was, proudly, the exact same >architecture as IPv4, when, manifestly, "more of the same, just with one >field bigger" was *NOT* the solution), one of my comrades-in-arms and I sat >down and had a long post-mortem, the subject of which was "we failed, and not >just ourselves, we failed in our duty to the network community as a whole - >how did we screw up, and what could/should we have done different to have had >a different outcome". > >The sad conclusion we came to (and if some want to say it was just >rationalizing/excusing our failure, feel free, I don't give a rat's posterior >any more) was that the task was, by definition, impossible. You don't get >large consensus-based communities to take big leaps into the dark - and >a radical architectural change is, by definition, a big leap into the dark. > >Yes, to a great architect, it's not a big leap - but not everyone has that >kind of architectural vision. To most people, it just looks like a big, risky >step into unknown territory, and they just aren't comfortable going there. >So you're *never* going to get a large consensus-based group to take a big >architectural step. Sorry. Fundamentally you are correct. Consensus organizations are inherently conservative. However, this particular issue was immensely complicated by the fact that the academic community had completely failed to teach the principles of networking and had turned it into a purely vocational education task. I remember being completely surprised how few people understood the addressing issues that surrounded that fiasco. They were understood in the circles I had been in and was completely surprised by how few understood them then or now. (You can see this problem in the frequency with which we get the question on various lists "Why can't we have portable IP addresses?" For me, this is a sure sign that the basics were never taught. > "An important scientific innovation rarely makes its way by gradually > winning over and converting its opponents: it rarely happens that Saul > becomes Paul." -- Max Planck, "The Philosophy of Physics" > >I expect the next big revolution in computer communications too come from some >group outside the IETF, a group which is small, and designs, builds and >deploys some new thing which can utilize/interoperate with the existing >Internet, but is fundamentally different. Once it is seen to be good, others >will take it up. You are right. It can't come from the IETF. >Most everyone can see reality, only a few people can see visions with as much >clarity as they see reality. > > > > I am afraid the IETF may have become the new bell heads. > >Your conclusion is basically correct - except that I would call them the >new ISO. See previous note. >The corollaries are amazing. The Tuba designers couldn't get the CLNP >community to sign on to TUBA "because we have deployed base already, even >though there's very little of it in total, and this subset of CLNP is >incompatible with that base". Now we hear "we can't make what are obviously >badly-needed changes to IPv6 because we already have some deployed base, >although it's really very small, and this is incompatible with that base". Isn't that rationale (both then and now) just doublespeak for "I am holding out because I still believe my position will finally win"? ;-) I am really saddened when I see an organization that I believed was suppose to be dedicated to straight shooting and telling it like it is resort to spin and marketing hype of the sort we just suffered through in the US for the past few weeks. >Oh well.... > > > > Sorry to be on such a downer this morning. > >"CYNIC, n. A blackguard whose faulty vision sees things as they are, not as >they ought to be. Hence the custom among the Scythians of plucking out a >cynic's eyes to improve his vision." - Ambrose Bierce, 'The Devil's >Dictionary' > >I don't wish to discourage people who want to try and change/improve things. >I wish them well, and hope they succeed. Glad you are so upbeat! ;-) John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 12:00:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDGC-000169-90; Thu, 09 Nov 2006 12:00:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDGB-000164-Oc for architecture-discuss@ietf.org; Thu, 09 Nov 2006 12:00:15 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDG9-0007Sk-Ab for architecture-discuss@ietf.org; Thu, 09 Nov 2006 12:00:15 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GiDG7-00058J-Of for architecture-discuss@ietf.org; Thu, 09 Nov 2006 09:00:12 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Nov 2006 18:00:20 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: Jefsey_Morfin Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? In-Reply-To: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> References: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-729D5F40; boundary="=======AVGMAIL-45535EA471ED=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --=======AVGMAIL-45535EA471ED======= Content-Type: multipart/alternative; boundary="=====================_12287265==.ALT"; x-avg-checked=avg-ok-729D5F40 --=====================_12287265==.ALT Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-729D5F40 At 16:11 09/11/2006, Noel Chiappa wrote: >I expect the next big revolution in computer communications too come >from some group outside the IETF, a group which is small, and >designs, builds and deploys some new thing which can >utilize/interoperate with the existing Internet, but is >fundamentally different. Once it is seen to be good, others will take it up. Full agreement. Except that "computer communications" have probably delivered the most they can deliver. We have curbed "human relations" through the "computer communications" channel. This is what is to be corrected. So "human relations" take the lead and we can work on "computer cooperated human relations". I use to say that the problem is to know who is the master and who is the slave. RFC 3935 says that the master is the IETF which is to "influence the way people design, use, and manage the Internet". The reason why is to protect stability ("don't fix what ai'nt broke"), what leads to status quo [and market share protection] and maintenance. Not to innovation. >Most everyone can see reality, only a few people can see visions >with as much clarity as they see reality. Correct. We have to start from what we have. - the digital ecosystem - the IPv4 half-internationalised Internet, and other communications digitalised or digitalising services - the work on metadata by JTC1 - the list of the services we want to support from no-spam mail to TV, through telephone, mobiles, web, domotic, etc. - the need of an economical model - the impossibility to change the world in less than 10 years. - 7 billions of possible users and a ten times more computers, appliances, cars, washing machines, etc. IMHO the only way to proceed is to be user centric and to start from the users systems (SNHN - smart small standalone network/home network). What Microsoft/Linux failed to understand up to now. But ... Then to allocate each user a reasonable IPv6 address set (using the ITU /3 ? - along the telephone scheme?) At this time not for routing but for identification and architecture debugging purpose. Then to allocate each user its own DNS root. Not to create alt-roots, but to push their externets (external network look-alike) to federate in an adequate ways. Then to help organising user relational spaces matching their needs with the ecology of the digital ecosystem. Until this leads to various relational continuities people will be happy with. This is what I qualified as user/usage centric when I joined this list. I do not think that without a serious global model of the digital ecosystem it is possible to continue working on global solutions. But one can document individual solutions so they globally deploy in the real existing world. And in working better, better understand the digital ecosystem model we will want to better adapt to. jfc --=====================_12287265==.ALT Content-Type: text/html; charset=us-ascii; x-avg-checked=avg-ok-729D5F40 At 16:11 09/11/2006, Noel Chiappa wrote:
I expect the next big revolution in computer communications too come from some group outside the IETF, a group which is small, and designs, builds and deploys some new thing which can utilize/interoperate with the existing Internet, but is fundamentally different. Once it is seen to be good, others will take it up.

Full agreement. Except that "computer communications" have probably delivered the most they can deliver. We have curbed "human relations" through the "computer communications" channel. This is what is to be corrected. So "human relations" take the lead and we can work on "computer cooperated human relations". I use to say that the problem is to know who is the master and who is the slave. RFC 3935 says that the master is the IETF which is to "influence the way people design, use, and manage the Internet". The reason why is to protect stability ("don't fix what ai'nt broke"), what leads to status quo [and market share protection] and maintenance. Not to innovation.

Most everyone can see reality, only a few people can see visions with as much clarity as they see reality.

Correct. We have to start from what we have.

- the digital ecosystem
- the IPv4 half-internationalised Internet, and other communications digitalised or digitalising services
- the work on metadata by JTC1
- the list of the services we want to support from no-spam mail to TV, through telephone, mobiles, web, domotic, etc.
- the need of an economical model
- the impossibility to change the world in less than 10 years.
- 7 billions of possible users and a ten times more computers, appliances, cars, washing machines, etc.

IMHO the only way to proceed is to be user centric and to start from the users systems (SNHN - smart small standalone network/home network). What Microsoft/Linux failed to understand up to now. But ... Then to allocate each user a reasonable IPv6 address set (using the ITU /3 ? - along the telephone scheme?) At this time not for routing but for identification and architecture debugging purpose. Then to allocate each user its own DNS root. Not to create alt-roots, but to push their externets (external network look-alike) to federate in an adequate ways. Then to help organising user relational spaces matching their needs with the ecology of the digital ecosystem. Until this leads to various relational continuities people will be happy with.

This is what I qualified as user/usage centric when I joined this list. I do not think that without a serious global model of the digital ecosystem it is possible to continue working on global solutions. But one can document individual solutions so they globally deploy in the real existing world. And in working better, better understand the digital ecosystem model we will want to better adapt to.

jfc






--=====================_12287265==.ALT-- --=======AVGMAIL-45535EA471ED======= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=======AVGMAIL-45535EA471ED=======-- From architecture-discuss-bounces@ietf.org Thu Nov 09 12:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDst-0000JL-12; Thu, 09 Nov 2006 12:40:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDsr-0000If-MC for architecture-discuss@ietf.org; Thu, 09 Nov 2006 12:40:13 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDsq-0004PX-D5 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 12:40:13 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1CEF3872CA; Thu, 9 Nov 2006 12:40:12 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Message-Id: <20061109174012.1CEF3872CA@mercury.lcs.mit.edu> Date: Thu, 9 Nov 2006 12:40:12 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day [Skip a bunch of stuff I agree with] >> The Tuba designers couldn't get the CLNP community to sign on to TUBA >> "because we have deployed base already, even though there's very >> little of it in total, and this subset of CLNP is incompatible with >> that base". Now we hear "we can't make what are obviously badly-needed >> changes to IPv6 because we already have some deployed base, although >> it's really very small, and this is incompatible with that base". > Isn't that rationale (both then and now) just doublespeak for "I am > holding out because I still believe my position will finally win"? ;-) Yes and no. I mean, I don't think their thought train was simply "this will succeed just the way it is, so who needs to make changes". I think they really were concerned about installed base - but at the same time, they had to have been thinking "this will succeed just the way it is", because if the choice is between a) making changes, and b) total failure, most people will go with a). >> I would call them the new ISO. > I will have to disagree, ... You saw it from the outside. I was there. > ... by 1980, OSI had 3 major poles pulling it in very different and > incompatible directions. ... it ended up being two incompatible > architectures. OSI's destruction was seeded entirely by its own > internal contradictions. Actually, we don't disagree, because I wasn't explicit enough: I wasn't speaking of the processes/environments which created the ISO stack and IPv6, which I agree with you are not similar (the dynamics which created IPv6 were very different). Rather, I was thinking of i) the attitude of the respective communities to deployment (which seemed in both cases to have a strong flavour of an arrogant "we built it, therefore they will come, the competition is beneath our notice" - until it was too late), and ii) in particular detail, of resistance to change to increase the chances of success. > The PTTs were going to do all they could to protect their status quo > and were not going to allow the kind of results that would have allowed > a clean effective break. Although that part sounds familiar! :-) (Some of us wanted a radically different kind of network at the internetworking layer - one, oddly enough, which would have been a *perfect* fit for today's highly-optical systems. Nimrod virtual links for traffic aggregates map perfectly onto lamda-switched paths... but I digress.) > Had the ISO OSI developed alone there is a good chance that significant > progress would have been made and been visible to the outside world. As > it was, progress was made, but it so piled up with PTT garbage that you > had to know where to look. Alas, not sure I can even say that about this case... > to have the IETF involved in developing a new architecture is much more > like OSI inviting the phone companies to participate. There is far too > much vested interested in status quo to allow another consensus group > to make a clean break and do what needs to be done. Yes and no. In the particular case of routing, I don't think it's so much "vested interests", as something even simpler: people understand how the current thing works, and the new stuff is just a little too wierd and unfamiliar and "have to unscrew your head and screw it on again sideways". Yes, at the edges, that can turn into vested interests ("I know how to tweak Cisco configs to make it do traffic engineering the way we want"), but I think for most people the wierd/unfamiliar thing is bigger. Particularly because they are so deep in alligators they don't have the spare energy/ cycles/etc to think of doing something radically new. And with that, we have cycled back to Pekka's original post in this subthread... Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 13:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEXq-0003JD-Pt; Thu, 09 Nov 2006 13:22:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEXq-0003Ii-0J for architecture-discuss@ietf.org; Thu, 09 Nov 2006 13:22:34 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEXl-0001S7-Kx for architecture-discuss@ietf.org; Thu, 09 Nov 2006 13:22:33 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 8654F4AC78; Thu, 9 Nov 2006 13:22:27 -0500 (EST) Date: Thu, 9 Nov 2006 13:22:27 -0500 From: John Leslie To: Fred Baker Subject: Re: [CONTENT] RE: [arch-d] Re: Notes From Monday Nights Meeting Message-ID: <20061109182225.GB21864@verdi> References: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred Baker wrote: > > I'll suggest that you look through > http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis (33 pages)... written as advice to IP address registries: it is unlikely that registries can do much about the problem. :^( > http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis (52 pages)... analysis of GSE proposal; I haven't read it either. > http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr (20 pages)... the GSE proposal: calls for rewriting addresses at site boundaries. At first blush, it looks like automated renumbering for re-homing to a different upstream... > http://www.vaf.net/~vaf/v6ops.pdf or (longer) http://www.vaf.net/ > ~vaf/iepg.pdf (19 slides)... explains why provider-independent routing-as-we- know-it can't work. > Bottom line, I didn't look at GSE in the draft above, but I looked at > what we're doing now, and I looked at two other things that the IETF > has looked at, and compared them to the stated requirements for the > problem in RFC 3582. What I came up with is that PI addressing as > practiced today is very likely to put O(10^7) routes into the > backbone by 2050... Clearly unworkable! (I'll let others discuss the perpetual-motion-machines they envision to get around this routing problem...) > I'm told that traffic engineering is a big deal as well, which leads > me to believe that we don't have all the requirements on the table, > and to be frank I'm a little peeved that after ten years of bickering > and dismissive slamming of each other both IETF->ISPs and ISPs->IETF > we haven't managed to get that basic step done. Our problem is architectural: asking the routing infrastructure to solve the reliability problem which multi-homing intends to address can only decrease the reliability of the routing infrastructure. (I shall briefly resist the temptation to give an "obvioous" answer.) > It's not feature-creep. There is a very expert set of people who > stated up front that this problem needed to be addressed (among > others), and it hasn't gotten addressed. This is kind of their last > chance to get it addressed, and they really want to do so. I think it > is better for us that we take the step and have an honest and non- > combative discussion on the topic. By all means. But let's separate it from what particular protocol we use for inter-netting. > The biggest problem, frankly, is that we have conflicting > requirements and two communities that are willing to hurl insults > rather than listen and help. An example of the conflicting > requirements is that Vince and others, and many in the enterprise > community, want IP addressing without the requirement to renumber > when you leave a service provider, and consider that a fundamental > need, Examine that statement carefully: it's not quite correct. They want end-user source- and destination-addressing that need not change when a particular upstream ceases to provide what they need for reasonable prices and conditions. We'd be _very_ poorly advised to (try to) deny them this. > while many in the ISP community see IPv6 PA addressing as a > market lock and therefore something advantageous to them. The upstream providers want sufficient lock-in that they can pass through any cost increases without worrying about losing their customers. Without this, their businesses are more likely to fail. > We can't both create and not create a market lock, and whichever > group we fail to please is guaranteed to be wandering around > making pretty strong statements about the unresponsiveness and > stupidity of the IETF community. IMHO, we can't create this market lock, period. The ISPs must create it themselves (and I don't believe they'll succeed). We should, however, beware "reasonable-sounding" calls to "protect the infrastructure" by helping them create such locks. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 15:36:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGbe-0003Df-Se; Thu, 09 Nov 2006 15:34:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGbd-0003Cp-K8 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 15:34:37 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGbZ-0005CB-3n for architecture-discuss@ietf.org; Thu, 09 Nov 2006 15:34:37 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E6B6C212DFC for ; Thu, 9 Nov 2006 22:34:02 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6EA97212DCA for ; Thu, 9 Nov 2006 22:34:02 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Thu, 9 Nov 2006 22:34:02 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [arch-d] =?iso-8859-1?q?=5BOff-topic=5D=A0Further_thoughts=3A_ab?= =?iso-8859-1?q?out_systems_theory_and_the_theory_U?= X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org While I appreciate Fred's plea not to continue with non-technical discussion here, I don't think the general discussion list nor the e2e-interest lists are would be the right places either. We do have an architectural problem, that far I think we almost all agree. While we could argue about the detail problems ad infinum, it is pretty clear the Internet architecture as it was 20 years ago, and very much is considered to still be, doesn't work _that_well_ any more. That it, it still "works", for some definition of "works", but it could work much better. To me, the systems theory pattern was enlightening. It gave a behavioural, sociological explanation why we, i.e. the IETF, IAB, and IRTF, fail to discuss the architecture in the fundamental sense. We simply seem to be, as organisations, addicted to the current way of working. More important, however, might be the suggested aids. To copy from the web page I referred to: > 1. When dealing with a problem ask yourself if you are treating the > symptoms or addressing the real cause of the problem. Often, out of > expediency, the symptomatic solution is essential. The most > effective strategy for dealing with a Shifting the Burden structure > is an employment of the symptomatic solution AND development of the > fundamental solution. Thus one resolves the immediate problem and > works to ensure that it doesn't return. > > 2. If the structure promotes the development of an addiction then > you have another problem so solve. So, we seem to have three different problems to solve: 1. Creating new symptomatic solutions to address the short term needs. 2. Creating new fundamental solutions to address the fundamental problems. 3. Working out a structure that does not promote this addiction any more. IMHO, on this list we should focus on the middle one, to the extend we can. So, my apologies for this side track, but I think this side track is needed. The IETF in general takes pretty well care of the first one. I have no idea if there is any part of the current I* organisation that could really ponder about the last one, but maybe there is. At least there are brave people out there; perhaps this ongoing discussion could give some common direction to them. As a community, we have tried, in different ways over the years, discuss the fundamental architectural issues. We have had good ideas, many of which have been published. Almost all have died, and those that are still alive are not doing too well. Hence, some very fundamental changes seem to be needed. We, as an organisation, need to learn and change, I'm afraid. I cannot claim to be any expert of organisational learning. However, one particular organisational learning theory has recently gained my attention, and seems to have its roots deep: The Theory U, by Scharmer et al from MIT Sloan School of Management. For a good presentation of the central ideas, see http://www.learninggroup.org/ dec05presentation.pdf From the I* point of view, trying the U would mean really deep diving. I guess some old timers would recognise such deep diving, but I haven't seen it in any larger nor smaller scale, though. The current structure of our discussions just doesn't create the necessary space for such state of mind. However, only something like that would provide any real change to the architecture, I'm afraid. Very difficult, but perhaps not impossible. The next question for this forum, then, would be how to apply the U theory to the fundamental architectural problem, i.e., problem #2 above. I have no answer to that. But perhaps someone has. Or perhaps someone can point to a knowledgeable argument showing that this train of thought is completely pointless. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 17:01:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHwX-0008Df-Uw; Thu, 09 Nov 2006 17:00:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHwW-0008DT-MR for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:00:16 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHwV-0002Vo-Af for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:00:16 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kA9M0Ebm028405; Thu, 9 Nov 2006 14:00:14 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kA9M0ASc028404; Thu, 9 Nov 2006 14:00:10 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 9 Nov 2006 14:00:10 -0800 From: David Meyer To: Pekka Nikander Subject: Re: [arch-d] =?iso-8859-1?Q?=5BOff-topic?= =?iso-8859-1?Q?=5D=A0Furthe?= =?iso-8859-1?Q?r?= thoughts: about systems theory and the theory U Message-ID: <20061109220010.GA28334@1-4-5.net> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> Mime-Version: 1.0 In-Reply-To: <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154729485==" Errors-To: architecture-discuss-bounces@ietf.org --===============0154729485== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Pekka, > While I appreciate Fred's plea not to continue with non-technical =20 We plan to use this list for discussion of the outcomes of the routing and addressing workshop, and about the (technical) ways forward. If you desire a mailing list for non-technical issues (such as organizational theory), please set one up. We do, however, need to focus on the our task, and this is the list that we're going to use for that. Please respect this request. Thnx, --dmm --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFU6TqORgD1qCZ2KcRAlGQAJ90XroJ7lWejKNSPBCD5XOPVBxDPACfTBlR nu3XeltYpIVEU5bQ625Q96Q= =cXPT -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- --===============0154729485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0154729485==-- From architecture-discuss-bounces@ietf.org Thu Nov 09 17:11:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiI6O-0006Kz-67; Thu, 09 Nov 2006 17:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiI6M-0006Fr-PR for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:10:26 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiI6L-0003pQ-GZ for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:10:26 -0500 Received: from [10.0.1.25] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20061109221007m1300me0moe>; Thu, 9 Nov 2006 22:10:24 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061109220010.GA28334@1-4-5.net> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> <20061109220010.GA28334@1-4-5.net> Date: Thu, 9 Nov 2006 17:08:32 -0500 To: David Meyer , Pekka Nikander From: John Day Subject: Re: [arch-d] [Off-topic ] Furthe r thoughts: about systems theory and the theory U Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I guess the question is more, where should the architecture discussions go if this is going to be dedicated to routing and addressing? Just curious, John At 14:00 -0800 2006/11/09, David Meyer wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" >Content-Disposition: inline > > Pekka, > >> While I appreciate Fred's plea not to continue with non-technical > > We plan to use this list for discussion of the outcomes > of the routing and addressing workshop, and about the > (technical) ways forward. If you desire a mailing list > for non-technical issues (such as organizational theory), > please set one up. We do, however, need to focus on the > our task, and this is the list that we're going to use > for that. Please respect this request. > > Thnx, > > --dmm > >Attachment converted: Macintosh HD:Untitled 1 ( / ) (0047BDDF) >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 17:19:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIDx-0000qn-50; Thu, 09 Nov 2006 17:18:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIDw-0000nn-B3 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:18:16 -0500 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIDu-0005Xr-Vg for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:18:16 -0500 Received: from [130.129.71.116] (dhcp71-116.ietf67.org [130.129.71.116]) by kiwi.cs.ucla.edu (8.13.7+Sun/8.13.7/UCLACS-6.0) with ESMTP id kA9MIDlo021340; Thu, 9 Nov 2006 14:18:13 -0800 (PST) In-Reply-To: References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> <20061109220010.GA28334@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15BDBF21-B39B-4342-8DEA-02CDA901E49E@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [arch-d] [Off-topic ] Furthe r thoughts: about systems theory and the theory U Date: Thu, 9 Nov 2006 14:18:19 -0800 To: John Day X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.6 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 9, 2006, at 2:08 PM, John Day wrote: > I guess the question is more, where should the architecture > discussions go if this is going to be dedicated to routing and > addressing? routing and addressing discussion is architecture discussion. > Just curious, > John e2e-interest list has been used for many other architectural discussions. > > At 14:00 -0800 2006/11/09, David Meyer wrote: >> Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" >> Content-Disposition: inline >> >> Pekka, >> >>> While I appreciate Fred's plea not to continue with non-technical >> >> We plan to use this list for discussion of the outcomes >> of the routing and addressing workshop, and about the >> (technical) ways forward. If you desire a mailing list >> for non-technical issues (such as organizational theory), >> please set one up. We do, however, need to focus on the >> our task, and this is the list that we're going to use >> for that. Please respect this request. >> >> Thnx, >> >> --dmm >> >> Attachment converted: Macintosh HD:Untitled 1 ( / ) (0047BDDF) >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 18:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJT3-0005Tl-Uj; Thu, 09 Nov 2006 18:37:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJT2-0005SZ-Ub for architecture-discuss@ietf.org; Thu, 09 Nov 2006 18:37:56 -0500 Received: from mx.freeshell.org ([192.94.73.18] helo=sdf.lonestar.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJT1-0006De-Il for architecture-discuss@ietf.org; Thu, 09 Nov 2006 18:37:56 -0500 Received: from sdf.lonestar.org (IDENT:locks@norge.freeshell.org [192.94.73.3]) by sdf.lonestar.org (8.13.5.20060308/8.13.8) with ESMTP id kA9NbTe5018409; Thu, 9 Nov 2006 23:37:29 GMT Received: (from locks@localhost) by sdf.lonestar.org (8.13.8/8.12.8/Submit) id kA9NbHR9015691; Thu, 9 Nov 2006 23:37:17 GMT Date: Thu, 9 Nov 2006 23:37:17 +0000 (UTC) From: Alexis Turner X-X-Sender: locks@norge.freeshell.org To: David Meyer Subject: Re: [arch-d] =?iso-8859-1?Q?=5BOff-topic?= =?iso-8859-1?Q?=5D=A0Furthe?= =?iso-8859-1?Q?r?= thoughts: about systems theory and the theory U In-Reply-To: <20061109220010.GA28334@1-4-5.net> Message-ID: References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> <20061109220010.GA28334@1-4-5.net> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============0154729485==" Content-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: subbies@redheadedstepchild.org List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============0154729485== Content-Type: TEXT/PLAIN; charset=US-ASCII Well, that succinctly summed up why the net is broken - because no one wants to actually think about it. -A. --===============0154729485== Content-Type: MULTIPART/SIGNED; MICALG=pgp-sha1; PROTOCOL="application/pgp-signature"; BOUNDARY=rwEMma7ioTxnRzrJ Content-ID: Content-Description: Content-Disposition: INLINE This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --rwEMma7ioTxnRzrJ Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Content-Disposition: INLINE Pekka, > While I appreciate Fred's plea not to continue with non-technical =20 We plan to use this list for discussion of the outcomes of the routing and addressing workshop, and about the (technical) ways forward. If you desire a mailing list for non-technical issues (such as organizational theory), please set one up. We do, however, need to focus on the our task, and this is the list that we're going to use for that. Please respect this request. Thnx, --dmm --rwEMma7ioTxnRzrJ Content-Type: APPLICATION/PGP-SIGNATURE; CHARSET=US-ASCII Content-ID: Content-Disposition: INLINE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFU6TqORgD1qCZ2KcRAlGQAJ90XroJ7lWejKNSPBCD5XOPVBxDPACfTBlR nu3XeltYpIVEU5bQ625Q96Q= =cXPT -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- --===============0154729485== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0154729485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0154729485==-- From architecture-discuss-bounces@ietf.org Thu Nov 09 19:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKVR-00082o-Vs; Thu, 09 Nov 2006 19:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKVR-0007zz-0T for architecture-discuss@ietf.org; Thu, 09 Nov 2006 19:44:29 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKVO-0007Ob-D7 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 19:44:28 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kAA0iATO002194; Thu, 9 Nov 2006 16:44:10 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAA0i6Jc002193; Thu, 9 Nov 2006 16:44:06 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 9 Nov 2006 16:44:06 -0800 From: David Meyer To: Alexis Turner Subject: Re: [arch-d] =?iso-8859-1?Q?=5BOff-topic?= =?iso-8859-1?Q?=5D=A0Furthe?= =?iso-8859-1?Q?r?= thoughts: about systems theory and the theory U Message-ID: <20061110004406.GA2112@1-4-5.net> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> <20061109220010.GA28334@1-4-5.net> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0538556720==" Errors-To: architecture-discuss-bounces@ietf.org --===============0538556720== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 09, 2006 at 11:37:17PM +0000, Alexis Turner wrote: > Well, that succinctly summed up why the net is broken - because > no one wants to actually think about it. Well, that's really not a fair statement. A lot of folks care deeply and spend a lot of time thinking about what the problems are (both technical, organizational, and admistrative), and how they might be addressed. =20 What I do think we need, however, is a place to have a focused discussion about the problem space and potential solutions, and if this doesn't turn out to be the right place to do it, that's ok.=20 So let's stop trashing one another and get on to the work at hand. =20 --dmm --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFU8tWORgD1qCZ2KcRAr24AJ4lCLavm/qwl8fcBIha0vvSFZOP8ACeK0mM DmSsrR8zUZLlavdjnXOiPe0= =t8BC -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- --===============0538556720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0538556720==-- From architecture-discuss-bounces@ietf.org Thu Nov 09 20:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiL8l-0006vc-7A; Thu, 09 Nov 2006 20:25:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiL8k-0006vU-BO for architecture-discuss@ietf.org; Thu, 09 Nov 2006 20:25:06 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiL8j-0003ut-2p for architecture-discuss@ietf.org; Thu, 09 Nov 2006 20:25:06 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BC0A986AE1; Thu, 9 Nov 2006 20:25:04 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] =?iso-8859-1?Q?=5BOff-topic?= =?iso-8859-1?Q?=5D=A0Furthe?= =?iso-8859-1?Q?r?= thoughts: about systems theory and the theory U Message-Id: <20061110012504.BC0A986AE1@mercury.lcs.mit.edu> Date: Thu, 9 Nov 2006 20:25:04 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Meyer > We plan to use this list for discussion of the outcomes of the routing > and addressing workshop, and about the (technical) ways forward. ... We > do, however, need to focus on the our task, and this is the list that > we're going to use for that. David, that's all well and good, but architecture isn't engineering either - and that needs to happen elsewhere too - that's what IETF WG's (and, in particular, design groups of WG's) are for. These are the kind of questions I think of when I think of architecture, at least in the current region of discussion: - 1) What are the classes of objects we have names for - 2) What are the characteristics of the namespace(s) for each kind of object I'm kind of fried at the moment, so I can't think of what others I should list. John, what am I missing? Questions like "how many bits should this field in the name be" and "what's the mechanism to map between namespace A and namespace B" are *not* architecture; they are engineering. Which brings up one I missed: - 3) Which namespaces do we need to be able to map beween? (E.g. given a bare EID, do we need to be able to turn that into a locator, or is the expectation that they always travel in pairs, and that a DNS lookup always returns the pair?) Are the answers to these settled, or do they need more work? The NSRG started to think heavily about these issues, but we were just getting into it when the effort died, for a variety of reasons. A long time ago I put a stake in the ground on 1, claiming that we should name a) network interfaces (i.e. places the system of routers deliver packets to), and b) fatesharing entities which participate in end-end communication. (In other words, something like "one end of a TCP connection(s), along with the application(s) using it".) I've sometimes wondered since, in light of things like server farms, etc whether that was really the right thing, whether we shouldn't in fact be naming higher-level things. (So that, e.g., the actual server you could be talking to die, but there was some shared transaction state that another server could get to, and you could keep going, but with a new TCP connection - which is what clicking from page to page on web sites will do for you. We do this now in an ad-hoc way with cookies, and data in URL's, but is there a need for something more formal?) But perhaps I was correct to begin with, and we do need names for end-end things, and we *also* need a higher level of naming for the applications. I don't think a mailing list is the way to answer these kinds of questions. You have to take <12 very smart people, and put them in a room for 3 days, and lock the door and keep everyone else out. Sorry, but to quote Brooks, ("Mythical Man-Month", chapter 4, 'Aristocracy, Democracy and System Design') "there must be few architects". Sure, their output should be reviewed and commented on by everyone, once the door opens, and perhaps they need to close the door again and respin, but from experience with NSRG (particularly one design sub-group), and looking at the vagueness of the questions above, any attempt to discuss such issues on a mailing list with many people on it, all dropping a comment in here and there, will not reach closure. It was hard enough in a small room with 4 people actually phsyically there.... Or do you think the community is ready to just "ship it" with something like the endpoints concept - add naming of endpoints, and split IPv6 addresses in half to name the two classes of things, and call it a day quickly on the architecture? Which sounds a lot like a quick kludge, actually. Then again, some quick kludges (e.g. CIDR) have been reasonably good. But they aren't as good as starting from scratch, of course. CIDR bought us a few years, but it's hardly a "possession for all time". Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 20:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLIF-0004CE-WE; Thu, 09 Nov 2006 20:34:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLIF-0004C9-2X for architecture-discuss@ietf.org; Thu, 09 Nov 2006 20:34:55 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLID-0004wl-Jt for architecture-discuss@ietf.org; Thu, 09 Nov 2006 20:34:55 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kAA1YSva004393; Thu, 9 Nov 2006 17:34:28 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAA1YS1C004392; Thu, 9 Nov 2006 17:34:28 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 9 Nov 2006 17:34:28 -0800 From: David Meyer To: Noel Chiappa Subject: Re: [arch-d] =?iso-8859-1?Q?=5BOff-topic?= =?iso-8859-1?Q?=5D=A0Furthe?= =?iso-8859-1?Q?r?= thoughts: about systems theory and the theory U Message-ID: <20061110013428.GA4322@1-4-5.net> References: <20061110012504.BC0A986AE1@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20061110012504.BC0A986AE1@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0152558203==" Errors-To: architecture-discuss-bounces@ietf.org --===============0152558203== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 09, 2006 at 08:25:04PM -0500, Noel Chiappa wrote: > > From: David Meyer >=20 > > We plan to use this list for discussion of the outcomes of the rout= ing > > and addressing workshop, and about the (technical) ways forward. ..= . We > > do, however, need to focus on the our task, and this is the list th= at > > we're going to use for that. >=20 > David, that's all well and good, but architecture isn't engineering eithe= r - > and that needs to happen elsewhere too - that's what IETF WG's (and, in > particular, design groups of WG's) are for. >=20 >=20 > These are the kind of questions I think of when I think of architecture, > at least in the current region of discussion: >=20 > - 1) What are the classes of objects we have names for > - 2) What are the characteristics of the namespace(s) for each kind of ob= ject >=20 > I'm kind of fried at the moment, so I can't think of what others I should= list. > John, what am I missing? Understood. Maybe we need more than one list? > Questions like "how many bits should this field in the name be" and "what= 's > the mechanism to map between namespace A and namespace B" are *not* > architecture; they are engineering. Which brings up one I missed: >=20 > - 3) Which namespaces do we need to be able to map beween? (E.g. given a > bare EID, do we need to be able to turn that into a locator, or is the > expectation that they always travel in pairs, and that a DNS lookup always > returns the pair?) >=20 > Are the answers to these settled, or do they need more work? The NSRG sta= rted > to think heavily about these issues, but we were just getting into it when > the effort died, for a variety of reasons. >=20 >=20 > A long time ago I put a stake in the ground on 1, claiming that we should > name a) network interfaces (i.e. places the system of routers deliver pac= kets > to), and b) fatesharing entities which participate in end-end communicati= on. > (In other words, something like "one end of a TCP connection(s), along wi= th > the application(s) using it".) >=20 > I've sometimes wondered since, in light of things like server farms, etc > whether that was really the right thing, whether we shouldn't in fact be > naming higher-level things. (So that, e.g., the actual server you could be > talking to die, but there was some shared transaction state that another > server could get to, and you could keep going, but with a new TCP connect= ion - > which is what clicking from page to page on web sites will do for you. We= do > this now in an ad-hoc way with cookies, and data in URL's, but is there a= need > for something more formal?) >=20 > But perhaps I was correct to begin with, and we do need names for end-end > things, and we *also* need a higher level of naming for the applications. >=20 >=20 > I don't think a mailing list is the way to answer these kinds of question= s. > You have to take <12 very smart people, and put them in a room for 3 days, > and lock the door and keep everyone else out. >=20 > Sorry, but to quote Brooks, ("Mythical Man-Month", chapter 4, 'Aristocrac= y, > Democracy and System Design') "there must be few architects". Sure, again, understand. > Sure, their output should be reviewed and commented on by everyone, once = the > door opens, and perhaps they need to close the door again and respin, but= from > experience with NSRG (particularly one design sub-group), and looking at = the > vagueness of the questions above, any attempt to discuss such issues on a > mailing list with many people on it, all dropping a comment in here and t= here, > will not reach closure. It was hard enough in a small room with 4 people > actually phsyically there.... >=20 >=20 > Or do you think the community is ready to just "ship it" with something l= ike > the endpoints concept - add naming of endpoints, and split IPv6 addresses= in > half to name the two classes of things, and call it a day quickly on the > architecture? Definitely not. =20 > Which sounds a lot like a quick kludge, actually. Then again, some quick > kludges (e.g. CIDR) have been reasonably good. But they aren't as good as > starting from scratch, of course. CIDR bought us a few years, but it's ha= rdly > a "possession for all time". I guess it depends on things like whether you're looking at clean slate v. incremental deployability on the existing Internet, etc. These are all reasonable things to discuss (IMO), and as I said above, maybe we need more than one list.=20 --dmm --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFU9ckORgD1qCZ2KcRAt1KAJ0VuN7otzU6Tzrj9AjBDyDkQkTs7gCgg9bO KYHfpORXkMZpZ6dBCPRZQjU= =FO/C -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- --===============0152558203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0152558203==-- From architecture-discuss-bounces@ietf.org Thu Nov 09 21:02:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLhB-00065c-5T; Thu, 09 Nov 2006 21:00:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLgo-0004yR-Vq for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:00:18 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLZv-000721-RQ for architecture-discuss@ietf.org; Thu, 09 Nov 2006 20:53:13 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A10C286AE1; Thu, 9 Nov 2006 20:53:11 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] =?iso-8859-1?Q?=5BOff-topic?= =?iso-8859-1?Q?=5D=A0Furthe?= =?iso-8859-1?Q?r?= thoughts: about systems theory and the theory U Message-Id: <20061110015311.A10C286AE1@mercury.lcs.mit.edu> Date: Thu, 9 Nov 2006 20:53:11 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Meyer >> do you think the community is ready to just "ship it" with something >> like the endpoints concept - add naming of endpoints, and split IPv6 >> addresses in half to name the two classes of things, and call it a >> day quickly on the architecture? > Definitely not Well, now you're making me wonder - to be very frank and blunt - whether this whole exercise is really anything other than a (yet another) paper design exercise which is destined to go nowhere. Because in saying that, you're putting on the table the possibility of a major change to IPv6, not just a fairly minor tweak. The issue, to put it bluntly, is: how much will is there to change IPv6? (Even sticking a shim layer in between the internetwork layer and the tranport layer, so the IPv6 protocol itself doesn't have to be changed, is still a change to IPv6 in a larger sense.) If there's no community will to change IPv6, we're wasting out time. This is where the IESG and IAB *have* to suck it up and try and lead on this issue - and, yes, probably get some people pissed off at them - and say something. It can be as simple as "in our opinion, we think the community needs to do this - the community may disagree, but in doing so it will be going against our recommendation", but it has to be something. Yes, yes, I know the reply is going to be "well, do a good enough design and then people will buy into it". However, the IAB and IESG need to do their bit too, not lay back and lay all the burden off. This is make-or-break time for the IETF and this whole model of managing Internet technical governance. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 21:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiM7p-0007PE-MW; Thu, 09 Nov 2006 21:28:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiM7o-0007Nz-QE for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:28:12 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiM7m-00033A-Bx for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:28:12 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAA2PArG016007; Thu, 9 Nov 2006 18:25:11 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 09 Nov 2006 18:27:47 -0800 X-PGP-Universal: processed; by terminus.local on Thu, 09 Nov 2006 18:27:47 -0800 In-Reply-To: <20061110015311.A10C286AE1@mercury.lcs.mit.edu> References: <20061110015311.A10C286AE1@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <56EFE3BE-E71A-4E5C-8F42-27CE330B71CB@virtualized.org> From: David Conrad Subject: =?ISO-8859-1?Q?Re:_[arch-d]_[Off-topic]=A0Further_thoughts:_abou?= =?ISO-8859-1?Q?t_systems_theory_and_the_theory_U?= Date: Thu, 9 Nov 2006 18:27:45 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, On Nov 9, 2006, at 5:53 PM, Noel Chiappa wrote: > The issue, to put it bluntly, is: how much will is there to change > IPv6? My answer: little to none in all but a few router jockeys in large ISPs and some protocol geeks at a couple of large router vendors. But hopefully that'll be enough. > If there's no community will to change IPv6, we're wasting out time. Not really, because the alternative to not doing something is too scary. Something will be done because too much money is riding over the Internet today. However, I don't believe that something will be a wholesale re-architecture and redeployment of existing IPv6 technology, it will be an incremental, evolutionary hack that will make IPv6 suck just sufficiently less to keep things from falling over. Like CIDR. Like VLSM. Etc. If we're really lucky, it won't be too obscene a kludge, but I suspect that's about the best we can hope for at this stage. You're right. It isn't architecture, it is engineering (in the Rube Goldberg sense). But we've frittered away the time CIDR gave us and now we're looking at the wall approaching at an uncomfortable speed. As they say in Silicon Valley, "never enough time to do it right, but always enough time to do it over"... > This is where the IESG and IAB *have* to suck it up and try and > lead on this > issue - and, yes, probably get some people pissed off at them - and > say > something. You attribute more power to the IESG and IAB than I. However, I may be too cynical. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 21:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMBY-0001If-9B; Thu, 09 Nov 2006 21:32:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMBW-0001Ia-Vt for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:32:02 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiMBV-0003Se-MW for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:32:02 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 18:32:01 -0800 X-IronPort-AV: i="4.09,407,1157353200"; d="scan'208"; a="342028300:sNHT49668112" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAA2W00k021628; Thu, 9 Nov 2006 21:32:00 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAA2VwDM014783; Thu, 9 Nov 2006 21:31:58 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 21:31:58 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 21:31:57 -0500 Date: Thu, 9 Nov 2006 18:31:08 -0800 From: Scott W Brim To: Noel Chiappa Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? Message-ID: <20061110023107.GA1352@sbrim-wxp01> Mail-Followup-To: Scott W Brim , Noel Chiappa , architecture-discuss@ietf.org References: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 10 Nov 2006 02:31:57.0927 (UTC) FILETIME=[64EA3F70:01C70470] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Excerpts from Noel Chiappa on Thu, Nov 09, 2006 10:11:47AM -0500: > I expect the next big revolution in computer communications too come > from some group outside the IETF, a group which is small, and > designs, builds and deploys some new thing which can > utilize/interoperate with the existing Internet, but is > fundamentally different. Once it is seen to be good, others will > take it up. > Well, when we had this very same interaction about 5 years ago, I suggested that (1) whatever it is, it will run on top of IP to start with, and (2) the key is to figure out how to move features from whatever it is down into the internet layer *incrementally*. I still think this is a good idea. swb _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 21:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMET-0002bs-Hr; Thu, 09 Nov 2006 21:35:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMES-0002bY-Ry for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:35:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiMER-0003jb-1a for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:35:04 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 18:35:02 -0800 X-IronPort-AV: i="4.09,407,1157353200"; d="scan'208"; a="342029376:sNHT78193498" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kAA2Z2gx003306; Thu, 9 Nov 2006 18:35:02 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAA2Z1OV007345; Thu, 9 Nov 2006 18:35:01 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 21:35:01 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 21:35:00 -0500 Date: Thu, 9 Nov 2006 18:34:14 -0800 From: Scott W Brim To: David Meyer Subject: Re: [arch-d] [Off-topic]?Further thoughts: about systems theory and the theory U Message-ID: <20061110023414.GB3104@sbrim-wxp01> Mail-Followup-To: Scott W Brim , David Meyer , Pekka Nikander , architecture-discuss@ietf.org References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> <20061109220010.GA28334@1-4-5.net> Mime-Version: 1.0 In-Reply-To: <20061109220010.GA28334@1-4-5.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 10 Nov 2006 02:35:00.0903 (UTC) FILETIME=[D1FA2B70:01C70470] Authentication-Results: sj-dkim-8; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1120940557==" Errors-To: architecture-discuss-bounces@ietf.org --===============1120940557== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Excerpts from David Meyer on Thu, Nov 09, 2006 02:00:10PM -0800: > We plan to use this list for discussion of the outcomes > of the routing and addressing workshop, and about the > (technical) ways forward. If you desire a mailing list > for non-technical issues (such as organizational theory), > please set one up. We do, however, need to focus on the > our task, and this is the list that we're going to use > for that. Please respect this request. >=20 > Thnx, >=20 > --dmm Dave, are you saying you want this list *only* for routing & addressing issues? If so ... Routing & addressing interact with other architectural issues, and so far this list is lightly used. Let's wait until there's a demonstrated problem, and then weigh costs & benefits? Scott --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFFU+UlF0TR2hENFAQRAvJRAKD0BYA6kSWyu/uA2wifjBCOFgiZ7QCeM+at 27I5gu9tcRq7GD1B1z2Ekrc= =UV6H -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- --===============1120940557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1120940557==-- From architecture-discuss-bounces@ietf.org Thu Nov 09 22:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiN97-0004ik-EX; Thu, 09 Nov 2006 22:33:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiN96-0004if-PQ for architecture-discuss@ietf.org; Thu, 09 Nov 2006 22:33:36 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiN95-000528-GQ for architecture-discuss@ietf.org; Thu, 09 Nov 2006 22:33:36 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4BE0B898C5; Fri, 10 Nov 2006 05:33:34 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5EB7E898C2; Fri, 10 Nov 2006 05:33:33 +0200 (EET) Message-ID: <4553F30B.2080307@piuha.net> Date: Thu, 09 Nov 2006 19:33:31 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U References: <20061110015311.A10C286AE1@mercury.lcs.mit.edu> In-Reply-To: <20061110015311.A10C286AE1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, > If there's no community will to change IPv6, we're wasting out time. I believe there is will from the IESG/IAB to do whatever it takes. Lets see if we can convince the community that there is an issue that needs to be addressed. I don't, and I don't think the others in IESG/IAB have either, a magic solution. I would like to work towards people coming up with the solution(s), however. (But I would seriously question whether "change IPv6" is the answer, or at least not the complete answer.) --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 22:55:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiNTy-0000lB-Gy; Thu, 09 Nov 2006 22:55:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiNTw-0000ho-UM for architecture-discuss@ietf.org; Thu, 09 Nov 2006 22:55:08 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiNTv-0001MT-Mv for architecture-discuss@ietf.org; Thu, 09 Nov 2006 22:55:08 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 63F7286AE1; Thu, 9 Nov 2006 22:55:07 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: =?ISO-8859-1?Q?Re:_[arch-d]_[Off-topic]=A0Further_thoughts:_abou?= =?ISO-8859-1?Q?t_systems_theory_and_the_theory_U?= Message-Id: <20061110035507.63F7286AE1@mercury.lcs.mit.edu> Date: Thu, 9 Nov 2006 22:55:07 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Conrad >> The issue, to put it bluntly, is: how much will is there to change >> IPv6? > My answer: little to none in all but a few router jockeys in large > ISPs and some protocol geeks at a couple of large router vendors. But > hopefully that'll be enough. How will that be enough? If any change impacts on the hosts, as most attempts to separate location and id would, then don't host people have to be on board too? The exception would be if you're thinking of some kind of scheme where we jack up IPv6, make IPv6 an end-end host-naming only layer, and IPv6 addresses the end-end entity naming, and stick another layer underneath it with routing-names. The entry router would have to lookup the destination entity-name, and map it into the destination routing-name, and then throw on another header with the destination routing-name in it (you have to do that, otherwise you'd have to do the mapping step at every hop, which is probably too inefficient). Then the last-hop router would have to take that wrapper off. If either source of desination host eventually understands the routing-name layer, you could omit the first-hop/last-hop step. Even to do that you need to get all of the router vendors on board, otherwise you have to deal with the possibility that the packet has to get unwrapped half-way along the path, and then you start to lose a lot of the benefits if all you have is (effectively) a small portion of the network using the new addressing (and routing). Is there some other way to i) do identification/location split without getting general consensus that I missed? > I don't believe that something will be a wholesale re-architecture and > redeployment of existing IPv6 technology, it will be an incremental, > evolutionary hack that will make IPv6 suck just sufficiently less to > keep things from falling over. OK, so that takes whole books of potential solutions off the table. (Which kind of contradicts what David said earlier. I'd love to hear his take on your observations here.) > You attribute more power to the IESG and IAB than I. I am fully aware that they can't make the community do something the community doesn't want to do. Which is why I said: >> It can be as simple as "in our opinion, we think the community needs >> to do this - the community may disagree, but in doing so it will be >> going against our recommendation" But if we're constrained to only do "bag-on-the-side" fixes, then of course that's not needed. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 09 23:55:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiOOC-0000ol-P2; Thu, 09 Nov 2006 23:53:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiOOB-0000of-VG for architecture-discuss@ietf.org; Thu, 09 Nov 2006 23:53:15 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiOOA-0002XA-Ej for architecture-discuss@ietf.org; Thu, 09 Nov 2006 23:53:15 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAA4o9rG016198; Thu, 9 Nov 2006 20:50:16 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 09 Nov 2006 20:52:52 -0800 X-PGP-Universal: processed; by terminus.local on Thu, 09 Nov 2006 20:52:52 -0800 In-Reply-To: <20061110035507.63F7286AE1@mercury.lcs.mit.edu> References: <20061110035507.63F7286AE1@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5BE8C869-FD96-4EB6-8F5E-401981FDF48A@virtualized.org> From: David Conrad Subject: =?ISO-8859-1?Q?Re:_[arch-d]_[Off-topic]=A0Further_thoughts:_abou?= =?ISO-8859-1?Q?t_systems_theory_and_the_theory_U?= Date: Thu, 9 Nov 2006 20:52:45 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, On Nov 9, 2006, at 7:55 PM, Noel Chiappa wrote: > If any change impacts on the hosts, as most > attempts to separate location and id would, then don't host people > have to > be on board too? Obviously, yes. However, I am skeptical that you can re-implement and redeploy the host stack before one or another wall (there are several) is upon us. As such, as you correctly surmise: > The exception would be if you're thinking of some kind of scheme > where we jack > up IPv6, make IPv6 an end-end host-naming only layer, and IPv6 > addresses the > end-end entity naming, and stick another layer underneath it with > routing-names. Right. And to minimize the necessity of redeploying existing code, the 'layer underneath' would simply be unmodified IPv6, leveraging the existing deployment of IPv6 capable core routers. The 'underneath IPv6' would route on highly aggregated locators (routing- names) using existing tools and techniques ISPs are comfortable with today. > The entry router would have to lookup the destination > entity-name, and map it into the destination routing-name, and then > throw on > another header with the destination routing-name in it. Yep. Alternatively, if this sort of dynamic tunneling is too scary due to MTU issues or whatever, you could do address rewriting at both ends (but that has a few serious downsides). > Then the last-hop router would have to take that wrapper off. I personally prefer the model where the encapsulation is done at the source edge and de-encapsulation is done at the destination edge as opposed to the first hop/last hop as that makes site-wide multi- homing and number portability very easy, but both approaches can co- exist. > If either source of desination host eventually understands the > routing-name layer, you could omit the first-hop/last-hop step. At the cost of having to make the host understand the routing-name. > Even to do that you need to get all of the router vendors on board, Cisco and Juniper have 75% of the worldwide service provider market share in routers (according to a Gartner report published on 15 Aug 2006). > otherwise > you have to deal with the possibility that the packet has to get > unwrapped > half-way along the path, Or, if the destination does not have a mapping, you fall back to potentially sub-optimal 'normal' routing, treating the identifier as the now-standard locator/id merged address. > and then you start to lose a lot of the benefits if > all you have is (effectively) a small portion of the network using > the new > addressing (and routing). Which will be the case during transition for any approach unless you assume a global flag day. > Is there some other way to i) do identification/location split without > getting general consensus that I missed? Probably not -- you're a lot smarter on this stuff than I am, but I see this as a fairly pragmatic cost/benefit tradeoff. I see 4 options: a) Change both the end points and the infrastructure (I call this the IPv7 approach) b) Change only the end points (every host IPv6 stack deployed to date) c) Change only the infrastructure (all routers deployed for IPv6 service) d) Change the junction between the hosts and the infrastructure (e.g., the point between the "core" and the "edge"). I figure (d) is the cheapest, easiest, and thus, most likely to be deployed. > But if we're constrained to only do "bag-on-the-side" fixes, then > of course > that's not needed. To be clear, I am not suggesting these are constraints (I certainly am not the one to define constraints in any event), I am merely voicing my opinion that attempts to deploy design, architect, implement, and deploy IPv7 is unlikely to be successful in the timeframes we have. More to the point, the Internet is not going to stand still while IPv7 is developed, thus by the time the new architecture is "done", there will be that much more of an installed base to deal with. However, as I said, this is merely my opinion... Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 00:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiOdR-0001CI-IY; Fri, 10 Nov 2006 00:09:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiOdQ-0001Bb-70 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 00:09:00 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiOdJ-0004hH-Mj for architecture-discuss@ietf.org; Fri, 10 Nov 2006 00:09:00 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GiOd6-0007XP-IC for architecture-discuss@ietf.org; Thu, 09 Nov 2006 21:08:41 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Nov 2006 03:24:30 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: Jefsey_Morfin Subject: Re: [arch-d] [Off-topic ] Further thoughts: about systems theory and the theory U In-Reply-To: <20061110012504.BC0A986AE1@mercury.lcs.mit.edu> References: <20061110012504.BC0A986AE1@mercury.lcs.mit.edu> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0742115886==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0742115886== Content-Type: multipart/alternative; boundary="----MThepttcbbcuujpltmivvdcbbfrfogjvii" ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-EE7765B At 02:25 10/11/2006, Noel Chiappa wrote: >But perhaps I was correct to begin with, and we do need names for end-end >things, and we *also* need a higher level of naming for the applications. Correct. Physical addresses for the plug to plug. Domain names for end to end. Authentication for brain to brain/CPU. >I don't think a mailing list is the way to answer these kinds of questions. >You have to take <12 very smart people, and put them in a room for 3 days, >and lock the door and keep everyone else out. Correct. But you have to unpollute these people from their pet technology prior to entering the room. Or to gather them on the basis of a general enough common vision. >Sure, their output should be reviewed and commented on by everyone, once the >door opens, and perhaps they need to close the door again and respin, but from >experience with NSRG (particularly one design sub-group), and looking at the >vagueness of the questions above, any attempt to discuss such issues on a >mailing list with many people on it, all dropping a comment in here and there, >will not reach closure. It was hard enough in a small room with 4 people >actually phsyically there.... Mailing lists permit to consider <12 people groups and to make sure all the premises have been listed in case they forget some. Because there will not be one solution, but a diversity. This is why their first need is interoperability, starting with the current IPv4 and tentative IPv6 architecture. On 02:53 10/11/2006, Noel Chiappa said: > > From: David Meyer > > >> do you think the community is ready to just "ship it" with something > >> like the endpoints concept - add naming of endpoints, and split IPv6 > >> addresses in half to name the two classes of things, and call it a > >> day quickly on the architecture? > > > Definitely not > >Well, now you're making me wonder - to be very frank and blunt - whether this >whole exercise is really anything other than a (yet another) paper design >exercise which is destined to go nowhere. Because in saying that, you're >putting on the table the possibility of a major change to IPv6, not just a >fairly minor tweak. > >The issue, to put it bluntly, is: how much will is there to change IPv6? >(Even sticking a shim layer in between the internetwork layer and the >tranport layer, so the IPv6 protocol itself doesn't have to be changed, >is still a change to IPv6 in a larger sense.) Everything and nothing. When you can use IPv4 use it. When you can use IPv6 use it. When you need more develop it. >If there's no community will to change IPv6, we're wasting out time. No. You just say that community cannot develop something new. You only need <12 smart committed people. If their deliverable is good and interoperable it will fly. >This is where the IESG and IAB *have* to suck it up and try and lead on this >issue - and, yes, probably get some people pissed off at them - and say >something. This may help those who believe in IESG and IAB. But will they really be committed to change. I do not think that people able to design, test and deploy a new architecture are people who need the IESG and IAB to tell them they failed. RFC 3935 says "The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create." If IESG and IAB say the technology the IETF chosed to create is not adequate, it could mean that the IETF core values above (and IMHO rough consensus) are not adequate. This would call for more than just a mail. This should be the very matter of this mailing list. jfc ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/html At 02:25 10/11/2006, Noel Chiappa wrote:
>But perhaps I was correct to begin with, and we do need names for end-end
>things, and we *also* need a higher level of naming for the applications.

Correct. Physical addresses for the plug to plug. Domain names for
end to end. Authentication for brain to brain/CPU.

>I don't think a mailing list is the way to answer these kinds of questions.
>You have to take <12 very smart people, and put them in a room for 3 days,
>and lock the door and keep everyone else out.

Correct. But you have to unpollute these people from their pet
technology prior to entering the room. Or to gather them on the basis
of a general enough common vision.

>Sure, their output should be reviewed and commented on by everyone, once the
>door opens, and perhaps they need to close the door again and respin, but from
>experience with NSRG (particularly one design sub-group), and looking at the
>vagueness of the questions above, any attempt to discuss such issues on a
>mailing list with many people on it, all dropping a comment in here and there,
>will not reach closure. It was hard enough in a small room with 4 people
>actually phsyically there....

Mailing lists permit to consider <12 people groups and to make sure
all the premises have been listed in case they forget some.

Because there will not be one solution, but a diversity.
This is why their first need is interoperability, starting with the
current IPv4 and tentative IPv6 architecture.

On 02:53 10/11/2006, Noel Chiappa said:
>     > From: David Meyer <dmm@1-4-5.net>
>
>     >> do you think the community is ready to just "ship it" with something
>     >> like the endpoints concept - add naming of endpoints, and split IPv6
>     >> addresses in half to name the two classes of things, and call it a
>     >> day quickly on the architecture?
>
>     > Definitely not
>
>Well, now you're making me wonder - to be very frank and blunt - whether this
>whole exercise is really anything other than a (yet another) paper design
>exercise which is destined to go nowhere. Because in saying that, you're
>putting on the table the possibility of a major change to IPv6, not just a
>fairly minor tweak.
>
>The issue, to put it bluntly, is: how much will is there to change IPv6?
>(Even sticking a shim layer in between the internetwork layer and the
>tranport layer, so the IPv6 protocol itself doesn't have to be changed,
>is still a change to IPv6 in a larger sense.)

Everything and nothing. When you can use IPv4 use it. When you can
use IPv6 use it. When you need more develop it.

>If there's no community will to change IPv6, we're wasting out time.

No. You just say that community cannot develop something new. You
only need <12 smart committed people. If their deliverable is good
and interoperable it will fly.

>This is where the IESG and IAB *have* to suck it up and try and lead on this
>issue - and, yes, probably get some people pissed off at them - and say
>something.

This may help those who believe in IESG and IAB. But will they really
be committed to change. I do not think that people able to design,
test and deploy a new architecture are people who need the IESG and
IAB to tell them they failed.

RFC 3935 says "The Internet isn't value-neutral, and neither is the
IETF.  We want the Internet to be useful for communities that share
our commitment to openness and fairness.  We embrace technical
concepts such as decentralized control, edge-user empowerment and
sharing of resources, because those concepts resonate with the core
values of the IETF community.  These concepts have little to do with
the technology that's possible, and much to do with the technology
that we choose to create."

If IESG and IAB say the technology the IETF chosed to create is not
adequate, it could mean that the IETF core values above (and IMHO
rough consensus) are not adequate. This would call for more than just
a mail. This should be the very matter of this mailing list.

jfc

------MThepttcbbcuujpltmivvdcbbfrfogjvii-- --===============0742115886== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0742115886==-- From architecture-discuss-bounces@ietf.org Fri Nov 10 02:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQKM-0002hY-HD; Fri, 10 Nov 2006 01:57:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQKK-0002fq-S7 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 01:57:25 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiQKJ-0002yO-D7 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 01:57:24 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E4A43212E19 for ; Fri, 10 Nov 2006 08:57:01 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9E7F5212DFC for ; Fri, 10 Nov 2006 08:57:01 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <76A7DE06-EDE7-4956-AA16-136A8A35C4BF@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Pekka Nikander Date: Fri, 10 Nov 2006 08:57:01 +0200 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [arch-d] What are the "right" architectural problems to addressing and routing, then? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Not having been at the routing and addressing workshop, not seeing yesterday's plenary presentation, and knowing only what is on yesterday's slides, my personal opinion is that focusing on "how to make IPv6 routing scale" is most probably a wrong problem (very symptomatic approach). I think the right questions might be what Noel asked, but restating the most important one of those slightly more concretely: What are the things that we want to name and address? I think the focus on hosts and processes running on hosts is a wrong answer. Time to bite the bullet and acknowledge that the hosts in the Internet are no more very important. There are at least three alternative ways to answer to a problem requiring naming changes: 1. Overload the current name spaces with new semantics 2. Change (completely) the semantics of an existing name space 3. Add a new name space #1 has been what we have historically done most of the time. CIDR is a good example of #2. Changing IPv6 so that IPv6 addresses would no longer be host or interface addresses but perhaps something more fine grained might be another example of #2. That could be combined with GSE and/or SHIM6, the workshop's favourite solutions. HIP is probably the most mature of current architectural approaches in the #3 category, and apparently the EME RG is looking at others. Unfortunately, SIP and all that world is the best established approach overall, but IMHO not architecturally as clean as what I think HIP and other similar approaches are. But it seems to be the way we are going: SIP URLs, signalling gateways between IP addressing domains, and separated IP networks. Personally, I am somewhat worried about solutions in the first and second categories, including both GSE and SHIM6. Structurally, solutions in #2 seem more or less like CIDR -- buying more time without changing anything fundamental. As I stated, based on the systems theory pattern, such solutions are needed: symptomatic solutions are needed. But we should not focus *only* on them. But we should also discuss completely new approaches. Hence, IMHO the danger here is that focusing too much on solutions that buy time in the face of yet another wall ahead is another round of completely ignoring the more fundamental problems. When I worked towards the creating of this mailing list, I hoped that this would be a forum to ponder the more fundamental problems and solutions to them. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 02:34:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQuA-0005vC-3V; Fri, 10 Nov 2006 02:34:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQu8-0005v2-B7 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 02:34:24 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiQu7-0008QW-1H for architecture-discuss@ietf.org; Fri, 10 Nov 2006 02:34:24 -0500 Received: from webmail17.lax.untd.com (webmail17.lax.untd.com [10.131.27.157]) by smtpout05.lax.untd.com with SMTP id AABCXJL5EA4NZWYJ for (sender ); Thu, 9 Nov 2006 23:33:56 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKZbR3QPbty5+hrHlBin81nA== Received: (from fergdawg@netzero.net) by webmail17.lax.untd.com (jqueuemail) id L6S3LTCE; Thu, 09 Nov 2006 23:33:05 PST Received: from [67.111.99.2] by webmail17.lax.untd.com with HTTP: Fri, 10 Nov 2006 07:32:37 GMT X-Originating-IP: [67.111.99.2] Mime-Version: 1.0 From: "Fergie" Date: Fri, 10 Nov 2006 07:32:37 GMT To: pekka.nikander@nomadiclab.com Subject: Re: [arch-d] What are the "right" architectural problems to addressing and routing, then? X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061109.233305.793.888954@webmail17.lax.untd.com> X-ContentStamp: 9:4:525496971 X-MAIL-INFO: 0098d815b10d78d5ac3579b17d556de5fc8d48298dbd7d65296d1d6d2dd82939e1 X-UNTD-Peer-Info: 10.131.27.157|webmail17.lax.untd.com|webmail17.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -- Pekka Nikander wrote: >Not having been at the routing and addressing workshop, not seeing = >yesterday's plenary presentation, and knowing only what is on = >yesterday's slides, my personal opinion is that focusing on "how to = >make IPv6 routing scale" is most probably a wrong problem (very = >symptomatic approach). > >I think the right questions might be what Noel asked, but restating = >the most important one of those slightly more concretely: > > What are the things that we want to name and address? > I think the ISPs that are currently running the larger backbone networks would disagree with you on that one. In an environment with growth of $foo routes (where $foo is the number, and projected numbers, of additional projected routes discussed in the past few weeks/months), the principle concern here is the instability introduced by route churn (given those numbers) and may very well be problematic _at_best_. So it's not just an issue of names and addresses, but rather, how the addition of $foo routes, and the ability to recalculate alternate paths in a timely manner, affects the routing system. Without the ability to get bits from Point A to Point B, names and addresses are meaningless. - ferg _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 03:43:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiRwP-0005k5-0V; Fri, 10 Nov 2006 03:40:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiRwM-0005jx-UI for architecture-discuss@ietf.org; Fri, 10 Nov 2006 03:40:46 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiRwL-0007zM-ED for architecture-discuss@ietf.org; Fri, 10 Nov 2006 03:40:46 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 55785212FD5; Fri, 10 Nov 2006 10:40:31 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EC5A0212DFC; Fri, 10 Nov 2006 10:40:30 +0200 (EET) In-Reply-To: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> References: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E4219EA-5942-463F-A646-B0B16D2754B9@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 10 Nov 2006 10:40:29 +0200 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: architecture-discuss@ietf.org Subject: [arch-d] An example of how the requirements and right questions interrelate X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred, You wrote earlier: > The biggest problem, frankly, is that we have conflicting > requirements and two communities that are willing to hurl insults > rather than listen and help. An example of the conflicting > requirements is that Vince and others, and many in the enterprise > community, want IP addressing without the requirement to renumber > when you leave a service provider, and consider that a fundamental > need, while many in the ISP community see IPv6 PA addressing as a > market lock and therefore something advantageous to them. Yes, I > have heard those words from ISP mouths. We can't both create and > not create a market lock, and whichever group we fail to please is > guaranteed to be wandering around making pretty strong statements > about the unresponsiveness and stupidity of the IETF community. > shim6 right now creates a market lock for any customer that abhors > renumbering. I think this is a nice example where asking the right questions, or going deeper, may help. In this particular case, I'd like to ask why the enterprise community abhors renumbering? And I think we know the rough answer chain: 1) it costs too much, because 2a) addresses have high-level, application specific semantics, thereby making changing them costly, and 2b) there are no good mechanisms for addressing these costs in the current architecture So, jumping a little ahead in the name of brevity, IMHO, this goes directly to my previous question: What are the things that we want to name and address? According to yesterday's plenary slides, id/loc split was felt popular in the workshop. My interpretation would be that it was felt so because it shifts the cost structures, making your above described incentive tussle to disappear. In other terms, we want to name/address applications/services/ whatever differently from the network locations, creating a different cost structure than the current one. Basically, we seem to have three different asset structures here: 1) Applications, which are bound to the (socket) API. Changing these is very slow, as our experience with IPv6 amply shows. (> 10 years from spec to most apps having been changed) 2) Host operating systems. Here the turn around is fairly fast, only 3-5 years and the majority of hosts have a newer operating system. Again, think about prevalence of IPv6 implementation at today's hosts. 3) Routers. This is the area where I have least experience, but I would imagine that the routers get replaced at roughly the same rate as hosts. The purchasing and feature economics differ, though. The focus seems to be only on the routing system. I think that is a wrong approach. By changing the hosts appropriately, we could lift quite a lot of pressure from the routing system. There are even several ways for doing it! The trick is to simultaneously preserve the (socket) APIs and other needed backwards compatibility, as their changing takes much longer. In fact, both the GSE and SHIM6 approaches are going there already: changing both the hosts and routers, roughly but not quite at the same time. What I just consider sad is that people dare not be radical enough, given that we will, ANYWAY, need to change both the hosts and routers, and wait for the 3-5 years to get that deployed. So, based on the above, I still think the right question is to ask what we want to name and address, through the socket APIs. Only then plan how to change the hosts, routers, and infrastructure appropriately, preferably in a step-wise manner, each step making sense in itself. (A few IETFs ago I described how that could happen with HIP, if anyone remembers any more. Today I think that HIP is not radical enough; we need even bigger changes. HIP is just like SHIM6 + some elements of GSE + some more infra for referrals, but still focusing on hosts.) --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 07:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiVhw-0005Za-TQ; Fri, 10 Nov 2006 07:42:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiVhw-0005ZO-23 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 07:42:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiVhu-0002QN-DA for architecture-discuss@ietf.org; Fri, 10 Nov 2006 07:42:08 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 04:42:05 -0800 X-IronPort-AV: i="4.09,409,1157353200"; d="scan'208"; a="363341:sNHT115479999" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAACg5XV015950; Fri, 10 Nov 2006 04:42:05 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAACg1OV004514; Fri, 10 Nov 2006 04:42:01 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 04:42:00 -0800 Received: from [12.105.242.217] ([10.21.96.121]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 04:42:00 -0800 In-Reply-To: <2E4219EA-5942-463F-A646-B0B16D2754B9@nomadiclab.com> References: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> <2E4219EA-5942-463F-A646-B0B16D2754B9@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <237D030A-BA18-4E02-8591-CBACC932A983@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 10 Nov 2006 04:41:56 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 12:42:00.0456 (UTC) FILETIME=[9DB8F080:01C704C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7787; t=1163162525; x=1164026525; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20An=20example=20of=20how=20the=20requirements=20and=20 right=20questions=20interrelate |Sender:=20; bh=Ux4zCmmEKwJntCEUaim1UT7uGaplc78mwin7Ud3Pu28=; b=k5hQe5bY3z9/+rPlVv755kACfyPO7oYlbk4dRRw3nun0KmOmyhzlvxeP13v9NXJsPWtHVjXv n3AJOoA0qXQpIXQ9KDHs4d6hKtM/zsidDR6CnhTWHByTu6EucVB+CX5O; Authentication-Results: sj-dkim-7; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: architecture-discuss@ietf.org Subject: [arch-d] Re: An example of how the requirements and right questions interrelate X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 10, 2006, at 12:40 AM, Pekka Nikander wrote: > In this particular case, I'd like to ask why the enterprise > community abhors renumbering? > > And I think we know the rough answer chain: > > 1) it costs too much, because > 2a) addresses have high-level, application specific semantics, > thereby making changing them costly, and > 2b) there are no good mechanisms for addressing these costs in > the current architecture Those are certainly important parts of the question. I learned a lot while researching for http://www.ietf.org/rfc/rfc4192.txt 4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110 bytes) (Updates RFC2072) (Status: INFORMATIONAL) Bottom line, the primary reason that I came up with for people not wanting to renumber has to do with poor application design and network management practices. Unicast network layer addresses do not actually have "high-level, application specific semantics". There are some multicast addresses that have specific meanings, such as AllOspfDesignatedRouters; I'll argue that those are a very special case. If unicast applications had application-specific semantics, one would need different addresses for different applications. They don't; addresses are assigned per interface, not per application. One can argue that there is no need for a generic application to have any knowledge of either the address(es) of its own system or a peer it wants to communicate with. The reason that it does know is what I would consider to be poorly designed socket APIs. The way many OS's work today is something like: address := gethostbyname(DNS name); socket := opensocket(address); One could imagine a different API: socket := openSocketByName(DNS name) to accomplish the same thing, and hide the distinction between different kinds of IP addresses and the multiplicity of them entirely from the application. Alas, it is not so. Now, the folks in the opsec working group will tell you that they really don't want to have access by name, they really want the address, and will give you reasons why. No problem, we provide a separate API for folks who have a real requirement of this type. Let's just say that they are a special case, not the general one. Regarding mechanisms in the present architecture for managing address complexities, well, we have mechanisms (see, for example, RFC 2894, and more generally consider how a large network uses scripts and databases to manage configurations), but I'm not sure the mechanisms are all that relevant. The big issue is that there are a variety of configuration elements in routers (yes, my company is part of the problem here) and in some cases in applications where it is just a whole lot simpler to configure the address, and as a result the address is what is configured. Fixing this is a non-trivial problem, not something that one waves a hand at. Route maps, access lists, security associations, static routes, and a long list of other things are implicated here. I was told of a company whose shipping would stop cold if a certain computer was renumbered, because the hand-held UPC readers used in the process use a hard-coded IP address rather than a DNS name configured in a NVRAM or such - someone took an ill- advised short-cut, and it makes that particular change difficult. This class of issue is mostly what makes renumbering hard. And saying "well, if we just had defined and implemented that would be solved" is naive - the big problem there is that never mind what might or might not exist, the engineer designing chose to not use it. If the tool isn't used, it really doesn't matter how wonderful it is. You might find http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout "Things to think about when Renumbering an IPv6 network", Tim Chown, 20-Sep-06 interesting in this context. The problem is closest to your "it costs too much", although in this case it isn't a monetary cost. It is the fact that one has to somehow touch every computer in an organization including its network infrastructure and management and mission-critical servers, and in touching them do exactly the right thing. That is something that is doable (my company does it regularly) on a piecemeal basis, but pretty difficult for a company of any non-trivial size to do globally in one swell foop. So I mostly disagree with your 2(a) and 2(b), but I will agree with some variation on your first point. > So, based on the above, I still think the right question is to ask > what we want to name and address, through the socket APIs. OK, so what would they be? I tend to think of applications in the manner that the term "host" resulted from. An Application Host Processor, for those of us familiar with Big Blue, is a computer on which applications run. If two applications cannot coexist easily one one host, one either upgrades the host in some way or separates them, making them run on separate systems. If two systems are underutilized, one might similarly move an application from one to the other for economic reasons. The computer is a computational environment that some number of applications use, and the applications are in a very real sense the important part. So I will generally argue that one wants to name applications, not the computers they run on, and lo and behold we do that (sort of). We have names like ftp.example.com, smtp.example.com, and so on. The translations of these names into addresses may result in single or multiple addresses, and in the latter case they may be multiple interfaces on the same machine or they may be different machines. In general, I think that is a very sensible model. As to addresses, one needs a way to find the endpoint that a targeted application runs on in the topology of the network. That is a many- layered thing; when the message arrives at the host, how does the host determine that the message is intended for itself? How does the router in front of it determine which host to deliver the message to? On some different LAN, how does one find an acceptable path to the target LAN? In view of RFC 2008, in a remote administration, how does routing find the targeted administration that operates the intended LAN? This is the stuff (using GSE's terms) of the endpoint identifier, the LAN ID, and the "routing glop". There are many ways to cut this cookie: the addresses a system uses can, when treated as an equivalence class, be called a locator or endpoint identifier, or the DNS name could be called that. So the EID doesn't have to be implemented as a certain set of bits within a network address; there are other ways to do it. But functionally, we have to have some solution to the problem that the EID, however we understand it, solves. Ditto more and less specific components of the routing locator. I tend to think, and this isn't a very original thought, that the big problem that we have tripped over in this area is that we have not kept names at the application layer and network layer addresses at the network layer. They are in fact in the right places, but we manage to distribute addressing information to a part of the system it is irrelevant to, and in so doing shoot ourselves in the foot. If you want a detailed discussion of this, you might be interested to review the development and specification of the ISO CLNS NSAP :-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 10:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiY7A-0006Lz-Px; Fri, 10 Nov 2006 10:16:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiY79-0006Lu-Vz for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:16:19 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiY78-0001rF-FZ for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:16:19 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4BBA0212FD5; Fri, 10 Nov 2006 17:16:02 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E5788212DFC; Fri, 10 Nov 2006 17:16:01 +0200 (EET) In-Reply-To: <237D030A-BA18-4E02-8591-CBACC932A983@cisco.com> References: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> <2E4219EA-5942-463F-A646-B0B16D2754B9@nomadiclab.com> <237D030A-BA18-4E02-8591-CBACC932A983@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 10 Nov 2006 17:16:01 +0200 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: architecture-discuss@ietf.org Subject: [arch-d] Re: An example of how the requirements and right questions interrelate X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred, You managed to neatly summarise what I tried to say but failed: > I tend to think, and this isn't a very original thought, that the > big problem that we have tripped over in this area is that we have > not kept names at the application layer and network layer addresses > at the network layer. They are in fact in the right places, but we > manage to distribute addressing information to a part of the system > it is irrelevant to, and in so doing shoot ourselves in the foot. What I meant with "application specific semantics" is what you said: addressing information getting installed in various places in the application world (e.g. in configuration files), mostly due to bad design. Nothing new, already discussed in RFC 1958. But reality. What I meant with "having no good mechanisms for changing [the addresses]" is exactly what you said: "one has to somehow touch every computer in an organization". And when I say "cost", I my no means mean monetary costs; even needing to pay attention is a cost. I guess another communication problem is that I tend to consider the "Internet architecture" to be what is out there in reality, not the way we would like it to be. Another problem is apparently language. I'm not a native English speaker, and I seem to use some words differently than a native speaker would use; sorry about that. And thanks for your clear explanations. Now, getting to the second question: >> So, based on the above, I still think the right question is to ask >> what we want to name and address, through the socket APIs. >> > > OK, so what would they be? I tend to think that the "host" concept is not really something that applications are interested in. They are interested in getting certain information (content) or services (dynamic content or transactions, if you will). The lower layer implementation still probably benefits from the host concept, but I am not quite sure. Perhaps naming hosts by enumerating the dynamic set of locators currently associated with their interfaces might suffice. (Remember the late "Homeless MIP" draft?) However, due to the difficulty of keeping such dynamic information reliably up-to-date, I still lean towards having a layer able to name "hosts". That shouldn't be visible to the applications, though. Hence, since the socket API is what the applications see today and will see at least for the next 10 years and probably much longer, I think we should do quite a lot of changes underneath, just to get the architecture to match with the contemporary needs. Right now the applications see the locators. With MIP, HIP, or SHIM6 they see some kind of "host" identifiers, let they be called "home addresses", "host identity tags", or "upper layer identifiers". I think we should take one step further, and make the socket API "things" to refer to content and/or service names. Something that is completely independent from the physical location of the services. At the same time, we need to let the socket API "things" still look like IP addresses for the legacy apps. New steps of indirection to the legacy socket API: -> "internal service name" -> "host name" -> "locator". The important point is that if we manage to get to a level where the "things" applications "address" through to socket API are no longer bound to the network topology, we will get _much_ more freedom in reconsidering the addressing and routing structures. Renumbering will no longer be such an issue that it is today. In other words, it would become much easier to keep the addresses roughly in par with the topology, relieving most of the identified future burden from the routing tables. The second, perhaps less obvious point is that new layers of identifiers would allow routing over multiple IP domains. Hence, in addition to relieving burden from the routing tables by allowing more dynamic address assignment, we could also create a new routing layer on the the top of the existing ones. Something that could be called "architected overlay routing" across multiple domains, if you will. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 10:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYEs-0003uf-Vl; Fri, 10 Nov 2006 10:24:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYEr-0003uU-Fr for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:24:17 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYEp-00032z-49 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:24:17 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kAAFO7mj016266; Fri, 10 Nov 2006 07:24:07 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAAFO3VR016262; Fri, 10 Nov 2006 07:24:03 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 10 Nov 2006 07:24:03 -0800 From: David Meyer To: Scott W Brim , Pekka Nikander , architecture-discuss@ietf.org Subject: Re: [arch-d] [Off-topic]?Further thoughts: about systems theory and the theory U Message-ID: <20061110152403.GA16231@1-4-5.net> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> <20061109220010.GA28334@1-4-5.net> <20061110023414.GB3104@sbrim-wxp01> Mime-Version: 1.0 In-Reply-To: <20061110023414.GB3104@sbrim-wxp01> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1534751832==" Errors-To: architecture-discuss-bounces@ietf.org --===============1534751832== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 09, 2006 at 06:34:14PM -0800, Scott W Brim wrote: > Excerpts from David Meyer on Thu, Nov 09, 2006 02:00:10PM -0800: > > We plan to use this list for discussion of the outcomes > > of the routing and addressing workshop, and about the > > (technical) ways forward. If you desire a mailing list > > for non-technical issues (such as organizational theory), > > please set one up. We do, however, need to focus on the > > our task, and this is the list that we're going to use > > for that. Please respect this request. > >=20 > > Thnx, > >=20 > > --dmm >=20 > Dave, are you saying you want this list *only* for routing & > addressing issues? If so ... Routing & addressing interact with other > architectural issues, and so far this list is lightly used. Let's > wait until there's a demonstrated problem, and then weigh costs & > benefits? Come on folks. This has kinda gotten out of hand. We need a list for some technial discussions and this one had been very quiet, so we thought maybe we'd use it. Its not that big of a problem. We'll make another list. --dmm --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFVJmTORgD1qCZ2KcRAit+AKCVlVi0JGx1SCB2HsDQgOUp/j6DzACcC1UE 4X6obnWE1hGISuycNcK25EI= =RPbB -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- --===============1534751832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1534751832==-- From architecture-discuss-bounces@ietf.org Fri Nov 10 10:35:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYPB-0001m2-Te; Fri, 10 Nov 2006 10:34:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYPB-0001lx-71 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:34:57 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYP9-0004SE-UB for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:34:57 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 876AC86AE7; Fri, 10 Nov 2006 10:34:55 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: =?ISO-8859-1?Q?Re:_[arch-d]_[Off-topic]=A0Further_thoughts:_abou?= =?ISO-8859-1?Q?t_systems_theory_and_the_theory_U?= Message-Id: <20061110153455.876AC86AE7@mercury.lcs.mit.edu> Date: Fri, 10 Nov 2006 10:34:55 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Conrad >> The exception would be if you're thinking of some kind of scheme where >> we jack up IPv6, make IPv6 an end-end host-naming only layer, and IPv6 >> addresses [become] the end-end entity naming, and stick another layer >> underneath it with routing-names. > Right. And to minimize the necessity of redeploying existing code, the > 'layer underneath' would simply be unmodified IPv6, leveraging the > existing deployment of IPv6 capable core routers. The 'underneath IPv6' > would route on highly aggregated locators (routing-names) Oh great, so once again we do the most minimal possible "bag-on-the-side" kludge to muddle through the nearest bump we can see on the road. We don't even take the opportunity to put a more capable layer down there, something that could say, name (and thefore have the possibility of managing) traffic aggregates. No, instead we'll just do the simplest, easiest hack possible, and keep using our routing table lashup hammers to drive traffic engineering screws. For this, you don't need any architectural work, so this mailing list is inappropriate. (Then again, this mailing list may be a complete waste of time anyway. Sorry I'm so negative, but this is really depressing me. I think maybe I'd better go back to making furniture.) And the best part of all is that we're adding bags on the side of IPv6 before it's even deployed. Wow, what a great design. Sorry I'm ranting, but this is really, really, really depressing. >> Then the last-hop router would have to take that wrapper off. > I personally prefer the model where the encapsulation is done at the > source edge and de-encapsulation is done at the destination edge as > opposed to the first hop/last hop as that makes site-wide multi-homing > and number portability very easy You're right, that would be the way to go. >> If either source of desination host eventually understands the >> routing-name layer, you could omit the first-hop/last-hop step. > At the cost of having to make the host understand the routing-name. Right, but the host gets more flexibility - e.g. if the other end has multiple addresses (because it has interfaces to multiple networks), it could control which one is picked, if it had some reason to so. (That may not be a very useful thing to do in practise, it's just off the top of my head as an *example* of the kind of thing you could do.) > if the destination does not have a mapping, you fall back to > potentially sub-optimal 'normal' routing, treating the identifier as > the now-standard locator/id merged address. In other words, you'd inject routes using names from the "identifier" namespace into the "locator" routing plane? Ugh. How soon until you basically lose the value of having a separate locator plane, if that becomes widespread? And you know someone will find a reason to do that kludge. My motto is always "make it impossible for people to kludge, otherwise they will". >> otherwise you have to deal with the possibility that the packet has to >> get unwrapped half-way along the path, and then you start to lose a >> lot of the benefits if all you have is (effectively) a small portion >> of the network using the new addressing > Which will be the case during transition for any approach unless you > assume a global flag day. I understand that it will have to be deployed incrementally. All I meant was that unless in the "end" state (I know, nothing's ever permanent) it is deployed fairly widely, you'll have a large part of the network which does have to deal with mega-tables, and does that really help? I suppose it helps those people who are part of the region with the new stuff... > I see this as a fairly pragmatic cost/benefit tradeoff. I see it, obviously, as another instance of what Pekka pointed out - people taking the easiest, but short-term, solution to their problem. > I see 4 options: > a) Change both the end points and the infrastructure .. > b) Change only the end points .. > c) Change only the [router] infrastructure .. > d) Change the junction between the hosts and the infrastructure > (e.g., the point between the "core" and the "edge"). > I figure (d) is the cheapest, easiest, and thus, most likely to be > deployed. Well, you're right there. It's basically 8+8, only it's now 16+16, and the edge routers add an entire header, not just play with the RG bits. > I am not suggesting these are constraints (I certainly am not the one > to define constraints in any event), I am merely voicing my opinion Alas (to me), it's one that makes a lot of sense. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 10:44:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYYD-0006uR-5A; Fri, 10 Nov 2006 10:44:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYYB-0006rZ-BM for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:44:15 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYYA-0005fM-5B for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:44:15 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ED12C86AE7; Fri, 10 Nov 2006 10:44:04 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U Message-Id: <20061110154404.ED12C86AE7@mercury.lcs.mit.edu> Date: Fri, 10 Nov 2006 10:44:04 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Jari Arkko >> If there's no community will to change IPv6, we're wasting out time. > I believe there is will from the IESG/IAB to do whatever it takes. Alas, I put a lot of weight in David's argument that people will opt for the most minimal, easiest fix to the most obvious problem. > I don't, and I don't think the others in IESG/IAB have either, a magic > solution. ... > (But I would seriously question whether "change IPv6" is the answer, or > at least not the complete answer.) The thing is, that if you're going for solutions of the form "jack up the existing internetwork layer and turn it into an end-end naming layer, and stick a new internetwork layer underneath it", it's probably a lot easier to jack up IPv4 and stick a new routing layer underneath it. After all, 2^32 is 4 billion, which is a lot of hosts, and that's how many distinct names you get out of IPv4 "addresses" if you dole them out serially, and remove the topological significance. And NAT continues to do its thing, if we need "more" identifiers. That way, you don't have to change *any* hosts (including the forklift upgrade to IPv6). I mean, you're going to have to have zillions of legacy hosts to deal with anyway, so any solution that works for them is going to have be be pretty good anyway. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 10:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYfY-0002p8-BQ; Fri, 10 Nov 2006 10:51:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYfX-0002oj-0R for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:51:51 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYfV-0006pt-4i for architecture-discuss@ietf.org; Fri, 10 Nov 2006 10:51:50 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GiYfH-0005wA-Vf for architecture-discuss@ietf.org; Fri, 10 Nov 2006 07:51:37 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Nov 2006 16:51:41 +0100 To: Fred Baker From: Jefsey_Morfin Subject: Re: [arch-d] Re: An example of how the requirements and right questions interrelate In-Reply-To: <237D030A-BA18-4E02-8591-CBACC932A983@cisco.com> References: <8445C02A-9B1A-48B9-9887-9E5A9EDCBDA8@cisco.com> <2E4219EA-5942-463F-A646-B0B16D2754B9@nomadiclab.com> <237D030A-BA18-4E02-8591-CBACC932A983@cisco.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0255483831==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0255483831== Content-Type: multipart/alternative; boundary="----MTnoyriaszutfdxupwrhcqhwehoyeegeom" ------MTnoyriaszutfdxupwrhcqhwehoyeegeom Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-331443D2 Dear Fred, I read what you say. And this very interesting. Thank you. But I do not understand why you want to change what exists? Not only to improve what is coming and give all the time to what exists to become obsolete or to find new solutions for new needs. There are six IPv6 /3 blocks. People needing hard coded IP addresses are eiher using the current IPv6 block or IPv4. What is the problem of keeping supporting them? And to pcik another block for another numbering plan reducing the load on tables? This is why I lobby for RIRs and ITU addressing blocks to coexist and cooperate. Multihoming and mobility are an issue for people not bound to their IP addresses? IMHO routing is not to be addressed in tables but in the addressing plan (coordinates) plus a distributed needle mechanism (probably a ONES, i.e. networked OPES which could probably also address the problem at the net/host edge). For a few years birds, fishes, ants, etc. succeed to go where they want rather efficiently without any table on the top of the moutains or the bottom of the sea? jfc On 13:41 10/11/2006, Fred Baker said: >On Nov 10, 2006, at 12:40 AM, Pekka Nikander wrote: >>In this particular case, I'd like to ask why the enterprise >>community abhors renumbering? >> >>And I think we know the rough answer chain: >> >> 1) it costs too much, because >> 2a) addresses have high-level, application specific semantics, >>thereby making changing them costly, and >> 2b) there are no good mechanisms for addressing these costs in >>the current architecture > >Those are certainly important parts of the question. I learned a lot >while researching for > >http://www.ietf.org/rfc/rfc4192.txt >4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. > Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110 >bytes) > (Updates RFC2072) (Status: INFORMATIONAL) > >Bottom line, the primary reason that I came up with for people not >wanting to renumber has to do with poor application design and >network management practices. > >Unicast network layer addresses do not actually have "high-level, >application specific semantics". There are some multicast addresses >that have specific meanings, such as AllOspfDesignatedRouters; I'll >argue that those are a very special case. If unicast applications had >application-specific semantics, one would need different addresses >for different applications. They don't; addresses are assigned per >interface, not per application. > >One can argue that there is no need for a generic application to have >any knowledge of either the address(es) of its own system or a peer >it wants to communicate with. The reason that it does know is what I >would consider to be poorly designed socket APIs. The way many OS's >work today is something like: > > address := gethostbyname(DNS name); > socket := opensocket(address); > >One could imagine a different API: > > socket := openSocketByName(DNS name) > >to accomplish the same thing, and hide the distinction between >different kinds of IP addresses and the multiplicity of them entirely >from the application. Alas, it is not so. > >Now, the folks in the opsec working group will tell you that they >really don't want to have access by name, they really want the >address, and will give you reasons why. No problem, we provide a >separate API for folks who have a real requirement of this type. >Let's just say that they are a special case, not the general one. > >Regarding mechanisms in the present architecture for managing address >complexities, well, we have mechanisms (see, for example, RFC 2894, >and more generally consider how a large network uses scripts and >databases to manage configurations), but I'm not sure the mechanisms >are all that relevant. The big issue is that there are a variety of >configuration elements in routers (yes, my company is part of the >problem here) and in some cases in applications where it is just a >whole lot simpler to configure the address, and as a result the >address is what is configured. Fixing this is a non-trivial problem, >not something that one waves a hand at. Route maps, access lists, >security associations, static routes, and a long list of other things >are implicated here. I was told of a company whose shipping would >stop cold if a certain computer was renumbered, because the hand-held >UPC readers used in the process use a hard-coded IP address rather >than a DNS name configured in a NVRAM or such - someone took an ill- >advised short-cut, and it makes that particular change difficult. >This class of issue is mostly what makes renumbering hard. And saying >"well, if we just had defined and implemented >that would be solved" is naive - the big problem there is that never >mind what might or might not exist, the engineer designing >chose to not use it. If the tool isn't used, it really doesn't matter >how wonderful it is. > >You might find > >http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout > "Things to think about when Renumbering an IPv6 network", Tim Chown, > 20-Sep-06 > >interesting in this context. > >The problem is closest to your "it costs too much", although in this >case it isn't a monetary cost. It is the fact that one has to somehow >touch every computer in an organization including its network >infrastructure and management and mission-critical servers, and in >touching them do exactly the right thing. That is something that is >doable (my company does it regularly) on a piecemeal basis, but >pretty difficult for a company of any non-trivial size to do globally >in one swell foop. > >So I mostly disagree with your 2(a) and 2(b), but I will agree with >some variation on your first point. > >>So, based on the above, I still think the right question is to ask >>what we want to name and address, through the socket APIs. > >OK, so what would they be? > >I tend to think of applications in the manner that the term "host" >resulted from. An Application Host Processor, for those of us >familiar with Big Blue, is a computer on which applications run. If >two applications cannot coexist easily one one host, one either >upgrades the host in some way or separates them, making them run on >separate systems. If two systems are underutilized, one might >similarly move an application from one to the other for economic >reasons. The computer is a computational environment that some number >of applications use, and the applications are in a very real sense >the important part. So I will generally argue that one wants to name >applications, not the computers they run on, and lo and behold we do >that (sort of). We have names like ftp.example.com, smtp.example.com, >and so on. The translations of these names into addresses may result >in single or multiple addresses, and in the latter case they may be >multiple interfaces on the same machine or they may be different >machines. In general, I think that is a very sensible model. > >As to addresses, one needs a way to find the endpoint that a targeted >application runs on in the topology of the network. That is a many- >layered thing; when the message arrives at the host, how does the >host determine that the message is intended for itself? How does the >router in front of it determine which host to deliver the message to? >On some different LAN, how does one find an acceptable path to the >target LAN? In view of RFC 2008, in a remote administration, how does >routing find the targeted administration that operates the intended >LAN? This is the stuff (using GSE's terms) of the endpoint >identifier, the LAN ID, and the "routing glop". There are many ways >to cut this cookie: the addresses a system uses can, when treated as >an equivalence class, be called a locator or endpoint identifier, or >the DNS name could be called that. So the EID doesn't have to be >implemented as a certain set of bits within a network address; there >are other ways to do it. But functionally, we have to have some >solution to the problem that the EID, however we understand it, >solves. Ditto more and less specific components of the routing locator. > >I tend to think, and this isn't a very original thought, that the big >problem that we have tripped over in this area is that we have not >kept names at the application layer and network layer addresses at >the network layer. They are in fact in the right places, but we >manage to distribute addressing information to a part of the system >it is irrelevant to, and in so doing shoot ourselves in the foot. > >If you want a detailed discussion of this, you might be interested to >review the development and specification of the ISO CLNS NSAP :-) > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > ------MTnoyriaszutfdxupwrhcqhwehoyeegeom Content-Type: text/html Dear Fred,
I read what you say. And this very interesting. Thank you.

But I do not understand why you want to change what exists? Not only
to improve what is coming and give all the time to what exists to
become obsolete or to find new solutions for new needs. There are six
IPv6 /3 blocks. People needing hard coded IP addresses are eiher
using the current IPv6 block or IPv4. What is the problem of keeping
supporting them? And to pcik another block for another numbering plan
reducing the load on tables? This is why I lobby for RIRs and ITU
addressing blocks to coexist and cooperate. Multihoming and mobility
are an issue for people not bound to their IP addresses?

IMHO routing is not to be addressed in tables but in the addressing
plan (coordinates) plus a distributed needle mechanism (probably a
ONES, i.e. networked OPES which could probably also address the
problem at the net/host edge). For a few years birds, fishes, ants,
etc. succeed to go where they want rather efficiently without any
table on the top of the moutains or the bottom of the sea?
jfc


On 13:41 10/11/2006, Fred Baker said:

>On Nov 10, 2006, at 12:40 AM, Pekka Nikander wrote:
>>In this particular case, I'd like to ask why the enterprise
>>community abhors renumbering?
>>
>>And I think we know the rough answer chain:
>>
>>   1) it costs too much, because
>>   2a) addresses have high-level, application specific semantics,
>>thereby making changing them costly, and
>>   2b) there are no good mechanisms for addressing these costs in
>>the current architecture
>
>Those are certainly important parts of the question. I learned a lot
>while researching for
>
>http://www.ietf.org/rfc/rfc4192.txt
>4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F.
>      Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110
>bytes)
>      (Updates RFC2072) (Status: INFORMATIONAL)
>
>Bottom line, the primary reason that I came up with for people not
>wanting to renumber has to do with poor application design and
>network management practices.
>
>Unicast network layer addresses do not actually have "high-level,
>application specific semantics". There are some multicast addresses
>that have specific meanings, such as AllOspfDesignatedRouters; I'll
>argue that those are a very special case. If unicast applications had
>application-specific semantics, one would need different addresses
>for different applications. They don't; addresses are assigned per
>interface, not per application.
>
>One can argue that there is no need for a generic application to have
>any knowledge of either the address(es) of its own system or a peer
>it wants to communicate with. The reason that it does know is what I
>would consider to be poorly designed socket APIs. The way many OS's
>work today is something like:
>
>         address := gethostbyname(DNS name);
>         socket := opensocket(address);
>
>One could imagine a different API:
>
>         socket := openSocketByName(DNS name)
>
>to accomplish the same thing, and hide the distinction between
>different kinds of IP addresses and the multiplicity of them entirely
>from the application. Alas, it is not so.
>
>Now, the folks in the opsec working group will tell you that they
>really don't want to have access by name, they really want the
>address, and will give you reasons why. No problem, we provide a
>separate API for folks who have a real requirement of this type.
>Let's just say that they are a special case, not the general one.
>
>Regarding mechanisms in the present architecture for managing address
>complexities, well, we have mechanisms (see, for example, RFC 2894,
>and more generally consider how a large network uses scripts and
>databases to manage configurations), but I'm not sure the mechanisms
>are all that relevant. The big issue is that there are a variety of
>configuration elements in routers (yes, my company is part of the
>problem here) and in some cases in applications where it is just a
>whole lot simpler to configure the address, and as a result the
>address is what is configured. Fixing this is a non-trivial problem,
>not something that one waves a hand at. Route maps, access lists,
>security associations, static routes, and a long list of other things
>are implicated here. I was told of a company whose shipping would
>stop cold if a certain computer was renumbered, because the hand-held
>UPC readers used in the process use a hard-coded IP address rather
>than a DNS name configured in a NVRAM or such - someone took an ill-
>advised short-cut, and it makes that particular change difficult.
>This class of issue is mostly what makes renumbering hard. And saying
>"well, if we just had <pick your protocol> defined and implemented
>that would be solved" is naive - the big problem there is that never
>mind what might or might not exist, the engineer designing <whatever>
>chose to not use it. If the tool isn't used, it really doesn't matter
>how wonderful it is.
>
>You might find
>
>http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout
>   "Things to think about when Renumbering an IPv6 network", Tim Chown,
>   20-Sep-06
>
>interesting in this context.
>
>The problem is closest to your "it costs too much", although in this
>case it isn't a monetary cost. It is the fact that one has to somehow
>touch every computer in an organization including its network
>infrastructure and management and mission-critical servers, and in
>touching them do exactly the right thing. That is something that is
>doable (my company does it regularly) on a piecemeal basis, but
>pretty difficult for a company of any non-trivial size to do globally
>in one swell foop.
>
>So I mostly disagree with your 2(a) and 2(b), but I will agree with
>some variation on your first point.
>
>>So, based on the above, I still think the right question is to ask
>>what we want to name and address, through the socket APIs.
>
>OK, so what would they be?
>
>I tend to think of applications in the manner that the term "host"
>resulted from. An Application Host Processor, for those of us
>familiar with Big Blue, is a computer on which applications run. If
>two applications cannot coexist easily one one host, one either
>upgrades the host in some way or separates them, making them run on
>separate systems. If two systems are underutilized, one might
>similarly move an application from one to the other for economic
>reasons. The computer is a computational environment that some number
>of applications use, and the applications are in a very real sense
>the important part. So I will generally argue that one wants to name
>applications, not the computers they run on, and lo and behold we do
>that (sort of). We have names like ftp.example.com, smtp.example.com,
>and so on. The translations of these names into addresses may result
>in single or multiple addresses, and in the latter case they may be
>multiple interfaces on the same machine or they may be different
>machines. In general, I think that is a very sensible model.
>
>As to addresses, one needs a way to find the endpoint that a targeted
>application runs on in the topology of the network. That is a many-
>layered thing; when the message arrives at the host, how does the
>host determine that the message is intended for itself? How does the
>router in front of it determine which host to deliver the message to?
>On some different LAN, how does one find an acceptable path to the
>target LAN? In view of RFC 2008, in a remote administration, how does
>routing find the targeted administration that operates the intended
>LAN? This is the stuff (using GSE's terms) of the endpoint
>identifier, the LAN ID, and the "routing glop". There are many ways
>to cut this cookie: the addresses a system uses can, when treated as
>an equivalence class, be called a locator or endpoint identifier, or
>the DNS name could be called that. So the EID doesn't have to be
>implemented as a certain set of bits within a network address; there
>are other ways to do it. But functionally, we have to have some
>solution to the problem that the EID, however we understand it,
>solves. Ditto more and less specific components of the routing locator.
>
>I tend to think, and this isn't a very original thought, that the big
>problem that we have tripped over in this area is that we have not
>kept names at the application layer and network layer addresses at
>the network layer. They are in fact in the right places, but we
>manage to distribute addressing information to a part of the system
>it is irrelevant to, and in so doing shoot ourselves in the foot.
>
>If you want a detailed discussion of this, you might be interested to
>review the development and specification of the ISO CLNS NSAP :-)
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>

------MTnoyriaszutfdxupwrhcqhwehoyeegeom-- --===============0255483831== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0255483831==-- From architecture-discuss-bounces@ietf.org Fri Nov 10 11:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZJt-0002S7-3j; Fri, 10 Nov 2006 11:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZJs-0002RJ-CW for architecture-discuss@ietf.org; Fri, 10 Nov 2006 11:33:32 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIPK-0006zL-D3 for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:30:02 -0500 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiIB2-00033c-UQ for architecture-discuss@ietf.org; Thu, 09 Nov 2006 17:15:18 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kA9MFDhk029471; Thu, 9 Nov 2006 14:15:13 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kA9MFDYn029470; Thu, 9 Nov 2006 14:15:13 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 9 Nov 2006 14:15:13 -0800 From: David Meyer To: John Day Subject: Re: [arch-d] [Off-topic ] Furthe r thoughts: about systems theory and the theory U Message-ID: <20061109221513.GA29417@1-4-5.net> References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> <1A898C8A-6AB4-4584-A008-3DE6DBD2C4FA@nomadiclab.com> <20061109220010.GA28334@1-4-5.net> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.6 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1698007007==" Errors-To: architecture-discuss-bounces@ietf.org --===============1698007007== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 09, 2006 at 05:08:32PM -0500, John Day wrote: > I guess the question is more, where should the architecture=20 > discussions go if this is going to be dedicated to routing and=20 > addressing? I don't have an answer, and since I posted this message some of my collegues have suggested we use a different list for routing & addressing. We'll get together and get a dinfinitive answer to you as soon as possible. --dmm --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFU6hxORgD1qCZ2KcRAm9EAJ9RQ2NBB4OZAotqS/QkGb3gjXX14ACgkFe7 AKN8b572M6YL0jaF9IIC/FM= =JPmk -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- --===============1698007007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1698007007==-- From architecture-discuss-bounces@ietf.org Fri Nov 10 11:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZXW-0008TR-JP; Fri, 10 Nov 2006 11:47:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZXW-0008TM-6Q for architecture-discuss@ietf.org; Fri, 10 Nov 2006 11:47:38 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiZXQ-0005uU-Va for architecture-discuss@ietf.org; Fri, 10 Nov 2006 11:47:38 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id A54B2341F9; Fri, 10 Nov 2006 11:47:32 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:47:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] [Off-topic ] Furthe r thoughts: about systems theory andthe theory U Date: Fri, 10 Nov 2006 11:47:30 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8ADB5@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061109221513.GA29417@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] [Off-topic ] Furthe r thoughts: about systems theory andthe theory U Thread-Index: AccE5lL1SUlnXxbQSw+wuoIVM0EZ/gAASvlw From: "Bound, Jim" To: "David Meyer" , "John Day" X-OriginalArrivalTime: 10 Nov 2006 16:47:32.0145 (UTC) FILETIME=[EA7E4A10:01C704E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dave, That would be good I think. Probably should announce the list to this list too and whereever else it is announced. I would suggest we need to identify the technical topics well and if you can do that it would be helpful. Also might be good to work on addressing first then routing as Peter Sherbin from Rogers suggested last night at the Plenary. Thanks /jim=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: Thursday, November 09, 2006 5:15 PM > To: John Day > Cc: Pekka Nikander; architecture-discuss@ietf.org > Subject: Re: [arch-d] [Off-topic ] Furthe r thoughts: about=20 > systems theory andthe theory U >=20 > On Thu, Nov 09, 2006 at 05:08:32PM -0500, John Day wrote: > > I guess the question is more, where should the architecture=20 > > discussions go if this is going to be dedicated to routing and=20 > > addressing? >=20 > I don't have an answer, and since I posted this message > some of my collegues have suggested we use a different > list for routing & addressing. We'll get together and get > a dinfinitive answer to you as soon as possible. >=20 > --dmm >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 11:49:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZZQ-00011w-9z; Fri, 10 Nov 2006 11:49:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZZO-00011f-WD for architecture-discuss@ietf.org; Fri, 10 Nov 2006 11:49:35 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiZZM-0006Bd-N2 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 11:49:34 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6489B86AE7; Fri, 10 Nov 2006 11:49:32 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Re: An example of how the requirements and right questions interrelate Message-Id: <20061110164932.6489B86AE7@mercury.lcs.mit.edu> Date: Fri, 10 Nov 2006 11:49:32 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Fred Baker > The big issue is that there are a variety of configuration elements > .. where it is just a whole lot simpler to configure the address, and > as a result the address is what is configured. Fixing this is a > non-trivial problem ... > And saying "well, if we just had defined and > implemented that would be solved" is naive - the big problem there is > that never mind what might or might not exist, the engineer designing > chose to not use it. If the tool isn't used, it really > doesn't matter how wonderful it is. ... > one has to somehow touch every computer in an organization including > its network infrastructure and management and mission-critical servers, > and in touching them do exactly the right thing. Fred, illuminating. I've heard this stuff before, but your examples are interesting, and I like your description of the problem. The bottom line is that being able to switch ISP's seamlessly is really a priority-one requirement. How many of these problems go away if one uses a NAT box to insulate the local addressing domain from the global one? Yes, everything that's visible from the rest of the Internet still has to be updated, but everything involved in internal communication should be insulated, no? Interestingly, NAT boxes don't solve the problem of *other* people changing addresses - e.g. if company A has some other company B they cooperate with, and B is allowed (to make up an example for illustrative purposes only, I don't know if anyone actually does this) incoming FTP access through A's firewall, then if B switches ISP's, A has to update their configuration. As far as I can tell, the only thing that fixes that class of problem is to use a different namespace for configuration, and, as you point out, that's not trivial, to get people to change their habits. So jacking up the existing internetwork layer, and changing internetwork addresses into true identifiers, starts to look more and more appealing... > I will generally argue that one wants to name applications, not the > computers they run on .. The translations of these names into > addresses may result in single or multiple addresses, and in the latter > case they may be multiple interfaces on the same machine or they may be > different machines. In general, I think that is a very sensible model. > ... > There are many ways to cut this cookie: the addresses a system uses > can, when treated as an equivalence class, be called a locator or > endpoint identifier .. functionally, we have to have some solution to > the problem that the EID, however we understand it, solves. This is kind of what I was alluding to yesterday, when I questioned whether endpoints were really the thing we needed to add a namespace for, or whether it should be some sort of higher-level entity (e.g. a "service", which is actually implemented as a bunch of actual machines in a farm, which are separate fate-sharing entities) - and then went on to muse that perhaps we needed both. We clearly need names for interfaces, because those are the places that the system of routers delivers packets to. We clearly need names for services, because that's what people (and applications working on their behalf) really care about. The thing is, do we need another namespace in the middle, to name one end of a reliable transport connection? Perhaps not, if one had a blank sheet, but at the same time, for the reasons mentioned above, maybe it's pragmatic to add one, simply because of all this installed grup where people are using addresses as identifiers. > the big problem that we have tripped over in this area is that we have > not kept names at the application layer and network layer addresses at > the network layer. They are in fact in the right places, but we manage > to distribute addressing information to a part of the system it is > irrelevant to, and in so doing shoot ourselves in the foot. 'Exactement'. And by now the problem is so widespread we may never fix it. So, once again, jack-up looks good. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 12:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaGs-0004HC-Ee; Fri, 10 Nov 2006 12:34:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaGq-0004H7-TM for architecture-discuss@ietf.org; Fri, 10 Nov 2006 12:34:28 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiaGp-00044M-KN for architecture-discuss@ietf.org; Fri, 10 Nov 2006 12:34:28 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 19943898C2; Fri, 10 Nov 2006 19:34:20 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 579FE89880; Fri, 10 Nov 2006 19:34:19 +0200 (EET) Message-ID: <4554B81A.1090703@piuha.net> Date: Fri, 10 Nov 2006 09:34:18 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: Noel Chiappa Subject: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) References: <20061110153455.876AC86AE7@mercury.lcs.mit.edu> In-Reply-To: <20061110153455.876AC86AE7@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, > And the best part of all is that we're adding bags on the side of IPv6 before > it's even deployed. Wow, what a great design. > > Sorry I'm ranting, but this is really, really, really depressing. > I'm sorry to interrupt your depression, but I'm interested in hearing what you think we should do. Do you have a pointer to a proposal that I could look at? --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 13:44:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibLg-0007my-I1; Fri, 10 Nov 2006 13:43:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibJ3-0006YH-7P for architecture-discuss@ietf.org; Fri, 10 Nov 2006 13:40:49 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibA8-0004g0-EL for architecture-discuss@ietf.org; Fri, 10 Nov 2006 13:31:38 -0500 Received: from [130.129.67.56] (dhcp67-56.ietf67.org [130.129.67.56]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kAAIVeoN026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Nov 2006 10:31:41 -0800 Message-ID: <4554C57D.2070209@dcrocker.net> Date: Fri, 10 Nov 2006 10:31:25 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? References: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> In-Reply-To: <20061109151147.8A5CB872E5@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > We have been avoiding fundamentally resolving anything for the past 30 > > years. .. The constant patching is doing far more harm than good. ... > I agree wholeheartedly with all this. However... ... > After the IPv6 debacle (picking a solution which was, proudly, the exact same > architecture as IPv4, when, manifestly, "more of the same, just with one > field bigger" was *NOT* the solution), On reading through the thread, I think there is a mixture of some interesting observations and interesting conclusions. "Interesting" does not imply right or wrong... Some of each seems to me to be off the mark and others probably are on the mark. The IETF has mostly been extremely useful at developing refinements and getting large-scale adoption. The original work that it refines almost always comes from outside the IETF. The benefit of the IETF has been to develop a wider circle of support, possibly to ensure that the specification serves a broader audience, and frequently to preserve an installed base. (This last point is often asserted as a premature goal, but its application in legitimate situations has been massively beneficial.) The original task for IPv6 was to solve an address space problem. Had the IPv6 effort restricted itself to that task, it would have been a successful effort. It would have been simple and quick. Transition to it would have been nicely painless. Instead the requirements list got bloated and turned into a pseudo-architecture-change project. We are 12 years down the road (pun intended, for those who get it). The world has changed in interesting ways and more architects understand more issues better. It is entirely reasonable to envision creating a set of technologies that could actually replace much or all of the current Internet infrastructure. In all likelihood, the replacement will demonstrate huge amount of DNA in common with the existing Internet technologies, but it is almost certainly better to think in terms of a new species. (On the other hand, the more shared DNA, the easier a transition is likely to be.) That effort MUST be done by a relatively small, relatively cohesive, and entirely independent team that produces a prototype, prior to involving the IETF. Possibly actually going much, much farther down the development and deployment path before doing anything that looks like an IETF working group. This is not meant as a criticism of the IETF but rather an acknowledgment that the skillset of IETF working groups has little overlap with the goal of creating a new architecture. I should comment that my double use of "relatively", above, does not mean a group filled with singing and hugging. Actually, a group that debates and shouts is probably better, to ensure that ideas are subjected to deep evaluation-by-challenge. But of course, what I really mean is that all participants buy into the same basic goals and probably buy into the same basic approach (although this latter is fuzzy to me.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 13:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibO6-0000cd-Uj; Fri, 10 Nov 2006 13:46:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibO4-0000cN-VE for architecture-discuss@ietf.org; Fri, 10 Nov 2006 13:46:00 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibO3-0007RK-Lk for architecture-discuss@ietf.org; Fri, 10 Nov 2006 13:46:00 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3EC9289883; Fri, 10 Nov 2006 20:45:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 73CC089880; Fri, 10 Nov 2006 20:45:55 +0200 (EET) Message-ID: <4554C8E2.3080004@piuha.net> Date: Fri, 10 Nov 2006 10:45:54 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] Systems theory: The IETF "addicted" to "symptomatic solutions" aka "point solutions"? References: <20061109022418.01CA2872DD@mercury.lcs.mit.edu> <1DB19C14-A97E-4D0E-B1E6-226591ACECE4@nomadiclab.com> <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> In-Reply-To: <47DA7873-591B-45DB-80D6-BD04815607BD@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org +1 Actually, I don't mind discussing this topic. But what I am missing is a discussion of (1) Do we have an architectural problem with regards to routing scalability, and what are the supporting facts? (2) Possible ways to address the problem and the relevant trade-offs. --Jari Fred Baker kirjoitti: > Guys, maybe we should set up a different list for this discussion. I'm > sure it's a very interesting and important discussion for the IETF to > have about itself. > > That said, we have cycles for one thing. We can navel-gaze and wonder > whether we need a counsellor, or we can go solve the IPv6 addressing > problem. This list is for technical discussions, and right now we > really need to be thinking about the technical topic. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 13:55:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibWm-0007H1-0C; Fri, 10 Nov 2006 13:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibWl-0007Gd-0B for architecture-discuss@ietf.org; Fri, 10 Nov 2006 13:54:59 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibWe-0000Ou-NQ for architecture-discuss@ietf.org; Fri, 10 Nov 2006 13:54:58 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6C449341A3; Fri, 10 Nov 2006 13:54:50 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 13:54:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Systems theory: The IETF "addicted" to "symptomaticsolutions" aka "point solutions"? Date: Fri, 10 Nov 2006 13:54:48 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8AEEA@tayexc14.americas.cpqcorp.net> In-Reply-To: <4554C8E2.3080004@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Systems theory: The IETF "addicted" to "symptomaticsolutions" aka "point solutions"? Thread-Index: AccE+JEWMHWi48N5Tpiyx+mwKDswQAAAPYGQ From: "Bound, Jim" To: "Jari Arkko" , "Fred Baker" X-OriginalArrivalTime: 10 Nov 2006 18:54:49.0856 (UTC) FILETIME=[B2EC8000:01C704F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I would like to see these questions discussed. Also under trade-offs the market and business ramifications are part of that discussion when it happens. /jim=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, November 10, 2006 1:46 PM > To: Fred Baker > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Systems theory: The IETF "addicted" to=20 > "symptomaticsolutions" aka "point solutions"? >=20 > +1 >=20 > Actually, I don't mind discussing this topic. But what I am=20 > missing is a discussion of >=20 > (1) Do we have an architectural problem with > regards to routing scalability, and what > are the supporting facts? >=20 > (2) Possible ways to address the problem and the > relevant trade-offs. >=20 > --Jari >=20 > Fred Baker kirjoitti: > > Guys, maybe we should set up a different list for this=20 > discussion. I'm=20 > > sure it's a very interesting and important discussion for=20 > the IETF to=20 > > have about itself. > > > > That said, we have cycles for one thing. We can navel-gaze=20 > and wonder=20 > > whether we need a counsellor, or we can go solve the IPv6=20 > addressing=20 > > problem. This list is for technical discussions, and right now we=20 > > really need to be thinking about the technical topic. >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 14:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gibl5-000393-TV; Fri, 10 Nov 2006 14:09:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gibl4-00038s-MD for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:09:46 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gibl2-0002iL-8e for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:09:46 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAAJ9dBj207906 for ; Fri, 10 Nov 2006 19:09:39 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAAJCm8a2973792 for ; Fri, 10 Nov 2006 20:12:48 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAAJ9dk3008292 for ; Fri, 10 Nov 2006 20:09:39 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAAJ9cqs008277; Fri, 10 Nov 2006 20:09:39 +0100 Received: from zurich.ibm.com ([9.4.210.165]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA102230; Fri, 10 Nov 2006 20:09:37 +0100 Message-ID: <4554CE6F.1090400@zurich.ibm.com> Date: Fri, 10 Nov 2006 20:09:35 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Noel Chiappa Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) References: <20061110183347.BE3A286AFC@mercury.lcs.mit.edu> In-Reply-To: <20061110183347.BE3A286AFC@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Well, my thoughts on how to jack up IPv4 (or IPv6, although there's no > benefit to deploying that if you do this), turn it into an end-end endpoint > identification layer, When you have more than 4 billion nodes, or any nodes with ambiguous IPv4 addresses, surely you need extra address bits? Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 14:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic0m-00035e-Tx; Fri, 10 Nov 2006 14:26:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic0k-00031j-K0 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:25:58 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gibsr-0003bS-Vl for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:17:51 -0500 Received: (qmail 20620 invoked from network); 10 Nov 2006 19:17:37 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 10 Nov 2006 19:17:37 -0000 Received: from LIPC ([192.168.1.73]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:17:36 -0800 From: "Tony Li" To: "'Brian E Carpenter'" , "'Noel Chiappa'" Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 11:17:31 -0800 Message-ID: <011d01c704fc$dece4c00$4901a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccE+93tjCWbYJVZQs6NjvjFQOX73QAAPT8Q In-Reply-To: <4554CE6F.1090400@zurich.ibm.com> X-OriginalArrivalTime: 10 Nov 2006 19:17:36.0525 (UTC) FILETIME=[E185A3D0:01C704FC] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > Well, my thoughts on how to jack up IPv4 (or IPv6, although > there's no > > benefit to deploying that if you do this), turn it into an > end-end endpoint > > identification layer, > > When you have more than 4 billion nodes, or any nodes with > ambiguous IPv4 > addresses, surely you need extra address bits? NAT T _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 14:43:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicGD-0007HG-OQ; Fri, 10 Nov 2006 14:41:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicGD-0007HB-0N for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:41:57 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GicGB-0001Oa-Kg for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:41:56 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kAAJfsse363888 for ; Fri, 10 Nov 2006 19:41:54 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAAJidm02396246 for ; Fri, 10 Nov 2006 19:44:39 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAAJfs9l014387 for ; Fri, 10 Nov 2006 19:41:54 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAAJfs56014384; Fri, 10 Nov 2006 19:41:54 GMT Received: from zurich.ibm.com ([9.4.210.165]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA94202; Fri, 10 Nov 2006 20:41:52 +0100 Message-ID: <4554D5FE.2050603@zurich.ibm.com> Date: Fri, 10 Nov 2006 20:41:50 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: tony.li@tony.li Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) References: <011d01c704fc$dece4c00$4901a8c0@tropos.com> In-Reply-To: <011d01c704fc$dece4c00$4901a8c0@tropos.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Noel Chiappa' , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony Li wrote: > > > >>>Well, my thoughts on how to jack up IPv4 (or IPv6, although >> >>there's no >> >>>benefit to deploying that if you do this), turn it into an >> >>end-end endpoint >> >>>identification layer, >> >>When you have more than 4 billion nodes, or any nodes with >>ambiguous IPv4 >>addresses, surely you need extra address bits? > > > > NAT Even if you have an antiNAT at the other end, address ambiguity destroys the e2e identification property and third party referrals. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 14:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicKy-0003A7-GE; Fri, 10 Nov 2006 14:46:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicKx-0003A2-Nk for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:46:51 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GicKt-0003l2-7E for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:46:51 -0500 Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAAJjVJe024589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Nov 2006 11:45:31 -0800 (PST) Message-ID: <4554D6DA.7060001@isi.edu> Date: Fri, 10 Nov 2006 11:45:30 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ian Peter Subject: Re: [arch-d] FW: [IRTF-Announce] New IRTF RG chartered: End-Middle-End Research Group References: <01e701c70307$28e466a0$4a02a8c0@IAN> In-Reply-To: <01e701c70307$28e466a0$4a02a8c0@IAN> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.5 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1598848726==" Errors-To: architecture-discuss-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1598848726== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA2E47BD2E41D1574F1587B3E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2E47BD2E41D1574F1587B3E Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: quoted-printable Ick. More "solve the world through the DNS". When the only tool you have is a hammer... Joe Ian Peter wrote: > This may be related...... >=20 > Ian Peter > Ian Peter and Associates Pty Ltd > PO Box 10670 Adelaide St Brisbane 4000 > Australia > Tel (+614) 1966 7772 > www.ianpeter.com > www.internetmark2.org > www.nethistory.info >=20 >=20 > -----Original Message----- > From: Aaron Falk [mailto:falk@ISI.EDU]=20 > Sent: 08 November 2006 17:44 > To: IRTF Announcements > Subject: [IRTF-Announce] New IRTF RG chartered: End-Middle-End Research= > Group >=20 > A new IRTF research group, End-Middle-End (EME) Research Group, has =20 > been created with the appended charter. >=20 > The full RG charter is at > http://www.irtf.org/eme > The RG web page/wiki is at: > http://www1.tools.ietf.org/group/irtf/trac/wiki/EME > Subscribe to the mailing list: > https://www1.ietf.org/mailman/listinfo/eme. >=20 > Aaron Falk > IRTF Chair >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > In the original Internet end-to-end architecture, a transport > connection linked a pair of hosts and was bound to a globally unique= > IP address and locally meaningful transport port at each end host. > This architecture has been progressively eroded, most notably by the= > use of NATs, which modify addresses, and firewalls and other middle > boxes, which expect to understand the semantics behind any given > port number (for instance to block or differentially handle a flow).= > As a result, end hosts are often not able to connect even when > security policies would otherwise allow such connections. This > problem will only be exacerbated with the emerging need for > IPv4-IPv6 translation. Beyond this, other changes in the way the > Internet is used has stressed the original unique-address:port model= > of transport connections. For instance, the need for robustness has= > resulted in a rise in multi-homing, which has led to scaling issues > in BGP. The use of multiple addresses at hosts is known to > alleviate this problem, but the architecture provides no good way to= > manage multiple addresses, either at connection establishment or > when the active address has to be changed. Mobility across access > networks similarly results in the need to cope with changing IP > addresses during a connection. In addition, DoS attacks are > increasingly a concern. There is a need for hosts to be able to > control which other hosts can send packets to it, and to exercise > that control deep in the network (i.e. near the attacker). >=20 > The common roots of this seemingly diverse set of problems are the > following: >=20 > 1. The IP address is no longer globally unique, is no longer intact > end-to-end, and is no longer stable over even short time periods.= >=20 > 2. The transport port number has no clear semantics outside of the > end-host that opened the socket. >=20 > 3. End hosts are often not explicitly aware of middle boxes, > especially middle boxes far away from them, and therefore cannot > control them much less be aware of what they are doing. >=20 > Beyond the specific problems mentioned above, this erosion of the > original E2E Internet mechanisms broadly results in greater > application-level complexity (to cope with the erosion), network > fragility and lack of robustness, poor security, and difficulty in > debugging the resulting problems. >=20 > While this group is not the first to identify these problems, we do > recognize that there may be a single architectural enhancement that > solves them all. Namely, a higher-level DNS-based naming scheme > (i.e. URIs) coupled with signaling protocols used to initiate and > modify transport-level connections such as TCP, UDP, SCTP or DCCP > flows. Such a protocol could provide a way for end-to-end > communication to explicitly address middleboxes, so that their > behavior can be understood, monitored and controlled. Such a > protocol might also be used to move connections between IP > addresses, as with mobility and multihoming, and to shut down > unwanted communication, as with DoS attacks. >=20 > The goal of the End-Middle-End Research Group (EME) is to evaluate = > the > feasibility and desirability of such an architectural change to the > Internet. The aim is first to investigate possible designs for a > strawman experimental protocol that can perform these tasks (the > so-called "ideal" design) without being overly constrained by > overlapping work happening in the IETF and elsewhere. Should one or= > more designs appear viable, then issues such as related work and > incremental deployment should be considered. Should this work still= > appear viable, then the IESG will be consulted with regards to > whether and how this should be brought into the IETF for =20 > standardization. >=20 > There are many questions that need to be answered along the > way. These issues include precisely which architectural problems > should be tackled and which should not, the degree to which such > signaling should be on-path vs off-path and the balance between > flexibility vs simplicity and efficiency. There are clear concerns > about such a track that need to be evaluated. Candidate protocols > should avoid falling into the virtual circuit trap, where routers > lose the ability to remedy failures locally, and avoid building a > mechanism that encourages the construction of walled gardens to the > detriment of the Internet as a whole. >=20 >=20 > _______________________________________________ > IRTF-Announce mailing list > IRTF-Announce@irtf.org > https://www1.ietf.org/mailman/listinfo/irtf-announce >=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigA2E47BD2E41D1574F1587B3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFVNbaE5f5cImnZrsRAnAEAJ4m1y+lJrY2asLFvAbPnTJ3nrLa5ACfX0hY VpmHKGv5cSMcUUCViAIm2eE= =yGZ0 -----END PGP SIGNATURE----- --------------enigA2E47BD2E41D1574F1587B3E-- --===============1598848726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1598848726==-- From architecture-discuss-bounces@ietf.org Fri Nov 10 14:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicK1-0002uJ-Sa; Fri, 10 Nov 2006 14:45:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicK0-0002tL-Qo for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:45:52 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GicJw-0003Wy-GA for architecture-discuss@ietf.org; Fri, 10 Nov 2006 14:45:52 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kAAJjcW5002172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Nov 2006 11:45:39 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kAAJjctU022449; Fri, 10 Nov 2006 11:45:38 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kAAJjbYM022392; Fri, 10 Nov 2006 11:45:38 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:45:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 11:44:54 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584B68@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <011d01c704fc$dece4c00$4901a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccE+93tjCWbYJVZQs6NjvjFQOX73QAAPT8QAADvxaA= From: "Fleischman, Eric" To: , "Brian E Carpenter" , "Noel Chiappa" X-OriginalArrivalTime: 10 Nov 2006 19:45:37.0962 (UTC) FILETIME=[CBBC90A0:01C70500] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, Your answer surprises me. Could you give a bit longer answer for what you are thinking? That is, I recognize the desirability of IPv4. Are you thinking of a large number of devices using private addresses behind a NAT that exposes a few public addresses? If so, then how can the receiving NAT do that mapping? I'm just not following you here. What are you thinking? --Eric -----Original Message----- From: Tony Li [mailto:tli@tropos.com]=20 Sent: Friday, November 10, 2006 11:18 AM To: 'Brian E Carpenter'; 'Noel Chiappa' Cc: architecture-discuss@ietf.org Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) =20 > > Well, my thoughts on how to jack up IPv4 (or IPv6, although > there's no > > benefit to deploying that if you do this), turn it into an > end-end endpoint > > identification layer, >=20 > When you have more than 4 billion nodes, or any nodes with > ambiguous IPv4 > addresses, surely you need extra address bits? NAT T _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 15:24:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gicv7-0003TH-Fa; Fri, 10 Nov 2006 15:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gicv6-0003TC-PX for architecture-discuss@ietf.org; Fri, 10 Nov 2006 15:24:12 -0500 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gicv4-00079U-DQ for architecture-discuss@ietf.org; Fri, 10 Nov 2006 15:24:12 -0500 Received: (qmail 31687 invoked from network); 10 Nov 2006 20:17:21 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 10 Nov 2006 20:17:21 -0000 Received: from LIPC ([192.168.1.73]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 12:17:21 -0800 From: "Tony Li" To: "'Fleischman, Eric'" , , "'Brian E Carpenter'" , "'Noel Chiappa'" Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 12:17:17 -0800 Message-ID: <014d01c70505$37b03a60$4901a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccE+93tjCWbYJVZQs6NjvjFQOX73QAAPT8QAADvxaAAAPRQcA== In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B68@XCH-NW-6V1.nw.nos.boeing.com> X-OriginalArrivalTime: 10 Nov 2006 20:17:21.0439 (UTC) FILETIME=[3A4C1AF0:01C70505] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Your answer surprises me. Could you give a bit longer answer for what > you are thinking? That is, I recognize the desirability of > IPv4. Are you > thinking of a large number of devices using private addresses behind a > NAT that exposes a few public addresses? If so, then how can the > receiving NAT do that mapping? I'm just not following you > here. What are > you thinking? Eric, Sorry for being terse. I was simply pointing out that appropriate use of address translation can easily allow us to map much more than 4 billion nodes onto 4 billion addresses. This was brought up at one of the first ROAD meetings. Please note that I do *NOT* advocate this approach, I simply mentioned it because we all need to be on the same page about the solution envelope be it good, bad, or ugly. I'm less than interested in applying more kludges to, or underneath, the existing architecture. I'm much more interested in doing it Right, doing it Once and doing it Forever. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 15:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gid27-0007yG-5d; Fri, 10 Nov 2006 15:31:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gid26-0007y8-14 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 15:31:26 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gid23-0000C1-Qh for architecture-discuss@ietf.org; Fri, 10 Nov 2006 15:31:26 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 955C286AFC; Fri, 10 Nov 2006 15:31:18 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Message-Id: <20061110203118.955C286AFC@mercury.lcs.mit.edu> Date: Fri, 10 Nov 2006 15:31:18 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Brian E Carpenter > When you have more than 4 billion nodes .. surely you need extra > address bits? Oh, one other thought I had (sorry, had it too late to tack it onto the other reply email): If we go the jack-up route (to avoid having to modify hosts), then we have a big, painful job ahead of us, which is to build, deploy, and populate that mapping database - the one that maps from old-style "addresses" (aka identifiers, now) to new-style locators. Getting that done, reliable, getting the data into it, etc, etc is going to be a major job of work. And I haven't even talked about the wrapping/unwrapping code in the routers, etc, etc. It's a scientific (and maybe engineering to) dictum to never change more than one variable at once in an experiment. I dunno about you, but if we're going to go the jack-up route, to me that mapping database alone is enough to bite off in one chew. Let's leave the "running out of 32-bit identifiers" problem, and the deployment of its solution, until later, yeah? In fact, I'd be inclined to leave any better routing architecture to phase II as well, which ought to show you how concerned I am about the magnitude of the basic jack-up stuff. But of course we should think about what a follow-on routing architecture might need, and make sure that both the mapping database, the wrapped header format (maybe GRE, or something like it?), and the wrapping code in the routers, all are ready to support a new routing architecture at some later phase of deployment. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 16:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gie8T-0004f6-TT; Fri, 10 Nov 2006 16:42:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gie8S-0004en-DZ for architecture-discuss@ietf.org; Fri, 10 Nov 2006 16:42:04 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gie8Q-0000dJ-0f for architecture-discuss@ietf.org; Fri, 10 Nov 2006 16:42:04 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kAALfuU7025310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Nov 2006 15:41:56 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kAALftEf010612; Fri, 10 Nov 2006 13:41:55 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kAALfqMl010515; Fri, 10 Nov 2006 13:41:55 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 13:41:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 13:41:02 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584B6A@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <014d01c70505$37b03a60$4901a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccE+93tjCWbYJVZQs6NjvjFQOX73QAAPT8QAADvxaAAAPRQcAACDTuQ From: "Fleischman, Eric" To: , "Brian E Carpenter" , "Noel Chiappa" X-OriginalArrivalTime: 10 Nov 2006 21:41:53.0891 (UTC) FILETIME=[09B6DB30:01C70511] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, I believe that I'm tracking with you, though I'm naturally curious what specific technical approach you would recommend. For example, the IETF has preferred to view locators to be absolute identifiers within a universal schema (e.g., a SPF approach to location). However, they could also be relative locators in a Bellman-Ford or Landmark routing manner. Regardless, how would you solve the EGP routing and end point ID addressing issue? Changing topics, I was surprised by this email thread because it is apparent that my memory of IPng (IPv6) differs significantly from the views I've seen thus far. Specifically, I believe that the IETF consensus position today supports Noel's distinction between end point IDs and topology locators -- we just don't agree on how to achieve it. I also believe that this distinction was also part of our original IPng consensus position and it is part of what I was thinking when I originally suggested the proto-IPv6 autoconfiguration approach: the first 10 bytes (in my original version) is the locator and the last 6 bytes are the identifiers. 8x8 is fine -- I'm not really talking about where the division is made just that it occurs and that the locators locate the routing topology to subnetworks. I then left Boeing and the IETF and when I eventually returned I was surprised to note that the standards had diverged from the positions that I thought we had agreed upon, as if Noel's contributions hadn't achieved the mindshare that I thought they had. Anyway, when I first saw Vince Fuller's material earlier this week, I resonated with his points, believing that he was restating our original IPng consensus position before it evolved into becoming "IPv4 with larger addresses." Regardless, from where we stand today, how would you technically solve EGP routing and end-point ID addressing if you were the king of the world? =20 --Eric -----Original Message----- From: Tony Li [mailto:tli@tropos.com]=20 Eric, Sorry for being terse. I was simply pointing out that appropriate use of address translation can easily allow us to map much more than 4 billion nodes onto 4 billion addresses. This was brought up at one of the first ROAD meetings. Please note that I do *NOT* advocate this approach, I simply mentioned it because we all need to be on the same page about the solution envelope be it good, bad, or ugly. I'm less than interested in applying more kludges to, or underneath, the existing architecture. I'm much more interested in doing it Right, doing it Once and doing it Forever. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 17:27:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiepX-00010b-Vw; Fri, 10 Nov 2006 17:26:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiepW-000106-DK for architecture-discuss@ietf.org; Fri, 10 Nov 2006 17:26:34 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiepV-0001KT-04 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 17:26:34 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAAMNGrG019708; Fri, 10 Nov 2006 14:23:20 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Fri, 10 Nov 2006 14:25:57 -0800 X-PGP-Universal: processed; by terminus.local on Fri, 10 Nov 2006 14:25:57 -0800 In-Reply-To: <20061110153455.876AC86AE7@mercury.lcs.mit.edu> References: <20061110153455.876AC86AE7@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <39D52065-4DA3-4EAE-A36A-F05251593109@virtualized.org> From: David Conrad Subject: =?ISO-8859-1?Q?Re:_[arch-d]_[Off-topic]=A0Further_thoughts:_abou?= =?ISO-8859-1?Q?t_systems_theory_and_the_theory_U?= Date: Fri, 10 Nov 2006 14:25:52 -0800 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, On Nov 10, 2006, at 7:34 AM, Noel Chiappa wrote: > Oh great, so once again we do the most minimal possible "bag-on-the- > side" > kludge to muddle through the nearest bump we can see on the road. A not unfair characterization. > We don't even take the opportunity to put a more capable layer down > there, > something that could say, name (and thefore have the possibility of > managing) > traffic aggregates. Having worked at a Silicon Valley software company, I am painfully aware that trying to do too much in too little time pretty much guarantees failure. Given the dependence the world now has on the Internet, I'm fairly certain we don't really have the luxury of failing. It is probably worthwhile pointing out that one advantage to the "jack up" approach is that once we do the initial jack up, we have _much_ greater flexibility in replacing the underlying layer(s). Right now, we're pretty screwed, particularly given the topics Fred touched on. > And the best part of all is that we're adding bags on the side of > IPv6 before > it's even deployed. I'd argue that IPv6 is deployed to a large extent now, if not actually used. I believe most core routers and host OSes support IPv6 if the latest code is installed. I would agree that there is very little if any actual use at this stage. However, on the other hand, it has taken us 10 years to get this far. Even if someone comes up with the Best Internet Architecture Ever(tm), it will take several years to get it deployed to the same level IPv6 is today and in the intervening time, people are going to be deploying more and more IPv6 and (presumably) actually using it. > Wow, what a great design. Call it an great educational experience. > Sorry I'm ranting, but this is really, really, really depressing. Again, I am just expressing my opinion and I too consider the state we're now in to be quite depressing. I would be overjoyed to see an alternative. Pragmatically speaking, however, I'm not sure there is one given the situation we have placed ourselves in. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 17:31:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gietp-0007mM-6r; Fri, 10 Nov 2006 17:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gieto-0007mG-5v for architecture-discuss@ietf.org; Fri, 10 Nov 2006 17:31:00 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gietm-0001sz-Qo for architecture-discuss@ietf.org; Fri, 10 Nov 2006 17:31:00 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 14:30:58 -0800 X-IronPort-AV: i="4.09,411,1157353200"; d="scan'208"; a="835109:sNHT145051758" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAAMUwOb003991; Fri, 10 Nov 2006 14:30:58 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAAMUtdE017549; Fri, 10 Nov 2006 14:30:55 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 14:30:55 -0800 Received: from [10.0.4.3] ([10.21.121.115]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 14:30:55 -0800 In-Reply-To: <20061110164932.6489B86AE7@mercury.lcs.mit.edu> References: <20061110164932.6489B86AE7@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: An example of how the requirements and right questions interrelate Date: Fri, 10 Nov 2006 14:30:53 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 22:30:55.0555 (UTC) FILETIME=[E3152930:01C70517] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3360; t=1163197858; x=1164061858; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20Re=3A=20An=20example=20of=20how=20the=20re quirements=20and=20right=20questions=20interrelate |Sender:=20; bh=LNHJa55fDnY+Wua8wCW6DZ/CRtGfIs8zW/pKy9oLiPo=; b=E+lNdfNBP+2OfE6HAbZax7ATRPk2pb+xecR8ETl1jh5hqtfvvyry429N/YqFbydXc+zXDOK+ Wr+5KQKJq+VqQ6rapI46pKaSksy5fGR85m6R+npy+PPj+5jcI8VNdBUe; Authentication-Results: sj-dkim-7; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > How many of these problems go away if one uses a NAT box to > insulate the local addressing domain from the global one? or an address rewrite algorithm like GSE proposes, or a single address at the site which is independent of the ISP as is proposed in PI or Metro? Some but not all. Consider the example of the shipping-management- system that has an externally visible and don't-you-dare-change-it IPv4 address. Well, even if we put the thing behind a NAT, changing that address is going to have to be done just right, and so on. Never underestimate the power of human stupidity. Robert A. Heinlein And the flip side is that NATs don't especially help with application architectures other than client-server. I imagine you have taken a glance at some of the p2p applications floating around the net. I find the level of hijinks they go through for firewall traversal bizarre. I'm not among those who bristle at the mention of NATs, but I do agree that they represent a significant limitation on the application architecture at this point. >> There are many ways to cut this cookie: the addresses a system >> uses can, when treated as an equivalence class, be called a >> locator or endpoint identifier .. functionally, we have to have >> some solution to the problem that the EID, however we understand >> it, solves. > > This is kind of what I was alluding to yesterday, when I questioned > whether endpoints were really the thing we needed to add a > namespace for, or whether it should be some sort of higher-level > entity (e.g. a "service", which is actually implemented as a bunch > of actual machines in a farm, which are separate fate-sharing > entities) - and then went on to muse that perhaps we needed both. > > We clearly need names for interfaces, because those are the places > that the system of routers delivers packets to. We clearly need > names for services, because that's what people (and applications > working on their behalf) really care about. > > The thing is, do we need another namespace in the middle, to name > one end of > a reliable transport connection? Hmm. Is that anything like a TCEPID? My point in mentioning the NSAP yesterday and the TCEPID (its counterpart on the other side of the Transport/Network interface) is not to suggest that ISO generated the answers here. It is to observe in passing that while their protocols were not necessarily wonderful and many are OBE, there is some applicable thought there. This is familiar territory. >> the big problem that we have tripped over in this area is that we >> have not kept names at the application layer and network layer >> addresses at the network layer. They are in fact in the right >> places, but we manage to distribute addressing information to a >> part of the system it is irrelevant to, and in so doing shoot >> ourselves in the foot. > > 'Exactement'. And by now the problem is so widespread we may never > fix it. So, once again, jack-up looks good. Actually, I wonder how much of it could be solved by an appropriate redesign of the socket API so that the application only sees names. I'll bet that once we do that, it is a matter of time before the addresses move out most of the applications. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 17:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gif4I-0005mh-QK; Fri, 10 Nov 2006 17:41:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gif4I-0005mc-1D for architecture-discuss@ietf.org; Fri, 10 Nov 2006 17:41:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gif4F-0003go-Bo for architecture-discuss@ietf.org; Fri, 10 Nov 2006 17:41:50 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 14:41:45 -0800 X-IronPort-AV: i="4.09,411,1157353200"; d="scan'208"; a="845033:sNHT3927477285" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAAMfixn015719 for ; Fri, 10 Nov 2006 14:41:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAAMfaj0006330 for ; Fri, 10 Nov 2006 14:41:44 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 14:41:44 -0800 Received: from [10.0.4.3] ([10.21.121.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 14:41:44 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <20061110164932.6489B86AE7@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: An example of how the requirements and right questions interrelate Date: Fri, 10 Nov 2006 14:41:42 -0800 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 22:41:44.0542 (UTC) FILETIME=[65E8B7E0:01C70519] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2129; t=1163198504; x=1164062504; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20Re=3A=20An=20example=20of=20how=20the=20re quirements=20and=20right=20questions=20interrelate |Sender:=20; bh=FkPFBNXncVooTyWmQ/5GIB8lIRbqASd8h/c8NW2MgIk=; b=yQcj+fQAYHOT01mhIlzXrMTSCETMfSV8+D3LRLwr5J9nbHSbXjPjszSr9Gg82KOW033diekr xV7X60GlCjWB0sf0zMrYbOZwOmFlqZep1lryZHDXDaOJ8YBRpJEa1hU8; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 10, 2006, at 2:30 PM, Fred Baker wrote: >>> the big problem that we have tripped over in this area is that we >>> have not kept names at the application layer and network layer >>> addresses at the network layer. They are in fact in the right >>> places, but we manage to distribute addressing information to a >>> part of the system it is irrelevant to, and in so doing shoot >>> ourselves in the foot. >> >> 'Exactement'. And by now the problem is so widespread we may never >> fix it. So, once again, jack-up looks good. > > Actually, I wonder how much of it could be solved by an appropriate > redesign of the socket API so that the application only sees names. > I'll bet that once we do that, it is a matter of time before the > addresses move out most of the applications. let me put hands and feet on that. one problem that I have with the socket API is, as I said, that it more-or-less requires the application to know something about the address. I recognize that there are legitimate applications that have this as a requirement - gated is an example. But in my small and not- very-wise mind, it seems like one could (a) create openSocketByName(char *) (b) do something to the existing open-socket-by-address call to make it continue to work but become truly undesirable. Maybe every time it is called it prints out a message that says "oh my goodness, no truly cool user uses code that is still using this API; it's just so October 2006" or some such thing. Basically, allow people to continue shipping systems and applications but put some form of "you really want to switch to the new API" in there. While fixing this, I would really like a user up-call to be built into the SYN/SYN-ACK cycle. It would be very nice if the application knew it had an incoming connection and could either accept or reject it, rather than having it completely opened before the application knows. Note that the above has nothing to do with the id/locator split in the address per se. It's about making renumbering less painful. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:06:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifPi-0002Rt-A9; Fri, 10 Nov 2006 18:03:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifPh-0002RQ-2S for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:03:57 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GifPf-0007LJ-MR for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:03:57 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAAN0trG019766; Fri, 10 Nov 2006 15:00:55 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Fri, 10 Nov 2006 15:03:32 -0800 X-PGP-Universal: processed; by terminus.local on Fri, 10 Nov 2006 15:03:32 -0800 In-Reply-To: <20061110203118.955C286AFC@mercury.lcs.mit.edu> References: <20061110203118.955C286AFC@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <77F477B7-4491-436B-BB86-F2F91C1D53F9@virtualized.org> From: David Conrad Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 15:03:31 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, > If we go the jack-up route (to avoid having to modify hosts), then > we have a > big, painful job ahead of us, which is to build, deploy, and > populate that > mapping database - the one that maps from old-style "addresses" (aka > identifiers, now) to new-style locators. I hesitate to mention this because if you were depressed before, this might cause you to slit your wrists, but... (:-)) If the destination DNS has: # Label Cl RRtype Pref Rdata 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.id.arpa IN LOCATOR 100 A000::0001 LOCATOR 200 B000::0001 and the source (edge or last hop) router does: locators = dnslookup(destination_identifier) if locators exist then destination_locator = pick_one(locators) encapsulate_and_forward(destination_locator,input_packet) else try_and_forward(input_packet) endif No new technology needed, just a small matter of programming. The mapping is done at the edges, distributing both the map database and the lookup load. Caching is built in (although you probably want to modify the cache to do a refetch for active flows before the TTL expires so you don't have to take the latency hit in the middle of the flow). You get incremental deployment (assuming non-mapped prefixes are routable). And assuming DNSSEC, the mapping is secured. Like I said, I don't want this to cause you to slit your wrists... Yes, there are disadvantages to this approach (the first packet latency hit, DDoS vulnerability, for example) and there are other approaches (some sort of push method, e.g., a BGP attribute), but this may be quicker/easier to deploy... Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifRh-0006Jt-S7; Fri, 10 Nov 2006 18:06:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifRg-0006Ib-E6 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:06:00 -0500 Received: from ober.cs.columbia.edu ([128.59.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GifRf-0007i0-58 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:06:00 -0500 Received: from lion.cs.columbia.edu (IDENT:5GZDXacx6YY4aoMKpmNrbplh4PnuLrEu@lion.cs.columbia.edu [128.59.16.120]) by ober.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id kAAN3b6S004861 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 10 Nov 2006 18:05:50 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id kAAMraaB032001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Nov 2006 17:53:37 -0500 Message-ID: <455502E2.50107@cs.columbia.edu> Date: Fri, 10 Nov 2006 17:53:22 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] Re: An example of how the requirements and right questions interrelate References: <20061110164932.6489B86AE7@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Java.net already supports connecting to a host name http://java.sun.com/j2se/1.4.2/docs/api/java/net/SocketImpl.html#connect(java.lang.String,%20int) (as a random example). The practical problem is that life is more complicated now that we have more than DNS A records. Such an API would have to deal with rather application-specific modalities included in various retry algorithms, NAPTR, SRV and the like. With security protocol negotiation, this can get fairly messy; just take a look at RFC 3263 for the general flavor of what "connect to host A" has become. Unfortunately, the semantics of this differ from application to application, partially for historical reasons, partially because of genuinely different needs. I also don't think that the socket API is the main problem. Generally, the address returned by the socket API is just passed as a blob or handle from one place (resolution) to another (socket), without the program inspecting it. Henning > > one problem that I have with the socket API is, as I said, that it > more-or-less requires the application to know something about the > address. I recognize that there are legitimate applications that have > this as a requirement - gated is an example. But in my small and > not-very-wise mind, it seems like one could > > (a) create openSocketByName(char *) > (b) do something to the existing open-socket-by-address call to make > it continue to work but become truly undesirable. > > Maybe every time it is called it prints out a message that says "oh my > goodness, no truly cool user uses code that is still using this API; > it's just so October 2006" or some such thing. Basically, allow people > to continue shipping systems and applications but put some form of "you > really want to switch to the new API" in there. > > While fixing this, I would really like a user up-call to be built into > the SYN/SYN-ACK cycle. It would be very nice if the application knew it > had an incoming connection and could either accept or reject it, rather > than having it completely opened before the application knows. > > Note that the above has nothing to do with the id/locator split in the > address per se. It's about making renumbering less painful. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:13:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifYw-0002mI-7p; Fri, 10 Nov 2006 18:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifYu-0002mC-SV for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:13:28 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GifYt-0001Ge-F9 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:13:28 -0500 Received: (qmail 18814 invoked from network); 10 Nov 2006 23:13:18 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 10 Nov 2006 23:13:18 -0000 Received: from LIPC ([192.168.1.73]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:13:18 -0800 From: "Tony Li" To: "'Brian E Carpenter'" , Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 15:13:12 -0800 Message-ID: <019c01c7051d$cb821980$4901a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccFHKNIZNg3gc20Ql6Vj1fxmReRlQAAPyKQ In-Reply-To: <4554D5FE.2050603@zurich.ibm.com> X-OriginalArrivalTime: 10 Nov 2006 23:13:18.0631 (UTC) FILETIME=[CEDFC370:01C7051D] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Noel Chiappa' , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > NAT > > Even if you have an antiNAT at the other end, address ambiguity > destroys the e2e identification property and third party referrals. Third party referrals are just security problems and should be wholly eliminated as intrinsically untrustworthy. Point made about e2e identification. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifxQ-0001Zi-VW; Fri, 10 Nov 2006 18:38:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GifxP-0001W6-S0 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:38:47 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gifwt-0005oo-5a for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:38:16 -0500 Received: (qmail 21654 invoked from network); 10 Nov 2006 23:38:12 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 10 Nov 2006 23:38:12 -0000 Received: from LIPC ([192.168.1.73]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:38:12 -0800 From: "Tony Li" To: "'Fleischman, Eric'" , , "'Brian E Carpenter'" , "'Noel Chiappa'" Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 15:38:06 -0800 Message-ID: <019d01c70521$45c00420$4901a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccE+93tjCWbYJVZQs6NjvjFQOX73QAAPT8QAADvxaAAAPRQcAACDTuQAATEUkA= In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B6A@XCH-NW-6V1.nw.nos.boeing.com> X-OriginalArrivalTime: 10 Nov 2006 23:38:12.0328 (UTC) FILETIME=[492FD680:01C70521] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Eric, > Changing topics, I was surprised by this email thread because it is > apparent that my memory of IPng (IPv6) differs significantly from the > views I've seen thus far. Specifically, I believe that the IETF > consensus position today supports Noel's distinction between end point > IDs and topology locators -- we just don't agree on how to > achieve it. I agree that that seems to be the growing consensus today. However, I also believe that this consensus is relatively recent. Not long ago, a loc/id split was anathema. > I > also believe that this distinction was also part of our original IPng > consensus position and it is part of what I was thinking when I > originally suggested the proto-IPv6 autoconfiguration approach: the > first 10 bytes (in my original version) is the locator and the last 6 > bytes are the identifiers. 8x8 is fine -- I'm not really talking about > where the division is made just that it occurs and that the locators > locate the routing topology to subnetworks. Sorry, I don't believe that we ever got to a consensus where the locator was truly independent of the identifier. In particular, I'll claim that if the locator is part of the TCP pseudo-header, then it's definitely not sufficiently independent. We never got that far. > Regardless, from where we stand today, how would you technically solve > EGP routing and end-point ID addressing if you were the king of the > world? If I were king, I'd tend to worry about bigger things. ;-) My favorite approach is to morph GSE, but the most signficant bits are a) separation of loc and id, resulting in b) much better multi-level locator abstraction, c) multi-homing without global prefixes, d) easier renumbering, e) better mobility, and f) a reasonably clean architecture. Not necessarily in that order. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:40:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gifxc-0001sY-CI; Fri, 10 Nov 2006 18:39:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gifxa-0001nH-GC for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:38:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GifsF-0004z7-Ib for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:33:28 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2006 15:33:27 -0800 X-IronPort-AV: i="4.09,412,1157353200"; d="scan'208"; a="342816427:sNHT54183344" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAANXRRK004215; Fri, 10 Nov 2006 15:33:27 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAANXQW4027198; Fri, 10 Nov 2006 15:33:26 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:33:26 -0800 Received: from [10.0.4.3] ([10.21.121.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:33:26 -0800 In-Reply-To: <455502E2.50107@cs.columbia.edu> References: <20061110164932.6489B86AE7@mercury.lcs.mit.edu> <455502E2.50107@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <613B943D-455E-41D7-8422-60DD8E6DE1DC@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: An example of how the requirements and right questions interrelate Date: Fri, 10 Nov 2006 15:33:23 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 23:33:26.0238 (UTC) FILETIME=[9EA9F7E0:01C70520] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=633; t=1163201607; x=1164065607; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20Re=3A=20An=20example=20of=20how=20the=20re quirements=20and=20right=09questions=20interrelate |Sender:=20; bh=l1efQkFssXBm3I9kLXnb4LRd0rAUR92c3yu3+unDzIo=; b=Lo1woBjeO+ZDfkB+8fiX/YFzP/5oZOfchrR7E2ZjYTsMrkirLlbJMhJGiZACRV5PYjJRubKT 9+UniFEsK1XUric4lOk+9qcBNe+OjdyiD7LmcBi1+yl5r6jupVRN1eof; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 10, 2006, at 2:53 PM, Henning Schulzrinne wrote: > I also don't think that the socket API is the main problem. > Generally, the address returned by the socket API is just passed as > a blob or handle from one place (resolution) to another (socket), > without the program inspecting it. Maybe. There seem to be an awful lot of applications that have to be restarted to gte them to change the address. I would think that if the application was executing while (TRUE){ socket = openSocket(getHostByName(name)); while (socket is still up) { do whatever } } then that wouldn't happen. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:42:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig0d-0004ci-Tz; Fri, 10 Nov 2006 18:42:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig0c-0004cX-Je for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:42:06 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gig0b-0007Nr-71 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:42:06 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 15:42:00 -0800 X-IronPort-AV: i="4.09,412,1157353200"; d="scan'208"; a="891558:sNHT10152253584" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAANfxSh031161 for ; Fri, 10 Nov 2006 15:41:59 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAANfxW4002068 for ; Fri, 10 Nov 2006 15:41:59 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:41:59 -0800 Received: from [10.0.4.3] ([10.21.121.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:41:59 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <4554D5FE.2050603@zurich.ibm.com> References: <011d01c704fc$dece4c00$4901a8c0@tropos.com> <4554D5FE.2050603@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <336060FA-C04A-440D-AC56-A0DB8A17FDF6@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 15:41:57 -0800 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 23:41:59.0417 (UTC) FILETIME=[D08ADE90:01C70521] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=979; t=1163202119; x=1164066119; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Ok, =20so=20what=20should=20we=20do=20then?=20(Was=3A= 20Re=3A=20[arch-d]=20[Off-topic]Further=20thoughts=3A=20about=20systems=20 theory=20and=20the=20theory=20U) |Sender:=20; bh=GMu0A6Kz5g10znpbps4yV8k0AMtCAGisAAQ3dCco51Y=; b=AZbce40TlFIAcVXV4rIZ5FWLOWN/lHuy96ys/gkUqYRDwvMmjxkz9IKRjMUrFunE5etGixUp xJy7OQmof3kLAWst+2x10t4q9jgxMMxs/QKMhP305WFMfnvcOa+Kzx8L; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 10, 2006, at 11:41 AM, Brian E Carpenter wrote: > Even if you have an antiNAT at the other end noting that I am neither ultimately anti-nat or pro-nat... I just see some problems that nats solve and others that it creates or doesn't fix, and I see other ways of fixing the problems that don't have those issues (but in a 32 bit address space have other problems). Please, could we manage to not be arguing about NATs? We are using NATs now, probably as effectively as we collectively know how, and a five year old with a ruler and the RIR address allocation data can draw valid conclusions that lead us to believe that we have a limited timeframe to do something different. We need a problem statement, preferably a set of requirements, one or more proposed solutions, and for each solution an honest analysis that leads to to believe whether it actually fixes the issues set forth in the problem statement. Let's target that. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:42:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig0e-0004d9-4i; Fri, 10 Nov 2006 18:42:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig0c-0004cd-Ok for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:42:06 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gig0b-0007Nx-A3 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:42:06 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0550786AE4; Fri, 10 Nov 2006 18:42:04 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Message-Id: <20061110234204.0550786AE4@mercury.lcs.mit.edu> Date: Fri, 10 Nov 2006 18:42:04 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Conrad >> If we go the jack-up route (to avoid having to modify hosts), then we >> have a big, painful job ahead of us, which is to build, deploy, and >> populate that mapping database - the one that maps from old-style >> "addresses" (aka identifiers, now) to new-style locators. > If the destination DNS has: > No new technology needed, just a small matter of programming. If I understand what you are proposing (it's been so long since I looked at the DNS that the bits have all been swapped out to a tape drive in my brain that has gone offline :-), you're basically proposing to use the DNS as the mapping database. That way we don't have to design, build or deploy it, it's already there. That's perfectly feasible, but of course we still have to enter all the data. I'm not sure why I assumed we'd build something new. I do know that every time in the past when I tried suggesting we'd use the DNS for anything related to this kind of stuff, Keith Moore would go totally non-linear, saying that for a variety of reasons (I'll let Keith explain, if you want details) that was a Really, REALLY, Bad Idea. Basically, IIRC, it boiled down to the DNS being too flaky and overloaded (in the conceptual sense, not number of packets sense) already. It's certainly true that the mapping database becomes something that has to be running before packets can flow (sorry, I don't believe in the "else try_and_forward(input_packet)" clause, except for local traffic), so it's really critical. I'd also want to make sure we aren't getting in any dependency loop issues (e.g. on cold-boot after the next big regional power failure, A needs B to be up before it can restart, and B needs A to be up). If so, a separate database might make it easier to solve any such issues. Anyway, I wonder if you're not falling into "this problem is easy if I give the hard part to someone else" syndrome. (The classic example of this is that lots of people think multi-homing via PI is easy, because it gives the problem to the routing. NOT!) I wonder if the DNS people won't go non-linear when you spring this on them, saying the DNS has enough problems already, without adding this functionality too, etc, etc, etc. You might wind up having to do a database... > The mapping is done at the edges, distributing both the map database > and the lookup load. Oh, I always assumed that. That why I said "make it a distributed database". Oh, I should have said "replicated," - typing too fast! One big central database, or even a small number of them, is clearly a bad idea for about 9 different reasons. > there are disadvantages to this approach (the first packet latency hit Well, that's true of any jack-up scheme that relies on querying a database, instead of having a complete mapping database already on hand. > there are other approaches (some sort of push method, e.g., a BGP > attribute) Hmm, intesting idea. You get the range(s) of identifiers that map to a particular locator (which might be a high-level aggregate) when you get information about the path to the aggregate. The nice thing about using a database, though, is that it gives you an place to go and update the mapping, though. (Yes, yes, I know, routing tables are just a large distributed replicated database too... :-) For instance, one issue with predistributed tables that is that it makes it harder to do certain kinds of mobility (e.g. slow motion) where it's feasible to do it by changing the mapping in the database for just that one node. No way you'd want to inject that info into the routing. That one may not be that important, but here's one that is: avoiding the query/response cycle also makes doing fault bypassing with multi-homing harder. E.g. assume your link to your primary ISP goes down, you just switch to a different set of locators (or disable the ones in the database that refer to the failed link), and you don't have to flood the entire network with a down status on that link (so that people can recompute paths). How to handle people who are already communicating with you, when a link goes out, is harder; I have a long list of ideas, but this is too long already. But doing a push instead of / as well as a pull is definitely something to consider. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:46:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig4I-00007W-K1; Fri, 10 Nov 2006 18:45:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig4G-0008QB-Nv for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:45:52 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gig4F-0007y8-Co for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:45:52 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 862FB4AC9C; Fri, 10 Nov 2006 18:45:37 -0500 (EST) Date: Fri, 10 Nov 2006 18:45:37 -0500 From: John Leslie To: David Conrad Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Message-ID: <20061110234537.GK73049@verdi> References: <20061110203118.955C286AFC@mercury.lcs.mit.edu> <77F477B7-4491-436B-BB86-F2F91C1D53F9@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77F477B7-4491-436B-BB86-F2F91C1D53F9@virtualized.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Conrad wrote: > To: Noel Chiappa > >> If we go the jack-up route (to avoid having to modify hosts), then >> we have a big, painful job ahead of us, which is to build, deploy, >> and populate that mapping database - the one that maps from old-style >> "addresses" (aka identifiers, now) to new-style locators. Whadaya mean "we", kemosabe? > I hesitate to mention this because if you were depressed before, this > might cause you to slit your wrists, but... (:-)) Please! No blood on the carpet! ;^) > If the destination DNS has: > > # Label Cl RRtype Pref Rdata > 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.id.arpa IN LOCATOR 100 A000::0001 > LOCATOR 200 B000::0001 > > and the source (edge or last hop) router does: > > locators = dnslookup(destination_identifier) > if locators exist then > destination_locator = pick_one(locators) > encapsulate_and_forward(destination_locator,input_packet) > else > try_and_forward(input_packet) > endif Ignoring details for the moment, the idea looks really promising. It even passes my "mobility test". (I believe that any "right" architecture will yield a workable "solution" for mobile computers.) > No new technology needed, just a small matter of programming. The > mapping is done at the edges, distributing both the map database and > the lookup load. Caching is built in (although you probably want to > modify the cache to do a refetch for active flows before the TTL > expires so you don't have to take the latency hit in the middle of > the flow). Essential for mobility. It even gives a free hint as to how long the mapping is expected to last. > You get incremental deployment (assuming non-mapped prefixes are > routable). Yes!!!! And that assumption, initially, is perfectly reasonable! Although both input and output have the form of IPv6 addresses, we know which is which. And in the "default" (current) state, the input is _likely_ to serve as a workable output. > And assuming DNSSEC, the mapping is secured. Well, everyone's entitled to a _little_ wishful thinking... ;^) > Yes, there are disadvantages to this approach (the first packet > latency hit, DDoS vulnerability, for example) Engineering details! (I'm sure workarounds can be found.) > and there are other approaches (some sort of push method, e.g., > a BGP attribute), but this may be quicker/easier to deploy... I see no reason to limit this to one approach. However, we need to discuss "architecture". How, even whether, DNS supplies the mapping isn't the "architecture" -- rather we need to agree what we're calling the _input_ and _output_ of this mapping process. May I start the bidding with: - "endpoint name" for the input; and - "network attachment locator" for the output? -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 18:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig4n-0000lN-1S; Fri, 10 Nov 2006 18:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gig4l-0000lI-UU for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:46:23 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gig4l-000859-8V for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:46:23 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kAANiKjs055999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 11 Nov 2006 00:44:21 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9ED2417F-E3AC-4714-BD5C-48E886279450@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Iljitsch van Beijnum Date: Sat, 11 Nov 2006 00:45:50 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Subject: [arch-d] Think globally, act locally X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org In trying to address the scalability problem identified in the IAB RA workshop, we're faced with two challenges: come up with a sound architecture, and design and implement something that addresses the issue at hand, without unduly getting in the way of the continued operation of the network. A clean architecture that can't be implemented is just as useless as applying hack on hack until we've completely painted ourself into an architectural corner. Taking a step back, it's a bit strange that there was such strong rough consensus that the id/loc overloading is a problem, as arguably, this overloading isn't all that pronounced. Rather than think of the IP address as both the identifier and the locator, it's possible to think of the FQDN as the identifier and the IP address as the locator. Or of the IP address as the identifier and the link address as the locator. In that light, a new effort to separate location and identity isn't something completely new, but rather, revisiting and (hopefully) improving something that's already present in our current architecture. In my opinion, architectural sanitation dictates that we at least pay lip service to the notion that the current socket API is a terrible layer violation, and the proper way to set up sessions and associations is by having the application provide the FQDN of the correspondent, so that the application is isolated from the structure of the addresses used. I.e., for all socket API operations that work with addresses, we define alternatives that work with DNS names. Taking care in the process that it becomes actually possible to have a single code base work over both IPv4 and IPv6 (and IPv8 and so on), something that's almost impossible today. After having done that, we have to face facts and realize that huge numbers of applications work with IP addresses, and only the tiniest networks don't have IP addresses hardcoded all over the place. It would be nice if we could just tell people "don't do that" and then have them renumber, but first of all, it doesn't work that way in practice (see the various BGP table size reports), and even if it did, we'd still have the issue of multihoming, which inflates the routing tables regardless of how easy or hard it is to renumber. It would help, though, if we could give current operators better traffic engineering tools. In my opinion, this isn't a particularly hard problem, so the IETF should just go ahead and charter a working group to develop TE mechanisms that can be bolted on to existing BGP4 with relative ease. If this saves us a few percent in yearly routing table growth, that adds up to significant extra time to work on the "real" solution and/or savings on hardware upgrades when amortized over a number of years. Next, another issue that in and of itself isn't going to save the day, but is something we've overlooked for too many years: the average packet size. Although some other aspects will obviously be much the same, a router that forwards 10 Gbps worth of 700 bytes avg packets only has to do half the FIB lookups as a router forwarding 10 Gbps worth of 350 bytes avg packets. Obviously there will always be small packets (acks, VoIP, DNS lookups), but a very large part of all internet traffic is transfer of data that is at least several kilobytes in size, so the transfer is split into several packets of a maximum size that is 1500 bytes in the vast majority of cases. This value comes from the original Ethernet II 1500 byte payload size. (Yes, that's from before the IEEE even came involved with Ethernet.) Even though today, modestly priced computers have increased in all other dimensions except size and cost by at least a factor of 100 (including communication speed which is now often 1000 Mbps) Ethernet packets are still just 1500 bytes. This is a fine size at 10 Mbps, somewhat defensible at 100 Mbps, but completely ridiculous at 1000 Mbps. This is not entirely trivial to fix, but until now nobody has even bothered to try. Again, charter a working group, or have an existing working group look at this. But back to the id/loc thing, as this is the part that will have to do the heavy lifting. The central issue here is that whatever it looks like, it must be highly parallelizeable. The problem with the current routing system is that it basically requires a full view of the network to be present in a single router, and as the network and therefore its full view increases in size, so has the router, with all the adverse effects described by Tony and others. In the new system, it's essential that when the network gets four times as big (measured in routing information), it is then possible to continue running the network with four devices doing the work previously done by one device, where each of the new devices doesn't have to do any more work than the one original device in the old situation. Now this suggests that the place where the change from stable identifiers to ephemeral locators happens should be as far out in the edge as possible: at least on site exit routers, but maybe even on individual hosts. However, there are two issues with this: 1. The people running sites or hosts don't feel the pain from large routing tables, so they have little or no incentive to spend time and money on a solution like this 2. It is not realistic to push out the complete state of the id->loc mappings of the entire network to all sites, or even all multihomed sites. This means that the id->loc mapping information must be requested on-demand (like the DNS) rather than pushed out throughout the network (like BGP). This is a problem for several reasons: it takes extra time to request the information, introducing user-visible delays, and there is an inherent circularity: in order to ask someone for her mapping information, you must first be able to talk to her. This can be solved by publishing static mapping information augmented by discovering dynamic reachability information (as with the shim6 REAP protocol), but this only serves to furthr increase delays on initial communication. The alternative is doing the mapping inside service provider networks. In my opinion, this has many advantages: 1. The users don't see the locators, so they can't do things that get in the way of renumberability 2. The costs are aligned with the benefits: the service providers pay for the extra processing, but also reap the benefits in the form of smaller routing tables in core routers 3. In service provider networks, there link layer capabilities are generally much more advanced than what's common in end-user networks. Such capabilities, such as Ethernet VLANs, MPLS, light paths, or even IP paths with higher MTUs, can be leveraged to tunnel packets through the core. 4. Having the solution be local to a single AS allows for easy deployment So the solution that I envision is something like the following: For each IPv4 and IPv6 prefix, one of the following must be true: 1. The prefix is present in routing tables throughout the internet so that the packet can be forwarded through existing mechanisms, or 2. The prefix is not present in regular routing tables, but it is present in a to-define new protocol that distributes id->loc mapping data. The prefix functions as a set of identifiers, different types of locators may be available: link-based locators (such as MPLS tunnels) or IP tunneling/address rewriting. In the case of 2., the packets are forwarded to a local mapping device that is capable of encapsulating packets and transmitting them to an equivalent device either at the edge of the local AS where the packets can be handed over to the destination AS, or the encapsulation is kept intact between ASes and the decapsulation happens in the destination AS. This requires a new protocol to flood mapping information, which must be dynamic enough to facilitate multihoming. But because reachability of intermediate links or ASes isn't an issue, the protocol can be much simpler than existing BGP. In essence, it functions much like iBGP. Because we get to design this new protocol from scratch, we can make sure it's possible to have the desired parallel operation where required. By selectively moving prefixes from the regular routing table to the encapsulation devices and back, it's possible to optimize operation of the new machinery without requiring renumbering or other invasive changes. When the above is operational, it would be possible to optimize by having site exit routers participate in the encapsulation. Most sites will probably not be interested in having the mapping state for the entire internet, but they can receive feeds with limited mapping data views. At this stage, it becomes possible for two sites to detect their mutual mapping capability and directly negotiate optimizations on-demand. One optimization could be route optimization towards mobile nodes. Ultimately, individual hosts may want to participate in this process, much like MIPv6, SHIM6 or HIP operation, but aided by the flooded mapping information that's available in the site. An interesting side effect of the encapsulation is that it becomes quite easy to expose the location where a packet originated (i.e., the outer source address when doing IP-in-IP tunneling) and if the new mapping flooding protocol is designed to be secure, it may very well become unnecessary to implement heavy security mechanisms in BGP, as BGP will subsequently only be used for PA space from ISPs, and the number of PA blocks is small enough to make more traditional security mechanisms feasible. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 19:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GigLw-0003ts-Is; Fri, 10 Nov 2006 19:04:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GigLu-0003q3-SQ for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:04:06 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GigDm-00014R-R7 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:55:43 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kAANrt1O056160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Nov 2006 00:53:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <336060FA-C04A-440D-AC56-A0DB8A17FDF6@cisco.com> References: <011d01c704fc$dece4c00$4901a8c0@tropos.com> <4554D5FE.2050603@zurich.ibm.com> <336060FA-C04A-440D-AC56-A0DB8A17FDF6@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7934B0EC-ACBC-4318-887F-F0B0CDABB9FF@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 00:55:37 +0100 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 11-nov-2006, at 0:41, Fred Baker wrote: >> Even if you have an antiNAT at the other end > noting that I am neither ultimately anti-nat or pro-nat... What he meant was that even if at the other end, the NAT rewriting is reversed so that the original addresses are restored, certain problems remain. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 19:05:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GigM7-0003yd-TP; Fri, 10 Nov 2006 19:04:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GigM5-0003x0-5l for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:04:17 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GigBA-0000kA-EI for architecture-discuss@ietf.org; Fri, 10 Nov 2006 18:53:00 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kAANpEF5056135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Nov 2006 00:51:15 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <019c01c7051d$cb821980$4901a8c0@tropos.com> References: <019c01c7051d$cb821980$4901a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 00:52:57 +0100 To: tony.li@tony.li X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 11-nov-2006, at 0:13, Tony Li wrote: > Third party referrals are just security problems and should be wholly > eliminated as intrinsically untrustworthy. You may want to be careful going down this road; before long you'll have eliminated the entire internet... _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 19:34:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GignA-000389-V4; Fri, 10 Nov 2006 19:32:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gign8-00036V-TX for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:32:14 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gign6-0006p3-ES for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:32:14 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kAB0WB5K170168 for ; Sat, 11 Nov 2006 00:32:11 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAB0Ytwm2412730 for ; Sat, 11 Nov 2006 00:34:55 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAB0WBCs012266 for ; Sat, 11 Nov 2006 00:32:11 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAB0WApA012255; Sat, 11 Nov 2006 00:32:10 GMT Received: from zurich.ibm.com ([9.4.210.165]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id BAA35560; Sat, 11 Nov 2006 01:32:08 +0100 Message-ID: <45551A06.6060108@zurich.ibm.com> Date: Sat, 11 Nov 2006 01:32:06 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) References: <011d01c704fc$dece4c00$4901a8c0@tropos.com> <4554D5FE.2050603@zurich.ibm.com> <336060FA-C04A-440D-AC56-A0DB8A17FDF6@cisco.com> <7934B0EC-ACBC-4318-887F-F0B0CDABB9FF@muada.com> In-Reply-To: <7934B0EC-ACBC-4318-887F-F0B0CDABB9FF@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Iljitsch van Beijnum wrote: > On 11-nov-2006, at 0:41, Fred Baker wrote: > >>> Even if you have an antiNAT at the other end > > >> noting that I am neither ultimately anti-nat or pro-nat... > > > What he meant was that even if at the other end, the NAT rewriting is > reversed so that the original addresses are restored, certain problems > remain. Exactly... _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 19:41:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigvc-0001nb-4X; Fri, 10 Nov 2006 19:41:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gigvb-0001m7-8o for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:40:59 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GigvZ-0007PH-Tt for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:40:59 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 46DED4AC6E; Fri, 10 Nov 2006 19:40:58 -0500 (EST) Date: Fri, 10 Nov 2006 19:40:58 -0500 From: John Leslie To: Noel Chiappa Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Message-ID: <20061111004058.GM73049@verdi> References: <20061110234204.0550786AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061110234204.0550786AE4@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Much though I dislike delving into details too early... Noel Chiappa wrote: > >> If the destination DNS has: >> No new technology needed, just a small matter of programming. > > ... you're basically proposing to use the DNS as the mapping database. > That way we don't have to design, build or deploy it, it's already > there. We shouldn't think of it as the "only" database, though it might be the "authoritative" database. > That's perfectly feasible, but of course we still have to enter all > the data. Someone has to enter the data (except where a default will work), but I don't think it's "we". > ... Keith Moore would go totally non-linear... Perhaps that needs to happen, but not (IMHO) now. That's an engineering issue -- the data could be maintained in DNS but queried through an entirely different mechanism. > ... sorry, I don't believe in the "else try_and_forward(input_packet)" > clause, except for local traffic)... You don't have to believe it would always work. But we do have to believe it would _sometimes_ work; and it would be _really_nice_ if we could believe it would work for a large majority of current use. (Do you have evidence it wouldn't?) > I'd also want to make sure we aren't getting in any dependency loop > issues (e.g. on cold-boot after the next big regional power failure, > A needs B to be up before it can restart, and B needs A to be up). A very good question! > If so, a separate database might make it easier to solve any such > issues. Reasonable... I'm guessing that a number of endpoints would need to retain input==output mapping "forever". There's certainly no reason we couldn't have local copies of a small database (like /etc/hosts). > Anyway, I wonder if you're not falling into "this problem is easy > if I give the hard part to someone else" syndrome. Often that is the _only_ way to "solve" a problem... > (The classic example of this is that lots of people think > multi-homing via PI is easy, because it gives the problem to the > routing. NOT!) Agreed -- multi-homing via PI, at best, "tends to" break routing. Folks worth considering _don't_ think that makes it "easy" -- it's just the only plausible option they see. > I wonder if the DNS people won't go non-linear when you spring this > on them... Then let's not "spring it on them" yet. We need to work up an architecture, not wander in the weeds of implementing that architecture. >> there are other approaches (some sort of push method, e.g., a BGP >> attribute) > > Hmm, intesting idea. You get the range(s) of identifiers that map to a > particular locator (which might be a high-level aggregate) when you get > information about the path to the aggregate. Reasonable -- but it strikes me as an optimization, thus engineering. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 19:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gih5R-0000qr-Nf; Fri, 10 Nov 2006 19:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gih5Q-0000nA-4m for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:51:08 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gih5M-00089H-T7 for architecture-discuss@ietf.org; Fri, 10 Nov 2006 19:51:08 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kAB0ovSe011113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Nov 2006 18:50:57 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kAB0ouXu007516; Fri, 10 Nov 2006 18:50:56 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kAB0otik007486; Fri, 10 Nov 2006 18:50:56 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 16:50:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 16:50:03 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584B70@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Thread-Index: AccFJSXtQItvGduOReOVDT8hrPPrSQAAum1A From: "Fleischman, Eric" To: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 11 Nov 2006 00:50:55.0815 (UTC) FILETIME=[72071D70:01C7052B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 >> Third party referrals are just security problems and should be wholly >> eliminated as intrinsically untrustworthy. >You may want to be careful going down this road; before long you'll =20 >have eliminated the entire internet... Trust models are a very important security issue. Unless an assured basis to trust third party referrals is provided then hostile attackers are provided a target-rich opportunities for damage. Your point, Iljitsch, is centrally important: do the existing third party referrals (e.g., mobile IP, SIP, large number of proxy implementations) provide an adequate trust model foundation? Specifically, do the IETF protocols do so?=20 My personal conclusion is that the IETF protocols do not adequately address this issue but rather punt this issue to us end users. Therefore, the actual vulnerability of these approaches in real life networks is a function of how we end users actually deploy them in our specific deployments. Therefore, beware of referrals that span administrative domains! _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 21:17:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiiPS-0008Pv-DZ; Fri, 10 Nov 2006 21:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiiPR-0008PV-Ho for architecture-discuss@ietf.org; Fri, 10 Nov 2006 21:15:53 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiiPO-000735-2l for architecture-discuss@ietf.org; Fri, 10 Nov 2006 21:15:53 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAB2CgrG020031; Fri, 10 Nov 2006 18:12:47 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Fri, 10 Nov 2006 18:15:24 -0800 X-PGP-Universal: processed; by terminus.local on Fri, 10 Nov 2006 18:15:24 -0800 In-Reply-To: <20061110234204.0550786AE4@mercury.lcs.mit.edu> References: <20061110234204.0550786AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4E903FF1-B086-4BED-B6A0-8B6FF334BDD1@virtualized.org> From: David Conrad Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Date: Fri, 10 Nov 2006 18:15:18 -0800 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, On Nov 10, 2006, at 3:42 PM, Noel Chiappa wrote: > It's certainly true that the mapping database becomes something > that has to > be running before packets can flow (sorry, I don't believe in the > "else > try_and_forward(input_packet)" clause, except for local traffic), > so it's > really critical. Assume you have a source edge (or first hop) device that implements what I described. On the "inside", the network is numbered in "identifier" space. On the outside, the network is numbered in "locator" space. If the lookup for the destination fails, the device can either drop the packet on the floor, or it can try to forward the packet. If it decides to forward the packet, there are a couple of options: 1) assume the destination identifier is actually a "legacy" IPv6 address and throw it to the mercies of the existing routing system without any encapsulation. 2) do another lookup, this time for something like "d.e.s.t.i.d.p.r.e.f.source-isp.net." (a name managed by the ISP) which would return the locator endpoint of a device that would be at the "other side" of the source ISP (that is, to a peering or transit point where the source ISP would hand the packet off to another ISP), thus creating an intra-AS tunnel. The transit ISP the packet is handed off to would have the same decision about dropping or forwarding to make. (yes, kludge upon kludge... don't think I'm proud of coming up with stuff like this) > I'd also want to make sure we aren't getting in any dependency loop > issues > (e.g. on cold-boot after the next big regional power failure, A > needs B to be > up before it can restart, and B needs A to be up). As long as the mapping database servers are numbered out of locator space, there would not be any dependency loops. > I wonder if the DNS people won't go non-linear when you spring this > on them, > saying the DNS has enough problems already, without adding this > functionality > too, etc, etc, etc. I'm not wedded to the DNS (despite the fact I've been involved (at a management level) in the development of 3 different DNS servers) -- it's just easy for people to understand. This might be an opportunity to come up with a better distributed lookup technology, one that addresses many of the warts that's found in the DNS, but I would worry about trying to do or change too much in too short a time. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 21:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiiS0-00033i-7y; Fri, 10 Nov 2006 21:18:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiiRz-00031o-9L for architecture-discuss@ietf.org; Fri, 10 Nov 2006 21:18:31 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiiRw-0007Pq-JH for architecture-discuss@ietf.org; Fri, 10 Nov 2006 21:18:31 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 51BCB86AE4; Fri, 10 Nov 2006 21:18:28 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Message-Id: <20061111021828.51BCB86AE4@mercury.lcs.mit.edu> Date: Fri, 10 Nov 2006 21:18:28 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Leslie >> of course we still have to enter all the data. > Someone has to enter the data (except where a default will work), but I > don't think it's "we". By "we" I meant "the Internet community as a whole". >> I don't believe in the "else try_and_forward(input_packet)" >> clause, except for local traffic)... > You don't have to believe it would always work. > But we do have to believe it would _sometimes_ work Well, if you can't depend on it working (at least, in cases where the first part of the "if" is not true), how much use is it, really? But moving on... > it would be _really_nice_ if we could believe it would work for a large > majority of current use. (Do you have evidence it wouldn't?) I started to think through this whole issue, and discovered a problem. To see it, let's think in a little more detail about how the routing in a "jack-up" system is going to work. You have two separate routing planes, a new one for new-type locators, and another old one for old-style addresses. I know some would like to collapse it into one, but let's keep it separate for now, for several reasons. First, I think it's better engineering/etc, long-term, to have a separate system - more flexibility, robustness, etc. Second, even if you do collapse them for engineering efficiency (something I'd oppose, for the first reason), it's easier to think about the problem if you have separate ones in your mental model. Let's start with a model of what's happening. You have a range of old-style addresses Oi-j, which is entered into the what I'll call the "destination mapping database" (because it turns out we need *another* mapping database, for *routes*), which turns them into new-type locators Nr-s. Note that Ok-l, Om-n, etc may *also* map to Nr-s - this becomes very important later. Iterate over many Oi-j, Ok-l, etc and Nr-s. You also have Oa-b, Oc-d, etc which are only served by "old-style" routers, and aren't yet in the mapping database. Furthermore, here's what I think is a needed assumption: looking at the graph of the network, if you look at the area of the Internet's connectivity graph which is the "default-free" zone, some contiguous subset of that is modified routers. I know some people would like to say it shouldn't have to be contiguous, but then things get *really* ugly, because then the distributed path computation algorithm has to run across a mix of areas of new-style and old-style routing-names, *and the names for entities which that computation uses are going to have to get translated every time they get passed over a new/old or old/new boundary*. This is really a problem, for several reasons. First, the "destination mapping table" is prepared to translate from Oi -> Nr, not Oi-j -> Nr-s. Second, the DMT is *not* prepared to do the reverse mapping *at all*! Furthermore, a single entry Nr-s may map into multiple entries Oi-j, Ok-l, etc. Very, very, ugly, and very, very likely to get screwed up. You do *not* want to be doing that. Having to translate from "a path to Oi-j" into "a path to Nr-s", as you go, say, from some non-transit AS into the new DFZ is going to be ugly enough, but it's kind of feasible, say with the appropriate table in the border routers. (Handwave here about if we use a push mechanism, this means we may not need the destination mapping database, this can be the source of the data, but let's move on.) Although, in the period where there's a large old-style DFZ, it's going to be plenty painful maintaining that large full mapping, in both directions, which you need at the boundary. (Only for Oi-j, etc, of course - Oa-b, etc have to be injected into the new plane at the boundary "as is".) In fact, given the difficulty of doing the reverse mapping Nr-s -> Oi-j, Ok-l, etc, I'd say that the contiguous subset of the DMZ which is new-style routers ought not be in the 'center' of the DFZ (i.e. you always have to go through some old-style DFZ routers to get to edge AS's). Rather, it should be along one "side" of the DFZ, with a single contiguous boundary between the old-style and the new-style parts of the DFZ, which is where the mapping of routing updates happens. I.e. most of its boundary is to leaf AS's. (Sorry if there should have been a picture here!) That way, you're usually only giving the leaf AS a default, and you don't need to explode Nr-s into its constituent Oi-j, etc for them. On the other end, I don't think it's feasible to assume the entire default-free zone switches to new-style routers instantly, because that's infeasible as a deployment plan. So between those two, I think my assumption above ("some contiguous subset of the DFZ is modified routers") is shown to be an OK assumption. (People in the DFZ running old-style routers are going to be gagging on large routing tables, so there - or ought to be, see below - an incentive to switch ASAP.) The way things *ought* to be able to work is that once you have the mapping up in the destination mapping table, and you have made arrangements for the route mapping, you *ought* to be able to withdraw Oi-j from the old plane (except 'near' the destination, i.e. in the AS which it's part of, of course), and only advertise Nr-s in the new-style. Wrongo, perhaps. Think about what happens when an old-style router in the "default-free" zone gets a packet with a destination address in Oi-j. It has to have a route to that destination, or it will toss the packet. So until there are no more old-style routers in the DFZ, we have to keep injecting routes to *all* destinations into the old-style part of the DFZ. Either that, or the DFZ has to contain a default route, which goes to the nearest new-style router... If we don't either i) kill all old-style routers in the DFZ, or ii) use the default, we're *still* going to have to deal with the maximum-size old routing table in all the old-style routers in the DFZ - which kind of defeats the whole purpose, I'd have thought. And here's where we get back to the original point that brought us here. It would also be nice if, once a new-stle router has no old-style router neighbours, only new-style router neighbours, it could toss the entire old routing table, i.e. stop participating in the old plane. The reason is the same as above: if we don't make that assumption, then *nobody* can stop participating in the old plane until the last old-style DFZ router is shut down - which again, kind of defeats the whole purpose. But if a new router is not participating in the old plane, then the "else try_and_forward(input_packet)" won't work, except for packets to local destinations. Hence my previous intuitive statement: >> I don't believe in the "else try_and_forward(input_packet)" >> clause, except for local traffic)... now seems to have some solid rationale. Am I understanding this all correctly, or am I missing something obvious? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 10 21:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiimL-0001Bb-QR; Fri, 10 Nov 2006 21:39:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiimK-00016M-9f for architecture-discuss@ietf.org; Fri, 10 Nov 2006 21:39:32 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GicyG-0007fJ-FP for architecture-discuss@ietf.org; Fri, 10 Nov 2006 15:27:28 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gickp-0006Z6-FF for architecture-discuss@ietf.org; Fri, 10 Nov 2006 15:13:36 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EE5AC872C0; Fri, 10 Nov 2006 15:13:30 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Message-Id: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> Date: Fri, 10 Nov 2006 15:13:30 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Brian E Carpenter > address ambiguity destroys the e2e identification property and third > party referrals That's not a bug, that's a feature. We want to discourage people from passing around bare endpoint identifiers. (Such an identifier might e.g. identify one particular server in a pool - not what you really wanted anyway.) Rather, they *should* be passing around higher-level identifiers. NewArch deliberately, for architectural reasons on a blank sheet, went down this same path, that endpoint identifiers (except the approximately equivalent things in NewArch are somewhat different) are not globally unique, and necessarily cannot be passed to third parties. So, if it doesn't work to pass around bare endpoint identifiers to third parties, so much the better. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 02:35:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GinMS-0007tx-FZ; Sat, 11 Nov 2006 02:33:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GinMR-0007tm-K5 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 02:33:07 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GinMQ-0001gJ-9V for architecture-discuss@ietf.org; Sat, 11 Nov 2006 02:33:07 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Nov 2006 08:33:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHEJVUWQ/uCLh2dsb2JhbACMTgkOKg X-IronPort-AV: i="4.09,413,1157320800"; d="scan'208"; a="119095982:sNHT24301116" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAB7X5Cq006315; Sat, 11 Nov 2006 08:33:05 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAB7X44Z010903; Sat, 11 Nov 2006 08:33:04 +0100 (MET) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 08:33:03 +0100 Received: from 10.61.81.74 ([10.61.81.74]) by xmb-ams-33b.emea.cisco.com ([144.254.231.86]) with Microsoft Exchange Server HTTP-DAV ; Sat, 11 Nov 2006 07:33:03 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sat, 11 Nov 2006 08:33:00 +0100 Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) From: Peter Tomsu To: "Fleischman, Eric" , Iljitsch van Beijnum , Message-ID: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Thread-Index: AccFJSXtQItvGduOReOVDT8hrPPrSQAAum1AAA7jYjo= In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B70@XCH-NW-6V1.nw.nos.boeing.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Nov 2006 07:33:03.0957 (UTC) FILETIME=[9F856850:01C70563] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=537; t=1163230385; x=1164094385; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ptomsu@cisco.com; z=From:=20Peter=20Tomsu=20 |Subject:=20Re=3A=20Ok, =20so=20what=20should=20we=20do=20then?=20(Was=3A= 20Re=3A=20[arch-d]=0A=20[Off-topic]Furtherthoughts=3A=20about=20systems=20 theory=20and=20the=20theory=20U) |Sender:=20; bh=ZFKWZ5I6z4NHdutCbyy9mEu8nRnDIy+K/3D3f86wQ1w=; b=FRmR3UbuNoyuHsLXH7mvdUq7mWHNCGYOtep3qrHzvgQYdG8yW7p5tfBeXJ1RN9F4R9EEfQ9R 8US1+UAwxRykdqHg1UUiOQM6YxLPbjE/VlRPi5LWIsYaWNcQUf6+l/b8; Authentication-Results: ams-dkim-2; header.From=ptomsu@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Agree, spanning multiple administrative domains has always issues. On 11.11.2006 1:50 Uhr, "Fleischman, Eric" wrote: > My personal conclusion is that the IETF protocols do not adequately > address this issue but rather punt this issue to us end users. > Therefore, the actual vulnerability of these approaches in real life > networks is a function of how we end users actually deploy them in our > specific deployments. Therefore, beware of referrals that span > administrative domains! > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 08:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Git6A-00009R-T6; Sat, 11 Nov 2006 08:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Git68-00007d-N1 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 08:40:40 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Git66-0007iw-EI for architecture-discuss@ietf.org; Sat, 11 Nov 2006 08:40:40 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5486769; Sat, 11 Nov 2006 08:40:38 -0500 In-Reply-To: <019d01c70521$45c00420$4901a8c0@tropos.com> References: <019d01c70521$45c00420$4901a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 08:40:35 -0500 To: tony.li@tony.li X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Fleischman, Eric" , Noel Chiappa , Terry L Davis , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Tony, et al; On Nov 10, 2006, at 6:38 PM, Tony Li wrote: > > Eric, > >> Changing topics, I was surprised by this email thread because it is >> apparent that my memory of IPng (IPv6) differs significantly from the >> views I've seen thus far. Specifically, I believe that the IETF >> consensus position today supports Noel's distinction between end >> point >> IDs and topology locators -- we just don't agree on how to >> achieve it. > > > I agree that that seems to be the growing consensus today. However, I > also believe that this consensus is relatively recent. Not long > ago, a > loc/id split was anathema. > One place where the loc/id split might make a lot of sense would be in mobile platform internets (MPI's), such as modern commercial airliners with routers, lots of networked devices and three or more internal subnets and address blocks per plane (see some of the documents at http://www.multicasttech.com/mpi/ if you want more details). 10,000 such planes flying around would tax even an airplane only BGP network. Suppose this was done in a loc/id split, with (say) a /8 allocated to this with 22 bits each assigned to latitude and longitude (for ~1 meter location precision), 12 bits to altitude (~ 10 meters accuracy, although you might want to do a mu law type enocding) there would be 64 bits for the ID. That implies a pretty high density of stuff per square meter and would make MPI routing pretty easy. It may make a lot of sense to assume that the internet is divided into pieces with different needs, and different routing policies. Regards Marshall >> I >> also believe that this distinction was also part of our original IPng >> consensus position and it is part of what I was thinking when I >> originally suggested the proto-IPv6 autoconfiguration approach: the >> first 10 bytes (in my original version) is the locator and the last 6 >> bytes are the identifiers. 8x8 is fine -- I'm not really talking >> about >> where the division is made just that it occurs and that the locators >> locate the routing topology to subnetworks. > > Sorry, I don't believe that we ever got to a consensus where the > locator > was truly independent of the identifier. In particular, I'll claim > that > if the locator is part of the TCP pseudo-header, then it's definitely > not sufficiently independent. We never got that far. > >> Regardless, from where we stand today, how would you technically >> solve >> EGP routing and end-point ID addressing if you were the king of the >> world? > > If I were king, I'd tend to worry about bigger things. ;-) > > My favorite approach is to morph GSE, but the most signficant bits are > a) separation of loc and id, resulting in b) much better multi-level > locator abstraction, c) multi-homing without global prefixes, d) > easier > renumbering, e) better mobility, and f) a reasonably clean > architecture. > Not necessarily in that order. > > Tony > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 09:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giu6j-0005x0-Eh; Sat, 11 Nov 2006 09:45:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giu6i-0005wv-QO for architecture-discuss@ietf.org; Sat, 11 Nov 2006 09:45:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giu6h-0004Wg-GK for architecture-discuss@ietf.org; Sat, 11 Nov 2006 09:45:20 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2006 06:45:19 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="343158263:sNHT53737104" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kABEjIBx015861; Sat, 11 Nov 2006 06:45:18 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kABEjEdE028098; Sat, 11 Nov 2006 06:45:14 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 06:45:13 -0800 Received: from [12.105.242.217] ([10.21.146.248]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 06:45:13 -0800 In-Reply-To: <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> References: <019d01c70521$45c00420$4901a8c0@tropos.com> <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 06:45:11 -0800 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Nov 2006 14:45:13.0545 (UTC) FILETIME=[FEC28B90:01C7059F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1560; t=1163256318; x=1164120318; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Ok, =20so=20what=20should=20we=20do=20then?=20(Was=3A= 20Re=3A=20[arch-d][Off-topic]Further=09thoughts=3A=20about=20systems=20the ory=20and=20the=20theory=20U) |Sender:=20; bh=6jPWUpkgSCSZ3/yFj+RYRLvj04uRkF4dbQRiOdFOoKQ=; b=EFSgGh5Ks/H68m7N7KXuDg50nDm7V7t0hpJHcMPdPH7nSkIdWexxLfXyVxDfPMqBMmLidNEF YmhGGuWJ3ObFhfEK9SsbAvjmNYt0/1UJg2uzJXG327ewygQ2vFkipeD3; Authentication-Results: sj-dkim-5; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Fleischman, Eric" , Noel Chiappa , Terry L Davis , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 5:40 AM, Marshall Eubanks wrote: > a /8 allocated to this with > 22 bits each assigned to latitude and longitude (for ~1 meter > location precision), > 12 bits to altitude (~ 10 meters accuracy, although you might want > to do a mu law type enocding) > there would be 64 bits for the ID. This has been discussed by Tony Hain for quite a while, along the lines of "if I can enumerate the locations on the earth I don't need an RIR to assign me a prefix". We probably have some internet drafts about it somewhere. The presumed routing algorithm here is something like "find the next hop router most obviously in the same direction as the target". Sort of like routing in a hypercube: "calculoate the difference between the address of this corner and the target corner, and send the message on an edge to a device with a lower difference". I worry about backhauls. Lets imagine you're routing to some south pacific island. The only path to it may be by routing to an undersea cable landfall on an island quite a distance away, so that topological and target-based routing take you in exactly opposite directions. I also worry about the possibility of distinguishing one's location - GPS has a minimum footprint that it can discern - and the possibility of having multiple objects within that distance. If I put 50 single RU boxes in a rack, do they all get the same address? What leads me to believe that they are all by virtual of being on the same rack on the same LAN? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 10:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOC-0005im-9x; Sat, 11 Nov 2006 10:03:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOB-0005he-5C for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:03:23 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiuLF-0006V9-0C for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:00:22 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061111150016b1400s747fe>; Sat, 11 Nov 2006 15:00:20 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <019d01c70521$45c00420$4901a8c0@tropos.com> <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> Date: Sat, 11 Nov 2006 09:59:59 -0500 To: Fred Baker , Marshall Eubanks From: John Day Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Fleischman, Eric" , Noel Chiappa , Terry L Davis , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org You guys are being too literal in thinking about "location." Location has to be relative to the topology of the network. (And I do mean topology, not graph.) The topology of the address space and the topology of the network must be compatible. Even then, one will have exceptions that will have to be explicitly noted. But then this is why we maintain a mapping between addresses and routes. Remember addresses are location-dependent. They tell you *where* they are not how to get there. They may give you a hint about where to look for a how! ;-) But that is all. Take care, John At 6:45 -0800 2006/11/11, Fred Baker wrote: >On Nov 11, 2006, at 5:40 AM, Marshall Eubanks wrote: >>a /8 allocated to this with >>22 bits each assigned to latitude and longitude (for ~1 meter >>location precision), >>12 bits to altitude (~ 10 meters accuracy, although you might want >>to do a mu law type enocding) >>there would be 64 bits for the ID. > >This has been discussed by Tony Hain for quite a while, along the >lines of "if I can enumerate the locations on the earth I don't need >an RIR to assign me a prefix". We probably have some internet drafts >about it somewhere. > >The presumed routing algorithm here is something like "find the next >hop router most obviously in the same direction as the target". Sort >of like routing in a hypercube: "calculoate the difference between >the address of this corner and the target corner, and send the >message on an edge to a device with a lower difference". > >I worry about backhauls. Lets imagine you're routing to some south >pacific island. The only path to it may be by routing to an undersea >cable landfall on an island quite a distance away, so that >topological and target-based routing take you in exactly opposite >directions. > >I also worry about the possibility of distinguishing one's location >- GPS has a minimum footprint that it can discern - and the >possibility of having multiple objects within that distance. If I >put 50 single RU boxes in a rack, do they all get the same address? >What leads me to believe that they are all by virtual of being on >the same rack on the same LAN? > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 10:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOD-0005it-6O; Sat, 11 Nov 2006 10:03:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOB-0005he-S4 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:03:23 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiuKK-0006SY-U1 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 09:59:26 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5486877; Sat, 11 Nov 2006 09:59:24 -0500 In-Reply-To: References: <019d01c70521$45c00420$4901a8c0@tropos.com> <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87E73445-4C29-4B7C-8EC0-AB6471054F75@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 09:59:13 -0500 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Noel Chiappa , Eric Fleischman , architecture-discuss@ietf.org, "\(Mobile Platform Internet Mailing List\)" , Terry L Davis X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Fred; (Note cross-posted to the MPI list.) On Nov 11, 2006, at 9:45 AM, Fred Baker wrote: > On Nov 11, 2006, at 5:40 AM, Marshall Eubanks wrote: >> a /8 allocated to this with >> 22 bits each assigned to latitude and longitude (for ~1 meter >> location precision), >> 12 bits to altitude (~ 10 meters accuracy, although you might want >> to do a mu law type enocding) >> there would be 64 bits for the ID. > > This has been discussed by Tony Hain for quite a while, along the > lines of "if I can enumerate the locations on the earth I don't > need an RIR to assign me a prefix". We probably have some internet > drafts about it somewhere. > I would be interested to see them. > The presumed routing algorithm here is something like "find the > next hop router most obviously in the same direction as the > target". Sort of like routing in a hypercube: "calculoate the > difference between the address of this corner and the target > corner, and send the message on an edge to a device with a lower > difference". > In the wired case, this can indeed be problematic (especially if you add in tunnels and VPNs and ...). In the MPI case, where connectivity is by wireless or maybe P2P laser, then it works better. You _can_ only connect to something nearby. (Of course, there are satellites, but then you can only connect to the ones in your foot-print.) And, at least in the aircraft MPI case, there is a desire to connect to _everything_ nearby. > I worry about backhauls. Lets imagine you're routing to some south > pacific island. The only path to it may be by routing to an > undersea cable landfall on an island quite a distance away, so that > topological and target-based routing take you in exactly opposite > directions. > > I also worry about the possibility of distinguishing one's location > - GPS has a minimum footprint that it can discern - and the > possibility of having multiple objects within that distance. If I > put 50 single RU boxes in a rack, do they all get the same address? > What leads me to believe that they are all by virtual of being on > the same rack on the same LAN? With differential GPS/Galileo, you can do 1 meter pretty straight- forwardly. You need that near airports, at least if you are landing there. Over the ocean the accuracy might be less, but so is the crowding. Planes certainly pass over each other, so you need another separator, which I called altitude, which is one possibility (if two planes have the same location and altitude, I am afraid that they would no longer need routing). But the separator could be something else. I would say, if I have 50 1U boxes all in the same airplane, yes, they get the same "loc" but of course different "ids". In any case, the idea of MPI is that it is (in fact if not in name) an autonomous system, with internal routing. Regards Marshall _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 10:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOC-0005im-9x; Sat, 11 Nov 2006 10:03:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOB-0005he-5C for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:03:23 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiuLF-0006V9-0C for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:00:22 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061111150016b1400s747fe>; Sat, 11 Nov 2006 15:00:20 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <019d01c70521$45c00420$4901a8c0@tropos.com> <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> Date: Sat, 11 Nov 2006 09:59:59 -0500 To: Fred Baker , Marshall Eubanks From: John Day Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Fleischman, Eric" , Noel Chiappa , Terry L Davis , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org You guys are being too literal in thinking about "location." Location has to be relative to the topology of the network. (And I do mean topology, not graph.) The topology of the address space and the topology of the network must be compatible. Even then, one will have exceptions that will have to be explicitly noted. But then this is why we maintain a mapping between addresses and routes. Remember addresses are location-dependent. They tell you *where* they are not how to get there. They may give you a hint about where to look for a how! ;-) But that is all. Take care, John At 6:45 -0800 2006/11/11, Fred Baker wrote: >On Nov 11, 2006, at 5:40 AM, Marshall Eubanks wrote: >>a /8 allocated to this with >>22 bits each assigned to latitude and longitude (for ~1 meter >>location precision), >>12 bits to altitude (~ 10 meters accuracy, although you might want >>to do a mu law type enocding) >>there would be 64 bits for the ID. > >This has been discussed by Tony Hain for quite a while, along the >lines of "if I can enumerate the locations on the earth I don't need >an RIR to assign me a prefix". We probably have some internet drafts >about it somewhere. > >The presumed routing algorithm here is something like "find the next >hop router most obviously in the same direction as the target". Sort >of like routing in a hypercube: "calculoate the difference between >the address of this corner and the target corner, and send the >message on an edge to a device with a lower difference". > >I worry about backhauls. Lets imagine you're routing to some south >pacific island. The only path to it may be by routing to an undersea >cable landfall on an island quite a distance away, so that >topological and target-based routing take you in exactly opposite >directions. > >I also worry about the possibility of distinguishing one's location >- GPS has a minimum footprint that it can discern - and the >possibility of having multiple objects within that distance. If I >put 50 single RU boxes in a rack, do they all get the same address? >What leads me to believe that they are all by virtual of being on >the same rack on the same LAN? > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 10:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOD-0005it-6O; Sat, 11 Nov 2006 10:03:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiuOB-0005he-S4 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:03:23 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiuKK-0006SY-U1 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 09:59:26 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5486877; Sat, 11 Nov 2006 09:59:24 -0500 In-Reply-To: References: <019d01c70521$45c00420$4901a8c0@tropos.com> <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87E73445-4C29-4B7C-8EC0-AB6471054F75@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 09:59:13 -0500 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Noel Chiappa , Eric Fleischman , architecture-discuss@ietf.org, "\(Mobile Platform Internet Mailing List\)" , Terry L Davis X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Fred; (Note cross-posted to the MPI list.) On Nov 11, 2006, at 9:45 AM, Fred Baker wrote: > On Nov 11, 2006, at 5:40 AM, Marshall Eubanks wrote: >> a /8 allocated to this with >> 22 bits each assigned to latitude and longitude (for ~1 meter >> location precision), >> 12 bits to altitude (~ 10 meters accuracy, although you might want >> to do a mu law type enocding) >> there would be 64 bits for the ID. > > This has been discussed by Tony Hain for quite a while, along the > lines of "if I can enumerate the locations on the earth I don't > need an RIR to assign me a prefix". We probably have some internet > drafts about it somewhere. > I would be interested to see them. > The presumed routing algorithm here is something like "find the > next hop router most obviously in the same direction as the > target". Sort of like routing in a hypercube: "calculoate the > difference between the address of this corner and the target > corner, and send the message on an edge to a device with a lower > difference". > In the wired case, this can indeed be problematic (especially if you add in tunnels and VPNs and ...). In the MPI case, where connectivity is by wireless or maybe P2P laser, then it works better. You _can_ only connect to something nearby. (Of course, there are satellites, but then you can only connect to the ones in your foot-print.) And, at least in the aircraft MPI case, there is a desire to connect to _everything_ nearby. > I worry about backhauls. Lets imagine you're routing to some south > pacific island. The only path to it may be by routing to an > undersea cable landfall on an island quite a distance away, so that > topological and target-based routing take you in exactly opposite > directions. > > I also worry about the possibility of distinguishing one's location > - GPS has a minimum footprint that it can discern - and the > possibility of having multiple objects within that distance. If I > put 50 single RU boxes in a rack, do they all get the same address? > What leads me to believe that they are all by virtual of being on > the same rack on the same LAN? With differential GPS/Galileo, you can do 1 meter pretty straight- forwardly. You need that near airports, at least if you are landing there. Over the ocean the accuracy might be less, but so is the crowding. Planes certainly pass over each other, so you need another separator, which I called altitude, which is one possibility (if two planes have the same location and altitude, I am afraid that they would no longer need routing). But the separator could be something else. I would say, if I have 50 1U boxes all in the same airplane, yes, they get the same "loc" but of course different "ids". In any case, the idea of MPI is that it is (in fact if not in name) an autonomous system, with internal routing. Regards Marshall _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 10:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giuh4-0007Qh-Jg; Sat, 11 Nov 2006 10:22:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giuh2-0007Po-EO for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:22:52 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giugz-0001bj-56 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:22:52 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kABFKsma073480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Nov 2006 16:20:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <87E73445-4C29-4B7C-8EC0-AB6471054F75@multicasttech.com> References: <019d01c70521$45c00420$4901a8c0@tropos.com> <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> <87E73445-4C29-4B7C-8EC0-AB6471054F75@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <091AAAAD-4A1B-4452-BD13-D48F3D4BFDF7@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 16:22:32 +0100 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "\(\(Mobile Platform Internet Mailing List\)\)" , architecture-discuss@ietf.org, Tony Hain X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 11-nov-2006, at 15:59, Marshall Eubanks wrote: >> This has been discussed by Tony Hain for quite a while, along the >> lines of "if I can enumerate the locations on the earth I don't >> need an RIR to assign me a prefix". We probably have some internet >> drafts about it somewhere. > I would be interested to see them. http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-10.txt I haven't read the latest version, but unless something has changed this is only addressing. A few years ago, I wrote a draft about how to make use of geographically aggregatable address space to have more scalable routing, which includes a different way to do geographic address allocation, but should be compatible with Tony's system as well: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt Iljitsch _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 10:37:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiutW-0007w5-Nz; Sat, 11 Nov 2006 10:35:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiutV-0007v3-H8 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:35:45 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiutU-0004yk-BM for architecture-discuss@ietf.org; Sat, 11 Nov 2006 10:35:45 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EA95D872C1; Sat, 11 Nov 2006 10:35:43 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Message-Id: <20061111153543.EA95D872C1@mercury.lcs.mit.edu> Date: Sat, 11 Nov 2006 10:35:43 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Marshall Eubanks > One place where the loc/id split might make a lot of sense would be > in mobile platform internets (MPI's) > ... > 22 bits each assigned to latitude and longitude > ... > there would be 64 bits for the ID. That would be great for generating an identifier, but it's probably useless for generating a routing-name (locator), because those depend on *who is connected to who*. Physical location tells you nothing about who is connected to who. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 11:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GivH1-00060c-Bp; Sat, 11 Nov 2006 11:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GivGz-00060T-T9 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 11:00:01 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GivGy-0008Ir-Mt for architecture-discuss@ietf.org; Sat, 11 Nov 2006 11:00:01 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7BDFA872C1; Sat, 11 Nov 2006 11:00:00 -0500 (EST) To: architecture-discuss@ietf.org Message-Id: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> Date: Sat, 11 Nov 2006 11:00:00 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: jnc@mercury.lcs.mit.edu Subject: [arch-d] It's the routing, people! X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Some years ago, in one U.S. campaign there was a slogan "It's the economy, stupid!". I would like to paraphrase that here, to focus the discussion on what's important. We're here primarily because there's a routing problem - i.e. the routing is going to melt down. That's the problem people are trying to solve. So, "It's the routing, people!" In other words, the first order of business ought to be trying to figure out how the routing is going to work. Designing addresses is kind of fun, but it's also "looking for keys under the streetlight" (in the words of the old joke). May I remind people that *we are here now precisely because people designed addresses (IPv6), instead of figuring out how the routing is going to work*. I'm somewhat disheartened that the IETF, like the Bourbons (in Talleyrand's famous phrase), has seemingly learned nothing, and forgotten nothing. (There's also a military maxim about "amateurs study tactics, professionals study logistics" - I'll leave it to you all to work out how I'd modify that for us.) So, until we have figured out how the routing is going to work, can we please table *all* discussion of what the addresses are going to look like? Thank you. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 11:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GivfF-0004FX-AK; Sat, 11 Nov 2006 11:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GivfD-0004FR-J3 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 11:25:03 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GivfC-0004oT-61 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 11:25:03 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GivfB-0005DO-AI for architecture-discuss@ietf.org; Sat, 11 Nov 2006 08:25:01 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Nov 2006 16:42:04 +0100 To: John Day ,Fred Baker , Marshall Eubanks From: Jefsey_Morfin Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) In-Reply-To: References: <019d01c70521$45c00420$4901a8c0@tropos.com> <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: "Fleischman, Eric" , Noel Chiappa , Terry L Davis , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0138591188==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0138591188== Content-Type: multipart/alternative; boundary="----MTzeafxiwtzhkvagbnkadsikogdhbsiuro" ------MTzeafxiwtzhkvagbnkadsikogdhbsiuro Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-60FF1A59 At 15:59 11/11/2006, John Day wrote: >You guys are being too literal in thinking about "location." >Location has to be relative to the topology of the network. (And I >do mean topology, not graph.) The topology of the address space and >the topology of the network must be compatible. Even then, one will >have exceptions that will have to be explicitly noted. But then >this is why we maintain a mapping between addresses and routes. Is there not something named X.121 about that? Or E.164? >Remember addresses are location-dependent. They tell you *where* >they are not how to get there. They may give you a hint about where >to look for a how! ;-) But that is all. It helps depending on their segmentation and the dependance between segments. May be, we could consider if instead of obtaining an IP address from the DNS we could obtain a path? What I learned to call a "needle"? It could be kept in cache for a TTL or until an broken path report is received? That DNS would be a Distributed Network Supervisor System? It could be also called with an IP address. By default the origin end would be the calling IP address, but that DNSS could be called to know the status of a different network area. The system could be loaded with a "bandwidth cost per segment" to permit to trim the cheapest (fastest) path. What would be interesting is that it would address the multihoming issue while preserving the origin end autonomy (it could calculate its own needle). Other services would be very easy to support such as ISP rotation (I rotate ISP within a same cession), Daisy Chaining Back-up, Follow-me (mobile, semimobiles), externets (open walled gardens, open user groups) and extranets. The DNSS algorithm and network status knowledge would be simpler if the segments resulted from a topology oriented numbering plan. Obviously the routers would need far less computing power and memory and could easily reconfigure the network in case of line problem or addition. I think the DNSS could be a ONES like the DNS using OPES at the ends to enter the needle and receiving reports from the routers and gateways (line status, traffic load, result of tests, etc.). May be could it be associated directly with the DNS to share security and dynamic network knowledge. And as an extended redesign some additional features could be associated from the offing such as the support of enhanced unicode for foolproof ML.DNs. May be also the needle could be checked at the receiving end to filter out spoofing? This could certainly be part of a distributed network operating system. Or may be is it a too smart yet proven solution? Cheers. jfc ------MTzeafxiwtzhkvagbnkadsikogdhbsiuro Content-Type: text/html At 15:59 11/11/2006, John Day wrote:
>You guys are being too literal in thinking about "location."
>Location has to be relative to the topology of the network.  (And I
>do mean topology, not graph.)  The topology of the address space and
>the topology of the network must be compatible.  Even then, one will
>have exceptions that will have to be explicitly noted.  But then
>this is why we maintain a mapping between addresses and routes.

Is there not something named X.121 about that? Or E.164?

>Remember addresses are location-dependent.  They tell you *where*
>they are not how to get there.  They may give you a hint about where
>to look for a how! ;-)  But that is all.

It helps depending on their segmentation and the dependance between segments.
May be, we could consider if instead of obtaining an IP address from
the DNS we could obtain a path? What I learned to call a "needle"?
It could be kept in cache for a TTL or until an broken path report is received?

That DNS would be a Distributed Network Supervisor System?

It could be also called with an IP address.

By default the origin end would be the calling IP address, but that
DNSS could be called to know the status of a different network area.
The system could be loaded with a "bandwidth cost per segment" to
permit to trim the cheapest (fastest) path.

What would be interesting is that it would address the multihoming
issue while preserving the origin end autonomy (it could calculate
its own needle). Other services would be very easy to support such as
ISP rotation (I rotate ISP within a same cession), Daisy Chaining
Back-up, Follow-me (mobile, semimobiles), externets (open walled
gardens, open user groups) and extranets.

The DNSS algorithm and network status knowledge would be simpler if
the segments resulted from a topology oriented numbering plan.
Obviously the routers would need far less computing power and memory
and could easily reconfigure the network in case of line problem or addition.

I think the DNSS could be a ONES like the DNS using OPES at the ends
to enter the needle and receiving reports from the routers and
gateways (line status, traffic load, result of tests, etc.). May be
could it be associated directly with the DNS to share security and
dynamic network knowledge. And as an extended redesign some
additional features could be associated from the offing such as the
support of enhanced unicode for foolproof ML.DNs. May be also the
needle could be checked at the receiving end to filter out spoofing?

This could certainly be part of a distributed network operating system.
Or may be is it a too smart yet proven solution?
Cheers.
jfc



------MTzeafxiwtzhkvagbnkadsikogdhbsiuro-- --===============0138591188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0138591188==-- From architecture-discuss-bounces@ietf.org Sat Nov 11 12:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwBw-0006T8-GK; Sat, 11 Nov 2006 11:58:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwBu-0006Su-Sh for architecture-discuss@ietf.org; Sat, 11 Nov 2006 11:58:50 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiwBt-0002Wa-6Y for architecture-discuss@ietf.org; Sat, 11 Nov 2006 11:58:50 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2006 08:58:48 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="343213582:sNHT47822596" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kABGwmfH025105; Sat, 11 Nov 2006 08:58:48 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kABGwmW4018757; Sat, 11 Nov 2006 08:58:48 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 08:58:47 -0800 Received: from [10.0.4.21] ([10.21.120.58]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 08:58:47 -0800 In-Reply-To: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <108C6CD3-A038-4F02-8952-1EDC4901BD42@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 08:58:46 -0800 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Nov 2006 16:58:47.0619 (UTC) FILETIME=[A7853130:01C705B2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=617; t=1163264328; x=1164128328; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20It's=20the=20routing,=20people! |Sender:=20; bh=o3twpE8uC7aK2u93exA09ly7ENzNJJZPa5BdXVVceAo=; b=BJB43ZXk5XKQ/O8m/ah9RicAscMjIZ3JS7B2KCrBpRU32DvO+58wkzves7SLnKFbQcjZJhe7 LH2nHEWNouTzVwdpks9yTL0WSqCLwTpN4CSqsmYXIjX5B0jREyjhg3nU; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 8:00 AM, Noel Chiappa wrote: > until we have figured out how the routing is going to work, can we > please table *all* discussion of what the addresses are going to > look like? I'll support you in this; you note my comments on routing in response to a particular address proposal this morning. That said, if you want to redefine routing, we need a proposal on the table, and we are in fact on a fairly constrained timeline. Are you asking us to reset to the rambling discussions of 1992 and presume that the current crunch will not actually happen until 20 years hence? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 12:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwPs-00017v-Ks; Sat, 11 Nov 2006 12:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwPr-00017q-Da for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:13:15 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiwPl-0005Bc-Is for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:13:15 -0500 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kABHCsOR027001; Sun, 12 Nov 2006 04:12:54 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061112035216.0140b900@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 12 Nov 2006 04:12:50 +1100 To: architecture-discuss@ietf.org From: Geoff Huston Subject: Re: [arch-d] It's the routing, people! In-Reply-To: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, Each of us has various ways of thinking about a space and various ways on conceptualizing the nature of the issues with such a space. While its pretty clear what works for you when you turn the considerations into symbols and start to move them around, others of us have different ways of conceptualizing the space, and indeed have different problem priorities. I don't see routing melting today. Today I see a class of FIB implementations coming close to a current design limit. I don't necessarily accept that FIB meltdown is only prevented by changing the routing paradigm, as I still don't accept that FIB = RIB. I see that if per packet performance is critical, and that appears to be the case, then the lookup performed per packet should be fast. But I don't accept that this necessarily implies that you have to perform this lookup over the equivalent of the RIB stuffed into a fast lookup data structure to derive an answer that is of the same order as the number of physical egress choices on the box. I suspect that a better understanding of the semantics of addresses, and the distinction, even in a constrained routing world about what are the characteristics of the packet's source and destination tag, and the relationship of these two tags to the forwarding path across the network are useful in understanding the relationship to the problem being presented here and the degrees of freedom in the symbol space that we can manipulate to provide mitigation, both in the short and long term. So I interpret your request to table all consideration on the semantics of an address at the routing level as being unwise and overly tactical (yes, "tactical" as in the full sense of the quote you provided below). regards, Geoff As a postscript to this note, having lived in the IETF for so long, I may be ignorant amateur in full conformance with the comment in your note, but frankly, I really didn't need you to point this out Noel! Either I knew that already, in which case your repetition of the accusation is unhelpful and uninformative, or I didn't, in which case the accusation alone is entirely unconvincing to me! At 03:00 AM 12/11/2006, Noel Chiappa wrote: >Some years ago, in one U.S. campaign there was a slogan "It's the economy, >stupid!". I would like to paraphrase that here, to focus the discussion on >what's important. > >We're here primarily because there's a routing problem - i.e. the routing is >going to melt down. That's the problem people are trying to solve. So, "It's >the routing, people!" In other words, the first order of business ought to be >trying to figure out how the routing is going to work. > >Designing addresses is kind of fun, but it's also "looking for keys under the >streetlight" (in the words of the old joke). May I remind people that *we are >here now precisely because people designed addresses (IPv6), instead of >figuring out how the routing is going to work*. > >I'm somewhat disheartened that the IETF, like the Bourbons (in Talleyrand's >famous phrase), has seemingly learned nothing, and forgotten nothing. >(There's also a military maxim about "amateurs study tactics, professionals >study logistics" - I'll leave it to you all to work out how I'd modify that >for us.) > >So, until we have figured out how the routing is going to work, can we please >table *all* discussion of what the addresses are going to look like? Thank >you. > > Noel > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 12:21:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwXo-0005b0-HT; Sat, 11 Nov 2006 12:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwXn-0005au-BB for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:21:27 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiwXm-0007Xa-3G for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:21:27 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <200611111721250120030536e>; Sat, 11 Nov 2006 17:21:25 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> Date: Sat, 11 Nov 2006 12:21:17 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] It's the routing, people! Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Then the addresses should simply be labels. Not true. If the addresses are suppose to be location-dependent, that location dependence is relative to the *topology* of the network. Think in terms of how location-dependence should be represented relative to the graph of the network. The nature of the address space is as important as the routes. They actually influence each other to some degree. You are concentrating on the arithmetic, when you need to be looking at the algebra. I agree with you that v6 did not do this. But then what did you expect. I have yet to see any proposals on this list that do it. But they are possible. If you don't get the two things working together, you won't get a solution that scales. That much I can pretty much guarantee. Take care, john At 11:00 -0500 2006/11/11, Noel Chiappa wrote: >Some years ago, in one U.S. campaign there was a slogan "It's the economy, >stupid!". I would like to paraphrase that here, to focus the discussion on >what's important. > >We're here primarily because there's a routing problem - i.e. the routing is >going to melt down. That's the problem people are trying to solve. So, "It's >the routing, people!" In other words, the first order of business ought to be >trying to figure out how the routing is going to work. > >Designing addresses is kind of fun, but it's also "looking for keys under the >streetlight" (in the words of the old joke). May I remind people that *we are >here now precisely because people designed addresses (IPv6), instead of >figuring out how the routing is going to work*. > >I'm somewhat disheartened that the IETF, like the Bourbons (in Talleyrand's >famous phrase), has seemingly learned nothing, and forgotten nothing. >(There's also a military maxim about "amateurs study tactics, professionals >study logistics" - I'll leave it to you all to work out how I'd modify that >for us.) > >So, until we have figured out how the routing is going to work, can we please >table *all* discussion of what the addresses are going to look like? Thank >you. > > Noel > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 12:34:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giwje-0004ML-Mn; Sat, 11 Nov 2006 12:33:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giwjc-0004Lf-Ur for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:33:40 -0500 Received: from [2001:470:117:128:209:5bff:fe8c:8515] (helo=uillean.fuaim.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giwja-0005Se-Ey for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:33:40 -0500 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id E1A14B933; Sat, 11 Nov 2006 09:33:20 -0800 (PST) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 56596-03; Sat, 11 Nov 2006 09:33:15 -0800 (PST) Received: from clairseach.fuaim.com (unknown [IPv6:2001:470:117:128:209:5bff:fe8e:6dd3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 9E545B932; Sat, 11 Nov 2006 09:33:15 -0800 (PST) Received: from [172.17.55.6] (69-174-161-251.frdrmd.adelphia.net [69.174.161.251]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id kABHS9q5030376 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 11 Nov 2006 09:28:12 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <131c452e1c3c8d5bbaa70a21320fb507@innovationslab.net> Content-Transfer-Encoding: 7bit From: Brian Haberman Subject: Re: [MPI]Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about system Date: Sat, 11 Nov 2006 12:33:10 -0500 To: (Mobile Platform Internet Mailing List) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Noel Chiappa , Eric Fleischman , architecture-discuss@ietf.org, Terry L Davis X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Marshall, On Nov 11, 2006, at 9:59, Marshall Eubanks wrote: > Dear Fred; > > (Note cross-posted to the MPI list.) > > On Nov 11, 2006, at 9:45 AM, Fred Baker wrote: > >> On Nov 11, 2006, at 5:40 AM, Marshall Eubanks wrote: >>> a /8 allocated to this with >>> 22 bits each assigned to latitude and longitude (for ~1 meter >>> location precision), >>> 12 bits to altitude (~ 10 meters accuracy, although you might want >>> to do a mu law type enocding) >>> there would be 64 bits for the ID. >> >> This has been discussed by Tony Hain for quite a while, along the >> lines of "if I can enumerate the locations on the earth I don't need >> an RIR to assign me a prefix". We probably have some internet drafts >> about it somewhere. >> > > I would be interested to see them. http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-10.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-10.txt Regards, Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 12:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwkW-0004rC-GH; Sat, 11 Nov 2006 12:34:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiwkU-0004n6-TN for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:34:34 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiwkT-0006Wn-J0 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:34:34 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id B21644AC7A; Sat, 11 Nov 2006 12:34:31 -0500 (EST) Date: Sat, 11 Nov 2006 12:34:31 -0500 From: John Leslie To: Noel Chiappa Subject: Re: [arch-d] It's the routing, people! Message-ID: <20061111173431.GP73049@verdi> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel Chiappa wrote: > > We're here primarily because there's a routing problem - i.e. the > routing is going to melt down. That's the problem people are trying > to solve. So, "It's the routing, people!" In other words, the first > order of business ought to be trying to figure out how the routing > is going to work. I'm not sure "order of business" applies on mailing lists, but I quite agree we'd be better off with some consensus on what we _want_ the routing to look like. > Designing addresses is kind of fun, but it's also "looking for keys > under the streetlight" (in the words of the old joke). May I remind > people that *we are here now precisely because people designed > addresses (IPv6), instead of figuring out how the routing is going > to work*. I'd say we're here because the folks designing IPv6 addresses were chartered to leave "routing" questions to some other group. > I'm somewhat disheartened that the IETF, like the Bourbons (in > Talleyrand's famous phrase), has seemingly learned nothing, and > forgotten nothing... :^) > So, until we have figured out how the routing is going to work, can > we please table *all* discussion of what the addresses are going to > look like? Personally, I'd be glad to. (I doubt it'll work though...) But could you humor me, and try to reach some agreement about what we mean by - "address", - "locator", - "identifier", and - "name" ? -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 12:37:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giwmr-0006Yd-BO; Sat, 11 Nov 2006 12:37:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giwmq-0006YX-1F for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:37:00 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giwmn-0007Nb-Pa for architecture-discuss@ietf.org; Sat, 11 Nov 2006 12:37:00 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 75E3886AE9; Sat, 11 Nov 2006 12:36:57 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) Message-Id: <20061111173657.75E3886AE9@mercury.lcs.mit.edu> Date: Sat, 11 Nov 2006 12:36:57 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) >> I don't believe in the "else try_and_forward(input_packet)" >> clause, except for local traffic)... > I started to think through this whole issue, and discovered a problem. > To see it, let's think in a little more detail about how the routing in > a "jack-up" system is going to work. In an attempt to make slightly clearer what I was jabbering on about here, I have drawn a couple of quick, simplified diagrams which show some of the things I was talking about. Remember, I'm talking about the flow of routing data here, *not* packets, and the mappings you see happening from old-style to new-style are mappings of routing data, not mappings of packet source/destination addresses. Again, the basic issue is that we're trying to reduce the amount of routing information, but my concern is (basically) that until the very last "old-style" DFZ router goes away, we may have to maintain full old-style tables anyway in all routers everywhere - depending on how we set things up. Anyway, the diagrams are here: http://ana-3.lcs.mit.edu/~jnc/tech/DisDFZ.jpg which shows the problems with discontiguous chunks of new-style DFZ (i.e. the repeated conversion from new-style locators back to old-style addresses), and here: http://ana-3.lcs.mit.edu/~jnc/tech/ContDFZ.jpg which shows how the same technical issue (the reverse mapping from new-style addresses back to old-style) occurs with a large, continugous new-style DFZ on the edge, but how it's more manageable since it's only happening on a single boundary. So, try rereading my other message (Fri, 10 Nov 2006 21:18:28 -0500) with these diagrams, and see if what I'm wondering about makes sense. For simplicities sake, I have drawn the diagrams as if all networks with unmapped addresses are attached to the old-style DFZ, and all with mapped to the new-style, but of course that's not necessary. Also, I have only drawn the physical topology, not the two separate routing planes - sorry, didn't have enough patience for a multi-layer drawing! Anyway, I'd really appreciate it if people could look at this material (diagrams and text), and see if I've made some obvious blunder in my understanding, or if there is a real issue here. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 13:18:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixOS-0004uB-KP; Sat, 11 Nov 2006 13:15:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GixOS-0004t9-17 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 13:15:52 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GixOP-0007fG-T6 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 13:15:52 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7B82986AE9; Sat, 11 Nov 2006 13:15:49 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] It's the routing, people! Message-Id: <20061111181549.7B82986AE9@mercury.lcs.mit.edu> Date: Sat, 11 Nov 2006 13:15:49 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Geoff Huston > I don't see routing melting today. I'm only here because other people seem to think it's coming, and want to get moving on a solution. If there is no problem, then this whole discussion is moot, no? > I don't necessarily accept that FIB meltdown is only prevented by > changing the routing paradigm, as I still don't accept that FIB = RIB. > I see that if per packet performance is critical, and that appears to > be the case, then the lookup performed per packet should be fast. But I > don't accept that this necessarily implies that you have to perform > this lookup over the equivalent of the RIB stuffed into a fast lookup > data structure to derive an answer that is of the same order as the > number of physical egress choices on the box. I'm not the person to be discussing that point with. You need to talk to the people who made the case at the IAB workshop. Apparently they convinced the people at the workshop, but maybe you see something they don't. I read through the slides from the workshop, and the conclusions seemed reasonable, but again, perhaps you see something that changes things. Do you have some approach in mind that works differently? If so, could you at least sketch it out for us briefly - a full-blown writeup isn't necessary. > I suspect that a better understanding of the semantics of addresses, > and the distinction .. about what are the characteristics of the > packet's source and destination tag, and the relationship of these two > tags to the forwarding path across the network are useful in > understanding the relationship to the problem being presented here and > the degrees of freedom in the symbol space that we can manipulate to > provide mitigation I'm not sure I fully see what you are getting at here, but this kind of discussion, about not just the semantics of addresses, but about how those semantics relate to the computation of paths across the connectivity graph, would be OK, but I didn't hear that happening. Again, something with a bit more information as to some new scheme which you might have in mind would make it possible to examine these issues you raise above, because at this level of abstraction it's hard to draw any definite conclusions. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 14:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giyn6-0002LC-Fs; Sat, 11 Nov 2006 14:45:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giyn4-0002L7-Or for architecture-discuss@ietf.org; Sat, 11 Nov 2006 14:45:22 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Giyn2-0004Db-Cg for architecture-discuss@ietf.org; Sat, 11 Nov 2006 14:45:22 -0500 Received: (qmail 5301 invoked from network); 11 Nov 2006 19:45:11 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 11 Nov 2006 19:45:11 -0000 Received: from LIPC ([192.168.1.157]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 11:45:11 -0800 From: "Tony Li" To: "'Marshall Eubanks'" , Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Sat, 11 Nov 2006 11:45:07 -0800 Message-ID: <003401c705c9$e456af00$9d01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0FE3639E-3B2F-4E94-AE17-3E7685E25ECE@multicasttech.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanA X-OriginalArrivalTime: 11 Nov 2006 19:45:11.0494 (UTC) FILETIME=[E65F9E60:01C705C9] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "'Fleischman, Eric'" , 'Noel Chiappa' , 'Terry L Davis' , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > One place where the loc/id split might make a lot of sense would be > in mobile platform internets (MPI's), such as > modern commercial airliners with routers, lots of networked devices > and three or more internal subnets and address blocks per plane (see > some of the documents at http://www.multicasttech.com/mpi/ if you > want more details). 10,000 such planes flying around would tax even > an airplane only BGP network. Hi Marshall, That's certainly one approach. However, there's another solution to this issue that doesn't really require architectural changes. If you take a look at how our friends at Connexion did things, they assigned one prefix per plane and then injected it into global routing at the point of its current downlink. With all due respect, an alternate approach would be to have a separate global domain that provides backhaul and have that domain inject all plane prefixes from all points simultaneously, effectively causing everyone to perform hot-potato routing to them with stable BGP injection. Note that the backhaul network need not be physically instantiated: a full mesh of tunnels between the downlink sites and an IGP carrying plane prefixes should work very nicely for little additional (physical) cost. It also has the nice property that your latency to the plane is not nearly as bad as bouncing to a single, fixed downlink would be. You can also decrease latency by adding (virtual) connectivity anywhere in the global topology to redirect traffic into the backhaul topology. Hiding mobility is a good option for the cases where you're not going to actually change providers. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 15:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizJv-0004Bp-2b; Sat, 11 Nov 2006 15:19:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GizJs-0004Bg-Uz for architecture-discuss@ietf.org; Sat, 11 Nov 2006 15:19:16 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GizJs-0002R8-EA for architecture-discuss@ietf.org; Sat, 11 Nov 2006 15:19:16 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 14:19:16 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 14:19:15 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccFvduWHian7WgZQQivkex9sostqAAEMz8w From: "Schliesser, Benson" To: X-OriginalArrivalTime: 11 Nov 2006 20:19:16.0102 (UTC) FILETIME=[A90E0A60:01C705CE] X-Spam-Score: 0.5 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0219053663==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0219053663== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C705CE.A8F2024B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C705CE.A8F2024B Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+PiBJIGRvbid0IHNlZSByb3V0aW5nIG1lbHRpbmcgdG9kYXkuDQo+IEknbSBvbmx5IGhlcmUg YmVjYXVzZSBvdGhlciBwZW9wbGUgc2VlbSB0byB0aGluaw0KPiBpdCdzIGNvbWluZywgYW5kIHdh bnQgdG8gZ2V0DQo+IG1vdmluZyBvbiBhIHNvbHV0aW9uLg0KDQpJIGRvbid0IHdhbnQgdG8gZGVy YWlsIHRoZSBicm9hZGVyIGFyY2hpdGVjdHVyYWwgZGlzY3Vzc2lvbiwgd2hpY2ggSSB0aGluayBp cyB2YWx1YWJsZS4gQnV0IGxldCBtZSBwb2ludCBvdXQgc29tZXRoaW5nIGRpcmVjdGx5IHJlbGF0 ZWQgdG8gdGhlIGVuZ2luZWVyaW5nIHByb2JsZW0gd2UgZmFjZSBpbiB0aGUgcm91dGluZyBzeXN0 ZW06IE9mIHRoZSBhcHByb3ggMjNrIEFTcyBpbiB0aGUgZ2xvYmFsIHJvdXRpbmcgc3lzdGVtLCBv bmx5IDNrIGFyZSB0cmFuc2l0IEFTcy4gVGhlIG90aGVyIDIwayBzeXN0ZW1zIGFyZSBiYXNpY2Fs bHkgZW5kIG5ldHdvcmtzIHRoYXQgbXVsdGlob21lLiAoWWVzLCB0aGVyZSBhcmUgZXhjZXB0aW9u cywgYW5kIHRoZXNlIG51bWJlcnMgYXJlIGdlbmVyYXRlZCBmcm9tIGEgcGFydGljdWxhciBwZXJz cGVjdGl2ZSBpbiB0aGUgbmV0d29yayB0aGF0IG1pZ2h0IG5vdCByZXByZXNlbnQgYWxsIHBlcnNw ZWN0aXZlcyBhY2N1cmF0ZWx5LCBidXQgdGhleSBjYXB0dXJlIGEgcm91Z2ggcGljdHVyZSB0aGF0 J3MgZ29vZCBlbm91Z2ggZm9yIHRoaXMgZGlzY3Vzc2lvbiwgSSB0aGluay4pIE9mIHRoZSBkZS1h Z2dyZWdhdGVkIGFuZCBQSSBzcGFjZSB0aGF0IGV4aXN0cyBhcyByb3V0ZXMgaW4gdGhlIGdsb2Jh bCB0YWJsZXMsIGEgc2lnbmlmaWNhbnQgcGFydCBvZiBpdCwgYW5kIHRoZSBtb3N0IGRpZmZpY3Vs dCBwYXJ0IHRvIGFkZHJlc3MgdGhyb3VnaCBlZHVjYXRpb24gYW5kIHBvbGljeSwgaXMgaW4gc3Vw cG9ydCBvZiB0aGVzZSAyMGsgZW5kIG5ldHdvcmtzLiBUaGV5IG5lZWQgZGUtYWdncmVnYXRlcyBh bmQvb3IgUEkgaW4gb3JkZXIgdG8gbWFpbnRhaW4gcmVkdW5kYW50IGNvbm5lY3Rpdml0eSwgYmVj YXVzZSB0aGVyZSBpc24ndCBhIGJldHRlciB0ZWNobmljYWwgc29sdXRpb24uIChVbmxlc3MgdGhl eSB1c2UgTkFUIGFuZCBkb24ndCBtaW5kIGNvbm5lY3Rpb24gcmVzZXRzIG9uIGZhaWxJb3ZlcnMs IGV0Yy4pLiBJZiB3ZSBjYW4gY29tZSB1cCB3aXRoIGEgZ29vZCBzb2x1dGlvbiB0byBtdWx0aWhv bWluZyB0aGF0IHJlbW92ZXMgdGhlIG5lZWQgZm9yIHRoZXNlIGVuZCBuZXR3b3JrcyB0byBwYXJ0 aWNpcGF0ZSBpbiBnbG9iYWwgcm91dGluZyBldGMsIGFuZCBjaGFuZ2UgcG9saWN5IHNvIHRoYXQg aXQgcmVmbGVjdHMgdGhpcyBpbiB0dXJuLCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIGNhbiBtYXRl cmlhbGx5IHJlZHVjZSB0YWJsZSBzaXplIGFuZCByYXRlIG9mIGdyb3d0aC4gKEdlb2ZmLCBpdCB3 YXMgc2FpZCB5b3Ugc3BlbmQgYWxsIG9mIHlvdXIgdGltZSBzdHVkeWluZyB0aGlzOyB3b3VsZCB5 b3UgYWdyZWU/KQ0KDQpZZXMsIHRoZSB3YXkgSSBlbnZpc2lvbiB0aGlzIGl0IHdvdWxkIGJlIGZh ciBmcm9tIGEgbmV3IGFyY2hpdGVjdHVyZS4gQnV0IGlmIGl0IHNvbHZlcyB0aGUgaW1tZWRpYXRl IHByb2JsZW0gdGhlbiB0aG9zZSBvZiB1cyBydW5uaW5nIG5ldHdvcmtzIGNhbiBrZWVwIHRoZSBu ZXR3b3JrIHdvcmtpbmcsIGFuZCB0aGlzIG1haWxpbmcgbGlzdCBjYW4gY29udGludWUgdG8gZnVu Y3Rpb24gYXMgYSBmb3J1bSBmb3IgYXJjaGl0ZWN0dXJhbCBkaXNjdXNzaW9uLiAgOykNCg0KQ2hl ZXJzLA0KLUJlbnNvbg0KKFNlbnQgZnJvbSBteSBCbGFja2JlcnJ5Li4uIFNvcnJ5IGZvciB0aHVt Yi10eXBvcykNCg0KDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOb2Vs IENoaWFwcGENClRvOiBhcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZw0KQ0M6IGpuY0BtZXJj dXJ5Lmxjcy5taXQuZWR1DQpTZW50OiBTYXQgTm92IDExIDEyOjE1OjQ5IDIwMDYNClN1YmplY3Q6 IFJlOiBbYXJjaC1kXSBJdCdzIHRoZSByb3V0aW5nLCBwZW9wbGUhDQoNCiAgICA+IEZyb206IEdl b2ZmIEh1c3RvbiA8Z2loQGFwbmljLm5ldD4NCg0KICAgID4gSSBkb24ndCBzZWUgcm91dGluZyBt ZWx0aW5nIHRvZGF5Lg0KDQpJJ20gb25seSBoZXJlIGJlY2F1c2Ugb3RoZXIgcGVvcGxlIHNlZW0g dG8gdGhpbmsgaXQncyBjb21pbmcsIGFuZCB3YW50IHRvIGdldA0KbW92aW5nIG9uIGEgc29sdXRp b24uIElmIHRoZXJlIGlzIG5vIHByb2JsZW0sIHRoZW4gdGhpcyB3aG9sZSBkaXNjdXNzaW9uIGlz DQptb290LCBubz8NCg0KICAgID4gSSBkb24ndCBuZWNlc3NhcmlseSBhY2NlcHQgdGhhdCBGSUIg bWVsdGRvd24gaXMgb25seSBwcmV2ZW50ZWQgYnkNCiAgICA+IGNoYW5naW5nIHRoZSByb3V0aW5n IHBhcmFkaWdtLCBhcyBJIHN0aWxsIGRvbid0IGFjY2VwdCB0aGF0IEZJQiA9IFJJQi4NCiAgICA+ IEkgc2VlIHRoYXQgaWYgcGVyIHBhY2tldCBwZXJmb3JtYW5jZSBpcyBjcml0aWNhbCwgYW5kIHRo YXQgYXBwZWFycyB0bw0KICAgID4gYmUgdGhlIGNhc2UsIHRoZW4gdGhlIGxvb2t1cCBwZXJmb3Jt ZWQgcGVyIHBhY2tldCBzaG91bGQgYmUgZmFzdC4gQnV0IEkNCiAgICA+IGRvbid0IGFjY2VwdCB0 aGF0IHRoaXMgbmVjZXNzYXJpbHkgaW1wbGllcyB0aGF0IHlvdSBoYXZlIHRvIHBlcmZvcm0NCiAg ICA+IHRoaXMgbG9va3VwIG92ZXIgdGhlIGVxdWl2YWxlbnQgb2YgdGhlIFJJQiBzdHVmZmVkIGlu dG8gYSBmYXN0IGxvb2t1cA0KICAgID4gZGF0YSBzdHJ1Y3R1cmUgdG8gZGVyaXZlIGFuIGFuc3dl ciB0aGF0IGlzIG9mIHRoZSBzYW1lIG9yZGVyIGFzIHRoZQ0KICAgID4gbnVtYmVyIG9mIHBoeXNp Y2FsIGVncmVzcyBjaG9pY2VzIG9uIHRoZSBib3guDQoNCkknbSBub3QgdGhlIHBlcnNvbiB0byBi ZSBkaXNjdXNzaW5nIHRoYXQgcG9pbnQgd2l0aC4gWW91IG5lZWQgdG8gdGFsayB0byB0aGUNCnBl b3BsZSB3aG8gbWFkZSB0aGUgY2FzZSBhdCB0aGUgSUFCIHdvcmtzaG9wLiBBcHBhcmVudGx5IHRo ZXkgY29udmluY2VkIHRoZQ0KcGVvcGxlIGF0IHRoZSB3b3Jrc2hvcCwgYnV0IG1heWJlIHlvdSBz ZWUgc29tZXRoaW5nIHRoZXkgZG9uJ3QuIEkgcmVhZA0KdGhyb3VnaCB0aGUgc2xpZGVzIGZyb20g dGhlIHdvcmtzaG9wLCBhbmQgdGhlIGNvbmNsdXNpb25zIHNlZW1lZCByZWFzb25hYmxlLA0KYnV0 IGFnYWluLCBwZXJoYXBzIHlvdSBzZWUgc29tZXRoaW5nIHRoYXQgY2hhbmdlcyB0aGluZ3MuDQoN CkRvIHlvdSBoYXZlIHNvbWUgYXBwcm9hY2ggaW4gbWluZCB0aGF0IHdvcmtzIGRpZmZlcmVudGx5 PyBJZiBzbywgY291bGQgeW91DQphdCBsZWFzdCBza2V0Y2ggaXQgb3V0IGZvciB1cyBicmllZmx5 IC0gYSBmdWxsLWJsb3duIHdyaXRldXAgaXNuJ3QgbmVjZXNzYXJ5Lg0KDQogICAgPiBJIHN1c3Bl Y3QgdGhhdCBhIGJldHRlciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBzZW1hbnRpY3Mgb2YgYWRkcmVz c2VzLA0KICAgID4gYW5kIHRoZSBkaXN0aW5jdGlvbiAuLiBhYm91dCB3aGF0IGFyZSB0aGUgY2hh cmFjdGVyaXN0aWNzIG9mIHRoZQ0KICAgID4gcGFja2V0J3Mgc291cmNlIGFuZCBkZXN0aW5hdGlv biB0YWcsIGFuZCB0aGUgcmVsYXRpb25zaGlwIG9mIHRoZXNlIHR3bw0KICAgID4gdGFncyB0byB0 aGUgZm9yd2FyZGluZyBwYXRoIGFjcm9zcyB0aGUgbmV0d29yayBhcmUgdXNlZnVsIGluDQogICAg PiB1bmRlcnN0YW5kaW5nIHRoZSByZWxhdGlvbnNoaXAgdG8gdGhlIHByb2JsZW0gYmVpbmcgcHJl c2VudGVkIGhlcmUgYW5kDQogICAgPiB0aGUgZGVncmVlcyBvZiBmcmVlZG9tIGluIHRoZSBzeW1i b2wgc3BhY2UgdGhhdCB3ZSBjYW4gbWFuaXB1bGF0ZSB0bw0KICAgID4gcHJvdmlkZSBtaXRpZ2F0 aW9uDQoNCkknbSBub3Qgc3VyZSBJIGZ1bGx5IHNlZSB3aGF0IHlvdSBhcmUgZ2V0dGluZyBhdCBo ZXJlLCBidXQgdGhpcyBraW5kIG9mDQpkaXNjdXNzaW9uLCBhYm91dCBub3QganVzdCB0aGUgc2Vt YW50aWNzIG9mIGFkZHJlc3NlcywgYnV0IGFib3V0IGhvdyB0aG9zZQ0Kc2VtYW50aWNzIHJlbGF0 ZSB0byB0aGUgY29tcHV0YXRpb24gb2YgcGF0aHMgYWNyb3NzIHRoZSBjb25uZWN0aXZpdHkgZ3Jh cGgsDQp3b3VsZCBiZSBPSywgYnV0IEkgZGlkbid0IGhlYXIgdGhhdCBoYXBwZW5pbmcuDQoNCkFn YWluLCBzb21ldGhpbmcgd2l0aCBhIGJpdCBtb3JlIGluZm9ybWF0aW9uIGFzIHRvIHNvbWUgbmV3 IHNjaGVtZSB3aGljaCB5b3UNCm1pZ2h0IGhhdmUgaW4gbWluZCB3b3VsZCBtYWtlIGl0IHBvc3Np YmxlIHRvIGV4YW1pbmUgdGhlc2UgaXNzdWVzIHlvdSByYWlzZQ0KYWJvdmUsIGJlY2F1c2UgYXQg dGhpcyBsZXZlbCBvZiBhYnN0cmFjdGlvbiBpdCdzIGhhcmQgdG8gZHJhdyBhbnkgZGVmaW5pdGUN CmNvbmNsdXNpb25zLg0KDQoJTm9lbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGluZyBsaXN0DQpBcmNo aXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MNCg== ------_=_NextPart_001_01C705CE.A8F2024B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41LjcyMzQuMyI+DQo8VElUTEU+UmU6IFthcmNoLWRd IEl0J3MgdGhlIHJvdXRpbmcsIHBlb3BsZSE8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0t IENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KPEJSPg0KDQo8UD48Rk9OVCBT SVpFPTI+Jmd0OyZndDsgSSBkb24ndCBzZWUgcm91dGluZyBtZWx0aW5nIHRvZGF5LjxCUj4NCiZn dDsgSSdtIG9ubHkgaGVyZSBiZWNhdXNlIG90aGVyIHBlb3BsZSBzZWVtIHRvIHRoaW5rPEJSPg0K Jmd0OyBpdCdzIGNvbWluZywgYW5kIHdhbnQgdG8gZ2V0PEJSPg0KJmd0OyBtb3Zpbmcgb24gYSBz b2x1dGlvbi48QlI+DQo8QlI+DQpJIGRvbid0IHdhbnQgdG8gZGVyYWlsIHRoZSBicm9hZGVyIGFy Y2hpdGVjdHVyYWwgZGlzY3Vzc2lvbiwgd2hpY2ggSSB0aGluayBpcyB2YWx1YWJsZS4gQnV0IGxl dCBtZSBwb2ludCBvdXQgc29tZXRoaW5nIGRpcmVjdGx5IHJlbGF0ZWQgdG8gdGhlIGVuZ2luZWVy aW5nIHByb2JsZW0gd2UgZmFjZSBpbiB0aGUgcm91dGluZyBzeXN0ZW06IE9mIHRoZSBhcHByb3gg MjNrIEFTcyBpbiB0aGUgZ2xvYmFsIHJvdXRpbmcgc3lzdGVtLCBvbmx5IDNrIGFyZSB0cmFuc2l0 IEFTcy4gVGhlIG90aGVyIDIwayBzeXN0ZW1zIGFyZSBiYXNpY2FsbHkgZW5kIG5ldHdvcmtzIHRo YXQgbXVsdGlob21lLiAoWWVzLCB0aGVyZSBhcmUgZXhjZXB0aW9ucywgYW5kIHRoZXNlIG51bWJl cnMgYXJlIGdlbmVyYXRlZCBmcm9tIGEgcGFydGljdWxhciBwZXJzcGVjdGl2ZSBpbiB0aGUgbmV0 d29yayB0aGF0IG1pZ2h0IG5vdCByZXByZXNlbnQgYWxsIHBlcnNwZWN0aXZlcyBhY2N1cmF0ZWx5 LCBidXQgdGhleSBjYXB0dXJlIGEgcm91Z2ggcGljdHVyZSB0aGF0J3MgZ29vZCBlbm91Z2ggZm9y IHRoaXMgZGlzY3Vzc2lvbiwgSSB0aGluay4pIE9mIHRoZSBkZS1hZ2dyZWdhdGVkIGFuZCBQSSBz cGFjZSB0aGF0IGV4aXN0cyBhcyByb3V0ZXMgaW4gdGhlIGdsb2JhbCB0YWJsZXMsIGEgc2lnbmlm aWNhbnQgcGFydCBvZiBpdCwgYW5kIHRoZSBtb3N0IGRpZmZpY3VsdCBwYXJ0IHRvIGFkZHJlc3Mg dGhyb3VnaCBlZHVjYXRpb24gYW5kIHBvbGljeSwgaXMgaW4gc3VwcG9ydCBvZiB0aGVzZSAyMGsg ZW5kIG5ldHdvcmtzLiBUaGV5IG5lZWQgZGUtYWdncmVnYXRlcyBhbmQvb3IgUEkgaW4gb3JkZXIg dG8gbWFpbnRhaW4gcmVkdW5kYW50IGNvbm5lY3Rpdml0eSwgYmVjYXVzZSB0aGVyZSBpc24ndCBh IGJldHRlciB0ZWNobmljYWwgc29sdXRpb24uIChVbmxlc3MgdGhleSB1c2UgTkFUIGFuZCBkb24n dCBtaW5kIGNvbm5lY3Rpb24gcmVzZXRzIG9uIGZhaWxJb3ZlcnMsIGV0Yy4pLiBJZiB3ZSBjYW4g Y29tZSB1cCB3aXRoIGEgZ29vZCBzb2x1dGlvbiB0byBtdWx0aWhvbWluZyB0aGF0IHJlbW92ZXMg dGhlIG5lZWQgZm9yIHRoZXNlIGVuZCBuZXR3b3JrcyB0byBwYXJ0aWNpcGF0ZSBpbiBnbG9iYWwg cm91dGluZyBldGMsIGFuZCBjaGFuZ2UgcG9saWN5IHNvIHRoYXQgaXQgcmVmbGVjdHMgdGhpcyBp biB0dXJuLCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIGNhbiBtYXRlcmlhbGx5IHJlZHVjZSB0YWJs ZSBzaXplIGFuZCByYXRlIG9mIGdyb3d0aC4gKEdlb2ZmLCBpdCB3YXMgc2FpZCB5b3Ugc3BlbmQg YWxsIG9mIHlvdXIgdGltZSBzdHVkeWluZyB0aGlzOyB3b3VsZCB5b3UgYWdyZWU/KTxCUj4NCjxC Uj4NClllcywgdGhlIHdheSBJIGVudmlzaW9uIHRoaXMgaXQgd291bGQgYmUgZmFyIGZyb20gYSBu ZXcgYXJjaGl0ZWN0dXJlLiBCdXQgaWYgaXQgc29sdmVzIHRoZSBpbW1lZGlhdGUgcHJvYmxlbSB0 aGVuIHRob3NlIG9mIHVzIHJ1bm5pbmcgbmV0d29ya3MgY2FuIGtlZXAgdGhlIG5ldHdvcmsgd29y a2luZywgYW5kIHRoaXMgbWFpbGluZyBsaXN0IGNhbiBjb250aW51ZSB0byBmdW5jdGlvbiBhcyBh IGZvcnVtIGZvciBhcmNoaXRlY3R1cmFsIGRpc2N1c3Npb24uJm5ic3A7IDspPEJSPg0KPEJSPg0K Q2hlZXJzLDxCUj4NCi1CZW5zb248QlI+DQooU2VudCBmcm9tIG15IEJsYWNrYmVycnkuLi4gU29y cnkgZm9yIHRodW1iLXR5cG9zKTxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KRnJvbTogTm9lbCBDaGlhcHBhPEJSPg0KVG86IGFyY2hp dGVjdHVyZS1kaXNjdXNzQGlldGYub3JnPEJSPg0KQ0M6IGpuY0BtZXJjdXJ5Lmxjcy5taXQuZWR1 PEJSPg0KU2VudDogU2F0IE5vdiAxMSAxMjoxNTo0OSAyMDA2PEJSPg0KU3ViamVjdDogUmU6IFth cmNoLWRdIEl0J3MgdGhlIHJvdXRpbmcsIHBlb3BsZSE8QlI+DQo8QlI+DQombmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBGcm9tOiBHZW9mZiBIdXN0b24gJmx0O2dpaEBhcG5pYy5uZXQmZ3Q7PEJSPg0K PEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSSBkb24ndCBzZWUgcm91dGluZyBtZWx0aW5n IHRvZGF5LjxCUj4NCjxCUj4NCkknbSBvbmx5IGhlcmUgYmVjYXVzZSBvdGhlciBwZW9wbGUgc2Vl bSB0byB0aGluayBpdCdzIGNvbWluZywgYW5kIHdhbnQgdG8gZ2V0PEJSPg0KbW92aW5nIG9uIGEg c29sdXRpb24uIElmIHRoZXJlIGlzIG5vIHByb2JsZW0sIHRoZW4gdGhpcyB3aG9sZSBkaXNjdXNz aW9uIGlzPEJSPg0KbW9vdCwgbm8/PEJSPg0KPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg SSBkb24ndCBuZWNlc3NhcmlseSBhY2NlcHQgdGhhdCBGSUIgbWVsdGRvd24gaXMgb25seSBwcmV2 ZW50ZWQgYnk8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjaGFuZ2luZyB0aGUgcm91dGlu ZyBwYXJhZGlnbSwgYXMgSSBzdGlsbCBkb24ndCBhY2NlcHQgdGhhdCBGSUIgPSBSSUIuPEJSPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSSBzZWUgdGhhdCBpZiBwZXIgcGFja2V0IHBlcmZvcm1h bmNlIGlzIGNyaXRpY2FsLCBhbmQgdGhhdCBhcHBlYXJzIHRvPEJSPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgYmUgdGhlIGNhc2UsIHRoZW4gdGhlIGxvb2t1cCBwZXJmb3JtZWQgcGVyIHBhY2tl dCBzaG91bGQgYmUgZmFzdC4gQnV0IEk8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBkb24n dCBhY2NlcHQgdGhhdCB0aGlzIG5lY2Vzc2FyaWx5IGltcGxpZXMgdGhhdCB5b3UgaGF2ZSB0byBw ZXJmb3JtPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhpcyBsb29rdXAgb3ZlciB0aGUg ZXF1aXZhbGVudCBvZiB0aGUgUklCIHN0dWZmZWQgaW50byBhIGZhc3QgbG9va3VwPEJSPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgZGF0YSBzdHJ1Y3R1cmUgdG8gZGVyaXZlIGFuIGFuc3dlciB0 aGF0IGlzIG9mIHRoZSBzYW1lIG9yZGVyIGFzIHRoZTxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IG51bWJlciBvZiBwaHlzaWNhbCBlZ3Jlc3MgY2hvaWNlcyBvbiB0aGUgYm94LjxCUj4NCjxC Uj4NCkknbSBub3QgdGhlIHBlcnNvbiB0byBiZSBkaXNjdXNzaW5nIHRoYXQgcG9pbnQgd2l0aC4g WW91IG5lZWQgdG8gdGFsayB0byB0aGU8QlI+DQpwZW9wbGUgd2hvIG1hZGUgdGhlIGNhc2UgYXQg dGhlIElBQiB3b3Jrc2hvcC4gQXBwYXJlbnRseSB0aGV5IGNvbnZpbmNlZCB0aGU8QlI+DQpwZW9w bGUgYXQgdGhlIHdvcmtzaG9wLCBidXQgbWF5YmUgeW91IHNlZSBzb21ldGhpbmcgdGhleSBkb24n dC4gSSByZWFkPEJSPg0KdGhyb3VnaCB0aGUgc2xpZGVzIGZyb20gdGhlIHdvcmtzaG9wLCBhbmQg dGhlIGNvbmNsdXNpb25zIHNlZW1lZCByZWFzb25hYmxlLDxCUj4NCmJ1dCBhZ2FpbiwgcGVyaGFw cyB5b3Ugc2VlIHNvbWV0aGluZyB0aGF0IGNoYW5nZXMgdGhpbmdzLjxCUj4NCjxCUj4NCkRvIHlv dSBoYXZlIHNvbWUgYXBwcm9hY2ggaW4gbWluZCB0aGF0IHdvcmtzIGRpZmZlcmVudGx5PyBJZiBz bywgY291bGQgeW91PEJSPg0KYXQgbGVhc3Qgc2tldGNoIGl0IG91dCBmb3IgdXMgYnJpZWZseSAt IGEgZnVsbC1ibG93biB3cml0ZXVwIGlzbid0IG5lY2Vzc2FyeS48QlI+DQo8QlI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBJIHN1c3BlY3QgdGhhdCBhIGJldHRlciB1bmRlcnN0YW5kaW5nIG9m IHRoZSBzZW1hbnRpY3Mgb2YgYWRkcmVzc2VzLDxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGFuZCB0aGUgZGlzdGluY3Rpb24gLi4gYWJvdXQgd2hhdCBhcmUgdGhlIGNoYXJhY3RlcmlzdGlj cyBvZiB0aGU8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBwYWNrZXQncyBzb3VyY2UgYW5k IGRlc3RpbmF0aW9uIHRhZywgYW5kIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhlc2UgdHdvPEJSPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGFncyB0byB0aGUgZm9yd2FyZGluZyBwYXRoIGFjcm9z cyB0aGUgbmV0d29yayBhcmUgdXNlZnVsIGluPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg dW5kZXJzdGFuZGluZyB0aGUgcmVsYXRpb25zaGlwIHRvIHRoZSBwcm9ibGVtIGJlaW5nIHByZXNl bnRlZCBoZXJlIGFuZDxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRoZSBkZWdyZWVzIG9m IGZyZWVkb20gaW4gdGhlIHN5bWJvbCBzcGFjZSB0aGF0IHdlIGNhbiBtYW5pcHVsYXRlIHRvPEJS Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcHJvdmlkZSBtaXRpZ2F0aW9uPEJSPg0KPEJSPg0K SSdtIG5vdCBzdXJlIEkgZnVsbHkgc2VlIHdoYXQgeW91IGFyZSBnZXR0aW5nIGF0IGhlcmUsIGJ1 dCB0aGlzIGtpbmQgb2Y8QlI+DQpkaXNjdXNzaW9uLCBhYm91dCBub3QganVzdCB0aGUgc2VtYW50 aWNzIG9mIGFkZHJlc3NlcywgYnV0IGFib3V0IGhvdyB0aG9zZTxCUj4NCnNlbWFudGljcyByZWxh dGUgdG8gdGhlIGNvbXB1dGF0aW9uIG9mIHBhdGhzIGFjcm9zcyB0aGUgY29ubmVjdGl2aXR5IGdy YXBoLDxCUj4NCndvdWxkIGJlIE9LLCBidXQgSSBkaWRuJ3QgaGVhciB0aGF0IGhhcHBlbmluZy48 QlI+DQo8QlI+DQpBZ2Fpbiwgc29tZXRoaW5nIHdpdGggYSBiaXQgbW9yZSBpbmZvcm1hdGlvbiBh cyB0byBzb21lIG5ldyBzY2hlbWUgd2hpY2ggeW91PEJSPg0KbWlnaHQgaGF2ZSBpbiBtaW5kIHdv dWxkIG1ha2UgaXQgcG9zc2libGUgdG8gZXhhbWluZSB0aGVzZSBpc3N1ZXMgeW91IHJhaXNlPEJS Pg0KYWJvdmUsIGJlY2F1c2UgYXQgdGhpcyBsZXZlbCBvZiBhYnN0cmFjdGlvbiBpdCdzIGhhcmQg dG8gZHJhdyBhbnkgZGVmaW5pdGU8QlI+DQpjb25jbHVzaW9ucy48QlI+DQo8QlI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm9lbDxCUj4NCjxCUj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KQXJjaGl0ZWN0 dXJlLWRpc2N1c3MgbWFpbGluZyBsaXN0PEJSPg0KQXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5v cmc8QlI+DQo8QSBIUkVGPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h cmNoaXRlY3R1cmUtZGlzY3VzcyI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3M8L0E+PEJSPg0KPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+ DQo8L0hUTUw+ ------_=_NextPart_001_01C705CE.A8F2024B-- --===============0219053663== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0219053663==-- From architecture-discuss-bounces@ietf.org Sat Nov 11 17:07:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0yo-0000Hm-LQ; Sat, 11 Nov 2006 17:05:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0yn-0000HU-AL for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:05:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj0yl-0000x2-Ul for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:05:37 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2006 14:05:35 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="343300745:sNHT54745232" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kABM5ZFZ022463; Sat, 11 Nov 2006 14:05:35 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kABM5Zio021810; Sat, 11 Nov 2006 14:05:35 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 14:05:35 -0800 Received: from [10.0.4.29] ([10.21.83.74]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 14:05:34 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 14:05:31 -0800 To: "Schliesser, Benson" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Nov 2006 22:05:34.0779 (UTC) FILETIME=[830AE8B0:01C705DD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2934; t=1163282735; x=1164146735; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20It's=20the=20routing,=20people! |Sender:=20; bh=XDOKZ1IcMupl4QZTV8xruWv8Wpglspi4be3FuHsplNI=; b=GwRTP77u2rMxu3/yXrftto7YXCIraj6xs1xgpZbrNGpGGw1FX3F3cGxORVhOFX1oTH5KZoRW j7GnMcs0SBkM+aTxqSSdPhmnmRyfopvblKF/iHR65+sCctI2FjAo71Gx; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 12:19 PM, Schliesser, Benson wrote: > > >> I don't see routing melting today. > > I'm only here because other people seem to think > > it's coming, and want to get > > moving on a solution. > > I don't want to derail the broader architectural discussion, which > I think is valuable. But let me point out something directly > related to the engineering problem we face in the routing system: > Of the approx 23k ASs in the global routing system, only 3k are > transit ASs. The other 20k systems are basically end networks that > multihome. actually, I asked Geoff about this, and he told me that ~15K AS's had only one upstream AS, meaning that only ~8K have more than one (multihome at the BGP level) and (per you) only ~3K of those have "many" peer and upstream AS's. > If we can come up with a good solution to multihoming that removes > the need for these end networks to participate in global routing > etc, and change policy so that it reflects this in turn, it seems > to me that we can materially reduce table size and rate of growth. > (Geoff, it was said you spend all of your time studying this; would > you agree?) > > Yes, the way I envision this it would be far from a new > architecture. But if it solves the immediate problem then those of > us running networks can keep the network working, and this mailing > list can continue to function as a forum for architectural > discussion. ;) I would generally agree, and the interesting thing is that one doesn't really need a pitch-it-all-and-redo architecture change to accomplish that. It means that you either want a model in which every upstream assigns a part of its own prefix to each of its downstreams and every host on every interface has an address from each of the relevant ISPs (which is a characteristic of both shim6 and GSE, although they are implemented very differently), or that somehow a prefix is assigned to an agreeable set of edge networks that can use that prefix across multiple ISPs (which is a characteristic of Metro). http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis tries to do something of an analysis of those from a technical perspective based on RFC 3582. Bottom line, if one does an analysis of the approach and can enumerate the number of prefixes in the backbone and comes up with a number on the order of 10^4 or 10^5, we have accomplished something important. The one thing we know for sure is that PI addressing doesn't do that. This is why I keep asking for that analysis. I think it's important enough to not be hand-waved. What I have concluded from various discussions is that the entire requirements set isn't on the table, though. I hear a lot about traffic engineering, for example, but don't see an RFC-3582-like set of assertions on that topic. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 17:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj18g-0004gg-Rl; Sat, 11 Nov 2006 17:15:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj18f-0004eF-5J for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:15:49 -0500 Received: from webmail.tropos.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gj18d-0005a1-Oe for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:15:49 -0500 Received: (qmail 24241 invoked from network); 11 Nov 2006 22:15:47 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 11 Nov 2006 22:15:47 -0000 Received: from LIPC ([192.168.1.157]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 14:15:46 -0800 From: "Tony Li" To: "'Fred Baker'" , "'Schliesser, Benson'" Subject: RE: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 14:15:44 -0800 Message-ID: <004701c705de$ee620bb0$9d01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccF3Z3/gq02dlX8TPyc5Z9+QDbAjQAAQkDw X-OriginalArrivalTime: 11 Nov 2006 22:15:46.0631 (UTC) FILETIME=[EFBC1D70:01C705DE] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > actually, I asked Geoff about this, and he told me that ~15K > AS's had > only one upstream AS, Only one that Geoff could see from his vantage point? Or only one period? If the latter, that would be an indication that RIR's and others are being conned into giving out ASNs and prefixes for PI purposes for singly homed customers. ;-( Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 17:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1IF-0000a2-HR; Sat, 11 Nov 2006 17:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1IE-0000Zq-4K for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:25:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj1IB-0001RC-HY for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:25:42 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2006 14:25:37 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="1291364:sNHT7116611994" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kABMPalb029285; Sat, 11 Nov 2006 14:25:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kABMPaio027315; Sat, 11 Nov 2006 14:25:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 14:25:36 -0800 Received: from [10.0.4.29] ([10.21.83.74]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 14:25:36 -0800 In-Reply-To: <004701c705de$ee620bb0$9d01a8c0@tropos.com> References: <004701c705de$ee620bb0$9d01a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4483002D-8718-4169-9D90-12992C1FAF73@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 14:25:35 -0800 To: X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Nov 2006 22:25:36.0028 (UTC) FILETIME=[4F0AF5C0:01C705E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=168; t=1163283936; x=1164147936; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20It's=20the=20routing,=20people! |Sender:=20; bh=R+7vPTjPsH4cCirjo3fd5ZFFNK+3rgZhruTvt4vzlzU=; b=Ga4xbWLosIVWpnnulq4a/5Jm1Yb0GzZK/wfnwPC3FJF2Xf0T7EKOu3SGH4zQqGTPbWeS9+tW Zy8NtMVjVJYyTaauqeknoqnk6oaK8fuuSeyqU55KwTAA3jfm1B9tDfri; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 2:15 PM, Tony Li wrote: > Only one that Geoff could see from his vantage point? Or only one > period? Geoff would have to answer that... _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 17:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1Ki-0002LZ-1g; Sat, 11 Nov 2006 17:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1Kg-0002LU-Mo for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:28:14 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj1Kc-0002ia-Vp for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:28:14 -0500 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kABMRH5S088848; Sun, 12 Nov 2006 09:27:17 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061112092032.01413960@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 12 Nov 2006 09:27:13 +1100 To: tony.li@tony.li, "'Fred Baker'" , "'Schliesser, Benson'" From: Geoff Huston Subject: RE: [arch-d] It's the routing, people! In-Reply-To: <004701c705de$ee620bb0$9d01a8c0@tropos.com> References: <004701c705de$ee620bb0$9d01a8c0@tropos.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 09:15 AM 12/11/2006, Tony Li wrote: > > > > actually, I asked Geoff about this, and he told me that ~15K > > AS's had > > only one upstream AS, > >Only one that Geoff could see from his vantage point? Or only one >period? > >If the latter, that would be an indication that RIR's and others are >being conned into giving out ASNs and prefixes for PI purposes for >singly homed customers. ;-( Its a property of BGP that you can't see a 'private" peer BGP connection unless you look from the vantage point of both of the peering AS's or see the table from the perspectives of a customer of both entities. These "no upstream transit" peering arrangements are simply occluded from the view of everyone else. Now Fred described this as something subtly different - he said "upstream AS". i.e. transit AS, and this is indeed something you can look at and measure a subset of and look over the longer term and make a reasonable estimate on what is missing. I'll stand by the measured numbers quoted above as being very close to whats out there for transit upstream. But transit upstream is not the same as AS-to-AS peering, and the numbers relating to AS-to-AS eBGP peering on any basis, including but not limited to transit upstream are probably higher. but unless you release a pervasive router bot that sends you back local RIB snapshots, it becomes a bit of a challenge to gather the raw data that would substantiate any number in any more reliable way than any other number!. Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 17:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1TR-0007iu-7x; Sat, 11 Nov 2006 17:37:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1TQ-0007hn-5M for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:37:16 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj1TP-0005aM-TT for architecture-discuss@ietf.org; Sat, 11 Nov 2006 17:37:16 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kABMZNgk082069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Nov 2006 23:35:24 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 23:37:07 +0100 To: "Schliesser, Benson" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_BANG autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 11-nov-2006, at 21:19, Schliesser, Benson wrote: > Of the approx 23k ASs in the global routing system, only 3k are > transit ASs. The other 20k systems are basically end networks that > multihome. [...] > If we can come up with a good solution to multihoming that removes > the need for these end networks to participate in global routing > etc, and change policy so that it reflects this in turn, it seems > to me that we can materially reduce table size and rate of growth. How can that be true? There are some 200k prefixes in the global table. If there are indeed 20k multihomers, that means only 10% of the global routing table can be attributed to multihoming, as multihoming functionality only requires a single prefix per multihomed AS. (Please note that my statement doesn't preclude people from announcing more prefixes for other reasons once they're multihomed.) So _today_ the majority of the routing table size/growth is not the result of multihoming. However, this doesn't mean that it couldn't be in the future, as other factors that contribute to large routing tables will become less important over time and/or in IPv6. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 18:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1v0-0006s9-Kp; Sat, 11 Nov 2006 18:05:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1uy-0006qW-T7 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 18:05:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj1ux-0001sv-Jr for architecture-discuss@ietf.org; Sat, 11 Nov 2006 18:05:44 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2006 15:05:37 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208"; a="343315141:sNHT15898181302" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kABN5bxK028255; Sat, 11 Nov 2006 15:05:37 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kABN5aio006282; Sat, 11 Nov 2006 15:05:36 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 15:05:36 -0800 Received: from [10.0.4.29] ([10.21.83.74]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 15:05:36 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <092DA27E-1DD2-4EBD-BA9B-10573FD2D1E8@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 15:05:27 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 11 Nov 2006 23:05:36.0231 (UTC) FILETIME=[E5ACDF70:01C705E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1106; t=1163286337; x=1164150337; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20It's=20the=20routing,=20people! |Sender:=20; bh=midlsKRYhiM8HPVQlUfyvZn/huqyj3urYX+PXEtMf2E=; b=WYR+VHOEJ8gRPX8Ly6aD2c/9Ry1qSRV8s2hY2CRrpAfDrE2CLxZ5DB8N7Mav0pd8gXSSdHLH 8tulVUJHbUAA/1NzQUn/ULSD2ox/I7Pj4Ndf8+NC0u5GGc34Oqplkpub; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 2:37 PM, Iljitsch van Beijnum wrote: > How can that be true? There are some 200k prefixes in the global > table. If there are indeed 20k multihomers, that means only 10% of > the global routing table can be attributed to multihoming, as > multihoming functionality only requires a single prefix per > multihomed AS. (Please note that my statement doesn't preclude > people from announcing more prefixes for other reasons once they're > multihomed.) > > So _today_ the majority of the routing table size/growth is not the > result of multihoming. The "BGP Update Report" I received a few days ago told me that roughly half of the prefixes advertised in the backbone are longer than their allocation length. That tells me one of two things, both of which are probably true to some extent. Some percentage of these prefixes derive from multihoming, some percentage from traffic engineering, and some percentage from errors and incompetence. If I were betting money, I would put it on multihoming and traffic engineering, not stupidity. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 18:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2SM-0004Bx-KF; Sat, 11 Nov 2006 18:40:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2SL-0004Bp-Aj for architecture-discuss@ietf.org; Sat, 11 Nov 2006 18:40:13 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj2SK-0007lE-0J for architecture-discuss@ietf.org; Sat, 11 Nov 2006 18:40:13 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kABNc1xt083394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Nov 2006 00:38:02 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <092DA27E-1DD2-4EBD-BA9B-10573FD2D1E8@cisco.com> References: <092DA27E-1DD2-4EBD-BA9B-10573FD2D1E8@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E5CC8D3-8EBF-4458-9C1B-A9F094D8432F@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 00:39:45 +0100 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_BANG autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 64592953d6410e1f725ee21266e2f396 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12-nov-2006, at 0:05, Fred Baker wrote: > The "BGP Update Report" I received a few days ago told me that > roughly half of the prefixes advertised in the backbone are longer > than their allocation length. That tells me one of two things, both > of which are probably true to some extent. Some percentage of these > prefixes derive from multihoming, How does multihoming follow from prefixes longer than the allocation size being advertised? > some percentage from traffic engineering, and some percentage from > errors and incompetence. If I were betting money, I would put it on > multihoming and traffic engineering, not stupidity. Well, I guess it's not stupidity if the offenders know better but just can't be bothered... But in what twisted universe does the following make sense? This AS is singlehandedly responsible for more than 1% of the global routing table, and from where I'm sitting, there is no evidence of them doing any kind of traffic engineering. Network Next Hop Metric LocPrf Weight Path *>i64.134.0.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.0.0/17 212.72.45.57 0 100 0 3356 14654 i *>i64.134.0.0/16 212.72.45.57 0 100 0 3356 14654 i *>i64.134.1.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.2.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.3.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.4.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.5.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.6.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.7.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.8.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.9.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.11.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.12.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.13.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.14.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.15.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.16.0/22 212.72.45.57 0 100 0 3356 14654 i *>i64.134.20.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.22.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.23.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.24.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.26.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.27.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.28.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.29.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.30.0/23 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i64.134.32.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.35.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.36.0/22 212.72.45.57 0 100 0 3356 14654 i *>i64.134.38.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.39.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.40.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.41.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.42.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.44.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.47.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.48.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.49.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.50.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.52.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.53.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.54.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.55.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.58.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.59.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.60.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.61.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.62.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.64.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.65.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.66.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.68.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.69.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.70.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.71.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.72.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.73.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.74.0/24 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i64.134.75.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.76.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.78.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.79.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.80.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.81.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.82.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.83.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.84.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.85.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.87.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.90.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.91.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.92.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.93.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.94.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.95.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.96.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.97.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.98.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.99.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.101.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.102.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.103.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.104.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.105.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.106.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.108.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.109.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.110.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.115.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.116.0/24 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i64.134.117.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.118.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.119.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.120.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.121.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.122.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.123.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.124.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.125.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.126.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.127.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.129.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.130.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.131.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.132.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.133.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.134.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.135.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.136.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.137.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.140.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.141.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.142.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.143.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.144.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.145.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.149.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.150.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.151.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.152.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.154.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.155.0/24 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i64.134.156.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.158.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.159.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.160.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.161.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.162.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.163.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.166.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.170.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.172.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.174.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.175.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.176.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.177.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.178.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.179.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.180.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.181.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.182.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.183.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.184.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.186.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.187.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.189.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.190.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.192.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.196.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.199.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.200.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.201.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.202.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.203.0/24 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i64.134.204.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.206.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.207.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.209.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.210.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.211.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.212.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.214.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.215.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.216.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.217.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.218.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.220.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.221.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.223.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.224.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.225.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.227.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.228.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.229.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.230.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.231.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.232.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.233.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.234.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.237.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.238.0/23 212.72.45.57 0 100 0 3356 14654 i *>i64.134.240.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.241.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.243.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.244.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.245.0/24 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i64.134.248.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.251.0/24 212.72.45.57 0 100 0 3356 14654 i *>i64.134.252.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.192.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.192.0/19 212.72.45.57 0 100 0 3356 14654 i *>i65.74.192.0/18 212.72.45.57 0 100 0 3356 14654 i *>i65.74.193.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.194.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.195.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.196.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.197.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.198.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.199.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.200.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.201.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.202.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.203.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.204.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.205.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.206.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.207.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.208.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.210.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.214.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.215.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.218.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.221.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.222.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.224.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.224.0/19 212.72.45.57 0 100 0 3356 14654 i *>i65.74.225.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.226.0/24 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i65.74.227.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.228.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.237.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.239.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.240.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.241.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.242.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.243.0/24 212.72.45.57 0 100 0 3356 14654 i *>i65.74.244.0/22 212.72.45.57 0 100 0 3356 14654 i *>i65.74.250.0/23 212.72.45.57 0 100 0 3356 14654 i *>i65.74.252.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.0.0/16 212.72.45.57 0 100 0 3356 14654 i *>i206.59.12.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.24.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.28.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.32.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.40.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.44.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.48.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.51.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.52.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.53.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.54.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.55.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.56.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.58.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.60.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.64.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.72.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.79.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.84.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.92.0/22 212.72.45.57 0 100 0 3356 14654 i Network Next Hop Metric LocPrf Weight Path *>i206.59.96.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.98.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.100.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.104.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.120.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.130.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.132.0/22 212.72.45.57 0 100 0 3356 14654 i *>i206.59.144.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.232.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.234.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.236.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.238.0/23 212.72.45.57 0 100 0 3356 14654 i *>i206.59.241.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.242.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.243.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.244.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.245.0 212.72.45.57 0 100 0 3356 14654 i *>i206.59.247.0 212.72.45.57 0 100 0 3356 14654 i *>i216.12.224.0/19 212.72.45.57 0 100 0 3356 14654 i *>i216.12.227.0 212.72.45.57 0 100 0 3356 14654 i *>i216.12.250.0/23 212.72.45.57 0 100 0 3356 14654 i _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 19:20:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj331-000874-Mj; Sat, 11 Nov 2006 19:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj331-00086z-BG for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:18:07 -0500 Received: from www.woodynet.net ([204.61.208.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj32y-0006J2-Ot for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:18:07 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net [24.125.117.214]) (authenticated bits=0) by www.woodynet.net (8.12.10/8.12.10) with ESMTP id kAC0PEDe000786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Nov 2006 16:25:16 -0800 (PST) In-Reply-To: <004701c705de$ee620bb0$9d01a8c0@tropos.com> References: <004701c705de$ee620bb0$9d01a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tom Vest Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 19:17:00 -0500 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 5:15 PM, Tony Li wrote: >> actually, I asked Geoff about this, and he told me that ~15K >> AS's had only one upstream AS, >> > > Only one that Geoff could see from his vantage point? Or only one > period? > > If the latter, that would be an indication that RIR's and others are > being conned into giving out ASNs and prefixes for PI purposes for > singly homed customers. ;-( > > Tony > This issue is not unknown, and plausibly (personal speculation only) is one of the reasons behind the ARIN "policy reinterpretation" of 12 Feb 2006: http://www.arin.net/announcements/archives/20060222.html The issue has troubled me for some time also. No doubt some of the apparent single-homers have private AS adjacencies that don't show up, e.g., in Route Views. Hard to imagine this explaining away close to 15k ASes -- all but about 225 of which post-date RFC 1930, the RIRs, et al. Casual inquiries with the three old RIRs suggest that "very few" ASNs have been allocated on the basis of RFC 2270... Tom Vest _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 19:40:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj3Mx-0000tG-Br; Sat, 11 Nov 2006 19:38:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj3Mv-0000kw-CI for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:38:41 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gj3BO-00006y-7C for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:26:47 -0500 Received: (qmail 4033 invoked from network); 12 Nov 2006 00:26:37 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 12 Nov 2006 00:26:37 -0000 Received: from LIPC ([192.168.1.157]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 16:26:36 -0800 From: "Tony Li" To: "'Iljitsch van Beijnum'" , "'Schliesser, Benson'" Subject: RE: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 16:26:32 -0800 Message-ID: <004901c705f1$34724630$9d01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccF4fwtZ5P1HATFTwuQ4+jvJfiHswADt3FA X-OriginalArrivalTime: 12 Nov 2006 00:26:36.0962 (UTC) FILETIME=[36E59020:01C705F1] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > If we can come up with a good solution to multihoming that removes > > the need for these end networks to participate in global routing > > etc, and change policy so that it reflects this in turn, it seems > > to me that we can materially reduce table size and rate of growth. > > How can that be true? There are some 200k prefixes in the global > table. If there are indeed 20k multihomers, that means only 10% of > the global routing table can be attributed to multihoming, as > multihoming functionality only requires a single prefix per > multihomed AS. Interestingly, multihoming was about 10% of the routing table in 1992, as well. It would seem to me that if we could reduce the growth due to a) TE, b) multihoming, and c) fraudulent PI allocations, then we would have an impact on the growth rate. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 20:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj3kn-0000Fj-R3; Sat, 11 Nov 2006 20:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj3km-0000Fe-An for architecture-discuss@ietf.org; Sat, 11 Nov 2006 20:03:20 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj3kl-0004DW-4p for architecture-discuss@ietf.org; Sat, 11 Nov 2006 20:03:20 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BCBEC872C9; Sat, 11 Nov 2006 20:03:18 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] It's the routing, people! Message-Id: <20061112010318.BCBEC872C9@mercury.lcs.mit.edu> Date: Sat, 11 Nov 2006 20:03:18 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Tony Li" > Interestingly, multihoming was about 10% of the routing table in 1992, > as well. It would seem to me that if we could reduce the growth due to > .. multihoming, .. then we would have an impact on the growth rate. You raise an interesting point. I don't think there's any way in the routing alone to support multi-homing in a way which reduces table growth (at least as long as the only scope we have for advertisements, other than "local", is "global"). To support multi-homing without impacting the routing, it seems that the way to go is have multiple locators for each multi-homed entity (which is the way Multi6 eventually went, with Shim6, but nobody likes the mechanism). So if we do, say GSE, how do we make multi-homing work, using multiple addresses? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 20:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj42u-00021K-Tk; Sat, 11 Nov 2006 20:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj42t-00020n-Hl for architecture-discuss@ietf.org; Sat, 11 Nov 2006 20:22:03 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj3yp-00026Z-S4 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 20:17:53 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 19:17:51 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 19:17:51 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccF4fIwqEHkRpo/Q/iL1Gsqi1IkPQAFmzcQ From: "Schliesser, Benson" To: X-OriginalArrivalTime: 12 Nov 2006 01:17:51.0573 (UTC) FILETIME=[5F81F850:01C705F8] X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1505628606==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============1505628606== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C705F8.5F4009C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C705F8.5F4009C4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpFeGNlcHQsIHdpdGggSVB2NCBlYWNoIEFTIGNvdWxkIGVhc2lseSBiZSBhbGxvY2F0ZWQgbXVs dGlwbGUgKG5vbi1jb250aWd1b3VzLCBub24tYWdncmVnYXRlYWJsZSkgcHJlZml4ZXMsIGZvciBp bnN0YW5jZSBhcyB0aGV5IGdyb3cgb3ZlciB0aW1lLiBXaXRoIHY2IGl0IHdvdWxkbid0IG5lY2Vz c2FyaWx5IGhhdmUgdG8gYmUgdGhhdCB3YXkuDQoNCkNoZWVycywNCi1CZW5zb24NCg0KDQogDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJbGppdHNjaCB2YW4gQmVpam51bQ0K VG86IFNjaGxpZXNzZXIsIEJlbnNvbg0KQ0M6IGFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3Jn DQpTZW50OiBTYXQgTm92IDExIDE2OjM3OjA3IDIwMDYNClN1YmplY3Q6IFJlOiBbYXJjaC1kXSBJ dCdzIHRoZSByb3V0aW5nLCBwZW9wbGUhDQoNCk9uIDExLW5vdi0yMDA2LCBhdCAyMToxOSwgU2No bGllc3NlciwgQmVuc29uIHdyb3RlOg0KDQo+IE9mIHRoZSBhcHByb3ggMjNrIEFTcyBpbiB0aGUg Z2xvYmFsIHJvdXRpbmcgc3lzdGVtLCBvbmx5IDNrIGFyZSAgDQo+IHRyYW5zaXQgQVNzLiBUaGUg b3RoZXIgMjBrIHN5c3RlbXMgYXJlIGJhc2ljYWxseSBlbmQgbmV0d29ya3MgdGhhdCAgDQo+IG11 bHRpaG9tZS4NCg0KWy4uLl0NCg0KPiBJZiB3ZSBjYW4gY29tZSB1cCB3aXRoIGEgZ29vZCBzb2x1 dGlvbiB0byBtdWx0aWhvbWluZyB0aGF0IHJlbW92ZXMgIA0KPiB0aGUgbmVlZCBmb3IgdGhlc2Ug ZW5kIG5ldHdvcmtzIHRvIHBhcnRpY2lwYXRlIGluIGdsb2JhbCByb3V0aW5nICANCj4gZXRjLCBh bmQgY2hhbmdlIHBvbGljeSBzbyB0aGF0IGl0IHJlZmxlY3RzIHRoaXMgaW4gdHVybiwgaXQgc2Vl bXMgIA0KPiB0byBtZSB0aGF0IHdlIGNhbiBtYXRlcmlhbGx5IHJlZHVjZSB0YWJsZSBzaXplIGFu ZCByYXRlIG9mIGdyb3d0aC4NCg0KSG93IGNhbiB0aGF0IGJlIHRydWU/IFRoZXJlIGFyZSBzb21l IDIwMGsgcHJlZml4ZXMgaW4gdGhlIGdsb2JhbCAgDQp0YWJsZS4gSWYgdGhlcmUgYXJlIGluZGVl ZCAyMGsgbXVsdGlob21lcnMsIHRoYXQgbWVhbnMgb25seSAxMCUgb2YgIA0KdGhlIGdsb2JhbCBy b3V0aW5nIHRhYmxlIGNhbiBiZSBhdHRyaWJ1dGVkIHRvIG11bHRpaG9taW5nLCBhcyAgDQptdWx0 aWhvbWluZyBmdW5jdGlvbmFsaXR5IG9ubHkgcmVxdWlyZXMgYSBzaW5nbGUgcHJlZml4IHBlciAg DQptdWx0aWhvbWVkIEFTLiAoUGxlYXNlIG5vdGUgdGhhdCBteSBzdGF0ZW1lbnQgZG9lc24ndCBw cmVjbHVkZSBwZW9wbGUgIA0KZnJvbSBhbm5vdW5jaW5nIG1vcmUgcHJlZml4ZXMgZm9yIG90aGVy IHJlYXNvbnMgb25jZSB0aGV5J3JlICANCm11bHRpaG9tZWQuKQ0KDQpTbyBfdG9kYXlfIHRoZSBt YWpvcml0eSBvZiB0aGUgcm91dGluZyB0YWJsZSBzaXplL2dyb3d0aCBpcyBub3QgdGhlICANCnJl c3VsdCBvZiBtdWx0aWhvbWluZy4gSG93ZXZlciwgdGhpcyBkb2Vzbid0IG1lYW4gdGhhdCBpdCBj b3VsZG4ndCBiZSAgDQppbiB0aGUgZnV0dXJlLCBhcyBvdGhlciBmYWN0b3JzIHRoYXQgY29udHJp YnV0ZSB0byBsYXJnZSByb3V0aW5nICANCnRhYmxlcyB3aWxsIGJlY29tZSBsZXNzIGltcG9ydGFu dCBvdmVyIHRpbWUgYW5kL29yIGluIElQdjYuDQo= ------_=_NextPart_001_01C705F8.5F4009C4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41LjcyMzQuMyI+DQo8VElUTEU+UmU6IFthcmNoLWRd IEl0J3MgdGhlIHJvdXRpbmcsIHBlb3BsZSE8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0t IENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KPEJSPg0KDQo8UD48Rk9OVCBT SVpFPTI+RXhjZXB0LCB3aXRoIElQdjQgZWFjaCBBUyBjb3VsZCBlYXNpbHkgYmUgYWxsb2NhdGVk IG11bHRpcGxlIChub24tY29udGlndW91cywgbm9uLWFnZ3JlZ2F0ZWFibGUpIHByZWZpeGVzLCBm b3IgaW5zdGFuY2UgYXMgdGhleSBncm93IG92ZXIgdGltZS4gV2l0aCB2NiBpdCB3b3VsZG4ndCBu ZWNlc3NhcmlseSBoYXZlIHRvIGJlIHRoYXQgd2F5LjxCUj4NCjxCUj4NCkNoZWVycyw8QlI+DQot QmVuc29uPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08QlI+DQpGcm9tOiBJbGppdHNjaCB2YW4gQmVpam51bTxCUj4NClRvOiBTY2hsaWVzc2Vy LCBCZW5zb248QlI+DQpDQzogYXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmc8QlI+DQpTZW50 OiBTYXQgTm92IDExIDE2OjM3OjA3IDIwMDY8QlI+DQpTdWJqZWN0OiBSZTogW2FyY2gtZF0gSXQn cyB0aGUgcm91dGluZywgcGVvcGxlITxCUj4NCjxCUj4NCk9uIDExLW5vdi0yMDA2LCBhdCAyMTox OSwgU2NobGllc3NlciwgQmVuc29uIHdyb3RlOjxCUj4NCjxCUj4NCiZndDsgT2YgdGhlIGFwcHJv eCAyM2sgQVNzIGluIHRoZSBnbG9iYWwgcm91dGluZyBzeXN0ZW0sIG9ubHkgM2sgYXJlJm5ic3A7 PEJSPg0KJmd0OyB0cmFuc2l0IEFTcy4gVGhlIG90aGVyIDIwayBzeXN0ZW1zIGFyZSBiYXNpY2Fs bHkgZW5kIG5ldHdvcmtzIHRoYXQmbmJzcDs8QlI+DQomZ3Q7IG11bHRpaG9tZS48QlI+DQo8QlI+ DQpbLi4uXTxCUj4NCjxCUj4NCiZndDsgSWYgd2UgY2FuIGNvbWUgdXAgd2l0aCBhIGdvb2Qgc29s dXRpb24gdG8gbXVsdGlob21pbmcgdGhhdCByZW1vdmVzJm5ic3A7PEJSPg0KJmd0OyB0aGUgbmVl ZCBmb3IgdGhlc2UgZW5kIG5ldHdvcmtzIHRvIHBhcnRpY2lwYXRlIGluIGdsb2JhbCByb3V0aW5n Jm5ic3A7PEJSPg0KJmd0OyBldGMsIGFuZCBjaGFuZ2UgcG9saWN5IHNvIHRoYXQgaXQgcmVmbGVj dHMgdGhpcyBpbiB0dXJuLCBpdCBzZWVtcyZuYnNwOzxCUj4NCiZndDsgdG8gbWUgdGhhdCB3ZSBj YW4gbWF0ZXJpYWxseSByZWR1Y2UgdGFibGUgc2l6ZSBhbmQgcmF0ZSBvZiBncm93dGguPEJSPg0K PEJSPg0KSG93IGNhbiB0aGF0IGJlIHRydWU/IFRoZXJlIGFyZSBzb21lIDIwMGsgcHJlZml4ZXMg aW4gdGhlIGdsb2JhbCZuYnNwOzxCUj4NCnRhYmxlLiBJZiB0aGVyZSBhcmUgaW5kZWVkIDIwayBt dWx0aWhvbWVycywgdGhhdCBtZWFucyBvbmx5IDEwJSBvZiZuYnNwOzxCUj4NCnRoZSBnbG9iYWwg cm91dGluZyB0YWJsZSBjYW4gYmUgYXR0cmlidXRlZCB0byBtdWx0aWhvbWluZywgYXMmbmJzcDs8 QlI+DQptdWx0aWhvbWluZyBmdW5jdGlvbmFsaXR5IG9ubHkgcmVxdWlyZXMgYSBzaW5nbGUgcHJl Zml4IHBlciZuYnNwOzxCUj4NCm11bHRpaG9tZWQgQVMuIChQbGVhc2Ugbm90ZSB0aGF0IG15IHN0 YXRlbWVudCBkb2Vzbid0IHByZWNsdWRlIHBlb3BsZSZuYnNwOzxCUj4NCmZyb20gYW5ub3VuY2lu ZyBtb3JlIHByZWZpeGVzIGZvciBvdGhlciByZWFzb25zIG9uY2UgdGhleSdyZSZuYnNwOzxCUj4N Cm11bHRpaG9tZWQuKTxCUj4NCjxCUj4NClNvIF90b2RheV8gdGhlIG1ham9yaXR5IG9mIHRoZSBy b3V0aW5nIHRhYmxlIHNpemUvZ3Jvd3RoIGlzIG5vdCB0aGUmbmJzcDs8QlI+DQpyZXN1bHQgb2Yg bXVsdGlob21pbmcuIEhvd2V2ZXIsIHRoaXMgZG9lc24ndCBtZWFuIHRoYXQgaXQgY291bGRuJ3Qg YmUmbmJzcDs8QlI+DQppbiB0aGUgZnV0dXJlLCBhcyBvdGhlciBmYWN0b3JzIHRoYXQgY29udHJp YnV0ZSB0byBsYXJnZSByb3V0aW5nJm5ic3A7PEJSPg0KdGFibGVzIHdpbGwgYmVjb21lIGxlc3Mg aW1wb3J0YW50IG92ZXIgdGltZSBhbmQvb3IgaW4gSVB2Ni48QlI+DQo8L0ZPTlQ+DQo8L1A+DQoN CjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C705F8.5F4009C4-- --===============1505628606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1505628606==-- From architecture-discuss-bounces@ietf.org Sat Nov 11 20:29:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj43C-0002CD-OM; Sat, 11 Nov 2006 20:22:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj43B-00029S-LM for architecture-discuss@ietf.org; Sat, 11 Nov 2006 20:22:21 -0500 Received: from webmail.tropos.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gj3ux-0000WJ-00 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 20:13:52 -0500 Received: (qmail 8464 invoked from network); 12 Nov 2006 01:13:50 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 12 Nov 2006 01:13:50 -0000 Received: from LIPC ([192.168.1.157]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 17:13:49 -0800 From: "Tony Li" To: "'Noel Chiappa'" , Subject: RE: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 17:13:38 -0800 Message-ID: <004a01c705f7$c8b9f6c0$9d01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20061112010318.BCBEC872C9@mercury.lcs.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccF9lkzxWe6Lk4/TzCTkGasDzMo0QAAS4/w X-OriginalArrivalTime: 12 Nov 2006 01:13:49.0840 (UTC) FILETIME=[CF6C7100:01C705F7] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > I don't think there's any way in the routing alone to support > multi-homing in > a way which reduces table growth (at least as long as the > only scope we have > for advertisements, other than "local", is "global"). To > support multi-homing > without impacting the routing, it seems that the way to go is > have multiple > locators for each multi-homed entity (which is the way Multi6 > eventually > went, with Shim6, but nobody likes the mechanism). So if we > do, say GSE, how > do we make multi-homing work, using multiple addresses? In my mind, that's one of the primary benefits of any loc/id split. Multiple locators per-site, with locator replacement at the border. I've always thought of this as being one of the primary applications of GSE. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 11 21:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj5GR-0008VR-Vf; Sat, 11 Nov 2006 21:40:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj5GQ-0008VF-LQ for architecture-discuss@ietf.org; Sat, 11 Nov 2006 21:40:06 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj5GQ-0001A6-4o for architecture-discuss@ietf.org; Sat, 11 Nov 2006 21:40:06 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 20:40:05 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 20:40:05 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccF3YP+hr0d+vhMR/Kr+6XeRcP1zwAJlfsi From: "Schliesser, Benson" To: X-OriginalArrivalTime: 12 Nov 2006 02:40:05.0821 (UTC) FILETIME=[DC8C76D0:01C70603] X-Spam-Score: 0.3 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0235928893==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0235928893== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70603.DC489A89" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70603.DC489A89 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGFzc3VtZSBHZW9mZiBjYW4gY29ycmVjdCBtZSBvbiB0aGlzLCBidXQgbXkgZ3V0IHJlc3Bv bnNlIHRvIHRoZSAxNWsgbnVtYmVyIGlzIHRoYXQgc29tZSB2aXNpYmlsaXR5IGlzIHByb2JhYmx5 IG1pc3NpbmcuIEkuZS4gVGhvc2UgQVNzIG1heSBiZSBtdWx0aWhvbWVkLCBhbmQgdGhlIGFuYWx5 c2lzIHRvb2xzIGp1c3QgZG9uJ3Qgc2VlIHRoZSBzZWNvbmRhcnkgcGF0aChzKSB0byB0aGVpciBw cmVmaXhlcy4NCg0KU29tZSBJU1BzIHRoYXQgYXNzaWduIHRvIHRoZWlyIGN1c3RvbWVycyBmcm9t IGEgbGFyZ2VyIGFsbG9jYXRpb24gZW5mb3JjZSBhZ2dyZWdhdGlvbiwgd2hpY2ggbWFrZXMgb3Jp Z2luIGFuYWx5c2lzIGxlc3Mgb2J2aW91cy4gKFRob3VnaCB0aGlzIGlzbid0IG9mdGVuIGEgZ29v ZCBpZGVhLCBhbmQgaXQncyBsaWtlbHkgdGhhdCByZXNlYXJjaGVycyB0aG91Z2h0IG9mIHRoaXMp IE1vcmUgdHJpY2t5LCBhbmQgbW9yZSBsaWtlbHkgdGhlIGlzc3VlIHdpdGggdmlzaWJpbGl0eSwg aXMgdGhhdCBsb2NhbCBwb2xpY3kgaW4gdHJhbnNpdCBBU3MgbWF5IG5vdCBzaGFyZSBtb3JlIHNw ZWNpZmljIHByZWZpeGVzIG9yIHBhcnRpY3VsYXIgQVMtcGF0aHMgd2l0aCBjdXN0b21lcnMsIG9y IHdpdGggcGVlcnMsIG9yIGhvd2V2ZXIgaXQgc2VydmVzIHRoZWlyIGJ1c2luZXNzIGJlc3QuICgi VGllciAyIiBwcm92aWRlcnMgYXJlIGluIHNvbWUgY2FzZXMgZmluYW5jaWFsbHkgbW90aXZhdGVk IHRvIG5vdCBzZW5kIHRoZXNlIHByZWZpeGVzIHRvIHRoZWlyIHVwc3RyZWFtcywgYnV0IHRvIHNo YXJlIHRoZW0gbW9yZSBmcmVlbHkgd2l0aCB0aGVpciBwZWVycykgQW55IGdpdmVuIHJvdXRlciBp cyB1bmxpa2VseSB0byBzZWUgYWxsIHRoZSBwYXRocy4NCg0KSW4gYW55IGNhc2UsIDE1ayBpcyBh IGJpZyBudW1iZXIsIHRvbyBiaWcgdG8gbWFrZSBtZSBmZWVsIGdvb2QgYnkgZWl0aGVyIG15IGV4 cGxhbmF0aW9ucyBhYm92ZSBvciB0aGUgcG9zc2liaWxpdHkgb2YgdW5uZWNlc3Nhcnkgc2luZ2xl LWhvbWVkIEJHUC4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHdlIG5lZWQgc29tZSBtb3JlIGFuYWx5 c2lzLg0KDQpBbmQgaWYgSSBoYXZlbid0IGJlZW4gb2J2aW91cyB5ZXQsIEkgdG90YWxseSBhZ3Jl ZSB3aXRoIHlvdSBhYm91dCBub3QgInBpdGNoaW5nIGl0IGFsbCIsIGJ1dCByYXRoZXIgZW5naW5l ZXJpbmcgKHRoZSBFIGluIElFVEYpIGEgc3VzdGFpbmluZyBzb2x1dGlvbi4gT2YgY291cnNlLCBJ IHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSB0aGUgYnJvYWRlciBhcmNoaXRlY3R1cmUgZGlz Y3Vzc2lvbnMsIHRvbywgYnV0IGl0cyBjbGVhciB0byBtZSB0aGF0IGdvb2QgYXJjaGl0ZWN0dXJl IG5lZWRzIHRvIHRoaW5rIGJleW9uZCBpbW1lZGlhdGUgaXNzdWVzIHRvIHByb2R1Y2UgaWRlYWwg cmVzdWx0cy4gVGhleSByZWFsbHkgYXJlIHR3byBzZXBhcmF0ZSB0b3BpY3MgYXQgdGhpcyBwb2lu dCBpbiB0aW1lLg0KDQpDaGVlcnMsDQotQmVuc29uDQoNCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRnJlZCBCYWtlcg0KVG86IFNjaGxpZXNzZXIsIEJlbnNvbg0KQ0M6 IGFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3JnDQpTZW50OiBTYXQgTm92IDExIDE2OjA1OjMx IDIwMDYNClN1YmplY3Q6IFJlOiBbYXJjaC1kXSBJdCdzIHRoZSByb3V0aW5nLCBwZW9wbGUhDQoN Cg0KT24gTm92IDExLCAyMDA2LCBhdCAxMjoxOSBQTSwgU2NobGllc3NlciwgQmVuc29uIHdyb3Rl Og0KDQo+DQo+ID4+IEkgZG9uJ3Qgc2VlIHJvdXRpbmcgbWVsdGluZyB0b2RheS4NCj4gPiBJJ20g b25seSBoZXJlIGJlY2F1c2Ugb3RoZXIgcGVvcGxlIHNlZW0gdG8gdGhpbmsNCj4gPiBpdCdzIGNv bWluZywgYW5kIHdhbnQgdG8gZ2V0DQo+ID4gbW92aW5nIG9uIGEgc29sdXRpb24uDQo+DQo+IEkg ZG9uJ3Qgd2FudCB0byBkZXJhaWwgdGhlIGJyb2FkZXIgYXJjaGl0ZWN0dXJhbCBkaXNjdXNzaW9u LCB3aGljaCAgDQo+IEkgdGhpbmsgaXMgdmFsdWFibGUuIEJ1dCBsZXQgbWUgcG9pbnQgb3V0IHNv bWV0aGluZyBkaXJlY3RseSAgDQo+IHJlbGF0ZWQgdG8gdGhlIGVuZ2luZWVyaW5nIHByb2JsZW0g d2UgZmFjZSBpbiB0aGUgcm91dGluZyBzeXN0ZW06ICANCj4gT2YgdGhlIGFwcHJveCAyM2sgQVNz IGluIHRoZSBnbG9iYWwgcm91dGluZyBzeXN0ZW0sIG9ubHkgM2sgYXJlICANCj4gdHJhbnNpdCBB U3MuIFRoZSBvdGhlciAyMGsgc3lzdGVtcyBhcmUgYmFzaWNhbGx5IGVuZCBuZXR3b3JrcyB0aGF0 ICANCj4gbXVsdGlob21lLg0KDQphY3R1YWxseSwgSSBhc2tlZCBHZW9mZiBhYm91dCB0aGlzLCBh bmQgaGUgdG9sZCBtZSB0aGF0IH4xNUsgQVMncyBoYWQgIA0Kb25seSBvbmUgdXBzdHJlYW0gQVMs IG1lYW5pbmcgdGhhdCBvbmx5IH44SyBoYXZlIG1vcmUgdGhhbiBvbmUgIA0KKG11bHRpaG9tZSBh dCB0aGUgQkdQIGxldmVsKSBhbmQgKHBlciB5b3UpIG9ubHkgfjNLIG9mIHRob3NlIGhhdmUgIA0K Im1hbnkiIHBlZXIgYW5kIHVwc3RyZWFtIEFTJ3MuDQoNCj4gSWYgd2UgY2FuIGNvbWUgdXAgd2l0 aCBhIGdvb2Qgc29sdXRpb24gdG8gbXVsdGlob21pbmcgdGhhdCByZW1vdmVzICANCj4gdGhlIG5l ZWQgZm9yIHRoZXNlIGVuZCBuZXR3b3JrcyB0byBwYXJ0aWNpcGF0ZSBpbiBnbG9iYWwgcm91dGlu ZyAgDQo+IGV0YywgYW5kIGNoYW5nZSBwb2xpY3kgc28gdGhhdCBpdCByZWZsZWN0cyB0aGlzIGlu IHR1cm4sIGl0IHNlZW1zICANCj4gdG8gbWUgdGhhdCB3ZSBjYW4gbWF0ZXJpYWxseSByZWR1Y2Ug dGFibGUgc2l6ZSBhbmQgcmF0ZSBvZiBncm93dGguICANCj4gKEdlb2ZmLCBpdCB3YXMgc2FpZCB5 b3Ugc3BlbmQgYWxsIG9mIHlvdXIgdGltZSBzdHVkeWluZyB0aGlzOyB3b3VsZCAgDQo+IHlvdSBh Z3JlZT8pDQo+DQo+IFllcywgdGhlIHdheSBJIGVudmlzaW9uIHRoaXMgaXQgd291bGQgYmUgZmFy IGZyb20gYSBuZXcgIA0KPiBhcmNoaXRlY3R1cmUuIEJ1dCBpZiBpdCBzb2x2ZXMgdGhlIGltbWVk aWF0ZSBwcm9ibGVtIHRoZW4gdGhvc2Ugb2YgIA0KPiB1cyBydW5uaW5nIG5ldHdvcmtzIGNhbiBr ZWVwIHRoZSBuZXR3b3JrIHdvcmtpbmcsIGFuZCB0aGlzIG1haWxpbmcgIA0KPiBsaXN0IGNhbiBj b250aW51ZSB0byBmdW5jdGlvbiBhcyBhIGZvcnVtIGZvciBhcmNoaXRlY3R1cmFsICANCj4gZGlz Y3Vzc2lvbi4gIDspDQoNCkkgd291bGQgZ2VuZXJhbGx5IGFncmVlLCBhbmQgdGhlIGludGVyZXN0 aW5nIHRoaW5nIGlzIHRoYXQgb25lICANCmRvZXNuJ3QgcmVhbGx5IG5lZWQgYSBwaXRjaC1pdC1h bGwtYW5kLXJlZG8gYXJjaGl0ZWN0dXJlIGNoYW5nZSB0byAgDQphY2NvbXBsaXNoIHRoYXQuIEl0 IG1lYW5zIHRoYXQgeW91IGVpdGhlciB3YW50IGEgbW9kZWwgaW4gd2hpY2ggZXZlcnkgIA0KdXBz dHJlYW0gYXNzaWducyBhIHBhcnQgb2YgaXRzIG93biBwcmVmaXggdG8gZWFjaCBvZiBpdHMgZG93 bnN0cmVhbXMgIA0KYW5kIGV2ZXJ5IGhvc3Qgb24gZXZlcnkgaW50ZXJmYWNlIGhhcyBhbiBhZGRy ZXNzIGZyb20gZWFjaCBvZiB0aGUgIA0KcmVsZXZhbnQgSVNQcyAod2hpY2ggaXMgYSBjaGFyYWN0 ZXJpc3RpYyBvZiBib3RoIHNoaW02IGFuZCBHU0UsICANCmFsdGhvdWdoIHRoZXkgYXJlIGltcGxl bWVudGVkIHZlcnkgZGlmZmVyZW50bHkpLCBvciB0aGF0IHNvbWVob3cgYSAgDQpwcmVmaXggaXMg YXNzaWduZWQgdG8gYW4gYWdyZWVhYmxlIHNldCBvZiBlZGdlIG5ldHdvcmtzIHRoYXQgY2FuIHVz ZSAgDQp0aGF0IHByZWZpeCBhY3Jvc3MgbXVsdGlwbGUgSVNQcyAod2hpY2ggaXMgYSBjaGFyYWN0 ZXJpc3RpYyBvZiBNZXRybykuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJh a2VyLXY2b3BzLWwzLW11bHRpaG9taW5nLWFuYWx5c2lzICANCnRyaWVzIHRvIGRvIHNvbWV0aGlu ZyBvZiBhbiBhbmFseXNpcyBvZiB0aG9zZSBmcm9tIGEgdGVjaG5pY2FsICANCnBlcnNwZWN0aXZl IGJhc2VkIG9uIFJGQyAzNTgyLiBCb3R0b20gbGluZSwgaWYgb25lIGRvZXMgYW4gYW5hbHlzaXMg IA0Kb2YgdGhlIGFwcHJvYWNoIGFuZCBjYW4gZW51bWVyYXRlIHRoZSBudW1iZXIgb2YgcHJlZml4 ZXMgaW4gdGhlICANCmJhY2tib25lIGFuZCBjb21lcyB1cCB3aXRoIGEgbnVtYmVyIG9uIHRoZSBv cmRlciBvZiAxMF40IG9yIDEwXjUsIHdlICANCmhhdmUgYWNjb21wbGlzaGVkIHNvbWV0aGluZyBp bXBvcnRhbnQuIFRoZSBvbmUgdGhpbmcgd2Uga25vdyBmb3Igc3VyZSAgDQppcyB0aGF0IFBJIGFk ZHJlc3NpbmcgZG9lc24ndCBkbyB0aGF0Lg0KDQpUaGlzIGlzIHdoeSBJIGtlZXAgYXNraW5nIGZv ciB0aGF0IGFuYWx5c2lzLiBJIHRoaW5rIGl0J3MgaW1wb3J0YW50ICANCmVub3VnaCB0byBub3Qg YmUgaGFuZC13YXZlZC4NCg0KV2hhdCBJIGhhdmUgY29uY2x1ZGVkIGZyb20gdmFyaW91cyBkaXNj dXNzaW9ucyBpcyB0aGF0IHRoZSBlbnRpcmUgIA0KcmVxdWlyZW1lbnRzIHNldCBpc24ndCBvbiB0 aGUgdGFibGUsIHRob3VnaC4gSSBoZWFyIGEgbG90IGFib3V0ICANCnRyYWZmaWMgZW5naW5lZXJp bmcsIGZvciBleGFtcGxlLCBidXQgZG9uJ3Qgc2VlIGFuIFJGQy0zNTgyLWxpa2Ugc2V0ICANCm9m IGFzc2VydGlvbnMgb24gdGhhdCB0b3BpYy4NCg== ------_=_NextPart_001_01C70603.DC489A89 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41LjcyMzQuMyI+DQo8VElUTEU+UmU6IFthcmNoLWRd IEl0J3MgdGhlIHJvdXRpbmcsIHBlb3BsZSE8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0t IENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KPEJSPg0KDQo8UD48Rk9OVCBT SVpFPTI+SSBhc3N1bWUgR2VvZmYgY2FuIGNvcnJlY3QgbWUgb24gdGhpcywgYnV0IG15IGd1dCBy ZXNwb25zZSB0byB0aGUgMTVrIG51bWJlciBpcyB0aGF0IHNvbWUgdmlzaWJpbGl0eSBpcyBwcm9i YWJseSBtaXNzaW5nLiBJLmUuIFRob3NlIEFTcyBtYXkgYmUgbXVsdGlob21lZCwgYW5kIHRoZSBh bmFseXNpcyB0b29scyBqdXN0IGRvbid0IHNlZSB0aGUgc2Vjb25kYXJ5IHBhdGgocykgdG8gdGhl aXIgcHJlZml4ZXMuPEJSPg0KPEJSPg0KU29tZSBJU1BzIHRoYXQgYXNzaWduIHRvIHRoZWlyIGN1 c3RvbWVycyBmcm9tIGEgbGFyZ2VyIGFsbG9jYXRpb24gZW5mb3JjZSBhZ2dyZWdhdGlvbiwgd2hp Y2ggbWFrZXMgb3JpZ2luIGFuYWx5c2lzIGxlc3Mgb2J2aW91cy4gKFRob3VnaCB0aGlzIGlzbid0 IG9mdGVuIGEgZ29vZCBpZGVhLCBhbmQgaXQncyBsaWtlbHkgdGhhdCByZXNlYXJjaGVycyB0aG91 Z2h0IG9mIHRoaXMpIE1vcmUgdHJpY2t5LCBhbmQgbW9yZSBsaWtlbHkgdGhlIGlzc3VlIHdpdGgg dmlzaWJpbGl0eSwgaXMgdGhhdCBsb2NhbCBwb2xpY3kgaW4gdHJhbnNpdCBBU3MgbWF5IG5vdCBz aGFyZSBtb3JlIHNwZWNpZmljIHByZWZpeGVzIG9yIHBhcnRpY3VsYXIgQVMtcGF0aHMgd2l0aCBj dXN0b21lcnMsIG9yIHdpdGggcGVlcnMsIG9yIGhvd2V2ZXIgaXQgc2VydmVzIHRoZWlyIGJ1c2lu ZXNzIGJlc3QuICgmcXVvdDtUaWVyIDImcXVvdDsgcHJvdmlkZXJzIGFyZSBpbiBzb21lIGNhc2Vz IGZpbmFuY2lhbGx5IG1vdGl2YXRlZCB0byBub3Qgc2VuZCB0aGVzZSBwcmVmaXhlcyB0byB0aGVp ciB1cHN0cmVhbXMsIGJ1dCB0byBzaGFyZSB0aGVtIG1vcmUgZnJlZWx5IHdpdGggdGhlaXIgcGVl cnMpIEFueSBnaXZlbiByb3V0ZXIgaXMgdW5saWtlbHkgdG8gc2VlIGFsbCB0aGUgcGF0aHMuPEJS Pg0KPEJSPg0KSW4gYW55IGNhc2UsIDE1ayBpcyBhIGJpZyBudW1iZXIsIHRvbyBiaWcgdG8gbWFr ZSBtZSBmZWVsIGdvb2QgYnkgZWl0aGVyIG15IGV4cGxhbmF0aW9ucyBhYm92ZSBvciB0aGUgcG9z c2liaWxpdHkgb2YgdW5uZWNlc3Nhcnkgc2luZ2xlLWhvbWVkIEJHUC4gSSBhZ3JlZSB3aXRoIHlv dSB0aGF0IHdlIG5lZWQgc29tZSBtb3JlIGFuYWx5c2lzLjxCUj4NCjxCUj4NCkFuZCBpZiBJIGhh dmVuJ3QgYmVlbiBvYnZpb3VzIHlldCwgSSB0b3RhbGx5IGFncmVlIHdpdGggeW91IGFib3V0IG5v dCAmcXVvdDtwaXRjaGluZyBpdCBhbGwmcXVvdDssIGJ1dCByYXRoZXIgZW5naW5lZXJpbmcgKHRo ZSBFIGluIElFVEYpIGEgc3VzdGFpbmluZyBzb2x1dGlvbi4gT2YgY291cnNlLCBJIHN0aWxsIHRo aW5rIHdlIG5lZWQgdG8gaGF2ZSB0aGUgYnJvYWRlciBhcmNoaXRlY3R1cmUgZGlzY3Vzc2lvbnMs IHRvbywgYnV0IGl0cyBjbGVhciB0byBtZSB0aGF0IGdvb2QgYXJjaGl0ZWN0dXJlIG5lZWRzIHRv IHRoaW5rIGJleW9uZCBpbW1lZGlhdGUgaXNzdWVzIHRvIHByb2R1Y2UgaWRlYWwgcmVzdWx0cy4g VGhleSByZWFsbHkgYXJlIHR3byBzZXBhcmF0ZSB0b3BpY3MgYXQgdGhpcyBwb2ludCBpbiB0aW1l LjxCUj4NCjxCUj4NCkNoZWVycyw8QlI+DQotQmVuc29uPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0K PEJSPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQpGcm9tOiBGcmVkIEJha2VyPEJS Pg0KVG86IFNjaGxpZXNzZXIsIEJlbnNvbjxCUj4NCkNDOiBhcmNoaXRlY3R1cmUtZGlzY3Vzc0Bp ZXRmLm9yZzxCUj4NClNlbnQ6IFNhdCBOb3YgMTEgMTY6MDU6MzEgMjAwNjxCUj4NClN1YmplY3Q6 IFJlOiBbYXJjaC1kXSBJdCdzIHRoZSByb3V0aW5nLCBwZW9wbGUhPEJSPg0KPEJSPg0KPEJSPg0K T24gTm92IDExLCAyMDA2LCBhdCAxMjoxOSBQTSwgU2NobGllc3NlciwgQmVuc29uIHdyb3RlOjxC Uj4NCjxCUj4NCiZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIHJvdXRpbmcgbWVs dGluZyB0b2RheS48QlI+DQomZ3Q7ICZndDsgSSdtIG9ubHkgaGVyZSBiZWNhdXNlIG90aGVyIHBl b3BsZSBzZWVtIHRvIHRoaW5rPEJSPg0KJmd0OyAmZ3Q7IGl0J3MgY29taW5nLCBhbmQgd2FudCB0 byBnZXQ8QlI+DQomZ3Q7ICZndDsgbW92aW5nIG9uIGEgc29sdXRpb24uPEJSPg0KJmd0OzxCUj4N CiZndDsgSSBkb24ndCB3YW50IHRvIGRlcmFpbCB0aGUgYnJvYWRlciBhcmNoaXRlY3R1cmFsIGRp c2N1c3Npb24sIHdoaWNoJm5ic3A7PEJSPg0KJmd0OyBJIHRoaW5rIGlzIHZhbHVhYmxlLiBCdXQg bGV0IG1lIHBvaW50IG91dCBzb21ldGhpbmcgZGlyZWN0bHkmbmJzcDs8QlI+DQomZ3Q7IHJlbGF0 ZWQgdG8gdGhlIGVuZ2luZWVyaW5nIHByb2JsZW0gd2UgZmFjZSBpbiB0aGUgcm91dGluZyBzeXN0 ZW06Jm5ic3A7PEJSPg0KJmd0OyBPZiB0aGUgYXBwcm94IDIzayBBU3MgaW4gdGhlIGdsb2JhbCBy b3V0aW5nIHN5c3RlbSwgb25seSAzayBhcmUmbmJzcDs8QlI+DQomZ3Q7IHRyYW5zaXQgQVNzLiBU aGUgb3RoZXIgMjBrIHN5c3RlbXMgYXJlIGJhc2ljYWxseSBlbmQgbmV0d29ya3MgdGhhdCZuYnNw OzxCUj4NCiZndDsgbXVsdGlob21lLjxCUj4NCjxCUj4NCmFjdHVhbGx5LCBJIGFza2VkIEdlb2Zm IGFib3V0IHRoaXMsIGFuZCBoZSB0b2xkIG1lIHRoYXQgfjE1SyBBUydzIGhhZCZuYnNwOzxCUj4N Cm9ubHkgb25lIHVwc3RyZWFtIEFTLCBtZWFuaW5nIHRoYXQgb25seSB+OEsgaGF2ZSBtb3JlIHRo YW4gb25lJm5ic3A7PEJSPg0KKG11bHRpaG9tZSBhdCB0aGUgQkdQIGxldmVsKSBhbmQgKHBlciB5 b3UpIG9ubHkgfjNLIG9mIHRob3NlIGhhdmUmbmJzcDs8QlI+DQomcXVvdDttYW55JnF1b3Q7IHBl ZXIgYW5kIHVwc3RyZWFtIEFTJ3MuPEJSPg0KPEJSPg0KJmd0OyBJZiB3ZSBjYW4gY29tZSB1cCB3 aXRoIGEgZ29vZCBzb2x1dGlvbiB0byBtdWx0aWhvbWluZyB0aGF0IHJlbW92ZXMmbmJzcDs8QlI+ DQomZ3Q7IHRoZSBuZWVkIGZvciB0aGVzZSBlbmQgbmV0d29ya3MgdG8gcGFydGljaXBhdGUgaW4g Z2xvYmFsIHJvdXRpbmcmbmJzcDs8QlI+DQomZ3Q7IGV0YywgYW5kIGNoYW5nZSBwb2xpY3kgc28g dGhhdCBpdCByZWZsZWN0cyB0aGlzIGluIHR1cm4sIGl0IHNlZW1zJm5ic3A7PEJSPg0KJmd0OyB0 byBtZSB0aGF0IHdlIGNhbiBtYXRlcmlhbGx5IHJlZHVjZSB0YWJsZSBzaXplIGFuZCByYXRlIG9m IGdyb3d0aC4mbmJzcDs8QlI+DQomZ3Q7IChHZW9mZiwgaXQgd2FzIHNhaWQgeW91IHNwZW5kIGFs bCBvZiB5b3VyIHRpbWUgc3R1ZHlpbmcgdGhpczsgd291bGQmbmJzcDs8QlI+DQomZ3Q7IHlvdSBh Z3JlZT8pPEJSPg0KJmd0OzxCUj4NCiZndDsgWWVzLCB0aGUgd2F5IEkgZW52aXNpb24gdGhpcyBp dCB3b3VsZCBiZSBmYXIgZnJvbSBhIG5ldyZuYnNwOzxCUj4NCiZndDsgYXJjaGl0ZWN0dXJlLiBC dXQgaWYgaXQgc29sdmVzIHRoZSBpbW1lZGlhdGUgcHJvYmxlbSB0aGVuIHRob3NlIG9mJm5ic3A7 PEJSPg0KJmd0OyB1cyBydW5uaW5nIG5ldHdvcmtzIGNhbiBrZWVwIHRoZSBuZXR3b3JrIHdvcmtp bmcsIGFuZCB0aGlzIG1haWxpbmcmbmJzcDs8QlI+DQomZ3Q7IGxpc3QgY2FuIGNvbnRpbnVlIHRv IGZ1bmN0aW9uIGFzIGEgZm9ydW0gZm9yIGFyY2hpdGVjdHVyYWwmbmJzcDs8QlI+DQomZ3Q7IGRp c2N1c3Npb24uJm5ic3A7IDspPEJSPg0KPEJSPg0KSSB3b3VsZCBnZW5lcmFsbHkgYWdyZWUsIGFu ZCB0aGUgaW50ZXJlc3RpbmcgdGhpbmcgaXMgdGhhdCBvbmUmbmJzcDs8QlI+DQpkb2Vzbid0IHJl YWxseSBuZWVkIGEgcGl0Y2gtaXQtYWxsLWFuZC1yZWRvIGFyY2hpdGVjdHVyZSBjaGFuZ2UgdG8m bmJzcDs8QlI+DQphY2NvbXBsaXNoIHRoYXQuIEl0IG1lYW5zIHRoYXQgeW91IGVpdGhlciB3YW50 IGEgbW9kZWwgaW4gd2hpY2ggZXZlcnkmbmJzcDs8QlI+DQp1cHN0cmVhbSBhc3NpZ25zIGEgcGFy dCBvZiBpdHMgb3duIHByZWZpeCB0byBlYWNoIG9mIGl0cyBkb3duc3RyZWFtcyZuYnNwOzxCUj4N CmFuZCBldmVyeSBob3N0IG9uIGV2ZXJ5IGludGVyZmFjZSBoYXMgYW4gYWRkcmVzcyBmcm9tIGVh Y2ggb2YgdGhlJm5ic3A7PEJSPg0KcmVsZXZhbnQgSVNQcyAod2hpY2ggaXMgYSBjaGFyYWN0ZXJp c3RpYyBvZiBib3RoIHNoaW02IGFuZCBHU0UsJm5ic3A7PEJSPg0KYWx0aG91Z2ggdGhleSBhcmUg aW1wbGVtZW50ZWQgdmVyeSBkaWZmZXJlbnRseSksIG9yIHRoYXQgc29tZWhvdyBhJm5ic3A7PEJS Pg0KcHJlZml4IGlzIGFzc2lnbmVkIHRvIGFuIGFncmVlYWJsZSBzZXQgb2YgZWRnZSBuZXR3b3Jr cyB0aGF0IGNhbiB1c2UmbmJzcDs8QlI+DQp0aGF0IHByZWZpeCBhY3Jvc3MgbXVsdGlwbGUgSVNQ cyAod2hpY2ggaXMgYSBjaGFyYWN0ZXJpc3RpYyBvZiBNZXRybykuPEJSPg0KPEJSPg0KPEEgSFJF Rj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFrZXItdjZvcHMtbDMtbXVsdGlo b21pbmctYW5hbHlzaXMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJha2VyLXY2 b3BzLWwzLW11bHRpaG9taW5nLWFuYWx5c2lzPC9BPiZuYnNwOzxCUj4NCnRyaWVzIHRvIGRvIHNv bWV0aGluZyBvZiBhbiBhbmFseXNpcyBvZiB0aG9zZSBmcm9tIGEgdGVjaG5pY2FsJm5ic3A7PEJS Pg0KcGVyc3BlY3RpdmUgYmFzZWQgb24gUkZDIDM1ODIuIEJvdHRvbSBsaW5lLCBpZiBvbmUgZG9l cyBhbiBhbmFseXNpcyZuYnNwOzxCUj4NCm9mIHRoZSBhcHByb2FjaCBhbmQgY2FuIGVudW1lcmF0 ZSB0aGUgbnVtYmVyIG9mIHByZWZpeGVzIGluIHRoZSZuYnNwOzxCUj4NCmJhY2tib25lIGFuZCBj b21lcyB1cCB3aXRoIGEgbnVtYmVyIG9uIHRoZSBvcmRlciBvZiAxMF40IG9yIDEwXjUsIHdlJm5i c3A7PEJSPg0KaGF2ZSBhY2NvbXBsaXNoZWQgc29tZXRoaW5nIGltcG9ydGFudC4gVGhlIG9uZSB0 aGluZyB3ZSBrbm93IGZvciBzdXJlJm5ic3A7PEJSPg0KaXMgdGhhdCBQSSBhZGRyZXNzaW5nIGRv ZXNuJ3QgZG8gdGhhdC48QlI+DQo8QlI+DQpUaGlzIGlzIHdoeSBJIGtlZXAgYXNraW5nIGZvciB0 aGF0IGFuYWx5c2lzLiBJIHRoaW5rIGl0J3MgaW1wb3J0YW50Jm5ic3A7PEJSPg0KZW5vdWdoIHRv IG5vdCBiZSBoYW5kLXdhdmVkLjxCUj4NCjxCUj4NCldoYXQgSSBoYXZlIGNvbmNsdWRlZCBmcm9t IHZhcmlvdXMgZGlzY3Vzc2lvbnMgaXMgdGhhdCB0aGUgZW50aXJlJm5ic3A7PEJSPg0KcmVxdWly ZW1lbnRzIHNldCBpc24ndCBvbiB0aGUgdGFibGUsIHRob3VnaC4gSSBoZWFyIGEgbG90IGFib3V0 Jm5ic3A7PEJSPg0KdHJhZmZpYyBlbmdpbmVlcmluZywgZm9yIGV4YW1wbGUsIGJ1dCBkb24ndCBz ZWUgYW4gUkZDLTM1ODItbGlrZSBzZXQmbmJzcDs8QlI+DQpvZiBhc3NlcnRpb25zIG9uIHRoYXQg dG9waWMuPEJSPg0KPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C70603.DC489A89-- --===============0235928893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0235928893==-- From architecture-discuss-bounces@ietf.org Sat Nov 11 22:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj64x-0004uR-Ik; Sat, 11 Nov 2006 22:32:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj64v-0004tu-SI for architecture-discuss@ietf.org; Sat, 11 Nov 2006 22:32:17 -0500 Received: from web54712.mail.yahoo.com ([206.190.49.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gj64r-0000Cu-KB for architecture-discuss@ietf.org; Sat, 11 Nov 2006 22:32:17 -0500 Received: (qmail 37946 invoked by uid 60001); 12 Nov 2006 03:32:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pJNYBRf5sIhrTSfGCpMdWkKqSrYdgnPGrRhDiSchjw5lJTU+Gx72fhNNIlXu9BlQuPlDQ0xkVLU/poSVHcgyUPp561y8jjHPHiiD8eKThcNmWn6xt7Urf0+MbmngsPBb6llXbXt9Q8BlZCFcjj54IEodPTu0ZLgMbI9UicoJEOU= ; Message-ID: <20061112033208.37944.qmail@web54712.mail.yahoo.com> Received: from [74.111.124.141] by web54712.mail.yahoo.com via HTTP; Sat, 11 Nov 2006 19:32:08 PST Date: Sat, 11 Nov 2006 19:32:08 -0800 (PST) From: Peter Sherbin To: architecture-discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [arch-d] Comment on 67th IETF Technical plenary X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Summary Current Internet is unsafe, its routing is not scalable Implication Government interferes for at least two reasons: 1. to protect its subjects 2. to tax underground economy Suggestions 1. community debates basic assumptions 2. agreed upon assumptions become requirements 3. requirements determine routing Consideration Participants may expect IETF guidance on socio-economic aspects of the Internet Thanks, PS ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 04:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBju-0000lU-M1; Sun, 12 Nov 2006 04:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBjt-0000lN-RC for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:34:57 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjBjo-0005sR-I6 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:34:57 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id AB26B340BA; Sun, 12 Nov 2006 04:34:54 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 04:34:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 04:34:49 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8B224@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccFqwCMdg0FOYFcS+aQXhe+d0FgWgAkntuA From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 12 Nov 2006 09:34:51.0912 (UTC) FILETIME=[CDD09880:01C7063D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I question this unless the IAB processes wants to agree to this. It was stated at the plenary it is an address and routing problem. Thus it is on the table as we proceed with the discussion. The IAB meeting is the driver for this work and I will assume it will become more formalized than a random set of opinions on our general architecture list as was stated Thursday night at the plenary. Would IAB rep like to comment and clarify? Best, /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Saturday, November 11, 2006 11:00 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: [arch-d] It's the routing, people! >=20 > Some years ago, in one U.S. campaign there was a slogan "It's=20 > the economy, stupid!". I would like to paraphrase that here,=20 > to focus the discussion on what's important. >=20 > We're here primarily because there's a routing problem - i.e.=20 > the routing is going to melt down. That's the problem people=20 > are trying to solve. So, "It's the routing, people!" In other=20 > words, the first order of business ought to be trying to=20 > figure out how the routing is going to work. >=20 > Designing addresses is kind of fun, but it's also "looking=20 > for keys under the streetlight" (in the words of the old=20 > joke). May I remind people that *we are here now precisely=20 > because people designed addresses (IPv6), instead of figuring=20 > out how the routing is going to work*. >=20 > I'm somewhat disheartened that the IETF, likFrom architecture-discuss-bounces@ietf.org Sun Nov 12 04:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBju-0000lU-M1; Sun, 12 Nov 2006 04:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBjt-0000lN-RC for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:34:57 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjBjo-0005sR-I6 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:34:57 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id AB26B340BA; Sun, 12 Nov 2006 04:34:54 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 04:34:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 04:34:49 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8B224@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccFqwCMdg0FOYFcS+aQXhe+d0FgWgAkntuA From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 12 Nov 2006 09:34:51.0912 (UTC) FILETIME=[CDD09880:01C7063D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I question this unless the IAB processes wants to agree to this. It was stated at the plenary it is an address and routing problem. Thus it is on the table as we proceed with the discussion. The IAB meeting is the driver for this work and I will assume it will become more formalized than a random set of opinions on our general architecture list as was stated Thursday night at the plenary. Would IAB rep like to comment and clarify? Best, /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Saturday, November 11, 2006 11:00 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: [arch-d] It's the routing, people! >=20 > Some years ago, in one U.S. campaign there was a slogan "It's=20 > the economy, stupid!". I would like to paraphrase that here,=20 > to focus the discussion on what's important. >=20 > We're here primarily because there's a routing problem - i.e.=20 > the routing is going to melt down. That's the problem people=20 > are trying to solve. So, "It's the routing, people!" In other=20 > words, the first order of business ought to be trying to=20 > figure out how the routing is going to work. >=20 > Designing addresses is kind of fun, but it's also "looking=20 > for keys under the streetlight" (in the words of the old=20 > joke). May I remind people that *we are here now precisely=20 > because people designed addresses (IPv6), instead of figuring=20 > out how the routing is going to work*. >=20 > I'm somewhat disheartened that the IETF, like the Bourbons=20 > (in Talleyrand's famous phrase), has seemingly learned=20 > nothing, and forgotten nothing. > (There's also a military maxim about "amateurs study tactics,=20 > professionals study logistics" - I'll leave it to you all to=20 > work out how I'd modify that for us.) >=20 > So, until we have figured out how the routing is going to=20 > work, can we please table *all* discussion of what the=20 > addresses are going to look like? Thank you. >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 04:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBmC-0002AG-Mt; Sun, 12 Nov 2006 04:37:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBmA-00024y-Gx for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:37:18 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjBm5-0006Bi-72 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:37:18 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 6145834077; Sun, 12 Nov 2006 04:37:14 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 04:37:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 04:37:10 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8B226@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccFtgsMY3oxFC+xSCKviumybRSqVgAh/ZiQ From: "Bound, Jim" To: "John Day" , "Noel Chiappa" , X-OriginalArrivalTime: 12 Nov 2006 09:37:12.0819 (UTC) FILETIME=[21CD4C30:01C7063E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org IPv6 did not do this or not do this it provided an address space. What we may or may not do with it moving foward is part of the TBD address discussion. =20 Best, /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Saturday, November 11, 2006 12:21 PM > To: Noel Chiappa; architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] It's the routing, people! >=20 > Then the addresses should simply be labels. Not true. If=20 > the addresses are suppose to be location-dependent, that=20 > location dependence is relative to the *topology* of the=20 > network. Think in terms of how location-dee the Bourbons=20 > (in Talleyrand's famous phrase), has seemingly learned=20 > nothing, and forgotten nothing. > (There's also a military maxim about "amateurs study tactics,=20 > professionals study logistics" - I'll leave it to you all to=20 > work out how I'd modify that for us.) >=20 > So, until we have figured out how the routing is going to=20 > work, can we please table *all* discussion of what the=20 > addresses are going to look like? Thank you. >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 04:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBmC-0002AG-Mt; Sun, 12 Nov 2006 04:37:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBmA-00024y-Gx for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:37:18 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjBm5-0006Bi-72 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:37:18 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 6145834077; Sun, 12 Nov 2006 04:37:14 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 04:37:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 04:37:10 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8B226@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccFtgsMY3oxFC+xSCKviumybRSqVgAh/ZiQ From: "Bound, Jim" To: "John Day" , "Noel Chiappa" , X-OriginalArrivalTime: 12 Nov 2006 09:37:12.0819 (UTC) FILETIME=[21CD4C30:01C7063E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org IPv6 did not do this or not do this it provided an address space. What we may or may not do with it moving foward is part of the TBD address discussion. =20 Best, /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Saturday, November 11, 2006 12:21 PM > To: Noel Chiappa; architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] It's the routing, people! >=20 > Then the addresses should simply be labels. Not true. If=20 > the addresses are suppose to be location-dependent, that=20 > location dependence is relative to the *topology* of the=20 > network. Think in terms of how location-dependence should be=20 > represented relative to the graph of the network. >=20 > The nature of the address space is as important as the=20 > routes. They actually influence each other to some degree. >=20 > You are concentrating on the arithmetic, when you need to be=20 > looking at the algebra. >=20 > I agree with you that v6 did not do this. But then what did=20 > you expect. I have yet to see any proposals on this list that=20 > do it. But they are possible. If you don't get the two=20 > things working together, you won't get a solution that=20 > scales. That much I can pretty much guarantee. >=20 > Take care, > john >=20 > At 11:00 -0500 2006/11/11, Noel Chiappa wrote: > >Some years ago, in one U.S. campaign there was a slogan "It's the=20 > >economy, stupid!". I would like to paraphrase that here, to=20 > focus the=20 > >discussion on what's important. > > > >We're here primarily because there's a routing problem - i.e. the=20 > >routing is going to melt down. That's the problem people are=20 > trying to=20 > >solve. So, "It's the routing, people!" In other words, the=20 > first order=20 > >of business ought to be trying to figure out how the routing=20 > is going to work. > > > >Designing addresses is kind of fun, but it's also "looking for keys=20 > >under the streetlight" (in the words of the old joke). May I remind=20 > >people that *we are here now precisely because people designed=20 > >addresses (IPv6), instead of figuring out how the routing is=20 > going to work*. > > > >I'm somewhat disheartened that the IETF, like the Bourbons (in=20 > >Talleyrand's famous phrase), has seemingly learned nothing,=20 > and forgotten nothing. > >(There's also a military maxim about "amateurs study tactics,=20 > >professionals study logistics" - I'll leave it to you all to=20 > work out=20 > >how I'd modify that for us.) > > > >So, until we have figured out how the routing is going to=20 > work, can we=20 > >please table *all* discussion of what the addresses are=20 > going to look=20 > >like? Thank you. > > > > Noel > > > >_______________________________________________ > >Architecture-discuss mailing list > >Architecture-discuss@ietf.org > >https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss pendence should be=20 > represented relative to the graph of the network. >=20 > The nature of the address space is as important as the=20 > routes. They actually influence each other to some degree. >=20 > You are concentrating on the arithmetic, when you need to be=20 > looking at the algebra. >=20 > I agree with you that v6 did not do this. But then what did=20 > you expect. I have yet to see any proposals on this list that=20 > do it. But they are possible. If you don't get the two=20 > things working together, you won't get a solution that=20 > scales. That much I can pretty much guarantee. >=20 > Take care, > john >=20 > At 11:00 -0500 2006/11/11, Noel Chiappa wrote: > >Some years ago, in one U.S. campaign there was a slogan "It's the=20 > >economy, stupid!". I would like to paraphrase that here, to=20 > focus the=20 > >discussion on what's important. > > > >We're here primarily because there's a routing problem - i.e. the=20 > >routing is going to melt down. That's the problem people are=20 > trying to=20 > >solve. So, "It's the routing, people!" In other words, the=20 > first order=20 > >of business ought to be trying to figure out how the routing=20 > is going to work. > > > >Designing addresses is kind of fun, but it's also "looking for keys=20 > >under the streetlight" (in the words of the old joke). May I remind=20 > >people that *we are here now precisely because people designed=20 > >addresses (IPv6), instead of figuring out how the routing is=20 > going to work*. > > > >I'm somewhat disheartened that the IETF, like the Bourbons (in=20 > >Talleyrand's famous phrase), has seemingly learned nothing,=20 > and forgotten nothing. > >(There's also a military maxim about "amateurs study tactics,=20 > >professionals study logistics" - I'll leave it to you all to=20 > work out=20 > >how I'd modify that for us.) > > > >So, until we have figured out how the routing is going to=20 > work, can we=20 > >please table *all* discussion of what the addresses are=20 > going to look=20 > >like? Thank you. > > > > Noel > > > >_______________________________________________ > >Architecture-discuss mailing list > >Architecture-discuss@ietf.org > >https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 04:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBsM-0005hg-RN; Sun, 12 Nov 2006 04:43:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBsM-0005hb-6y for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:43:42 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjBsG-0007We-S3 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:43:42 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A029A34041; Sun, 12 Nov 2006 04:43:36 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 04:43:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Date: Sun, 12 Nov 2006 04:43:33 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8B227@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061111173657.75E3886AE9@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccFuArNxsDNOLg+S6ODmteW6VEbbgAhjA8A From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 12 Nov 2006 09:43:36.0483 (UTC) FILETIME=[067BC730:01C7063F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org We are going to have to have multiple mail threads and flow aware state routers are one of them and at that time I will propose the entire routing based on a flow ID and locator can be done and far more efficiently than today. SHIM6 work in progress avoids the end host problem as input to this process. But, the point is there are many ideas and thoughts but they will not be focused and coordinated until we organize this effort per what I heard from Leslie as plan forward. Fine to brainstorm on this list and hear all persons ideas and thoughts but this needs a more focused IETF process with working groups, IETF rules of engagement etc. and to adhere well to Sam Hartmans word of caution at the Plenary which is working well thus far. I also suspect per Geof H mail that it is important for us to define what we want to be an identifier on the Internet and part of the address space discussion. I also wonder if the IETF can select such an identifier without liaison discussions with other SDO and Consortia stakeholders. Note IAB message we need to work with all stakeholders. Best, /jim > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Saturday, November 11, 2006 12:37 PM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: Ok, so what should we do then? (Was: Re:=20 > [arch-d] [Off-topic]Further thoughts: about systems theory=20 > and the theory U) >=20 > > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) >=20 > >> I don't believe in the "else try_and_forward(input_packet)" > >> clause, except for local traffic)... >=20 > > I started to think through this whole issue, and=20 > discovered a problem. > > To see it, let's think in a little more detail about=20 > how the routing in > > a "jack-up" system is going to work. >=20 > In an attempt to make slightly clearer what I was jabbering=20 > on about here, I have drawn a couple of quick, simplified=20 > diagrams which show some of the things I was talking about. >=20 > Remember, I'm talking about the flow of routing data here,=20 > *not* packets, and the mappings you see happening from=20 > old-style to new-style are mappings of routing data, not=20 > mappings of packet source/destination addresses. >=20 > Again, the basic issue is that we're trying to reduce the=20 > amount of routing information, but my concern is (basically)=20 > that until the very last "old-style" DFZ router goes away, we=20 > may have to maintain full old-style tables anyway in all=20 > routers everywhere - depending on how we set things up. >=20 >=20 > Anyway, the diagrams are here: >=20 > http://ana-3.lcs.mit.edu/~jnc/tech/DisDFZ.jpg >=20 > which shows the problems with discontiguous chunks of=20 > new-style DFZ (i.e. the repeated conversion from new-style=20 > locators back to old-style addresses), and > here: >=20 > http://ana-3.lcs.mit.edu/~jnc/tech/ContDFZ.jpg >=20 > which shows how the same technical issue (the reverse mapping=20 > from new-style addresses back to old-style) occurs with a=20 > large, continugous new-style DFZ on the edge, but how it's=20 > more manageable since it's only happening on a single boundary. >=20 > So, try rereading my other message (Fri, 10 Nov 2006 21:18:28=20 > -0500) with these diagrams, and see if what I'm wondering=20 > about makes sense. >=20 >=20 > For simplicities sake, I have drawn the diagrams as if all=20 > networks with unmapped addresses are attached to the=20 > old-style DFZ, and all with mapped to the new-style, but of=20 > course that's not necessary. >=20 > Also, I have only drawn the physical topology, not the two=20 > separate routing planes - sorry, didn't have enough patience=20 > for a multi-layer drawing! >=20 >=20 > Anyway, I'd really appreciate it if people could look at this=20 > material (diagrams and text), and see if I've made some=20 > obvious blunder in my understanding, or if there is a real issue here. >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 04:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBve-0007kX-2q; Sun, 12 Nov 2006 04:47:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjBvd-0007jG-0E for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:47:05 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjBvW-00089Y-MT for architecture-discuss@ietf.org; Sun, 12 Nov 2006 04:47:04 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 85EF234041; Sun, 12 Nov 2006 04:46:58 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 04:46:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re:[arch-d][Off-topic]Further thoughts: about systems theory andthe theory U) Date: Sun, 12 Nov 2006 04:46:55 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCE8B228@tayexc14.americas.cpqcorp.net> In-Reply-To: <003401c705c9$e456af00$9d01a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re:[arch-d][Off-topic]Further thoughts: about systems theory andthe theory U) Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanAAB2ueDA= From: "Bound, Jim" To: , "Marshall Eubanks" X-OriginalArrivalTime: 12 Nov 2006 09:46:58.0347 (UTC) FILETIME=[7ECDC7B0:01C7063F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "Fleischman, Eric" , Noel Chiappa , Terry L Davis , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Backhauling is a notion whose day has come and I for one believe we need to understand how it can assist the routing. Agree totally that when one changes providers the mobility has to be "seamless" simply because there is a good chance the locator has to change for the mobile node. The reason that is relative it requires routing analysis and I believe part of this problem. But it would be real great if we could write up the set of "what problems are we trying to solve".=20 /jim=20 > -----Original Message----- > From: Tony Li [mailto:tli@tropos.com]=20 > Sent: Saturday, November 11, 2006 2:45 PM > To: 'Marshall Eubanks'; tony.li@tony.li > Cc: 'Fleischman, Eric'; 'Noel Chiappa'; 'Terry L Davis';=20 > architecture-discuss@ietf.org > Subject: RE: Ok, so what should we do then? (Was:=20 > Re:[arch-d][Off-topic]Further thoughts: about systems theory=20 > andthe theory U) >=20 > =20 >=20 > > One place where the loc/id split might make a lot of sense=20 > would be in=20 > > mobile platform internets (MPI's), such as modern=20 > commercial airliners=20 > > with routers, lots of networked devices and three or more internal=20 > > subnets and address blocks per plane (see some of the documents at=20 > > http://www.multicasttech.com/mpi/ if you want more details). 10,000=20 > > such planes flying around would tax even an airplane only=20 > BGP network. >=20 >=20 > Hi Marshall, >=20 > That's certainly one approach. However, there's another=20 > solution to this issue that doesn't really require=20 > architectural changes. =20 >=20 > If you take a look at how our friends at Connexion did=20 > things, they assigned one prefix per plane and then injected=20 > it into global routing at the point of its current downlink. >=20 > With all due respect, an alternate approach would be to have=20 > a separate global domain that provides backhaul and have that=20 > domain inject all plane prefixes from all points=20 > simultaneously, effectively causing everyone to perform=20 > hot-potato routing to them with stable BGP injection. Note=20 > that the backhaul network need not be physically > instantiated: a full mesh of tunnels between the downlink=20 > sites and an IGP carrying plane prefixes should work very=20 > nicely for little additional (physical) cost. It also has=20 > the nice property that your latency to the plane is not=20 > nearly as bad as bouncing to a single, fixed downlink would=20 > be. You can also decrease latency by adding (virtual)=20 > connectivity anywhere in the global topology to redirect=20 > traffic into the backhaul topology. >=20 > Hiding mobility is a good option for the cases where you're=20 > not going to actually change providers. >=20 > Tony >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 08:48:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjFef-0006Uw-8U; Sun, 12 Nov 2006 08:45:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjFed-0006Uo-Tb for architecture-discuss@ietf.org; Sun, 12 Nov 2006 08:45:47 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjFed-0000J4-KV for architecture-discuss@ietf.org; Sun, 12 Nov 2006 08:45:47 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kACDhoZ2099078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Nov 2006 14:43:52 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <5F744BD3-8E59-4AF5-8D8E-E5DB0D7362D2@cisco.com> References: <092DA27E-1DD2-4EBD-BA9B-10573FD2D1E8@cisco.com> <8E5CC8D3-8EBF-4458-9C1B-A9F094D8432F@muada.com> <5F744BD3-8E59-4AF5-8D8E-E5DB0D7362D2@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2DD86C0B-0171-49C5-9CD0-CD3DD73D4211@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 14:45:32 +0100 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_BANG autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12-nov-2006, at 1:33, Fred Baker wrote: > On Nov 11, 2006, at 3:39 PM, Iljitsch van Beijnum wrote: >> This AS is singlehandedly responsible for more than 1% of the >> global routing table Ugh, it's only 0.13% or so. Sorry. > OK, so here's a proposed fix. Every *other* ISP ponies up $10 and > hands some money to this ISP's upstreams to, in their routing > policies, accept whatever prefixes from this jerk they are going to > accept, and then consider the advertisement of any combination of > subsets of an allocated prefix to be a single advertisement of the > entire prefix - and collapse said 1% of the route table into a very > few routable prefixes. I'm not sure I understand, but I'm pretty sure it's unworkable... What about we all give our favorite vendors some $$ and they build in some aggregation magic that makes all of this disappear? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 09:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGJN-0005Lq-8x; Sun, 12 Nov 2006 09:27:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjGJM-0005Ll-9r for architecture-discuss@ietf.org; Sun, 12 Nov 2006 09:27:52 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjGJL-0008RY-4V for architecture-discuss@ietf.org; Sun, 12 Nov 2006 09:27:52 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8D49486ADD; Sun, 12 Nov 2006 09:27:50 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] It's the routing, people! Message-Id: <20061112142750.8D49486ADD@mercury.lcs.mit.edu> Date: Sun, 12 Nov 2006 09:27:50 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Bound, Jim" > It was stated at the plenary it is an address and routing problem. Jim, addresses (in the "routing-name" or "locator" sense of the word) are nothing more than the data the path-selection ("routing") uses. We have a routing problem. I believe the conclusion is fairly obvious. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 12:12:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjIqC-0002DK-AH; Sun, 12 Nov 2006 12:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjIqA-00029y-Oy for architecture-discuss@ietf.org; Sun, 12 Nov 2006 12:09:54 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjIq7-0003SM-0s for architecture-discuss@ietf.org; Sun, 12 Nov 2006 12:09:54 -0500 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kACH9VRq040412; Mon, 13 Nov 2006 04:09:32 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061113040426.0141d628@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 13 Nov 2006 04:09:27 +1100 To: "Schliesser, Benson" , From: Geoff Huston Subject: Re: [arch-d] It's the routing, people! In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 01:40 PM 12/11/2006, Schliesser, Benson wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C70603.DC489A89" > > >I assume Geoff can correct me on this, but my gut response to the >15k number is that some visibility is probably missing. I.e. Those >ASs may be multihomed, and the analysis tools just don't see the >secondary path(s) to their prefixes. It depends on the nature of the multi-homed configuration. If the AS is multi-homed for transit then the alternative transit providers get exposed on withdrawl, in general. If the multi-homing is actually multi-peering, then you just can't see this from a remote location - BGP won't expose this. >Some ISPs that assign to their customers from a larger allocation >enforce aggregation, which makes origin analysis less obvious. >(Though this isn't often a good idea, and it's likely that >researchers thought of this) More tricky, and more likely the issue >with visibility, is that local policy in transit ASs may not share >more specific prefixes or particular AS-paths with customers, or >with peers, or however it serves their business best. ("Tier 2" >providers are in some cases financially motivated to not send these >prefixes to their upstreams, but to share them more freely with >their peers) Any given router is unlikely to see all the paths. If the route propagation is constrained, then more power to these folk - thats what keeps the routing system in some kind of 'control' - the issue is the gloibal propagation of more specifics, which is genrally the result of using a combination of more specifics and multiple upstream transits. >In any case, 15k is a big number, too big to make me feel good by >either my explanations above or the possibility of unnecessary >single-homed BGP. I agree with you that we need some more analysis. I suspect that an AS is sometimes something that consultants puton their check list. i.e. "get the client an AS number" :-) Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 13:33:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjK5o-00050r-GR; Sun, 12 Nov 2006 13:30:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjK5n-00050f-5o for architecture-discuss@ietf.org; Sun, 12 Nov 2006 13:30:07 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjK5j-0002QW-Np for architecture-discuss@ietf.org; Sun, 12 Nov 2006 13:30:05 -0500 Received: from webmail53.lax.untd.com (webmail51.lax.untd.com [10.131.27.191]) by smtpout08.lax.untd.com with SMTP id AABCXQ39GA6C735S for (sender ); Sun, 12 Nov 2006 10:28:54 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKmDiDsHBz/tOY1yK5LLe+hQ== Received: (from fergdawg@netzero.net) by webmail51.lax.untd.com (jqueuemail) id L6ZDVCSU; Sun, 12 Nov 2006 10:27:57 PST Received: from [24.23.201.115] by webmail51.lax.untd.com with HTTP: Sun, 12 Nov 2006 18:27:46 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Sun, 12 Nov 2006 18:27:46 GMT To: gih@apnic.net Subject: Re: [arch-d] It's the routing, people! X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061112.102757.2521.1436547@webmail51.lax.untd.com> X-ContentStamp: 9:4:2353728868 X-MAIL-INFO: 17a0e0ade1c0e0c0c061a0f0c9f1b5141481b901146405c9a144104d919090e0313d20ad X-UNTD-Peer-Info: 10.131.27.191|webmail51.lax.untd.com|webmail53.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -- Geoff Huston wrote: At 01:40 PM 12/11/2006, Schliesser, Benson wrote: >> >>I assume Geoff can correct me on this, but my gut response to the = >>15k number is that some visibility is probably missing. I.e. Those = >>ASs may be multihomed, and the analysis tools just don't see the = >>secondary path(s) to their prefixes. > >It depends on the nature of the multi-homed configuration. If the AS = >is multi-homed for transit then the alternative transit providers get = >exposed on withdrawl, in general. > >If the multi-homing is actually multi-peering, then you just can't = >see this from a remote location - BGP won't expose this. > I know I'm probably going to hate myself for saying this, but perhaps it is time for us to revisit the value of "selective" methods for proxy aggregation? It's a sensitive topic, for sure, which is why I highly emphasize the word: "selective"... - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 15:23:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjLoL-000721-FC; Sun, 12 Nov 2006 15:20:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjLoK-00071w-Qa for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:20:12 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjLoJ-00056b-FP for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:20:12 -0500 Received: (qmail 4960 invoked from network); 12 Nov 2006 20:20:06 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 12 Nov 2006 20:20:06 -0000 Received: from LIPC ([192.168.1.157]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 12:20:06 -0800 From: "Tony Li" To: "'Iljitsch van Beijnum'" , "'Fred Baker'" Subject: RE: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 12:20:02 -0800 Message-ID: <006f01c70697$ef56a5d0$9d01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2DD86C0B-0171-49C5-9CD0-CD3DD73D4211@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccGYRbzjeHOWY4KSG6mc9HGjmAp8QANpoRg X-OriginalArrivalTime: 12 Nov 2006 20:20:06.0189 (UTC) FILETIME=[F15275D0:01C70697] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > What about we all give our favorite vendors some $$ and they > build in > some aggregation magic that makes all of this disappear? Proxy aggregation was rejected by the operational community long ago, primarily due to the global traffic engineering effects. The knobs for doing this manually are already there. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 15:34:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjM1U-0004wx-Ii; Sun, 12 Nov 2006 15:33:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjM1T-0004wo-Rv for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:33:47 -0500 Received: from www.woodynet.net ([204.61.208.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjM1R-00077f-BX for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:33:47 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net [24.125.117.214]) (authenticated bits=0) by www.woodynet.net (8.12.10/8.12.10) with ESMTP id kACKfSDe015729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Nov 2006 12:41:29 -0800 (PST) In-Reply-To: <004701c705de$ee620bb0$9d01a8c0@tropos.com> References: <004701c705de$ee620bb0$9d01a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <269930AC-F886-4AC0-A801-87EA46D2DE77@pch.net> Content-Transfer-Encoding: 7bit From: Tom Vest Subject: Re: [arch-d] It's the routing, people! (singlehomers sanity check) Date: Sun, 12 Nov 2006 15:33:07 -0500 To: tony.li@tony.li X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Tom Vest , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 5:15 PM, Tony Li wrote: > >> actually, I asked Geoff about this, and he told me that ~15K >> AS's had only one upstream AS, > > Only one that Geoff could see from his vantage point? I compiled the data below from the Route Views Archive / OIX ribs data I'm using for my dissertation, so the vantage point varies over time as new peers / data contributors joined RV. I derived the adjacency counts using the CAIDA toolset: http://www.caida.org/funding/routing/atoms/download/rv2atoms-0.4/ > Or only one period? Data reflects (only) a single snapshot for each year, the first "apparently" complete OIX rib file in each November. > If the latter, that would be an indication that RIR's and others are > being conned into giving out ASNs and prefixes for PI purposes for > singly homed customers. ;-( > > Tony Given the caveats above, It looks like the singlehomer phenomenon is not as large as originally assumed; and the 15k number may reflect the historical total rather than the number of nonconforming ASes at any given time. Still if the numbers are accurate, it appears that the phenomenon may be growing again as a share of the total. Perhaps not surprising now (since 2004) that some large operators have added an explicit AS adjacency count to their settlement-free peering requirements.... If there is interest, it shouldn't take too much time to determine how many singlehomers became multihomers (e.g., vs. simply disappearing) in each successive year. Tom Year 1997 1998 1999 2000 2001 2002 2003 2004 2005 Benchmark: Originate>1 Edge=Any 2958 4237 6017 8973 11968 14001 16087 18374 20943 Originate>1 Edge=1 Nov-97 518 297 218 164 128 111 86 77 72 Nov-98 606 434 297 223 189 154 135 123 Nov-99 752 556 394 320 258 229 212 Nov-00 1080 710 540 428 372 341 Nov-01 1740 1172 899 762 680 Nov-02 1824 1385 1159 1035 Nov-03 2101 1740 1512 Nov-04 2741 2360 Nov-05 4127 Singlehomer share 17.51% 14.30% 12.50% 12.04% 14.54% 13.03% 13.06% 14.92% 19.71% _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 15:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjM4R-0006Re-6z; Sun, 12 Nov 2006 15:36:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjM4Q-0006RY-Ep for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:36:50 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjM4O-0007aQ-2S for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:36:50 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kACKaj5k014112; Sun, 12 Nov 2006 12:36:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kACKajSW014111; Sun, 12 Nov 2006 12:36:45 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 12 Nov 2006 12:36:45 -0800 From: David Meyer To: Fred Baker Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) Message-ID: <20061112203645.GC13852@1-4-5.net> References: <011d01c704fc$dece4c00$4901a8c0@tropos.com> <4554D5FE.2050603@zurich.ibm.com> <336060FA-C04A-440D-AC56-A0DB8A17FDF6@cisco.com> Mime-Version: 1.0 In-Reply-To: <336060FA-C04A-440D-AC56-A0DB8A17FDF6@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1309631382==" Errors-To: architecture-discuss-bounces@ietf.org --===============1309631382== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pAwQNkOnpTn9IO2O" Content-Disposition: inline --pAwQNkOnpTn9IO2O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 10, 2006 at 03:41:57PM -0800, Fred Baker wrote: >=20 > On Nov 10, 2006, at 11:41 AM, Brian E Carpenter wrote: >=20 > >Even if you have an antiNAT at the other end >=20 > noting that I am neither ultimately anti-nat or pro-nat... I just see =20 > some problems that nats solve and others that it creates or doesn't =20 > fix, and I see other ways of fixing the problems that don't have =20 > those issues (but in a 32 bit address space have other problems). >=20 > Please, could we manage to not be arguing about NATs? We are using =20 > NATs now, probably as effectively as we collectively know how, and a =20 > five year old with a ruler and the RIR address allocation data can =20 > draw valid conclusions that lead us to believe that we have a limited =20 > timeframe to do something different. >=20 > We need a problem statement, preferably a set of requirements, one or =20 > more proposed solutions, and for each solution an honest analysis =20 > that leads to to believe whether it actually fixes the issues set =20 > forth in the problem statement. Let's target that. >=20 Fred, Both of the latter (problem statement + requirements). I didn't see another way that the IAB could kick the IETF into action other than what we did (and yeah, we couldn't get everyone we wanted [or even everyone *I* wanted] there, but at least it was a start, and you have to start somewhere). In any event, the next steps Leslie outlined in the plenary include exactly these action items, so I think we're (at least) pointed in the right direction. That's more than I could have expected (given the history, etc).=20 --dmm --pAwQNkOnpTn9IO2O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFV4XdORgD1qCZ2KcRAtRjAJsHh3pSjbgeOBCwHvXXYS1dGz9HiACfYTIr cR33zVOuMUm4SnnT7gcqZjc= =ou3d -----END PGP SIGNATURE----- --pAwQNkOnpTn9IO2O-- --===============1309631382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1309631382==-- From architecture-discuss-bounces@ietf.org Sun Nov 12 15:43:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMAj-0002Jx-GJ; Sun, 12 Nov 2006 15:43:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMAi-0002Jq-A0 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:43:20 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjMAg-0008PE-M9 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:43:20 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kACKhCKY014172; Sun, 12 Nov 2006 12:43:12 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kACKh3TI014170; Sun, 12 Nov 2006 12:43:03 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 12 Nov 2006 12:43:03 -0800 From: David Meyer To: "Bound, Jim" Subject: Re: [arch-d] It's the routing, people! Message-ID: <20061112204303.GD13852@1-4-5.net> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> <816DD9299957E547B5D758D7F977D6DCE8B224@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 In-Reply-To: <816DD9299957E547B5D758D7F977D6DCE8B224@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0325716909==" Errors-To: architecture-discuss-bounces@ietf.org --===============0325716909== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oj4kGyHlBMXGt3Le" Content-Disposition: inline --oj4kGyHlBMXGt3Le Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 04:34:49AM -0500, Bound, Jim wrote: > I question this unless the IAB processes wants to agree to this. It was > stated at the plenary it is an address and routing problem. Thus it is > on the table as we proceed with the discussion. The IAB meeting is the > driver for this work and I will assume it will become more formalized > than a random set of opinions on our general architecture list as was > stated Thursday night at the plenary. >=20 > Would IAB rep like to comment and clarify? Speaking as an individual, what I can say is that someone got up during Leslie's "what's next" part and said addressing should come before routing. I didn't necessarily agree, but that's all I heard. --dmm >=20 > Best, >=20 > /jim=20 >=20 > > -----Original Message----- > > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > > Sent: Saturday, November 11, 2006 11:00 AM > > To: architecture-discuss@ietf.org > > Cc: jnc@mercury.lcs.mit.edu > > Subject: [arch-d] It's the routing, people! > >=20 > > Some years ago, in one U.S. campaign there was a slogan "It's=20 > > the economy, stupid!". I would like to paraphrase that here,=20 > > to focus the discussion on what's important. > >=20 > > We're here primarily because there's a routing problem - i.e.=20 > > the routing is going to melt down. That's the problem people=20 > > are trying to solve. So, "It's the routing, people!" In other=20 > > words, the first order of business ought to be trying to=20 > > figure out how the routing is going to work. > >=20 > > Designing addresses is kind of fun, but it's also "looking=20 > > for keys under the streetlight" (in the words of the old=20 > > joke). May I remind people that *we are here now precisely=20 > > because people designed addresses (IPv6), instead of figuring=20 > > out how the routing is going to work*. > >=20 > > I'm somewhat disheartened that the IETF, like the Bourbons=20 > > (in Talleyrand's famous phrase), has seemingly learned=20 > > nothing, and forgotten nothing. > > (There's also a military maxim about "amateurs study tactics,=20 > > professionals study logistics" - I'll leave it to you all to=20 > > work out how I'd modify that for us.) > >=20 > > So, until we have figured out how the routing is going to=20 > > work, can we please table *all* discussion of what the=20 > > addresses are going to look like? Thank you. > >=20 > > Noel > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss --oj4kGyHlBMXGt3Le Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFV4dXORgD1qCZ2KcRAnw6AJ9b9kvl0RPpg1umQ65OMO1lZcTxvwCeMHnm LK4QQ2ZyzPbthAvNDd0wlog= =E6uA -----END PGP SIGNATURE----- --oj4kGyHlBMXGt3Le-- --===============0325716909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0325716909==-- From architecture-discuss-bounces@ietf.org Sun Nov 12 15:47:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMEi-0003ma-Ul; Sun, 12 Nov 2006 15:47:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMEh-0003mT-Q2 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:47:27 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjMEd-0000Yn-Ba for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:47:25 -0500 Received: from webmail53.lax.untd.com (webmail53.lax.untd.com [10.131.27.193]) by smtpout04.lax.untd.com with SMTP id AABCXRCCJAMXMQMS for (sender ); Sun, 12 Nov 2006 12:47:04 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKfVUA5bKIWBg/yX5kaOkAJg== Received: (from fergdawg@netzero.net) by webmail53.lax.untd.com (jqueuemail) id L6ZMTNFM; Sun, 12 Nov 2006 12:46:50 PST Received: from [24.23.201.115] by webmail53.lax.untd.com with HTTP: Sun, 12 Nov 2006 20:46:12 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Sun, 12 Nov 2006 20:46:12 GMT To: dmm@1-4-5.net Subject: Re: [arch-d] It's the routing, people! X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061112.124650.717.956606@webmail53.lax.untd.com> X-ContentStamp: 9:4:2873894455 X-MAIL-INFO: 26659d7d64859d85858065c92951540909d11d9109c4502924d5f414b984849dbdd4cd7d X-UNTD-Peer-Info: 10.131.27.193|webmail53.lax.untd.com|webmail53.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -- David Meyer >On Sun, Nov 12, 2006 at 04:34:49AM -0500, Bound, Jim wrote: >> I question this unless the IAB processes wants to agree to this. It = was >> stated at the plenary it is an address and routing problem. Thus it = is >> on the table as we proceed with the discussion. The IAB meeting is t= he >> driver for this work and I will assume it will become more formalized= >> than a random set of opinions on our general architecture list as was= >> stated Thursday night at the plenary. >> = >> Would IAB rep like to comment and clarify? > > Speaking as an individual, what I can say is that someone > got up during Leslie's "what's next" part and said > addressing should come before routing. I didn't > necessarily agree, but that's all I heard. > > --dmm > I'm not so sure they can necessarily be decoupled in this context. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 15:58:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMOg-0000IT-4b; Sun, 12 Nov 2006 15:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMOe-0000ES-Kc for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:57:44 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjMOd-0001mL-8q for architecture-discuss@ietf.org; Sun, 12 Nov 2006 15:57:44 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kACKvgH1014672; Sun, 12 Nov 2006 12:57:42 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kACKvbC3014671; Sun, 12 Nov 2006 12:57:37 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 12 Nov 2006 12:57:37 -0800 From: David Meyer To: Fergie Subject: Re: [arch-d] It's the routing, people! Message-ID: <20061112205737.GA14539@1-4-5.net> References: <20061112.124650.717.956606@webmail53.lax.untd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20061112.124650.717.956606@webmail53.lax.untd.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Sun, Nov 12, 2006 at 08:46:12PM +0000, Fergie wrote: >=20 > -- David Meyer >=20 > >On Sun, Nov 12, 2006 at 04:34:49AM -0500, Bound, Jim wrote: > >> I question this unless the IAB processes wants to agree to this. It w= as > >> stated at the plenary it is an address and routing problem. Thus it is > >> on the table as we proceed with the discussion. The IAB meeting is the > >> driver for this work and I will assume it will become more formalized > >> than a random set of opinions on our general architecture list as was > >> stated Thursday night at the plenary. > >>=20 > >> Would IAB rep like to comment and clarify? > > > > Speaking as an individual, what I can say is that someone > > got up during Leslie's "what's next" part and said > > addressing should come before routing. I didn't > > necessarily agree, but that's all I heard. > > > > --dmm > > >=20 > I'm not so sure they can necessarily be decoupled in this context. I don't think that they can (I was trying play the "journalist role" and report on what I heard). So I'm not sure where this originated, but at the first IETF I ever attended (Columbus), Yakov told me that "Addressing can follow topology or topology can follow addressing. Choose one." I've been calling this Rehkter's Law ever since (he has mentioned to me that the advent of VPN technology weakens the "law").=20 In any event, you can argue about the details, but if scaling the routing system depends on topological aggregation (such as the "aggressive topological aggregation" that Mike was designing for in 8+8/GSE) [0], this "law" would seem to hold. So either way, if you believe you need to topological aggregation, then you need some form of congruence at some point. --dmm =09 [0] One might argue otherwise, cf Dima and Claffy's work (among others) on minimum stretch compact routing, or ROFL (routing on flat labels). _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 16:04:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMV5-0004Lb-VW; Sun, 12 Nov 2006 16:04:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjMV3-0004LR-OY for architecture-discuss@ietf.org; Sun, 12 Nov 2006 16:04:21 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjMV2-0002eZ-Cv for architecture-discuss@ietf.org; Sun, 12 Nov 2006 16:04:21 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kACL4J1a014948; Sun, 12 Nov 2006 13:04:19 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kACL4Jdl014947; Sun, 12 Nov 2006 13:04:19 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 12 Nov 2006 13:04:19 -0800 From: David Meyer To: Fergie Subject: Re: [arch-d] It's the routing, people! Message-ID: <20061112210419.GA14932@1-4-5.net> References: <20061112.124650.717.956606@webmail53.lax.untd.com> <20061112205737.GA14539@1-4-5.net> Mime-Version: 1.0 In-Reply-To: <20061112205737.GA14539@1-4-5.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Jim.Bound@hp.com, architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1181529108==" Errors-To: architecture-discuss-bounces@ietf.org --===============1181529108== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > [0] One might argue otherwise, cf Dima and Claffy's work > (among others) on minimum stretch compact routing, or > ROFL (routing on flat labels). BTW, I was just going to find some references for this work (but you can us goog or whatever for that). But I did want to say that I didn't want to diss anyone who is working on this stuff. The comment I made was close, but from memory, so not complete. Use goog (or whatever) to get a more complete bibliography. --dmm --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFV4xTORgD1qCZ2KcRArqGAJ4hSVreC/2xrYrIIAxE55sQ0bufXQCfT+vt Nn5Z1hbSCuoF5S1Rb+Ht7eQ= =uhxQ -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- --===============1181529108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1181529108==-- From architecture-discuss-bounces@ietf.org Sun Nov 12 16:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjN7Q-0000WP-43; Sun, 12 Nov 2006 16:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjN7O-0000WG-Jd for architecture-discuss@ietf.org; Sun, 12 Nov 2006 16:43:58 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjN7H-0008R1-1u for architecture-discuss@ietf.org; Sun, 12 Nov 2006 16:43:58 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 72A1E3401D; Sun, 12 Nov 2006 16:43:46 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 16:43:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 16:43:43 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCECD7CB@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061112142750.8D49486ADD@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccGZwtiZN3igolvQL+CUTztJdNEYgAPGyrg From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 12 Nov 2006 21:43:46.0134 (UTC) FILETIME=[A1714760:01C706A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, If it is that simple what IAB mean't by addresses then that is fine but I would like to hear from them it is and others? Best, /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Sunday, November 12, 2006 9:28 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [arch-d] It's the routing, people! >=20 > > From: "Bound, Jim" >=20 > > It was stated at the plenary it is an address and=20 > routing problem. >=20 > Jim, addresses (in the "routing-name" or "locator" sense of=20 > the word) are nothing more than the data the path-selection=20 > ("routing") uses. We have a routing problem. I believe the=20 > conclusion is fairly obvious. >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 17:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjNcW-0007u7-ND; Sun, 12 Nov 2006 17:16:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjNcV-0007pG-E9 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:16:07 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjNcU-0003QR-73 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:16:07 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006111222160401100ri6kqe>; Sun, 12 Nov 2006 22:16:04 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DCECD7CB@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCECD7CB@tayexc14.americas.cpqcorp.net> Date: Sun, 12 Nov 2006 17:15:37 -0500 To: "Bound, Jim" , "Noel Chiappa" , From: John Day Subject: RE: [arch-d] It's the routing, people! Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org :-) addresses are "nothing more than the data the path-selection." I hate to think of all the things subsumed under *that* phrase! ;-) So Noel would you class that as tautological or teleological! ;-) Take care, John At 16:43 -0500 2006/11/12, Bound, Jim wrote: >Noel, If it is that simple what IAB mean't by addresses then that is >fine but I would like to hear from them it is and others? > >Best, >/jim > >> -----Original Message----- >> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] >> Sent: Sunday, November 12, 2006 9:28 AM >> To: architecture-discuss@ietf.org >> Cc: jnc@mercury.lcs.mit.edu >> Subject: RE: [arch-d] It's the routing, people! >> >> > From: "Bound, Jim" >> >> > It was stated at the plenary it is an address and >> routing problem. >> >> Jim, addresses (in the "routing-name" or "locator" sense of > > the word) are nothing more than the data the path-selection >> ("routing") uses. We have a routing problem. I believe the >> conclusion is fairly obvious. >> >> Noel >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 17:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjNcU-0007p9-Gv; Sun, 12 Nov 2006 17:16:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjNcT-0007p4-6G for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:16:05 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjNcR-0003QR-W6 for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:16:05 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006111222154301100ri6kpe>; Sun, 12 Nov 2006 22:16:03 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061112205737.GA14539@1-4-5.net> References: <20061112.124650.717.956606@webmail53.lax.untd.com> <20061112205737.GA14539@1-4-5.net> Date: Sun, 12 Nov 2006 17:11:57 -0500 To: David Meyer , Fergie From: John Day Subject: Re: [arch-d] It's the routing, people! Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Jim.Bound@hp.com, architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > context. > > I don't think that they can (I was trying play the > "journalist role" and report on what I heard). So I'm not > sure where this originated, but at the first IETF I ever > attended (Columbus), Yakov told me that "Addressing can > follow topology or topology can follow addressing. Choose > one." I've been calling this Rehkter's Law ever since (he > has mentioned to me that the advent of VPN technology weakens > the "law"). As usual, Yakov only sort of gets it. The topology of the address space must be compatible with the graph of the network. Otherwise, why use that topology? It will just get in your way. It is a bit kludgy to try to apply the idea of topology to the Internet. All you really have is a graph. Lets just say that if the graph is static then addressing can follow the graph. However, if an address space is defined such that the network graph can grow, then it behooves the network to grow in ways compatible with the topology of the address space. Otherwise, you are working at cross purposes. > In any event, you can argue about the details, but if > scaling the routing system depends on topological > aggregation (such as the "aggressive topological > aggregation" that Mike was designing for in 8+8/GSE) [0], > this "law" would seem to hold. So either way, if you > believe you need to topological aggregation, then you > need some form of congruence at some point. This is indeed the case. Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 17:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjNkX-0003RM-0e; Sun, 12 Nov 2006 17:24:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjNkW-0003RH-5y for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:24:24 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjNkQ-0004XU-9t for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:24:24 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id EA513340AE; Sun, 12 Nov 2006 17:24:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Nov 2006 17:24:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Sun, 12 Nov 2006 17:24:16 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCECD7DF@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccGqCT9tYPtETBkSfuU96m+811CVgAAEaoA From: "Bound, Jim" To: "John Day" , "David Meyer" , "Fergie" X-OriginalArrivalTime: 12 Nov 2006 22:24:17.0533 (UTC) FILETIME=[4AAB52D0:01C706A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org My hope is there will be a lot of views and brilliance shared lets not assume any thing yet once we have what we are suppose to "get" then we decide how we move forward with only discussing models and architectures and within them the assumption by the many bright people who will contribute in the IETF. Right now as requested I am using a blank sheet of paper. What I believe is important is the business and time-to-market reality check we need to make. Some will say use IPv6 and go forward, some will say jack up v4 and move to v6 via the jackups, some might even say no invent IPv15 or we could go where Dr. Preston Marhall at DARPA is looking at using a new generation of wirless communications pretty much replacing IP all together for the most part. Fred said we need proposals and those proposals will have to address a core set of base questions, what those questions are is an important discussion too. I think this is going to take a minimum of two years and this is not the list to do the hands on work for as it is a general IETF list that should support many topics besides this one. Best, /jim > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Sunday, November 12, 2006 5:12 PM > To: David Meyer; Fergie > Cc: architecture-discuss@ietf.org; jnc@mercury.lcs.mit.edu; Bound, Jim > Subject: Re: [arch-d] It's the routing, people! >=20 > > context. > > > > I don't think that they can (I was trying play the > > "journalist role" and report on what I heard). So I'm not > > sure where this originated, but at the first IETF I ever > > attended (Columbus), Yakov told me that "Addressing can > > follow topology or topology can follow addressing. Choose > > one." I've been calling this Rehkter's Law ever since (he > > has mentioned to me that the advent of VPN technology weakens > > the "law"). >=20 > As usual, Yakov only sort of gets it. The topology of the=20 > address space must be compatible with the graph of the=20 > network. Otherwise, why use that topology? It will just get=20 > in your way. It is a bit=20 > kludgy to try to apply the idea of topology to the Internet. All=20 > you really have is a graph. Lets just say that if the graph=20 > is static then addressing can follow the graph. However, if=20 > an address space is defined such that the network graph can=20 > grow, then it behooves the network to grow in ways compatible=20 > with the topology of the address space. Otherwise, you are=20 > working at cross purposes. >=20 > > In any event, you can argue about the details, but if > > scaling the routing system depends on topological > > aggregation (such as the "aggressive topological > > aggregation" that Mike was designing for in 8+8/GSE) [0], > > this "law" would seem to hold. So either way, if you > > believe you need to topological aggregation, then you > > need some form of congruence at some point. >=20 > This is indeed the case. >=20 > Take care, > john >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 17:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOGt-0004AA-E0; Sun, 12 Nov 2006 17:57:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOGs-00049d-3X for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:57:50 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjOGl-0000c2-Uf for architecture-discuss@ietf.org; Sun, 12 Nov 2006 17:57:50 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kACMvQHd004953; Mon, 13 Nov 2006 09:57:26 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061113095229.01444010@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 13 Nov 2006 09:57:20 +1100 To: "Fergie" From: Geoff Huston Subject: Re: [arch-d] It's the routing, people! In-Reply-To: <20061112.102757.2521.1436547@webmail51.lax.untd.com> References: <20061112.102757.2521.1436547@webmail51.lax.untd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 05:27 AM 13/11/2006, Fergie wrote: >-- Geoff Huston wrote: > >At 01:40 PM 12/11/2006, Schliesser, Benson wrote: > > >> > >>I assume Geoff can correct me on this, but my gut response to the > >>15k number is that some visibility is probably missing. I.e. Those > >>ASs may be multihomed, and the analysis tools just don't see the > >>secondary path(s) to their prefixes. > > > >It depends on the nature of the multi-homed configuration. If the AS > >is multi-homed for transit then the alternative transit providers get > >exposed on withdrawl, in general. > > > >If the multi-homing is actually multi-peering, then you just can't > >see this from a remote location - BGP won't expose this. > > > >I know I'm probably going to hate myself for saying this, but >perhaps it is time for us to revisit the value of "selective" >methods for proxy aggregation? It's a sensitive topic, for sure, >which is why I highly emphasize the word: "selective"... I hate my life too, so lets go there.. Its true that our various methods for attempting to limit the propagation of localised information have been an abject failure and around 50% of local information (more specifics) appears in the global table. Its not that this information should go away - in local contexts it serves a valid purpose and has a valid reason for existence. But thats no reason why this should flood globally. I always wondered how you gain the knowledge that by absorbing the more specifics and not re-advertising them you are not just allowing the more specifics to take longer paths and still propagate anyway. But if I'm obsessing over the wrong thing then that's nothing new! Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 12 18:03:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOLh-0007SH-Fj; Sun, 12 Nov 2006 18:02:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOLf-0007S3-Jr for architecture-discuss@ietf.org; Sun, 12 Nov 2006 18:02:47 -0500 Received: from web54701.mail.yahoo.com ([206.190.49.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjOLe-0001GE-9Q for architecture-discuss@ietf.org; Sun, 12 Nov 2006 18:02:47 -0500 Received: (qmail 61391 invoked by uid 60001); 12 Nov 2006 23:02:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P9uF/BSJo5paoH2f4xw3itYJu4QZwx9kCNdDQhCHELRWE94p80pMcuL13pZF6FhHRUv6r483sWm8ju4+gLNDlVaFtfxvs1bWKZ4VBEMNPrbRwqL3rabbCzbkhcqkVjmsNDgf9ZMKm3XHyc+QcQAjp6s/GlfoEfv/REBxd5xoetE= ; Message-ID: <20061112230245.61389.qmail@web54701.mail.yahoo.com> Received: from [74.111.124.141] by web54701.mail.yahoo.com via HTTP; Sun, 12 Nov 2006 15:02:45 PST Date: Sun, 12 Nov 2006 15:02:45 -0800 (PST) From: Peter Sherbin Subject: RE: [arch-d] It's the routing, people! To: Noel Chiappa , architecture-discuss@ietf.org In-Reply-To: <816DD9299957E547B5D758D7F977D6DCE8B224@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > joke). May I remind people that *we are here now precisely > > because people designed addresses (IPv6), instead of figuring > > out how the routing is going to work*. We can design routing to route anything. The fundamental part is to figure out what is that thing. No one knows exactly because people are building and learning the Internet at the same time. We learn by modeling. Any sound model starts with assumptions. For the Internet assumptions will turn into requirements. We live in a world where consumers want a choice between competing providers to send the data. Data belong to a consumer. Communicating via IP requires addresses. Hence the very basic assumption is how to manage addresses. Unavoidably address management touches social, economical and political reality of the planet. When address management is established routing becomes a straightforward engineering exercise. Thanks, PS --- "Bound, Jim" wrote: > I question this unless the IAB processes wants to agree to this. It was > stated at the plenary it is an address and routing problem. Thus it is > on the table as we proceed with the discussion. The IAB meeting is the > driver for this work and I will assume it will become more formalized > than a random set of opinions on our general architecture list as was > stated Thursday night at the plenary. > > Would IAB rep like to comment and clarify? > > Best, > > /jim > > > -----Original Message----- > > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > > Sent: Saturday, November 11, 2006 11:00 AM > > To: architecture-discuss@ietf.org > > Cc: jnc@mercury.lcs.mit.edu > > Subject: [arch-d] It's the routing, people! > > > > Some years ago, in one U.S. campaign there was a slogan "It's > > the economy, stupid!". I would like to paraphrase that here, > > to focus the discussion on what's important. > > > > We're here primarily because there's a routing problem - i.e. > > the routing is going to melt down. That's the problem people > > are trying to solve. So, "It's the routing, people!" In other > > words, the first order of business ought to be trying to > > figure out how the routing is going to work. > > > > Designing addresses is kind of fun, but it's also "looking > > for keys under the streetlight" (in the words of the old > > joke). May I remind people that *we are here now precisely > > because people designed addresses (IPv6), instead of figuring > > out how the routing is going to work*. > > > > I'm somewhat disheartened that the IETF, like the Bourbons > > (in Talleyrand's famous phrase), has seemingly learned > > nothing, and forgotten nothing. > > (There's also a military maxim about "amateurs study tactics, > > professionals study logistics" - I'll leave it to you all to > > work out how I'd modify that for us.) > > > > So, until we have figured out how the routing is going to > > work, can we please table *all* discussion of what the > > addresses are going to look like? Thank you. > > > > Noel > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 09:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjd1b-0005NL-DW; Mon, 13 Nov 2006 09:43:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjd1Z-0005Lz-B2 for architecture-discuss@ietf.org; Mon, 13 Nov 2006 09:43:01 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjd1Z-0004YA-0U for architecture-discuss@ietf.org; Mon, 13 Nov 2006 09:43:01 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kADEejil025804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Nov 2006 15:40:46 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20061112205737.GA14539@1-4-5.net> References: <20061112.124650.717.956606@webmail53.lax.untd.com> <20061112205737.GA14539@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6844D1E7-00FE-4CBD-8248-66C1032D2A03@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] It's the routing, people! Date: Mon, 13 Nov 2006 15:42:30 +0100 To: David Meyer X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_BANG autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12-nov-2006, at 21:57, David Meyer wrote: > at the first IETF I ever > attended (Columbus), Yakov told me that "Addressing can > follow topology or topology can follow addressing. Choose > one." [...] > if > scaling the routing system depends on topological > aggregation (such as the "aggressive topological > aggregation" that Mike was designing for in 8+8/GSE) [0], > this "law" would seem to hold. There is another caveat: the address space must look the same to everyone. But the topology of the network doesn't, due to the policies that are applied in BGP. This means that, even if we disregard the fact that topology is subject to constant change, it's impossible to have a direct mapping between addressing and topology. And then there's the issue of crossconnects (multihomed ASes) that can't be expressed in the hierarchy we need to view the address space as in order to do our longest-match-first lookups. I remember someone saying something like "we can create any addressing architecture we want, routing will (have to) follow". Or maybe that's what the inventor of the Ethernet switch said? I'll file this next to "given sufficient thrust, pigs will fly just fine." A correlation between addressing and topology that's strong enough to be useful to make routing scale can only realistically happen by making compromises. I.e., neither addressing nor topology can be completely free, both will have to be limited. An example of this is geographic aggregation, where addressing is aligned with geography, which means that a network topology that ignores geography either can't work at all or must break aggregation. [1] If such a compromise is deemed undesireable or unacceptable, then, given the facts that the internet must support policy and multihoming and users require stable addressing (for your favorite value of "stable"), the only conclusion can be that the addressing seen by the users and the addressing seen by the core routers can't be the same. However, this doesn't really solve the problem, it only moves it away from the place where things are expensive (the fast routers that require the big tables), hopefully to a place where the information explosion caused by unaggregatable/unaggregated addressing is cheaper to manage. [1] Note that geographic aggregation can be seen as a special case of increased stretch routing where the alignment between the placement of routers containing table entries for part of the network and the location of the address users reduces the problem of scenic routing. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 10:37:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdrB-0005Lc-KG; Mon, 13 Nov 2006 10:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjddd-0005qs-LM for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:22:21 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjdda-0000nx-93 for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:22:21 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kADFLvTP018680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2006 09:21:57 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kADFLuOM021464; Mon, 13 Nov 2006 07:21:56 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kADFLrGT021338; Mon, 13 Nov 2006 07:21:56 -0800 (PST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 07:21:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re:[arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Mon, 13 Nov 2006 07:21:55 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD2A5D@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <816DD9299957E547B5D758D7F977D6DCE8B228@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re:[arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanAAB2ueDAAPdVX8A== From: "Davis, Terry L" To: "Bound, Jim" , , "Marshall Eubanks" , X-OriginalArrivalTime: 13 Nov 2006 15:21:55.0569 (UTC) FILETIME=[74183E10:01C70737] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Mon, 13 Nov 2006 10:36:18 -0500 Cc: "Fleischman, Eric" , "Ivancic, William D. \(\(GRC-RCN0\)\)" , Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jim For aviation mobility, that's what Marshall, Will Ivancic and I are trying to do with the web site and drafts below. By the Prague IETF meeting, we hope to have made significant updates to both the problem statement draft and the aviation requirements draft. Website: http://www.multicasttech.com/mpi/=20 Drafts: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-10.txt=20 http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-10.txt=20 Take care Terry > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Sunday, November 12, 2006 1:47 AM > To: tony.li@tony.li; Marshall Eubanks > Cc: Fleischman, Eric; Noel Chiappa; Davis, Terry L; architecture- > discuss@ietf.org > Subject: RE: Ok, so what should we do then? (Was: Re:[arch-d][Off- > topic]Further thoughts: about systems theory andthe theory U) >=20 > Backhauling is a notion whose day has come and I for one believe we need > to understand how it can assist the routing. Agree totally that when > one changes providers the mobility has to be "seamless" simply because > there is a good chance the locator has to change for the mobile node. > The reason that is relative it requires routing analysis and I believe > part of this problem. >=20 > But it would be real great if we could write up the set of "what > problems are we trying to solve". >=20 > /jim >=20 > > -----Original Message----- > > From: Tony Li [mailto:tli@tropos.com] > > Sent: Saturday, November 11, 2006 2:45 PM > > To: 'Marshall Eubanks'; tony.li@tony.li > > Cc: 'Fleischman, Eric'; 'Noel Chiappa'; 'Terry L Davis'; > > architecture-discuss@ietf.org > > Subject: RE: Ok, so what should we do then? (Was: > > Re:[arch-d][Off-topic]Further thoughts: about systems theory > > andthe theory U) > > > > > > > > > One place where the loc/id split might make a lot of sense > > would be in > > > mobile platform internets (MPI's), such as modern > > commercial airliners > > > with routers, lots of networked devices and three or more internal > > > subnets and address blocks per plane (see some of the documents at > > > http://www.multicasttech.com/mpi/ if you want more details). 10,000 > > > such planes flying around would tax even an airplane only > > BGP network. > > > > > > Hi Marshall, > > > > That's certainly one approach. However, there's another > > solution to this issue that doesn't really require > > architectural changes. > > > > If you take a look at how our friends at Connexion did > > things, they assigned one prefix per plane and then injected > > it into global routing at the point of its current downlink. > > > > With all due respect, an alternate approach would be to have > > a separate global domain that provides backhaul and have that > > domain inject all plane prefixes from all points > > simultaneously, effectively causing everyone to perform > > hot-potato routing to them with stable BGP injection. Note > > that the backhaul network need not be physically > > instantiated: a full mesh of tunnels between the downlink > > sites and an IGP carrying plane prefixes should work very > > nicely for little additional (physical) cost. It also has > > the nice property that your latency to the plane is not > > nearly as bad as bouncing to a single, fixed downlink would > > be. You can also decrease latency by adding (virtual) > > connectivity anywhere in the global topology to redirect > > traffic into the backhaul topology. > > > > Hiding mobility is a good option for the cases where you're > > not going to actually change providers. > > > > Tony > > > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 10:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdrB-0005LX-Ed; Mon, 13 Nov 2006 10:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj30e-0007eP-E6 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:15:40 -0500 Received: from rommie.caida.org ([192.172.226.78] helo=caida.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj30b-0005gu-4C for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:15:40 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net [24.125.117.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by caida.org (Postfix) with ESMTP id BBAA7BA12; Sat, 11 Nov 2006 16:15:33 -0800 (PST) In-Reply-To: <004701c705de$ee620bb0$9d01a8c0@tropos.com> References: <004701c705de$ee620bb0$9d01a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tom Vest Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 19:15:27 -0500 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Mon, 13 Nov 2006 10:36:18 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 5:15 PM, Tony Li wrote: > > >> actually, I asked Geoff about this, and he told me that ~15K >> AS's had only one upstream AS, > > Only one that Geoff could see from his vantage point? Or only one > period? > > If the latter, that would be an indication that RIR's and others are > being conned into giving out ASNs and prefixes for PI purposes for > singly homed customers. ;-( > > Tony This issue is not unknown, and plausibly (personal speculation only) is one of the reasons behind the ARIN "policy reinterpretation" of 12 Feb 2006: http://www.arin.net/announcements/archives/20060222.html The issue has troubled me for some time also. No doubt some of the apparent single-homers have private AS adjacencies that don't show up, e.g., in Route Views. Hard to imagine this explaining away close to 15k ASes -- all but about 225 of which post-date the RFC 1930, the RIRs, et al. Casual inquiries with the three old RIRs suggest that "very few" ASNs have been allocated on the basis of RFC 2270... Tom Vest _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 10:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdrB-0005Lm-S9; Mon, 13 Nov 2006 10:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdjV-0000TV-4Z for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:28:25 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjdjT-0001Qp-RX for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:28:25 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kADFSMRE022930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2006 09:28:23 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kADFSMWH004749; Mon, 13 Nov 2006 07:28:22 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kADFSJZI004690; Mon, 13 Nov 2006 07:28:21 -0800 (PST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 07:28:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Mon, 13 Nov 2006 07:28:19 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD2A5E@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <003401c705c9$e456af00$9d01a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanAAFrNCPA= From: "Davis, Terry L" To: , "Marshall Eubanks" X-OriginalArrivalTime: 13 Nov 2006 15:28:19.0702 (UTC) FILETIME=[590E4960:01C70738] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Mon, 13 Nov 2006 10:36:18 -0500 Cc: "Fleischman, Eric" , Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony/Marshall This type of concept is one of several we are discussing for the global ATC network and we could conceivably extend it for the airline operations domain. Take care Terry > -----Original Message----- > From: Tony Li [mailto:tli@tropos.com] > Sent: Saturday, November 11, 2006 11:45 AM > To: 'Marshall Eubanks'; tony.li@tony.li > Cc: Fleischman, Eric; 'Brian E Carpenter'; 'Noel Chiappa'; architecture- > discuss@ietf.org; Davis, Terry L > Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off- > topic]Further thoughts: about systems theory and the theory U) >=20 >=20 >=20 > > One place where the loc/id split might make a lot of sense would be > > in mobile platform internets (MPI's), such as > > modern commercial airliners with routers, lots of networked devices > > and three or more internal subnets and address blocks per plane (see > > some of the documents at http://www.multicasttech.com/mpi/ if you > > want more details). 10,000 such planes flying around would tax even > > an airplane only BGP network. >=20 >=20 > Hi Marshall, >=20 > That's certainly one approach. However, there's another solution to > this issue that doesn't really require architectural changes. >=20 > If you take a look at how our friends at Connexion did things, they > assigned one prefix per plane and then injected it into global routing > at the point of its current downlink. >=20 > With all due respect, an alternate approach would be to have a separate > global domain that provides backhaul and have that domain inject all > plane prefixes from all points simultaneously, effectively causing > everyone to perform hot-potato routing to them with stable BGP > injection. Note that the backhaul network need not be physically > instantiated: a full mesh of tunnels between the downlink sites and an > IGP carrying plane prefixes should work very nicely for little > additional (physical) cost. It also has the nice property that your > latency to the plane is not nearly as bad as bouncing to a single, fixed > downlink would be. You can also decrease latency by adding (virtual) > connectivity anywhere in the global topology to redirect traffic into > the backhaul topology. >=20 > Hiding mobility is a good option for the cases where you're not going to > actually change providers. >=20 > Tony >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 10:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdrB-0005LX-Ed; Mon, 13 Nov 2006 10:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj30e-0007eP-E6 for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:15:40 -0500 Received: from rommie.caida.org ([192.172.226.78] helo=caida.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj30b-0005gu-4C for architecture-discuss@ietf.org; Sat, 11 Nov 2006 19:15:40 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net [24.125.117.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by caida.org (Postfix) with ESMTP id BBAA7BA12; Sat, 11 Nov 2006 16:15:33 -0800 (PST) In-Reply-To: <004701c705de$ee620bb0$9d01a8c0@tropos.com> References: <004701c705de$ee620bb0$9d01a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tom Vest Subject: Re: [arch-d] It's the routing, people! Date: Sat, 11 Nov 2006 19:15:27 -0500 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Mon, 13 Nov 2006 10:36:18 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 5:15 PM, Tony Li wrote: > > >> actually, I asked Geoff about this, and he told me that ~15K >> AS's had only one upstream AS, > > Only one that Geoff could see from his vantage point? Or only one > period? > > If the latter, that would be an indication that RIR's and others are > being conned into giving out ASNs and prefixes for PI purposes for > singly homed customers. ;-( > > Tony This issue is not unknown, and plausibly (personal speculation only) is one of the reasons behind the ARIN "policy reinterpretation" of 12 Feb 2006: http://www.arin.net/announcements/archives/20060222.html The issue has troubled me for some time also. No doubt some of the apparent single-homers have private AS adjacencies that don't show up, e.g., in Route Views. Hard to imagine this explaining away close to 15k ASes -- all but about 225 of which post-date the RFC 1930, the RIRs, et al. Casual inquiries with the three old RIRs suggest that "very few" ASNs have been allocated on the basis of RFC 2270... Tom Vest _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 10:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdrB-0005Lm-S9; Mon, 13 Nov 2006 10:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdjV-0000TV-4Z for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:28:25 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjdjT-0001Qp-RX for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:28:25 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kADFSMRE022930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2006 09:28:23 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kADFSMWH004749; Mon, 13 Nov 2006 07:28:22 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kADFSJZI004690; Mon, 13 Nov 2006 07:28:21 -0800 (PST) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 07:28:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Mon, 13 Nov 2006 07:28:19 -0800 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD2A5E@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <003401c705c9$e456af00$9d01a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanAAFrNCPA= From: "Davis, Terry L" To: , "Marshall Eubanks" X-OriginalArrivalTime: 13 Nov 2006 15:28:19.0702 (UTC) FILETIME=[590E4960:01C70738] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Mon, 13 Nov 2006 10:36:18 -0500 Cc: "Fleischman, Eric" , Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony/Marshall This type of concept is one of several we are discussing for the global ATC network and we could conceivably extend it for the airline operations domain. Take care Terry > -----Original Message----- > From: Tony Li [mailto:tli@tropos.com] > Sent: Saturday, November 11, 2006 11:45 AM > To: 'Marshall Eubanks'; tony.li@tony.li > Cc: Fleischman, Eric; 'Brian E Carpenter'; 'Noel Chiappa'; architecture- > discuss@ietf.org; Davis, Terry L > Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off- > topic]Further thoughts: about systems theory and the theory U) >=20 >=20 >=20 > > One place where the loc/id split might make a lot of sense would be > > in mobile platform internets (MPI's), such as > > modern commercial airliners with routers, lots of networked devices > > and three or more internal subnets and address blocks per plane (see > > some of the documents at http://www.multicasttech.com/mpi/ if you > > want more details). 10,000 such planes flying around would tax even > > an airplane only BGP network. >=20 >=20 > Hi Marshall, >=20 > That's certainly one approach. However, there's another solution to > this issue that doesn't really require architectural changes. >=20 > If you take a look at how our friends at Connexion did things, they > assigned one prefix per plane and then injected it into global routing > at the point of its current downlink. >=20 > With all due respect, an alternate approach would be to have a separate > global domain that provides backhaul and have that domain inject all > plane prefixes from all points simultaneously, effectively causing > everyone to perform hot-potato routing to them with stable BGP > injection. Note that the backhaul network need not be physically > instantiated: a full mesh of tunnels between the downlink sites and an > IGP carrying plane prefixes should work very nicely for little > additional (physical) cost. It also has the nice property that your > latency to the plane is not nearly as bad as bouncing to a single, fixed > downlink would be. You can also decrease latency by adding (virtual) > connectivity anywhere in the global topology to redirect traffic into > the backhaul topology. >=20 > Hiding mobility is a good option for the cases where you're not going to > actually change providers. >=20 > Tony >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 10:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gje2m-0003d7-CE; Mon, 13 Nov 2006 10:48:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gje2k-0003d2-L9 for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:48:18 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gje2f-0004a8-9W for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:48:18 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id F2DCD3419D; Mon, 13 Nov 2006 10:48:12 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 10:48:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re:[arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Mon, 13 Nov 2006 10:48:08 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCECDA7B@tayexc14.americas.cpqcorp.net> In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A01BD2A5D@XCH-NW-8V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re:[arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanAAB2ueDAAPdVX8AABJNLQ From: "Bound, Jim" To: "Davis, Terry L" , , "Marshall Eubanks" , X-OriginalArrivalTime: 13 Nov 2006 15:48:12.0691 (UTC) FILETIME=[2021F630:01C7073B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: "Fleischman, Eric" , "Ivancic, William D. \(\(GRC-RCN0\)\)" , Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Terry, ACK. Best, /jim=20 > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis@boeing.com]=20 > Sent: Monday, November 13, 2006 10:22 AM > To: Bound, Jim; tony.li@tony.li; Marshall Eubanks;=20 > MPI@multicasttech.com > Cc: Fleischman, Eric; Noel Chiappa;=20 > architecture-discuss@ietf.org; Ivancic, William D. ((GRC-RCN0)) > Subject: RE: Ok, so what should we do then? (Was:=20 > Re:[arch-d][Off-topic]Further thoughts: about systems theory=20 > and the theory U) >=20 > Jim >=20 > For aviation mobility, that's what Marshall, Will Ivancic and=20 > I are trying to do with the web site and drafts below. By=20 > the Prague IETF meeting, we hope to have made significant=20 > updates to both the problem statement draft and the aviation=20 > requirements draft. >=20 > Website: > http://www.multicasttech.com/mpi/=20 >=20 > Drafts: > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-10.txt > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-us > e-10.txt=20 >=20 > Take care > Terry >=20 > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound@hp.com] > > Sent: Sunday, November 12, 2006 1:47 AM > > To: tony.li@tony.li; Marshall Eubanks > > Cc: Fleischman, Eric; Noel Chiappa; Davis, Terry L; architecture-=20 > > discuss@ietf.org > > Subject: RE: Ok, so what should we do then? (Was: Re:[arch-d][Off-=20 > > topic]Further thoughts: about systems theory andthe theory U) > >=20 > > Backhauling is a notion whose day has come and I for one believe we > need > > to understand how it can assist the routing. Agree totally=20 > that when=20 > > one changes providers the mobility has to be "seamless"=20 > simply because=20 > > there is a good chance the locator has to change for the=20 > mobile node. > > The reason that is relative it requires routing analysis=20 > and I believe=20 > > part of this problem. > >=20 > > But it would be real great if we could write up the set of "what=20 > > problems are we trying to solve". > >=20 > > /jim > >=20 > > > -----Original Message----- > > > From: Tony Li [mailto:tli@tropos.com] > > > Sent: Saturday, November 11, 2006 2:45 PM > > > To: 'Marshall Eubanks'; tony.li@tony.li > > > Cc: 'Fleischman, Eric'; 'Noel Chiappa'; 'Terry L Davis';=20 > > > architecture-discuss@ietf.org > > > Subject: RE: Ok, so what should we do then? (Was: > > > Re:[arch-d][Off-topic]Further thoughts: about systems=20 > theory andthe=20 > > > theory U) > > > > > > > > > > > > > One place where the loc/id split might make a lot of sense > > > would be in > > > > mobile platform internets (MPI's), such as modern > > > commercial airliners > > > > with routers, lots of networked devices and three or=20 > more internal=20 > > > > subnets and address blocks per plane (see some of the=20 > documents at=20 > > > > http://www.multicasttech.com/mpi/ if you want more details). > 10,000 > > > > such planes flying around would tax even an airplane only > > > BGP network. > > > > > > > > > Hi Marshall, > > > > > > That's certainly one approach. However, there's another=20 > solution to=20 > > > this issue that doesn't really require architectural changes. > > > > > > If you take a look at how our friends at Connexion did=20 > things, they=20 > > > assigned one prefix per plane and then injected it into global=20 > > > routing at the point of its current downlink. > > > > > > With all due respect, an alternate approach would be to have a=20 > > > separate global domain that provides backhaul and have=20 > that domain=20 > > > inject all plane prefixes from all points simultaneously,=20 > > > effectively causing everyone to perform hot-potato=20 > routing to them=20 > > > with stable BGP injection. Note that the backhaul=20 > network need not=20 > > > be physically > > > instantiated: a full mesh of tunnels between the downlink=20 > sites and=20 > > > an IGP carrying plane prefixes should work very nicely for little=20 > > > additional (physical) cost. It also has the nice=20 > property that your=20 > > > latency to the plane is not nearly as bad as bouncing to=20 > a single,=20 > > > fixed downlink would be. You can also decrease latency by adding=20 > > > (virtual) connectivity anywhere in the global topology to=20 > redirect=20 > > > traffic into the backhaul topology. > > > > > > Hiding mobility is a good option for the cases where you're not=20 > > > going to actually change providers. > > > > > > Tony > > > > > > > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 11:45:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjevp-000589-Mk; Mon, 13 Nov 2006 11:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjevo-00057X-9y for architecture-discuss@ietf.org; Mon, 13 Nov 2006 11:45:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjevm-0004Or-Th for architecture-discuss@ietf.org; Mon, 13 Nov 2006 11:45:12 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2006 08:44:25 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="344239766:sNHT4393440830" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kADGiOSE013116; Mon, 13 Nov 2006 08:44:24 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kADGiOio024526; Mon, 13 Nov 2006 08:44:24 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 08:44:24 -0800 Received: from [10.10.10.102] ([10.21.144.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 08:44:24 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <013080DE-2F8A-403C-BC5E-68687092C44B@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] It's the routing, people! Date: Mon, 13 Nov 2006 08:44:24 -0800 To: X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Nov 2006 16:44:24.0028 (UTC) FILETIME=[F99B29C0:01C70742] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1816; t=1163436264; x=1164300264; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20It's=20the=20routing,=20people! |Sender:=20; bh=LrsEv0LqaEOuTPsrSgst0OoCmtYAXF+7JXQqCxXCZZ0=; b=hCs6Osc5KjHyHqInGxhBBuK1NwsO69Iz6x21QIYDwGSqSbh3HdhFfnF4ELheBqqrR09k1Oc0 Wt5hwTlpPwbctOWJkNAvk7ls9Gn334mz+jXtednLiVnNX3+H+Ak/2hhg; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Both the RIB and the FIB are important, although of course the FIB is a more expensive type of memory. if the raw data in the RIB doesn't scale well, the smartest algorithm in the FIB isn't going to be able to make it compact. Yes, good algorithms are a good thing. We came here to find a way to make the raw data in Internet routing scale. On Nov 13, 2006, at 8:29 AM, wrote: > I thought the proposal was to not put all that redundant data on > your HW > forwarding path, even if that existed on the BGP routing table. Some > local aggregation magic within a router. > > The issue was running out of this expensive special memory > searched at > line speeds, not the memory used for BGP protocol operation. > > We would not be witnessing this discussion if the solution was to > utilize smarter algorithms to transform BGP FIB into a next-hop > forwarding database for a router having fixed set of next hops, right? > > Jarno > >> -----Original Message----- >> From: ext Tony Li [mailto:tli@tropos.com] >> Sent: 12 November, 2006 22:20 >> To: 'Iljitsch van Beijnum'; 'Fred Baker' >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] It's the routing, people! >> >> >> >>> What about we all give our favorite vendors some $$ and they >> build in >>> some aggregation magic that makes all of this disappear? >> >> >> Proxy aggregation was rejected by the operational community >> long ago, primarily due to the global traffic engineering >> effects. The knobs for doing this manually are already there. >> >> Tony >> >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 11:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjf4K-0002if-38; Mon, 13 Nov 2006 11:54:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjf4I-0002hN-Qg for architecture-discuss@ietf.org; Mon, 13 Nov 2006 11:53:58 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjf4H-0005sP-Ak for architecture-discuss@ietf.org; Mon, 13 Nov 2006 11:53:58 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kADGTdvV027124; Mon, 13 Nov 2006 18:31:16 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 18:29:11 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 18:29:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Mon, 13 Nov 2006 18:29:09 +0200 Message-ID: In-Reply-To: <006f01c70697$ef56a5d0$9d01a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccGYRbzjeHOWY4KSG6mc9HGjmAp8QANpoRgACmPOHA= From: To: , , X-OriginalArrivalTime: 13 Nov 2006 16:29:11.0128 (UTC) FILETIME=[D979AD80:01C70740] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I thought the proposal was to not put all that redundant data on your HW forwarding path, even if that existed on the BGP routing table. Some local aggregation magic within a router. The issue was running out of this expensive special memory searched at line speeds, not the memory used for BGP protocol operation. We would not be witnessing this discussion if the solution was to utilize smarter algorithms to transform BGP FIB into a next-hop forwarding database for a router having fixed set of next hops, right? Jarno >-----Original Message----- >From: ext Tony Li [mailto:tli@tropos.com]=20 >Sent: 12 November, 2006 22:20 >To: 'Iljitsch van Beijnum'; 'Fred Baker' >Cc: architecture-discuss@ietf.org >Subject: RE: [arch-d] It's the routing, people! > >=20 > >> What about we all give our favorite vendors some $$ and they=20 >build in=20 >> some aggregation magic that makes all of this disappear? > > >Proxy aggregation was rejected by the operational community=20 >long ago, primarily due to the global traffic engineering=20 >effects. The knobs for doing this manually are already there. > >Tony > > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 12:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfbJ-00010d-Js; Mon, 13 Nov 2006 12:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfbI-00010X-AZ for architecture-discuss@ietf.org; Mon, 13 Nov 2006 12:28:04 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfbB-0001yo-Vu for architecture-discuss@ietf.org; Mon, 13 Nov 2006 12:28:04 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C503E4AC48; Mon, 13 Nov 2006 12:27:54 -0500 (EST) Date: Mon, 13 Nov 2006 12:27:54 -0500 From: John Leslie To: Geoff Huston Subject: Re: [arch-d] It's the routing, people! Message-ID: <20061113172754.GR73049@verdi> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> <7.0.0.16.2.20061112035216.0140b900@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.0.16.2.20061112035216.0140b900@apnic.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Geoff Huston wrote: > > I don't see routing melting today. Today I see a class of FIB > implementations coming close to a current design limit. My understanding of the situation is that the expected "meltdown" is a matter of recalculating "best route" as routes are added and withdrawn too quickly -- not a matter of having "too many" routes. Thus, "FIB implementations" "coming close" etc. confuses me. The today-standard _forwarding_ algorhithm of matching closest enclosing prefix-length, as I understand it, is in no danger of meltdown. The "meltdown" is in analyzing RIB information to find a new "best route" (which must be done before any updates can be propagated). (There may be some routers in or near the backbone which can't forward all their packets at wire speed because the forwarding table is "too big"; but that is neither a "mestdown" nor what routing experts would call "routing".) > I don't necessarily accept that FIB meltdown is only prevented by > changing the routing paradigm, as I still don't accept that > FIB = RIB. Forwarding Information Base _isn't_ the same as Routing Information Base. Period. Nor is changing the routing paradigm an appropriate "fix" for routers which can't forward at wire speed. Period. > I see that if per packet performance is critical, and that appears > to be the case, (which, BTW, is engineering, not architecture...) > then the lookup performed per packet should be fast. Agreed. > But I don't accept that this necessarily implies that you have to > perform this lookup over the equivalent of the RIB stuffed into a > fast lookup data structure to derive an answer that is of the same > order as the number of physical egress choices on the box. Nor should you. Not merely is this engineering, not architecture: it is _bad_ engineering! > I suspect that a better understanding of the semantics of addresses, > and the distinction, even in a constrained routing world about what > are the characteristics of the packet's source and destination tag, > and the relationship of these two tags to the forwarding path across > the network are useful in understanding the relationship to the > problem being presented here I'm going to take a chance here, and introduce a layering paradigm which I find helpful in understanding this _architecturally_. We all understand, I hope the concept of a layer I'll call "internetworking" (commonly called OSI "network" layer, but I'll avoid that because of all the expectations it has accumulated). This layer allows packets on one network to be forwarded across other networks to (usually) reach their destinations on a final network. To accomplish this the destination provides an address in "internetworking" space which has a consistent meaning as to what final network a packet addressed to it should reach. (It also has information about what host on that network it should reach, but that should be considered meaningful _only_ to the destination network.) This "internetworking address" does _not_ contain information on how to get to the destination (except in the trivial case where you're already on the destination network). How to get there is commonly called "routing". It's a matter of finding a network "closer" to the destination and forwarding it to that network. What routing gurus call "routing" is somewhat different: it's any workable scheme to make sure that in the mythical "steady state" _every_ router will have a consistent view of what is "closer". Otherwise, packets can get stuck in loops, never reaching their destinations and clogging the forwarding paths so that other traffic crawls to a standstill. Let's stop there: the "internetworking" layer is designed to "usually" work "in the steady state". > and the degrees of freedom in the symbol space that we can manipulate > to provide mitigation, both in the short and long term. I'll get around to that later. > So I interpret your request to table all consideration on the > semantics of an address at the routing level as being unwise > and overly tactical (yes, "tactical" as in the full sense of the > quote you provided below). Note the "at the routing level"... > At 03:00 AM 12/11/2006, Noel Chiappa wrote: >> >> (There's also a military maxim about "amateurs study tactics, >> professionals study logistics" - I'll leave it to you all to work >> out how I'd modify that for us.) Those "professionals" know you need the right things in the right places at the right time before "tactics" can be applied. >> So, until we have figured out how the routing is going to work, >> can we please table *all* discussion of what the addresses are >> going to look like? Thank you. Routing-as-we-know-it will (to repeat myself) " " "usually" work "in the steady state". And should consider as an opaque string any part of any address it ebcounters which it can't use for forwarding from network to network. This, IMHO, is good. YMMV... Feel free to propose an alternative routing scheme... Meanwhile, let me return to architectural layers. My next layer I call "transport". I think of this as close enough to OSI layer 4 that there shouldn't be confusion... YMMV... My "transport" layer worries mostly about reliability. Thus, it should detect the loss of packets and deal with it; and it should detect corruption of packets and deal with it. That bears repeating: my "transport" layer should detect the loss of packets and deal with it; and it should detect corruption of packets and deal with it. We're not in 1970 anymore. We have better ways of dealing with loss or corruption than blind retransmission. The only other function of my "transport" layer I will cover here is congestion management. This isn't really even an "other" function, but it would seem to overlap with a congestion control issue at my "internetworking" layer. At the "transport" layer, you want to maximize utility. Usually this means maximize reliable throughput. In an ideal internetwork, there will be multiple paths. My "transport" layer, therefore, should be able to recognize congestion along one path and shift some traffic to another path. The "internetworking" layer, IMHO, should be able to report that it is experiencing congestion on a route. This should not change forwarding unless the congestion is severe enough to disincent the use of that route. (Conceptually, this is very similar to a short outage.) Enough for one post! -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 12:54:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjfzt-00017s-1a; Mon, 13 Nov 2006 12:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjfzr-00017m-GQ for architecture-discuss@ietf.org; Mon, 13 Nov 2006 12:53:27 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjfzo-0005DS-73 for architecture-discuss@ietf.org; Mon, 13 Nov 2006 12:53:27 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id kADHrG8D009955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2006 09:53:17 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kADHrG1b029404; Mon, 13 Nov 2006 11:53:16 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kADHr99Y029022; Mon, 13 Nov 2006 11:53:15 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 09:53:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Mon, 13 Nov 2006 09:53:10 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584B75@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <816DD9299957E547B5D758D7F977D6DCE8B227@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccFuArNxsDNOLg+S6ODmteW6VEbbgAhjA8AAEMnHoA= From: "Fleischman, Eric" To: "Bound, Jim" , "Noel Chiappa" , X-OriginalArrivalTime: 13 Nov 2006 17:53:12.0018 (UTC) FILETIME=[96147320:01C7074C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I actually think that this discussion is exactly what the doctor ordered at this stage. I surmise that while the basic facts are agreed upon, there is still a fair bit of analysis needed to confirm or modify Tony's observation that "we could reduce the growth due to a) TE, b) multihoming, and c) fraudulent PI allocations."=20 Our understanding of the issues are too fuzzy at this point to move into an IETF WG. It would be better for a small community to produce a detailed analysis the current state of the actual domain and then a larger community to brainstorm possible technical alternatives. Once we've done that, then we can form an IETF WG to progress the issue. -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com]=20 Fine to brainstorm on this list and hear all persons ideas and thoughts but this needs a more focused IETF process with working groups, IETF rules of engagement etc. and to adhere well to Sam Hartmans word of caution at the Plenary which is working well thus far. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 13:11:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgGJ-00037V-Am; Mon, 13 Nov 2006 13:10:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgGI-00037M-3g for architecture-discuss@ietf.org; Mon, 13 Nov 2006 13:10:26 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjgGC-0007O0-RD for architecture-discuss@ietf.org; Mon, 13 Nov 2006 13:10:26 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 09FBF34139; Mon, 13 Nov 2006 13:10:23 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:10:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Mon, 13 Nov 2006 13:10:18 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCECDB9F@tayexc14.americas.cpqcorp.net> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B75@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccFuArNxsDNOLg+S6ODmteW6VEbbgAhjA8AAEMnHoAAANyoQA== From: "Bound, Jim" To: "Fleischman, Eric" , "Noel Chiappa" , X-OriginalArrivalTime: 13 Nov 2006 18:10:20.0207 (UTC) FILETIME=[FAEDA3F0:01C7074E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Valid and I think the process will be similar to as you suggest from my read between the lines from the Plenary (clearly subjective for sure), but I believe that small community needs to be very diverse in views and we need to be very careful with that one and it might be better to form another list based on volunteers rather than selection by a few randomly. Always tough to find a balance and make sure all and diverse views are represented even for a clay model. But right now we are hearing things all over the map of what I believe is the problem space and I am positive my view is skewed so trying not to share it until later once the staircase of abstraction for analysis is better identified to move forward. /jim=20 > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20 > Sent: Monday, November 13, 2006 12:53 PM > To: Bound, Jim; Noel Chiappa; architecture-discuss@ietf.org > Subject: RE: Ok, so what should we do then? (Was: Re:=20 > [arch-d][Off-topic]Further thoughts: about systems theory and=20 > the theory U) >=20 > I actually think that this discussion is exactly what the=20 > doctor ordered at this stage. I surmise that while the basic=20 > facts are agreed upon, there is still a fair bit of analysis=20 > needed to confirm or modify Tony's observation that "we could=20 > reduce the growth due to a) TE, b) multihoming, and c)=20 > fraudulent PI allocations."=20 >=20 > Our understanding of the issues are too fuzzy at this point=20 > to move into an IETF WG. It would be better for a small=20 > community to produce a detailed analysis the current state of=20 > the actual domain and then a larger community to brainstorm=20 > possible technical alternatives. Once we've done that, then=20 > we can form an IETF WG to progress the issue. >=20 > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] Fine to=20 > brainstorm on this list and hear all persons ideas and=20 > thoughts but this needs a more focused IETF process with=20 > working groups, IETF rules of engagement etc. and to adhere=20 > well to Sam Hartmans word of caution at the Plenary which is=20 > working well thus far. > >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 13:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgIb-00079z-42; Mon, 13 Nov 2006 13:12:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgIZ-00079p-0F for architecture-discuss@ietf.org; Mon, 13 Nov 2006 13:12:47 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjgIX-0007kd-Nr for architecture-discuss@ietf.org; Mon, 13 Nov 2006 13:12:46 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GjgIU-0004dP-CE for architecture-discuss@ietf.org; Mon, 13 Nov 2006 10:12:43 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 19:12:59 +0100 To: John Leslie ,Geoff Huston From: Jefsey_Morfin Subject: Re: [arch-d] It's the routing, people! In-Reply-To: <20061113172754.GR73049@verdi> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> <7.0.0.16.2.20061112035216.0140b900@apnic.net> <20061113172754.GR73049@verdi> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 2.0 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0874159330==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0874159330== Content-Type: multipart/alternative; boundary="----MTefyjdzhbcwoscraixnilxjjmbwtexmdx" ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-44D860D6 At 18:27 13/11/2006, John Leslie wrote: >Those "professionals" know you need the right things in the right >places at the right time before "tactics" can be applied. I am afraid that knowing is not enough. Making sure is the issue. The whole issue is not knowing how it could work, but that it works. There are different ways which could work. Priority is to work out the one which will deliver. When something is to be done, an amateur accepts it is badly done, a professional demands it is well done. The first solution will work the same but it will not scale. What you eventually document is the need for dynamic routing. Due to the network size this is not possible unless the addressing builds the topology. Question is: has the network system gained the necessary maturity, or is it still in a deployment phase where topology commands addressing? jfc ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/html At 18:27 13/11/2006, John Leslie wrote:
>Those "professionals" know you need the right things in the right
>places at the right time before "tactics" can be applied.

I am afraid that knowing is not enough. Making sure is the issue.
The whole issue is not knowing how it could work, but that it works.
There are different ways which could work. Priority is to work out
the one which will deliver.

When something is to be done, an amateur accepts it is badly done, a
professional demands it is well done. The first solution will work
the same but it will not scale.

What you eventually document is the need for dynamic routing. Due to
the network size this is not possible unless the addressing builds
the topology. Question is: has the network system gained the
necessary maturity, or is it still in a deployment phase where
topology commands addressing?

jfc


------MTefyjdzhbcwoscraixnilxjjmbwtexmdx-- --===============0874159330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0874159330==-- From architecture-discuss-bounces@ietf.org Mon Nov 13 14:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh1Q-0000sE-Pl; Mon, 13 Nov 2006 13:59:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh1Q-0000s9-2C for architecture-discuss@ietf.org; Mon, 13 Nov 2006 13:59:08 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjh1L-0006Tm-Q9 for architecture-discuss@ietf.org; Mon, 13 Nov 2006 13:59:08 -0500 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kADIwaf2021551; Tue, 14 Nov 2006 05:58:36 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061114053849.050d9008@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 14 Nov 2006 05:58:29 +1100 To: John Leslie From: Geoff Huston Subject: Re: [arch-d] It's the routing, people! In-Reply-To: <20061113172754.GR73049@verdi> References: <20061111160000.7BDFA872C1@mercury.lcs.mit.edu> <7.0.0.16.2.20061112035216.0140b900@apnic.net> <20061113172754.GR73049@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 04:27 AM 14/11/2006, John Leslie wrote: >Geoff Huston wrote: > > > > I don't see routing melting today. Today I see a class of FIB > > implementations coming close to a current design limit. > > My understanding of the situation is that the expected "meltdown" >is a matter of recalculating "best route" as routes are added and >withdrawn too quickly -- not a matter of having "too many" routes. This sounds like a different story to me. The one that I heard Tony Li tell the Routing and Addressing the workshop was based on per-packet FIB lookup and the price performance of the chipsets that perform such lookups in the face of further scaling of the FIB and potential increases in packet rates. I've not heard the issue of recalculation of "best routers" as being critical until your note. Do you have any references for this that I (and other interested folk on this list) could follow up and read on? > Thus, "FIB implementations" "coming close" etc. confuses me. As I noted above, what you have describe above appears to be a different issue. If that's the case then its little wonder that there is some confusion here! > The today-standard _forwarding_ algorhithm of matching closest >enclosing prefix-length, as I understand it, is in no danger of >meltdown. The "meltdown" is in analyzing RIB information to find >a new "best route" (which must be done before any updates can be >propagated). I'm sorry, but I can't follow this - the RIB passes are by no means done in "per packet forwarding time", indeed there is no a priori pre-set time in which the RIB pass need be performed in any case. You can use "plain" old memory for the RIB and use "plain" old (well not too old please!) processors for the RIB pass and nothing breaks as far as I am aware. Neither of these are critical in terms of price performance and are not, at least as I understand it, critical issues in router hardware. (No, I don't build routers, not even at home, so I obviously don't have a clue what I'm talking about! :-)) > (There may be some routers in or near the backbone which can't >forward all their packets at wire speed because the forwarding >table is "too big"; but that is neither a "mestdown" nor what >routing experts would call "routing".) If the forwarding plane can't scale in performance terms and can't continue to deliver per packet unit cost reductions in switching then, yes, from my perspective I find myself in agreement with the prognosis of Tony Li when he observes that that we appear to have a fundamental routing and addressing problem. > > I don't necessarily accept that FIB meltdown is only prevented by > > changing the routing paradigm, as I still don't accept that > > FIB = RIB. > > Forwarding Information Base _isn't_ the same as Routing Information >Base. Period. Well these days in the implementations of router systems I'm aware of the FIB appears to be the much the same size as the RIB and share the same dynamic properties as the RIB, and contain similar information to the RIB. So if it quacks like a duck, walks like a duck and swims like a duck then it must be an elephant? right? :-) > Nor is changing the routing paradigm an appropriate "fix" for >routers which can't forward at wire speed. Period. Apparently we differ in perspective here. Period. > > I see that if per packet performance is critical, and that appears > > to be the case, > > (which, BTW, is engineering, not architecture...) At this stage we appear to be lost in a forest of semantic distinctions, none of them appear to me to be overly useful to assist in creating an analytic taxonomy! :-) cheers, Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 14:26:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhQs-0002n8-0p; Mon, 13 Nov 2006 14:25:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhPH-0001sR-Ls for architecture-discuss@ietf.org; Mon, 13 Nov 2006 14:23:47 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjhPG-0002Bi-1W for architecture-discuss@ietf.org; Mon, 13 Nov 2006 14:23:47 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id kADJNbjk014713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2006 11:23:37 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kADJNbZe027491; Mon, 13 Nov 2006 11:23:37 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kADJNNT1026818; Mon, 13 Nov 2006 11:23:29 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:23:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Mon, 13 Nov 2006 11:23:20 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584B79@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <004a01c705f7$c8b9f6c0$9d01a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccF9lkzxWe6Lk4/TzCTkGasDzMo0QAAS4/wAFad2fA= From: "Fleischman, Eric" To: , "Noel Chiappa" , X-OriginalArrivalTime: 13 Nov 2006 19:23:22.0094 (UTC) FILETIME=[2EBC88E0:01C70759] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Good answer, Tony!! Many Internet architects are apparently keen to burden us end users with multiple addresses. To the extent that Multi6 and Shim6 do this, to that extent they will be resisted for deployment into real life networks. People who intend for us to physically assign different addresses for each of our ISPs to each of our computers have not really understood the primary end user addressing requirement: no readdressing for something as unimportant as who our ISPs are. There are administrative, management, and security implications of multiple addresses that make them impractical for today's networks (unless there is a compelling business reason to justify those overhead expenses and risk).=20 Shifting the burden from ISPs to the end user is just not going to cut it. Why does anybody imagine that end users will willingly bear significant operational expenses for a problem that isn't even visible to us? ISPs are a fraction of our size -- and we are the customer!! Unless a monopoly situation exists, why would anybody maintain business relationships with an uncooperative ISP?=20 Rather, a clean solution that is equally good for everybody has to be found, which is why I personally have supported the loc/id split approach for many years now. Alternatively, we can NAT. -----Original Message----- From: Tony Li [mailto:tli@tropos.com]=20 Sent: Saturday, November 11, 2006 5:14 PM > I don't think there's any way in the routing alone to support > multi-homing in > a way which reduces table growth (at least as long as the=20 > only scope we have > for advertisements, other than "local", is "global"). To=20 > support multi-homing > without impacting the routing, it seems that the way to go is=20 > have multiple > locators for each multi-homed entity (which is the way Multi6=20 > eventually > went, with Shim6, but nobody likes the mechanism). So if we=20 > do, say GSE, how > do we make multi-homing work, using multiple addresses? In my mind, that's one of the primary benefits of any loc/id split. Multiple locators per-site, with locator replacement at the border. I've always thought of this as being one of the primary applications of GSE. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 20:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjn7K-0002hc-2x; Mon, 13 Nov 2006 20:29:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjn73-0002O0-FT for architecture-discuss@ietf.org; Mon, 13 Nov 2006 20:29:21 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjmyC-0001v2-Sl for architecture-discuss@ietf.org; Mon, 13 Nov 2006 20:20:14 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 19:20:06 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Mon, 13 Nov 2006 19:21:43 -0600 Message-ID: In-Reply-To: <20061112.102757.2521.1436547@webmail51.lax.untd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccGiIUQujMXwQ2LT8ut3PkOQ0S/NwA+5sJQ From: "Schliesser, Benson" To: X-OriginalArrivalTime: 14 Nov 2006 01:20:06.0389 (UTC) FILETIME=[04B0C250:01C7078B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fergie [mailto:fergdawg@netzero.net] wrote: > I know I'm probably going to hate myself for saying this, but > perhaps it is time for us to revisit the value of "selective" > methods for proxy aggregation? It's a sensitive topic, for sure, > which is why I highly emphasize the word: "selective"... The basic issue with proxy aggregation is that it breaks TE. (In turn, possibly breaking connectivity.) If we had some way of doing proxy aggregation while maintaining TE functionality then I suppose we'd have something useful, but as far as I can imagine that would require awareness/information beyond the borders of the aggregating AS's perspective. Thinking about this inspires me to propose a requirement. It's possible that everybody agrees and I'm simply stating the obvious, but let me be explicit regardless: The routing system must support arbitrary connectivity between transit networks. For instance, one could envision a (poor) solution to the aggregation problem that involves tunneling between the "primary" AS that assigns PA space to the end network and each other AS it multi-homes to. This would allow the global routing system to forward packets to the primary network, which would be responsible for forwarding over tunnels to the secondary networks during link failure etc. This constrains more specific prefixes to just those networks that are directly supporting the end customer. However this defeats one of the most important reasons that a network multi-homes--survival during failure of the primary provider's network. Thus each AS needs the ability to provide connectivity to the end network independently of any other AS (to the degree allowed by their peering/connectivity, of course). To extend on this, one could possibly imagine yet other schemes that allow for aggressive aggregation in the global system but which create a reliance on the "Tier 1" crowd for routing and connectivity. (I.e., similar to the "tunnel" model above, but with a group of "core" networks that everybody relies upon instead of a single "primary" network.) This might have better survivability/resiliency properties, but it also institutes an economic hierarchy that would ultimately be stifling and dangerous (socially, economically, politically, in terms of long-term security and stability of the network, etc). The way to avoid these issues is to allow networks to connect directly to each other, and have any connectivity graph / topology they might desire. This is the tussle counter-balance... Note that I'm talking specifically about transit networks here, which excludes end networks (leaf networks) that don't want to provide connectivity but merely want to receive connectivity services. (and possibly don't need an ASN) Is this an obvious requirement? Does anybody disagree? I have to admit, it certainly makes things more difficult in any case. (Is it even possible theoretically? I'm only slightly aware of Dima's/Claffy's recent work, so I don't quite know its properties versus my above proposed requirement. Perhaps somebody with a topology/graph theory background can comment?) Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 21:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjnjg-00072T-8l; Mon, 13 Nov 2006 21:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjnhc-00060Q-2u for architecture-discuss@ietf.org; Mon, 13 Nov 2006 21:07:08 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjnTe-0007H9-2X for architecture-discuss@ietf.org; Mon, 13 Nov 2006 20:52:43 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 19:52:41 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Mon, 13 Nov 2006 19:54:20 -0600 Message-ID: In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B79@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccF9lkzxWe6Lk4/TzCTkGasDzMo0QAAS4/wAFad2fAADlCfIA== From: "Schliesser, Benson" To: X-OriginalArrivalTime: 14 Nov 2006 01:52:41.0811 (UTC) FILETIME=[92367A30:01C7078F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fleischman, Eric [mailto:eric.fleischman@boeing.com] wrote: > Many Internet architects are apparently keen to burden us end users with > multiple addresses. > [...] > People who intend for us to physically assign different addresses for > each of our ISPs to each of our computers have not really understood the > primary end user addressing requirement: no readdressing for something > as unimportant as who our ISPs are. > [...] > Unless a monopoly situation exists, why would anybody maintain business > relationships with an uncooperative ISP? I think this is an excellent point, Eric, and I fundamentally agree with the sentiment. But I'm curious about your perception of multiple addresses as burdensome. For instance, with some of the auto-configuration options currently available this could be as simple as adding a prefix to your gateways for each ISP that you want to enable. Is there an acceptable-burden crossover point somewhere between "physically assign[ing]" addresses and the ideal zero-work "no readdressing" scenarios? > Shifting the burden from ISPs to the end user is just not going to cut > it. Why does anybody imagine that end users will willingly bear > significant operational expenses for a problem that isn't even visible > to us? Well, here is my perspective: The scale problems in the global routing system are economic externalities from the end network's perspective. This may (probably?) eventually lead to relative rising costs for the provider. Which would ultimately become a cost to the customer, though perhaps not until the provider marketplace is turned upside down. Given the options of 1) higher monetary costs for services, 2) higher administrative costs for renumbering, or 3) the cost of adopting whatever cool new technology we come up with, I'm betting on end networks / customers choosing #3. (unless we totally screw up the technology, I suppose) > Rather, a clean solution that is equally good for everybody has to be > found, which is why I personally have supported the loc/id split > approach for many years now. Alternatively, we can NAT. One might argue that loc/id split methods that don't require endpoint involvement inherently require NAT. Though not all NAT methods are created equal... Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 21:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjnjk-0007BZ-UF; Mon, 13 Nov 2006 21:09:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjnhW-00062g-9K for architecture-discuss@ietf.org; Mon, 13 Nov 2006 21:07:02 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjnW8-0007YY-1j for architecture-discuss@ietf.org; Mon, 13 Nov 2006 20:55:17 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AF8CB86AE0; Mon, 13 Nov 2006 20:55:15 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] It's the routing, people! Message-Id: <20061114015515.AF8CB86AE0@mercury.lcs.mit.edu> Date: Mon, 13 Nov 2006 20:55:15 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Fleischman, Eric" >> From: Tony Li [mailto:tli@tropos.com]=20 >> In my mind, that's one of the primary benefits of any loc/id split. >> Multiple locators per-site, with locator replacement at the border. > Good answer, Tony!! Well, I think we basically agree, but let me comment on one point you raise, perhaps not so much for your benefit (as you probably already understand the point I'm going to make), as for that of others: > Many Internet architects are apparently keen to burden us end users > with multiple addresses. To the extent that Multi6 and Shim6 do this, > to that extent they will be resisted for deployment > ... > There are administrative, management, and security implications of > multiple addresses that make them impractical > ... > Shifting the burden from ISPs to the end user is just not going to cut > it. Why does anybody imagine that end users will willingly bear > significant operational expenses As I pointed out a while back: Multihoming is something that is done to provide *benefits*. Those are not *free*. There is a *cost* for them, and a multihoming design has to think about *where* and how much those costs are. "TANSTAAFL: There Ain't No Such Thing As A Free Lunch" http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt So when you speak of "the burden", I hear "the cost of providing to someone something extra they want, e.g. extra reliability". And then I seem to hear you say that you think the rest of the network should bear that cost, and not "shift" it "to the end user" - i.e. the party who's getting the benefit. Doesn't sound like fair economics to me. Having said that, I understand your point that assigning multiple configured identity/location fields per host is unbearably painful in a large organization. At the same time, I hope (in fact, I expect I can assume) that you can see that from the point of view of the routing, if an organization is multi-homed to widely disparate places in the network's connectivity topology, assigning multiple "routing-names" (to avoid the mental baggage of the term "addresses") is really the only way to economically provide that party that benefit. Which leads us to: > Rather, a clean solution that is equally good for everybody has to be > found, which is why I personally have supported the loc/id split > approach for many years now. and I have long agreed with that, as my note went on to point out: My contention, however, is that the "optimal" solution .. to the large space of multihoming "problems" involves extra capabilities in two different areas: - identity/location separation which is really the only way to reconcile that particular pairing of irresistable force (routing overhead) and the immovable rock (configuration difficulties). > Alternatively, we can NAT. Hmmm. Yes... There is always NAT. I gather than one of the things that drove NAT deployment (in addition to address space shortages) was the fact that it made switching ISP's a lot simpler... Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 23:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjpUA-0006uy-1f; Mon, 13 Nov 2006 23:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjpU9-0006tH-A7 for architecture-discuss@ietf.org; Mon, 13 Nov 2006 23:01:21 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjpU7-0008JP-Np for architecture-discuss@ietf.org; Mon, 13 Nov 2006 23:01:21 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAE41B2P006543; Tue, 14 Nov 2006 06:01:12 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 05:56:26 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 18:57:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Nov 2006 18:57:06 +0200 Message-ID: In-Reply-To: <20061111173657.75E3886AE9@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? Thread-Index: AccFuCgaU5oybmjpRfW4tN2eA0QeCQBiSf2g From: To: , X-OriginalArrivalTime: 13 Nov 2006 16:57:08.0310 (UTC) FILETIME=[C1275760:01C70744] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061114060115-180B4BB0-6A6FDA79/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [arch-d] RE: Ok, so what should we do then? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org How about limiting DFZ only for provider aggregatable addressing and using some on-demand routing and tunneling over the DFZ for PI prefixes? Initially this tunneling could be over existing IPv4. This could be pretty much like some of the tunneling based IPv6 transition methods, but you keep tunneling even if the DFZ transfers to IPv6. The border (where the tunneling happens) does on-demand lookups for PI destination addresses and caches the results. Reverse DNS lookups would work fine, as long as the PI addresses have prefixes that aggregate on organizational + some regional structure. Outside of the DFZ the PI addresses would be routed (internally) and packets with foreign PI destinations would be default routed towards DFZ. Some sites having too much peers to cope with number of tunnels would use just provider based addressing (e.g. content distributors) and cope with renumbering. That way the tunneling state would distribute to content servers and could be manageable on the side of the transport protocol context. In summary the proposal is to keep DFZ provider based only, and have PI addressed traffic tunnel over it, forever. This will happen naturally as an outcome of the IPv6 transition, if we keep the IPv6 DFZ free of PI addressed routes, as the tunneling mechanism is needed to IPv6 transition over IPv4 anyway. Regards, Jarno >-----Original Message----- >From: ext Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 >Sent: 11 November, 2006 19:37 >To: architecture-discuss@ietf.org >Cc: jnc@mercury.lcs.mit.edu >Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d]=20 >[Off-topic]Further thoughts: about systems theory and the theory U) > > > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) > > >> I don't believe in the "else try_and_forward(input_packet)" > >> clause, except for local traffic)... > > > I started to think through this whole issue, and=20 >discovered a problem. > > To see it, let's think in a little more detail about how=20 >the routing in > > a "jack-up" system is going to work. > >In an attempt to make slightly clearer what I was jabbering on=20 >about here, I have drawn a couple of quick, simplified=20 >diagrams which show some of the things I was talking about. > >Remember, I'm talking about the flow of routing data here,=20 >*not* packets, and the mappings you see happening from=20 >old-style to new-style are mappings of routing data, not=20 >mappings of packet source/destination addresses. > >Again, the basic issue is that we're trying to reduce the=20 >amount of routing information, but my concern is (basically)=20 >that until the very last "old-style" DFZ router goes away, we=20 >may have to maintain full old-style tables anyway in all=20 >routers everywhere - depending on how we set things up. > > >Anyway, the diagrams are here: > > http://ana-3.lcs.mit.edu/~jnc/tech/DisDFZ.jpg > >which shows the problems with discontiguous chunks of=20 >new-style DFZ (i.e. the repeated conversion from new-style=20 >locators back to old-style addresses), and >here: > > http://ana-3.lcs.mit.edu/~jnc/tech/ContDFZ.jpg > >which shows how the same technical issue (the reverse mapping=20 >from new-style addresses back to old-style) occurs with a=20 >large, continugous new-style DFZ on the edge, but how it's=20 >more manageable since it's only happening on a single boundary. > >So, try rereading my other message (Fri, 10 Nov 2006 21:18:28=20 >-0500) with these diagrams, and see if what I'm wondering=20 >about makes sense. > > >For simplicities sake, I have drawn the diagrams as if all=20 >networks with unmapped addresses are attached to the old-style=20 >DFZ, and all with mapped to the new-style, but of course=20 >that's not necessary. > >Also, I have only drawn the physical topology, not the two=20 >separate routing planes - sorry, didn't have enough patience=20 >for a multi-layer drawing! > > >Anyway, I'd really appreciate it if people could look at this=20 >material (diagrams and text), and see if I've made some=20 >obvious blunder in my understanding, or if there is a real issue here. > > Noel > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 13 23:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjpz1-0006dT-Qg; Mon, 13 Nov 2006 23:33:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjpz0-0006cP-3n for architecture-discuss@ietf.org; Mon, 13 Nov 2006 23:33:14 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gjpyw-0003zf-Iw for architecture-discuss@ietf.org; Mon, 13 Nov 2006 23:33:12 -0500 Received: from webmail45.lax.untd.com (webmail45.lax.untd.com [10.131.27.185]) by smtpout01.lax.untd.com with SMTP id AABCXUTZMAW4B762 for (sender ); Mon, 13 Nov 2006 20:32:43 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKYMOLUDVxc1oTChAHaucyrg== Received: (from fergdawg@netzero.net) by webmail45.lax.untd.com (jqueuemail) id L642UUCF; Mon, 13 Nov 2006 20:32:24 PST Received: from [24.23.201.115] by webmail45.lax.untd.com with HTTP: Tue, 14 Nov 2006 04:32:06 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Tue, 14 Nov 2006 04:32:06 GMT To: jarno.rajahalme@nokia.com Subject: Re: [arch-d] RE: Ok, so what should we do then? X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061113.203224.16672.1447786@webmail45.lax.untd.com> X-ContentStamp: 15:7:4000163060 X-MAIL-INFO: 2e90c98510adc9adade59001e960b550504499dd5064d5e91484cd6d65fdfdc961c4e485 X-UNTD-Peer-Info: 10.131.27.185|webmail45.lax.untd.com|webmail45.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Sorry for top-posting, but wanted to retain the context of this. Geoff Huston mentioned something very similar to this to me last week (actually, it was more like "Tell me how crazy this sounds..."), but basically, the tunnels would forward based only on AS path found in the BGP path, per prefix, and not the RIB, from tunnel-endpoint to tunnel-endpoint. Before I butcher his idea, perhaps Geoff would care to expand on it himself.... = - ferg = -- wrote: How about limiting DFZ only for provider aggregatable addressing and using some on-demand routing and tunneling over the DFZ for PI prefixes?= Initially this tunneling could be over existing IPv4. This could be pretty much like some of the tunneling based IPv6 transition methods, but you keep tunneling even if the DFZ transfers to IPv6. The border (where the tunneling happens) does on-demand lookups for PI destination addresses and caches the results. Reverse DNS lookups would work fine, as long as the PI addresses have prefixes that aggregate on organizational + some regional structure. Outside of the DFZ the PI addresses would be routed (internally) and packets with foreign PI destinations would be default routed towards DFZ. Some sites having too much peers to cope with number of tunnels would use just provider based addressing (e.g. content distributors) and cope with renumbering. That way the tunneling state would distribute to content servers and could be manageable on the side of the transport protocol context. In summary the proposal is to keep DFZ provider based only, and have PI addressed traffic tunnel over it, forever. This will happen naturally as= an outcome of the IPv6 transition, if we keep the IPv6 DFZ free of PI addressed routes, as the tunneling mechanism is needed to IPv6 transition over IPv4 anyway. Regards, Jarno [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 00:23:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjqjT-0003jI-S2; Tue, 14 Nov 2006 00:21:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjqjS-0003hD-PA for architecture-discuss@ietf.org; Tue, 14 Nov 2006 00:21:14 -0500 Received: from inferno.ny1.corp.yahoo.com ([64.157.137.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjqjR-0002jz-IA for architecture-discuss@ietf.org; Tue, 14 Nov 2006 00:21:14 -0500 Received: from assassin.hjny.corp.yahoo.com (assassin.hjny.corp.yahoo.com [63.209.167.137]) by inferno.ny1.corp.yahoo.com (8.13.8/8.13.4/pop-ny) with ESMTP id kAE5LDGF030872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Nov 2006 00:21:13 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=uGxkORK28UIyr/cjsecDGKBcQcr+b3oP9IVZ7w3XPXX71hYPvwZz5Oh5JN842AMD Date: Tue, 14 Nov 2006 00:18:16 -0500 (EST) From: Igor Gashinsky X-X-Sender: igor@assassin.hjny.corp.yahoo.com To: "Schliesser, Benson" Subject: RE: [arch-d] It's the routing, people! In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, 13 Nov 2006, Schliesser, Benson wrote: :: I think this is an excellent point, Eric, and I fundamentally agree with :: the sentiment. But I'm curious about your perception of multiple :: addresses as burdensome. For instance, with some of the :: auto-configuration options currently available this could be as simple :: as adding a prefix to your gateways for each ISP that you want to :: enable. :: :: Is there an acceptable-burden crossover point somewhere between :: "physically assign[ing]" addresses and the ideal zero-work "no :: readdressing" scenarios? Because the problem here isn't just getting the address on the end host. It's getting all the ACLs/Firewalls configured with the new rules, adding those extra netblocks to loadbalancers, adding the routes all over the network (and filtered/leaked correctly), adding them into the application logic to recognize internal vs external, etc, and you want people to do that every time they want to add/remove/change ISP's? Talk about lock-in... Also, most people don't do dynamic addressing for their servers -- too many things that could break, and I'm not going to even going to bring up applications written 5-10 years ago with hardcoded IPs that everyone is afraid to shut down, much less change -- and that's just some of the burdens faced by quite a few enterprise networks (aren't you glad you don't work for them? I sure am...) which is why DHCP++ magic-auto-numbering stuff just doesn't work here. Honestly, I think anything that's more complext then "adding statement XYZ on the border router(s)" is "too complex" for most enterprises (and those who provide services to SMB's know exactly what I'm talking about)... Thanks, -igor (do not work for an enterprise network, luckily) ----------------------+----------------------+------------------ Igor Gashinsky, CISSP | Network Architecture | Yahoo! Inc. igor@yahoo-inc.com | cell 917.807.2213 | Do You... Yahoo? ----------------------+----------------------+------------------ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 00:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjrCm-000299-9J; Tue, 14 Nov 2006 00:51:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjrCl-00027c-15 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 00:51:31 -0500 Received: from webmail.tropos.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjrCj-0007a6-Lf for architecture-discuss@ietf.org; Tue, 14 Nov 2006 00:51:31 -0500 Received: (qmail 23713 invoked from network); 14 Nov 2006 05:51:08 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 14 Nov 2006 05:51:08 -0000 Received: from LIPC ([192.168.1.158]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 21:51:08 -0800 From: "Tony Li" To: "'Schliesser, Benson'" , Subject: RE: [arch-d] It's the routing, people! Date: Mon, 13 Nov 2006 21:51:04 -0800 Message-ID: <01fc01c707b0$df2faa70$9d01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccGiIUQujMXwQ2LT8ut3PkOQ0S/NwA+5sJQAAr3xUA= X-OriginalArrivalTime: 14 Nov 2006 05:51:08.0091 (UTC) FILETIME=[E16B90B0:01C707B0] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > The basic issue with proxy aggregation is that it breaks TE. (In turn, > possibly breaking connectivity.) If we had some way of doing proxy > aggregation while maintaining TE functionality then I suppose > we'd have > something useful, but as far as I can imagine that would require > awareness/information beyond the borders of the aggregating AS's > perspective. The whole point of doing proxy aggregation is to create an aggregate that is sufficiently remote from the originating AS so that TE is not affected. An aggregate should be injected at the same point that the longer prefixes are dropped, so connectivity should not suffer. A perfect example: why should Geoff, on his Wee Island Down Under (tm), really need to carry all of the /24s for Europe? Once all of the components of an aggregate share the same next hop, then they can all be replaced by the aggregate. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 01:18:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjrcb-000739-6Z; Tue, 14 Nov 2006 01:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjrcZ-00072l-7h for architecture-discuss@ietf.org; Tue, 14 Nov 2006 01:18:11 -0500 Received: from neo-u2.ops-netman.net ([2001:408:1009:1:2d0:a8ff:fe00:4bc4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjrcX-0002KE-0p for architecture-discuss@ietf.org; Tue, 14 Nov 2006 01:18:11 -0500 Received: from [IPv6?2001?408?1009?2?211?24ff?fea9?7105] (en1.russian-fingers.as701.net [IPv6:2001:408:1009:2:211:24ff:fea9:7105]) by neo-u2.ops-netman.net (Postfix) with ESMTP id B976D17A; Tue, 14 Nov 2006 06:17:47 +0000 (GMT) In-Reply-To: <5F744BD3-8E59-4AF5-8D8E-E5DB0D7362D2@cisco.com> References: <092DA27E-1DD2-4EBD-BA9B-10573FD2D1E8@cisco.com> <8E5CC8D3-8EBF-4458-9C1B-A9F094D8432F@muada.com> <5F744BD3-8E59-4AF5-8D8E-E5DB0D7362D2@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31CC16FA-D855-4C65-B555-81E2B96AB46D@ops-netman.net> Content-Transfer-Encoding: 7bit From: Chris Morrow Subject: Re: [arch-d] It's the routing, people! Date: Tue, 14 Nov 2006 01:17:41 -0500 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Nov 11, 2006, at 7:33 PM, Fred Baker wrote: > > On Nov 11, 2006, at 3:39 PM, Iljitsch van Beijnum wrote: > >> This AS is singlehandedly responsible for more than 1% of the >> global routing table > > OK, so here's a proposed fix. Every *other* ISP ponies up $10 and > hands some money to this ISP's upstreams to, in their routing > policies, accept whatever prefixes from this jerk they are going oh, this is late, but... 14654 == wayport == airport/hotel/blah wireless access provider. I'd imagine they have many hundreds (many atleast) seperate links all over creation, they MAY prefer a single provider (L3 in the clipped example) or that may just be the view in this instance. They may NOT want to have another AS originate their covering /16 for some business reasons, their individual sites may be multi-homed... In any case, this has drifted some from architecture I think, eh? If you want a interested example try: AS4755 which tops out at 1032 prefixes which could get aggregated to 66... -Chris _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 01:42:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjrx9-0000hP-6I; Tue, 14 Nov 2006 01:39:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjrx7-0000e9-RZ for architecture-discuss@ietf.org; Tue, 14 Nov 2006 01:39:25 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjrx6-00058S-FD for architecture-discuss@ietf.org; Tue, 14 Nov 2006 01:39:25 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kAE6dL1G021081; Mon, 13 Nov 2006 22:39:21 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kAE6dIPP021077; Mon, 13 Nov 2006 22:39:18 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Nov 2006 22:39:18 -0800 (PST) From: "william(at)elan.net" To: jarno.rajahalme@nokia.com Subject: Re: [arch-d] RE: Ok, so what should we do then? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: jnc@mercury.lcs.mit.edu, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, 13 Nov 2006 jarno.rajahalme@nokia.com wrote: > How about limiting DFZ only for provider aggregatable addressing and > using some on-demand routing and tunneling over the DFZ for PI prefixes? Actually how about doing on-demand routing in general - i.e. does each router really need/use all the entries in RIB? Can we do something similar to DNS where routes are received and cached but can then expire if not used [note that it would not be easy since you need route before you can do dns, etc]? Related research question - Has anyone actually done (or wants to do) a study how many routes from BGP each router actually does use for various size networks & organizations? -- William Leibzon Elan Networks william@elan.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 01:57:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjsEC-0001l5-1E; Tue, 14 Nov 2006 01:57:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjsEA-0001kE-1Y for architecture-discuss@ietf.org; Tue, 14 Nov 2006 01:57:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjsE7-0007nt-Mj for architecture-discuss@ietf.org; Tue, 14 Nov 2006 01:57:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 22:56:59 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAE6uwIH026846; Mon, 13 Nov 2006 22:56:58 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAE6uwW4007808; Mon, 13 Nov 2006 22:56:58 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 22:56:58 -0800 Received: from [10.10.10.102] ([10.21.152.251]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 22:56:58 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] RE: Ok, so what should we do then? Date: Mon, 13 Nov 2006 22:56:57 -0800 To: "william(at)elan.net" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Nov 2006 06:56:58.0321 (UTC) FILETIME=[13F0D410:01C707BA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1554; t=1163487418; x=1164351418; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20RE=3A=20Ok, =20so=20what=20should=20we=20do =20then? |Sender:=20; bh=ZCrHo1vu30+/+JNjwOIpA5QPDKLylJF5VU33cC1j0+U=; b=eWIiHZ3tCCJo/r7GOj1ktt7bFoQlIP3T9qZ3fFT//SkBnO44mQUWhK0YRLnQ5sl0gP9uTM6W c6nVFfFhd8dyx6NeOffItW2J2ljuU6yKj1uph+hPaJIplJhjJ0UThpgZ; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org let's see. Having the FIB-equivalent-cache built route by route from a RIB that was maintained on a neighboring card turned out to be a problem, so we decided we needed to have a complete FIB (as in, a next hop for every possible destination address) on every forwarding card. Now we want to build the FIB-equivalent-cache built route by route by querying systems that might be tens to hundreds of milliseconds away? I'll think about that one and let you know what I come up with... On Nov 13, 2006, at 10:39 PM, william(at)elan.net wrote: > > On Mon, 13 Nov 2006 jarno.rajahalme@nokia.com wrote: > >> How about limiting DFZ only for provider aggregatable addressing and >> using some on-demand routing and tunneling over the DFZ for PI >> prefixes? > > Actually how about doing on-demand routing in general - i.e. does > each router really need/use all the entries in RIB? Can we do > something similar to DNS where routes are received and cached > but can then expire if not used [note that it would not be > easy since you need route before you can do dns, etc]? > > Related research question - > Has anyone actually done (or wants to do) a study how many routes > from BGP each router actually does use for various size networks & > organizations? > > -- > William Leibzon > Elan Networks > william@elan.net > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 02:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt65-0004vx-VN; Tue, 14 Nov 2006 02:52:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt64-0004rI-AP for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:52:44 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjt62-0007vu-0u for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:52:42 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kAE7obYD044258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Nov 2006 08:50:38 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C89027F-A6C1-47AF-9F62-68DCDF5BBD2F@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] RE: Ok, so what should we do then? Date: Tue, 14 Nov 2006 08:52:22 +0100 To: "" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 13-nov-2006, at 17:57, wrote: > How about limiting DFZ only for provider aggregatable addressing and > using some on-demand routing and tunneling over the DFZ for PI > prefixes? Something like this has been suggested by several people, including myself. However, there are many details to be worked out. For instance, I'm not a fan of doing this on-demand, I'd rather flood the mapping information. That makes everything a lot faster and makes debugging easier, as you have a full view of the state of the network. > Initially this tunneling could be over existing IPv4. This could be > pretty much like some of the tunneling based IPv6 transition methods, > but you keep tunneling even if the DFZ transfers to IPv6. The nice thing is that you can offer multiple tunnel options: over IPv4 only, over both IPv4 and IPv6, or, in the future, over IPv6 only. And the payload protocol can be IPv4 or IPv6. Note though that tunneling isn't entirely problem-free: it reduces your MTU, and having a smaller than 1500 MTU is a problem in IPv4, while a smaller than 1280 MTU isn't allowed in IPv6. For IPv6 over IPv6, an alternative is address rewriting. > The border (where the tunneling happens) I thinkt the tunneling/encapsulation should happen in service provider networks, at least at first. This aids transparency and deployability, and service providers have a bigger incentive to do this than end-users. If end-users want to parFrom architecture-discuss-bounces@ietf.org Tue Nov 14 02:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt65-0004vx-VN; Tue, 14 Nov 2006 02:52:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt64-0004rI-AP for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:52:44 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjt62-0007vu-0u for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:52:42 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kAE7obYD044258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Nov 2006 08:50:38 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C89027F-A6C1-47AF-9F62-68DCDF5BBD2F@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] RE: Ok, so what should we do then? Date: Tue, 14 Nov 2006 08:52:22 +0100 To: "" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 13-nov-2006, at 17:57, wrote: > How about limiting DFZ only for provider aggregatable addressing and > using some on-demand routing and tunneling over the DFZ for PI > prefixes? Something like this has been suggested by several people, including myself. However, there are many details to be worked out. For instance, I'm not a fan of doing this on-demand, I'd rather flood the mapping information. That makes everything a lot faster and makes debugging easier, as you have a full view of the state of the network. > Initially this tunneling could be over existing IPv4. This could be > pretty much like some of the tunneling based IPv6 transition methods, > but you keep tunneling even if the DFZ transfers to IPv6. The nice thing is that you can offer multiple tunnel options: over IPv4 only, over both IPv4 and IPv6, or, in the future, over IPv6 only. And the payload protocol can be IPv4 or IPv6. Note though that tunneling isn't entirely problem-free: it reduces your MTU, and having a smaller than 1500 MTU is a problem in IPv4, while a smaller than 1280 MTU isn't allowed in IPv6. For IPv6 over IPv6, an alternative is address rewriting. > The border (where the tunneling happens) I thinkt the tunneling/encapsulation should happen in service provider networks, at least at first. This aids transparency and deployability, and service providers have a bigger incentive to do this than end-users. If end-users want to participate in this, so much the better, but we shouldn't make this a requirement for succes. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 02:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt7E-0005ao-Gh; Tue, 14 Nov 2006 02:53:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt7D-0005ag-Fx for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:53:55 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjt7B-000894-Vl for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:53:55 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1Gjk81-0005VR-Sc for architecture-discuss@ietf.org; Mon, 13 Nov 2006 14:18:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 23:07:42 +0100 To: "Fleischman, Eric" ,, "Noel Chiappa" , From: Jefsey_Morfin Subject: RE: [arch-d] It's the routing, people! In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B79@XCH-NW-6V1.nw.nos .boeing.com> References: <004a01c705f7$c8b9f6c0$9d01a8c0@tropos.com> <474EEBD229DF754FB83D256004D0210802584B79@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1822035316==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1822035316== Content-Type: multipart/alternative; boundary="----MTefyjdzhbcwoscraixnilxjjmbwtexmdx" ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2363315A Dear Eric, the solution is quite simple. Consider that you have three orthogonal concatenated segments in an IP address: - the ISP address global (X.121, E.164, are example) - your own address obtained to your favorite registrar - your own extensions you manage by yourself. The second address part is the one interesting you. You will keep it whatever the ISP (as you will keep your extensions the way you like). Now you change ISP (or you rotate ISP for security reasons, or move abroad, etc.): you can give your ISP address, or you can have it dynamically registered, etc. When you move around the world with your mobile, you keep your number, but you change prefixes. Because you need far less numbers, and can far better manage them, you have room enough for: the_type_of_address:the_network_address:the_user_global_address:your_extensions and you can easily think ways to have variable length numbers. May be this iticipate in this, so much the better, but we shouldn't make this a requirement for succes. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 02:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt7E-0005ao-Gh; Tue, 14 Nov 2006 02:53:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjt7D-0005ag-Fx for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:53:55 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjt7B-000894-Vl for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:53:55 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1Gjk81-0005VR-Sc for architecture-discuss@ietf.org; Mon, 13 Nov 2006 14:18:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 23:07:42 +0100 To: "Fleischman, Eric" ,, "Noel Chiappa" , From: Jefsey_Morfin Subject: RE: [arch-d] It's the routing, people! In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B79@XCH-NW-6V1.nw.nos .boeing.com> References: <004a01c705f7$c8b9f6c0$9d01a8c0@tropos.com> <474EEBD229DF754FB83D256004D0210802584B79@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1822035316==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1822035316== Content-Type: multipart/alternative; boundary="----MTefyjdzhbcwoscraixnilxjjmbwtexmdx" ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2363315A Dear Eric, the solution is quite simple. Consider that you have three orthogonal concatenated segments in an IP address: - the ISP address global (X.121, E.164, are example) - your own address obtained to your favorite registrar - your own extensions you manage by yourself. The second address part is the one interesting you. You will keep it whatever the ISP (as you will keep your extensions the way you like). Now you change ISP (or you rotate ISP for security reasons, or move abroad, etc.): you can give your ISP address, or you can have it dynamically registered, etc. When you move around the world with your mobile, you keep your number, but you change prefixes. Because you need far less numbers, and can far better manage them, you have room enough for: the_type_of_address:the_network_address:the_user_global_address:your_extensions and you can easily think ways to have variable length numbers. May be this is why there are 2 billions mobiles in 10 years and no IPv6 in 14? But we just are lead users ... all the best. jfc At 20:23 13/11/2006, Fleischman, Eric wrote: >Good answer, Tony!! > >Many Internet architects are apparently keen to burden us end users with >multiple addresses. To the extent that Multi6 and Shim6 do this, to that >extent they will be resisted for deployment into real life networks. >People who intend for us to physically assign different addresses for >each of our ISPs to each of our computers have not really understood the >primary end user addressing requirement: no readdressing for something >as unimportant as who our ISPs are. > >There are administrative, management, and security implications of >multiple addresses that make them impractical for today's networks >(unless there is a compelling business reason to justify those overhead >expenses and risk). > >Shifting the burden from ISPs to the end user is just not going to cut >it. Why does anybody imagine that end users will willingly bear >significant operational expenses for a problem that isn't even visible >to us? ISPs are a fraction of our size -- and we are the customer!! >Unless a monopoly situation exists, why would anybody maintain business >relationships with an uncooperative ISP? > >Rather, a clean solution that is equally good for everybody has to be >found, which is why I personally have supported the loc/id split >approach for many years now. Alternatively, we can NAT. > >-----Original Message----- >From: Tony Li [mailto:tli@tropos.com] >Sent: Saturday, November 11, 2006 5:14 PM > > I don't think there's any way in the routing alone to support > > multi-homing in > > a way which reduces table growth (at least as long as the > > only scope we have > > for advertisements, other than "local", is "global"). To > > support multi-homing > > without impacting the routing, it seems that the way to go is > > have multiple > > locators for each multi-homed entity (which is the way Multi6 > > eventually > > went, with Shim6, but nobody likes the mechanism). So if we > > do, say GSE, how > > do we make multi-homing work, using multiple addresses? >In my mind, that's one of the primary benefits of any loc/id split. >Multiple locators per-site, with locator replacement at the border. >I've always thought of this as being one of the primary applications of >GSE. > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/html Dear Eric,
the solution is quite simple. Consider that you have three orthogonal
concatenated segments in an IP address:

- the ISP address global (X.121, E.164, are example)
- your own address obtained to your favorite registrar
- your own extensions you manage by yourself.

The second address part is the one interesting you. You will keep it
whatever the ISP (as you will keep your extensions the way you like).
Now you change ISP (or you rotate ISP for security reasons, or move
abroad, etc.): you can give your ISP address, or you can have it
dynamically registered, etc. When you move around the world with your
mobile, you keep your number, but you change prefixes. Because you
need far less numbers, and can far better manage them, you have room
enough for:

     the_type_of_address:the_network_address:the_user_global_address:your_extensions


and you can easily think ways to have variable length numbers.

May be this is why there are 2 billions mobiles in 10 years and no
IPv6 in 14? But we just are lead users ...
all the best.
jfc


At 20:23 13/11/2006, Fleischman, Eric wrote:

>Good answer, Tony!!
>
>Many Internet architects are apparently keen to burden us end users with
>multis why there are 2 billions mobiles in 10 years and no IPv6 in 14? But we just are lead users ... all the best. jfc At 20:23 13/11/2006, Fleischman, Eric wrote: >Good answer, Tony!! > >Many Internet architects are apparently keen to burden us end users with >multiple addresses. To the extent that Multi6 and Shim6 do this, to that >extent they will be resisted for deployment into real life networks. >People who intend for us to physically assign different addresses for >each of our ISPs to each of our computers have not really understood the >primary end user addressing requirement: no readdressing for something >as unimportant as who our ISPs are. > >There are administrative, management, and security implications of >multiple addresses that make them impractical for today's networks >(unless there is a compelling business reason to justify those overhead >expenses and risk). > >Shifting the burden from ISPs to the end user is just not going to cut >it. Why does anybody imagine that end users will willingly bear >significant operational expenses for a problem that isn't even visible >to us? ISPs are a fraction of our size -- and we are the customer!! >Unless a monopoly situation exists, why would anybody maintain business >relationships with an uncooperative ISP? > >Rather, a clean solution that is equally good for everybody has to be >found, which is why I personally have supported the loc/id split >approach for many years now. Alternatively, we can NAT. > >-----Original Message----- >From: Tony Li [mailto:tli@tropos.com] >Sent: Saturday, November 11, 2006 5:14 PM > > I don't think there's any way in the routing alone to support > > multi-homing in > > a way which reduces table growth (at least as long as the > > only scope we have > > for advertisements, other than "local", is "global"). To > > support multi-homing > > without impacting the routing, it seems that the way to go is > > have multiple > > locators for each multi-homed entity (which is the way Multi6 > > eventually > > went, with Shim6, but nobody likes the mechanism). So if we > > do, say GSE, how > > do we make multi-homing work, using multiple addresses? >In my mind, that's one of the primary benefits of any loc/id split. >Multiple locators per-site, with locator replacement at the border. >I've always thought of this as being one of the primary applications of >GSE. > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/html Dear Eric,
the solution is quite simple. Consider that you have three orthogonal
concatenated segments in an IP address:

- the ISP address global (X.121, E.164, are example)
- your own address obtained to your favorite registrar
- your own extensions you manage by yourself.

The second address part is the one interesting you. You will keep it
whatever the ISP (as you will keep your extensions the way you like).
Now you change ISP (or you rotate ISP for security reasons, or move
abroad, etc.): you can give your ISP address, or you can have it
dynamically registered, etc. When you move around the world with your
mobile, you keep your number, but you change prefixes. Because you
need far less numbers, and can far better manage them, you have room
enough for:

     the_type_of_address:the_network_address:the_user_global_address:your_extensions


and you can easily think ways to have variable length numbers.

May be this is why there are 2 billions mobiles in 10 years and no
IPv6 in 14? But we just are lead users ...
all the best.
jfc


At 20:23 13/11/2006, Fleischman, Eric wrote:

>Good answer, Tony!!
>
>Many Internet architects are apparently keen to burden us end users with
>multiple addresses. To the extent that Multi6 and Shim6 do this, to that
>extent they will be resisted for deployment into real life networks.
>People who intend for us to physically assign different addresses for
>each of our ISPs to each of our computers have not really understood the
>primary end user addressing requirement: no readdressing for something
>as unimportant as who our ISPs are.
>
>There are administrative, management, and security implications of
>multiple addresses that make them impractical for today's networks
>(unless there is a compelling business reason to justify those overhead
>expenses and risk).
>
>Shifting the burden from ISPs to the end user is just not going to cut
>it. Why does anybody imagine that end users will willingly bear
>significant operational expenses for a problem that isn't even visible
>to us? ISPs are a fraction of our size -- and we are the customer!!
>Unless a monopoly situation exists, why would anybody maintain business
>relationships with an uncooperative ISP?
>
>Rather, a clean solution that is equally good for everybody has to be
>found, which is why I personally have supported the loc/id split
>approach for many years now. Alternatively, we can NAT.
>
>-----Original Message-----
>From: Tony Li [mailto:tli@tropos.com]
>Sent: Saturday, November 11, 2006 5:14 PM
> > I don't think there's any way in the routing alone to support
> > multi-homing in
> > a way which reduces table growth (at least as long as the
> > only scope we have
> > for advertisements, other than "local", is "global"). To
> > support multi-homing
> > without impacting the routing, it seems that the way to go is
> > have multiple
> > locators for each multi-homed entity (which is the way Multi6
> > eventually
> > went, with Shim6, but nobody likes the mechanism). So if we
> > do, say GSE, how
> > do we make multi-homing work, using multiple addresses?
>In my mind, that's one of the primary benefits of any loc/id split.
>Multiple locators per-site, with locator replacement at the border.
>I've always thought of this as being one of the primary applications of
>GSE.
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss

------MTefyjdzhbcwoscraixnilxjjmbwtexmdx-- --===============1822035316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1822035316==-- ple addresses. To the extent that Multi6 and Shim6 do this, to that
>extent they will be resisted for deployment into real life networks.
>People who intend for us to physically assign different addresses for
>each of our ISPs to each of our computers have not really understood the
>primary end user addressing requirement: no readdressing for something
>as unimportant as who our ISPs are.
>
>There are administrative, management, and security implications of
>multiple addresses that make them impractical for today's networks
>(unless there is a compelling business reason to justify those overhead
>expenses and risk).
>
>Shifting the burden from ISPs to the end user is just not going to cut
>it. Why does anybody imagine that end users will willingly bear
>significant operational expenses for a problem that isn't even visible
>to us? ISPs are a fraction of our size -- and we are the customer!!
>Unless a monopoly situation exists, why would anybody maintain business
>relationships with an uncooperative ISP?
>
>Rather, a clean solution that is equally good for everybody has to be
>found, which is why I personally have supported the loc/id split
>approach for many years now. Alternatively, we can NAT.
>
>-----Original Message-----
>From: Tony Li [mailto:tli@tropos.com]
>Sent: Saturday, November 11, 2006 5:14 PM
> > I don't think there's any way in the routing alone to support
> > multi-homing in
> > a way which reduces table growth (at least as long as the
> > only scope we have
> > for advertisements, other than "local", is "global"). To
> > support multi-homing
> > without impacting the routing, it seems that the way to go is
> > have multiple
> > locators for each multi-homed entity (which is the way Multi6
> > eventually
> > went, with Shim6, but nobody likes the mechanism). So if we
> > do, say GSE, how
> > do we make multi-homing work, using multiple addresses?
>In my mind, that's one of the primary benefits of any loc/id split.
>Multiple locators per-site, with locator replacement at the border.
>I've always thought of this as being one of the primary applications of
>GSE.
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss

------MTefyjdzhbcwoscraixnilxjjmbwtexmdx-- --===============1822035316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1822035316==-- From architecture-discuss-bounces@ietf.org Tue Nov 14 05:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjvgm-0006yv-UU; Tue, 14 Nov 2006 05:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjvgl-0006yp-J1 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 05:38:47 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjvgj-0008Ax-3N for architecture-discuss@ietf.org; Tue, 14 Nov 2006 05:38:47 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1Gjvgg-0006hP-EH for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:38:43 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Nov 2006 10:19:26 +0100 To: "Schliesser, Benson" , From: Jefsey_Morfin Subject: RE: [arch-d] It's the routing, people! In-Reply-To: References: <20061112.102757.2521.1436547@webmail51.lax.untd.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0172270779==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0172270779== Content-Type: multipart/alternative; boundary="----MTkfupcqyoilferzqroctdgwslzebeajkj" ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-43A95D3D No. The user should in a way keep control of the path of his data. For obvious security reasons. jfc At 02:21 14/11/2006, Schliesser, Benson wrote: >Fergie [mailto:fergdawg@netzero.net] wrote: > > I know I'm probably going to hate myself for saying this, but > > perhaps it is time for us to revisit the value of "selective" > > methods for proxy aggregation? It's a sensitive topic, for sure, > > which is why I highly emphasize the word: "selective"... > >The basic issue with proxy aggregation is that it breaks TE. (In turn, >possibly breaking connectivity.) If we had some way of doing proxy >aggregation while maintaining TE functionality then I suppose we'd have >something useful, but as far as I can imagine that would require >awareness/information beyond the borders of the aggregating AS's >perspective. > >Thinking about this inspires me to propose a requirement. It's possible >that everybody agrees and I'm simply stating the obvious, but let me be >explicit regardless: The routing system must support arbitrary >connectivity between transit networks. > >For instance, one could envision a (poor) solution to the aggregation >problem that involves tunneling between the "primary" AS that assigns PA >space to the end network and each other AS it multi-homes to. This would >allow the global routing system to forward packets to the primary >network, which would be responsible for forwarding over tunnels to the >secondary networks during link failure etc. This constrains more >specific prefixes to just those networks that are directly supporting >the end customer. However this defeats one of the most important reasons >that a network multi-homes--survival during failure of the primary >provider's network. Thus each AS needs the ability to provide >connectivity to the end network independently of any other AS (to the >degree allowed by their peering/connectivity, of course). > >To extend on this, one could possibly imagine yet other schemes that >allow for aggressive aggregation in the global system but which create a >reliance on the "Tier 1" crowd for routing and connectivity. (I.e., >similar to the "tunnel" model above, but with a group of "core" networks >that everybody relies upon instead of a single "primary" network.) This >might have better survivability/resiliency properties, but it also >institutes an economic hierarchy that would ultimately be stifling and >dangerous (socially, economically, politically, in terms of long-term >security and stability of the network, etc). > >The way to avoid these issues is to allow networks to connect directly >to each other, and have any connectivity graph / topology they might >desire. This is the tussle counter-balance... > >Note that I'm talking specifically about transit networks here, which >excludes end networks (leaf networks) that don't want to provide >connectivity but merely want to receive connectivity services. (and >possibly don't need an ASN) > >Is this an obvious requirement? Does anybody disagree? I have to admit, >it certainly makes things more difficult in any case. (Is it even >possible theoretically? I'm only slightly aware of Dima's/Claffy's >recent work, so I don't quite know its properties versus my above >proposed requirement. Perhaps somebody with a topology/graph theory >background can comment?) > >Cheers, >-Benson > > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/html No.
The user should in a way keep control of the path of his data.
For obvious security reasons.
jfc


At 02:21 14/11/2006, Schliesser, Benson wrote:



>Fergie [mailto:fergdawg@netzero.net] wrote:
> > I know I'm probably going to hate myself for saying this, but
> > perhaps it is time for us to revisit the value of "selective"
> > methods for proxy aggregation? It's a sensitive topic, for sure,
> > which is why I highly emphasize the word: "selective"...
>
>The basic issue with proxy aggregation is that it breaks TE. (In turn,
>possibly breaking connectivity.)  If we had some way of doing proxy
>aggregation while maintaining TE functionality then I suppose we'd have
>something useful, but as far as I can imagine that would require
>awareness/information beyond the borders of the aggregating AS's
>perspective.
>
>Thinking about this inspires me to propose a requirement. It's possible
>that everybody agrees and I'm simply stating the obvious, but let me be
>explicit regardless: The routing system must support arbitrary
>connectivity between transit networks.
>
>For instance, one could envision a (poor) solution to the aggregation
>problem that involves tunneling between the "primary" AS that assigns PA
>space to the end network and each other AS it multi-homes to. This would
>allow the global routing system to forward packets to the primary
>network, which would be responsible for forwarding over tunnels to the
>secondary networks during link failure etc. This constrains more
>specific prefixes to just those networks that are directly supporting
>the end customer. However this defeats one of the most important reasons
>that a network multi-homes--survival during failure of the primary
>provider's network. Thus each AS needs the ability to provide
>connectivity to the end network independently of any other AS (to the
>degree allowed by their peering/connectivity, of course).
>
>To extend on this, one could possibly imagine yet other schemes that
>allow for aggressive aggregation in the global system but which create a
>reliance on the "Tier 1" crowd for routing and connectivity. (I.e.,
>similar to the "tunnel" model above, but with a group of "core" networks
>that everybody relies upon instead of a single "primary" network.) This
>might have better survivability/resiliency properties, but it also
>institutes an economic hierarchy that would ultimately be stifling and
>dangerous (socially, economically, politically, in terms of long-term
>security and stability of the network, etc).
>
>The way to avoid these issues is to allow networks to connect directly
>to each other, and have any connectivity graph / topology they might
>desire. This is the tussle counter-balance...
>
>Note that I'm talking specifically about transit networks here, which
>excludes end networks (leaf networks) that don't want to provide
>connectivity but merely want to receive connectivity services. (and
>possibly don't need an ASN)
>
>Is this an obvious requirement? Does anybody disagree? I have to admit,
>it certainly makes things more difficult in any case. (Is it even
>possible theoretically? I'm only slightly aware of Dima's/Claffy's
>recent work, so I don't quite know its properties versus my above
>proposed requirement. Perhaps somebody with a topology/graph theory
>background can comment?)
>
>Cheers,
>-Benson
>
>
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss

------MTkfupcqyoilferzqroctdgwslzebeajkj-- --===============0172270779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0172270779==-- From architecture-discuss-bounces@ietf.org Tue Nov 14 05:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjvgp-00073B-5n; Tue, 14 Nov 2006 05:38:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjvgo-00072g-3T for architecture-discuss@ietf.org; Tue, 14 Nov 2006 05:38:50 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjvgm-0008DA-Q0 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 05:38:50 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1Gjvgm-0006iM-GK for architecture-discuss@ietf.org; Tue, 14 Nov 2006 02:38:48 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Nov 2006 10:34:59 +0100 To: Fred Baker ,"william(at)elan.net" From: Jefsey_Morfin Subject: Re: [arch-d] RE: Ok, so what should we do then? In-Reply-To: References: MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.3 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1978694583==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1978694583== Content-Type: multipart/alternative; boundary="----MTxagxraeekkdantogwbmbjrfunkbzebbc" ------MTxagxraeekkdantogwbmbjrfunkbzebbc Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-43A95D3D At 07:56 14/11/2006, Fred Baker wrote: >let's see. Having the FIB-equivalent-cache built route by route from >a RIB that was maintained on a neighboring card turned out to be a >problem, so we decided we needed to have a complete FIB (as in, a >next hop for every possible destination address) on every forwarding >card. Now we want to build the FIB-equivalent-cache built route by >route by querying systems that might be tens to hundreds of >milliseconds away? My proposition was simpler. To have the DNSS (distributed network supervisory system) to resolve the domain name/IP address into a route from a permanent knowledge of the network helped by a numbering plan in symbiosis with topology. The route is put into each packet (I called it the "needle"). The routers obey the needle or return it to the origin and alert the DNSS in case of failure. This decreases the load on the router and permits all the value added/extended (content related) services you want. The big issue is the distributed supervisor design. Transition is simple: if there is no needle, current solutions apply. The IP dependent users (most probably in IPv4 today) can still been served. Tables could transition to some local supervisory outputs being cached? I explained how the PI issue can be addressed. jfc ------MTxagxraeekkdantogwbmbjrfunkbzebbc Content-Type: text/html At 07:56 14/11/2006, Fred Baker wrote:
>let's see. Having the FIB-equivalent-cache built route by route from
>a RIB that was maintained on a neighboring card turned out to be a
>problem, so we decided we needed to have a complete FIB (as in, a
>next hop for every possible destination address) on every forwarding
>card. Now we want to build the FIB-equivalent-cache built route by
>route by querying systems that might be tens to hundreds of
>milliseconds away?

My proposition was simpler. To have the DNSS (distributed network
supervisory system) to resolve the domain name/IP address into a
route from a permanent knowledge of the network helped by a numbering
plan in symbiosis with topology. The route is put into each packet
(I  called it the "needle"). The routers obey the needle or return it
to the origin and alert the DNSS in case of failure. This decreases
the load on the router and permits all the value added/extended
(content related) services you want. The big issue is the distributed
supervisor design. Transition is simple: if there is no needle,
current solutions apply. The IP dependent users (most probably in
IPv4 today) can still been served. Tables could transition to some
local supervisory outputs being cached?

I explained how the PI issue can be addressed.
jfc


------MTxagxraeekkdantogwbmbjrfunkbzebbc-- --===============1978694583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1978694583==-- From architecture-discuss-bounces@ietf.org Tue Nov 14 09:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjypJ-00049r-NF; Tue, 14 Nov 2006 08:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjypI-00049l-DF for architecture-discuss@ietf.org; Tue, 14 Nov 2006 08:59:48 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjypA-0006at-5N for architecture-discuss@ietf.org; Tue, 14 Nov 2006 08:59:48 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A5C4D3407C; Tue, 14 Nov 2006 08:59:37 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 08:59:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was:Re:[arch-d][Off-topic]Further thoughts: about systems theoryandthe theory U) Date: Tue, 14 Nov 2006 08:59:36 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCECE016@tayexc14.americas.cpqcorp.net> In-Reply-To: <326A98184EC61140A2569345DB3614C103BF642E@esebe105.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was:Re:[arch-d][Off-topic]Further thoughts: about systems theoryandthe theory U) Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanAAB2ueDAAavXiQAACgoBw From: "Bound, Jim" To: , , X-OriginalArrivalTime: 14 Nov 2006 13:59:37.0169 (UTC) FILETIME=[1EFDF410:01C707F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: eric.fleischman@boeing.com, jnc@mercury.lcs.mit.edu, terry.l.davis@boeing.com, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I would not support this as you state, but would support updates once identity and location were clearly determined with consensus. /jim=20 > -----Original Message----- > From: Mikael.Latvala@nokia.com [mailto:Mikael.Latvala@nokia.com]=20 > Sent: Tuesday, November 14, 2006 7:53 AM > To: Bound, Jim; tony.li@tony.li; tme@multicasttech.com > Cc: eric.fleischman@boeing.com; jnc@mercury.lcs.mit.edu;=20 > terry.l.davis@boeing.com; architecture-discuss@ietf.org > Subject: RE: Ok, so what should we do then?=20 > (Was:Re:[arch-d][Off-topic]Further thoughts: about systems=20 > theoryandthe theory U) >=20 > How about starting with a denouncement of MIPv4/MIPv6 as they=20 > both are based on the assumption that the IP address can be=20 > used both as a locator and an identifier? >=20 > /Mikael >=20 > > > >But it would be real great if we could write up the set of "what=20 > >problems are we trying to solve". > > > >/jim > > >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 09:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjz2U-0004NT-MN; Tue, 14 Nov 2006 09:13:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjz2T-0004KU-8V for architecture-discuss@ietf.org; Tue, 14 Nov 2006 09:13:25 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjz2Q-0008ES-0i for architecture-discuss@ietf.org; Tue, 14 Nov 2006 09:13:25 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 08:13:21 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] RE: Ok, so what should we do then? Date: Tue, 14 Nov 2006 08:14:46 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] RE: Ok, so what should we do then? Thread-Index: AccHuiGyYG9GGVwdQuiDi6gzOY4RDAAOveig From: "Schliesser, Benson" To: X-OriginalArrivalTime: 14 Nov 2006 14:13:21.0763 (UTC) FILETIME=[0A7D0330:01C707F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred Baker [mailto:fred@cisco.com] wrote: > >> How about limiting DFZ only for provider aggregatable addressing and > >> using some on-demand routing and tunneling over the DFZ for PI > >> prefixes? > > > > Actually how about doing on-demand routing in general - i.e. does > > each router really need/use all the entries in RIB? >=20 > let's see. Having the FIB-equivalent-cache built route by route from > a RIB that was maintained on a neighboring card turned out to be a > problem, so we decided we needed to have a complete FIB (as in, a > next hop for every possible destination address) on every forwarding > card. Now we want to build the FIB-equivalent-cache built route by > route by querying systems that might be tens to hundreds of > milliseconds away? I have to agree with Fred. Despite my previous comments indicating that any AS should be able to connect arbitrarily, the fact is that today there are a relatively small number of networks at the "core" of the connectivity graph. This on-demand model might not blow up *completely* for routers that forward to a relatively small number of destinations. (I.e. the end-network that only talks to Google, Yahoo, and their ISP's mail server, etc.) But the routing scale problem exists largely in the "core", where the routers are actually forwarding traffic to a fairly significant proportion of the allocated address space and currently have the largest tables. Making routes on-demand for these routers would initially hinder their ability to forward packets as Fred points out. And after lookups and tunneling take place their cache state would probably be on the same scale as today's global routing table, anyway. Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 09:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzDy-0007wN-JI; Tue, 14 Nov 2006 09:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzDx-0007wF-Du for architecture-discuss@ietf.org; Tue, 14 Nov 2006 09:25:17 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzDv-0001Zm-6r for architecture-discuss@ietf.org; Tue, 14 Nov 2006 09:25:17 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 08:25:15 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Tue, 14 Nov 2006 08:26:39 -0600 Message-ID: In-Reply-To: <01fc01c707b0$df2faa70$9d01a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccGiIUQujMXwQ2LT8ut3PkOQ0S/NwA+5sJQAAr3xUAAEdDKIA== From: "Schliesser, Benson" To: X-OriginalArrivalTime: 14 Nov 2006 14:25:15.0116 (UTC) FILETIME=[B3AE0AC0:01C707F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony Li [mailto:tli@tropos.com] wrote: > The whole point of doing proxy aggregation is to create an aggregate > that is sufficiently remote from the originating AS so that TE is not > affected. An aggregate should be injected at the same point that the > longer prefixes are dropped, so connectivity should not suffer. In an ideal and well-engineered environment this is true. But as a general rule I'm not so sure. For instance, when provider A announces their PA space and provider B announces a proxy aggregate for the same space, which path does network C follow? Assume that C is connected to both A and B. Even if B maintains the more specific prefixes/paths so that it can forward traffic to the end-network, network C might still forward to provider A. If the connection between the end-network and provider A is down, then the only way traffic arrives at the destination is if A and B are exchanging more specific prefixes across their peering. Proxy aggregation in this case is nice to ensure that downstream "default-free" networks which filter on prefix length can still reach all endpoints, but it doesn't help the "core" networks whom still have to carry all routes. Or did you have something else in mind that I'm not thinking about? If we can find a way to work-around/fix what I'm talking about then maybe we have a useful tool, so please point out if I've missed something. Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 10:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzm7-0007nc-SA; Tue, 14 Nov 2006 10:00:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzm7-0007nX-0L for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:00:35 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjzm1-0006t2-Sq for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:00:34 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAEF0RRE390528 for ; Tue, 14 Nov 2006 15:00:27 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAEF3fOl3276992 for ; Tue, 14 Nov 2006 16:03:41 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAEF0Q5F004725 for ; Tue, 14 Nov 2006 16:00:26 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAEF0PCR004699; Tue, 14 Nov 2006 16:00:26 +0100 Received: from zurich.ibm.com ([9.4.210.177]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA93284; Tue, 14 Nov 2006 16:00:24 +0100 Message-ID: <45599739.8030209@zurich.ibm.com> Date: Tue, 14 Nov 2006 11:15:21 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] RE: Ok, so what should we do then? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Or another way to ask the question: how long a startup delay is acceptable for a new flow, if remote lookup is needed? In the phone system, the answer seems to be up to several seconds, but when sending short flows of 1500 byte packets on a 10 Gb link, it doesn't seem like we can tolerate more than a few tens of microseconds at most. Brian Fred Baker wrote: > let's see. Having the FIB-equivalent-cache built route by route from a > RIB that was maintained on a neighboring card turned out to be a > problem, so we decided we needed to have a complete FIB (as in, a next > hop for every possible destination address) on every forwarding card. > Now we want to build the FIB-equivalent-cache built route by route by > querying systems that might be tens to hundreds of milliseconds away? > > I'll think about that one and let you know what I come up with... > > On Nov 13, 2006, at 10:39 PM, william(at)elan.net wrote: > >> >> On Mon, 13 Nov 2006 jarno.rajahalme@nokia.com wrote: >> >>> How about limiting DFZ only for provider aggregatable addressing and >>> using some on-demand routing and tunneling over the DFZ for PI >>> prefixes? >> >> >> Actually how about doing on-demand routing in general - i.e. does >> each router really need/use all the entries in RIB? Can we do >> something similar to DNS where routes are received and cached >> but can then expire if not used [note that it would not be >> easy since you need route before you can do dns, etc]? >> >> Related research question - >> Has anyone actually done (or wants to do) a study how many routes >> from BGP each router actually does use for various size networks & >> organizations? >> >> -- >> William Leibzon >> Elan Networks >> william@elan.net >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 10:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzmA-0007oF-48; Tue, 14 Nov 2006 10:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzm8-0007o5-9z for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:00:36 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjzm2-0006t6-4H for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:00:36 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAEF0Sub252040 for ; Tue, 14 Nov 2006 15:00:28 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAEF3hmT471134 for ; Tue, 14 Nov 2006 16:03:43 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAEF0Swe004804 for ; Tue, 14 Nov 2006 16:00:28 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAEF0RFn004788; Tue, 14 Nov 2006 16:00:27 +0100 Received: from zurich.ibm.com ([9.4.210.177]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA42646; Tue, 14 Nov 2006 16:00:26 +0100 Message-ID: <4559980C.4080106@zurich.ibm.com> Date: Tue, 14 Nov 2006 11:18:52 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Noel Chiappa Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) References: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> In-Reply-To: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel Chiappa wrote: > > From: Brian E Carpenter > > > address ambiguity destroys the e2e identification property and third > > party referrals > > That's not a bug, that's a feature. > > We want to discourage people from passing around bare endpoint identifiers. > (Such an identifier might e.g. identify one particular server in a pool - not > what you really wanted anyway.) Rather, they *should* be passing around > higher-level identifiers. In theory, I agree. In practice, real time apps really don't want to pay the overhead of another lookup, once a multiparty session is started. Address ambiguity has other unpleasant effects as well, of course. And there's no need for it any more. Brian > > NewArch deliberately, for architectural reasons on a blank sheet, went down > this same path, that endpoint identifiers (except the approximately equivalent > things in NewArch are somewhat different) are not globally unique, and > necessarily cannot be passed to third parties. > > So, if it doesn't work to pass around bare endpoint identifiers to third > parties, so much the better. > > Noel > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 10:04:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzpJ-00005K-Km; Tue, 14 Nov 2006 10:03:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzpI-00005C-QJ for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:03:52 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzpH-0007P9-B6 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:03:52 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAEF3Ekd024589; Tue, 14 Nov 2006 17:03:49 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:02:52 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:02:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] RE: Ok, so what should we do then? Date: Tue, 14 Nov 2006 17:02:52 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] RE: Ok, so what should we do then? Thread-Index: AccHuiGyYG9GGVwdQuiDi6gzOY4RDAAOveigAAG63zA= From: To: , X-OriginalArrivalTime: 14 Nov 2006 15:02:52.0540 (UTC) FILETIME=[F5359BC0:01C707FD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Schliesser, Benson [mailto:bensons@savvis.net] wrote:=20 >Fred Baker [mailto:fred@cisco.com] wrote: >> >> How about limiting DFZ only for provider aggregatable addressing >and >> >> using some on-demand routing and tunneling over the DFZ for PI=20 >> >> prefixes? >> > >> > Actually how about doing on-demand routing in general - i.e. does=20 >> > each router really need/use all the entries in RIB? >>=20 >> let's see. Having the FIB-equivalent-cache built route by=20 >route from a=20 >> RIB that was maintained on a neighboring card turned out to be a=20 >> problem, so we decided we needed to have a complete FIB (as=20 >in, a next=20 >> hop for every possible destination address) on every=20 >forwarding card.=20 >> Now we want to build the FIB-equivalent-cache built route by=20 >route by=20 >> querying systems that might be tens to hundreds of milliseconds away? > >I have to agree with Fred. Despite my previous comments=20 >indicating that any AS should be able to connect arbitrarily,=20 >the fact is that today there are a relatively small number of=20 >networks at the "core" of the connectivity graph. This=20 >on-demand model might not blow up *completely* for routers=20 >that forward to a relatively small number of destinations. >(I.e. the end-network that only talks to Google, Yahoo, and=20 >their ISP's mail server, etc.) But the routing scale problem=20 >exists largely in the "core", where the routers are actually=20 >forwarding traffic to a fairly significant proportion of the=20 >allocated address space and currently have the largest tables.=20 >Making routes on-demand for these routers would initially=20 >hinder their ability to forward packets as Fred points out. >And after lookups and tunneling take place their cache state=20 >would probably be on the same scale as today's global routing=20 >table, anyway. > The proposal was to keep routing in the "core" provider based (which scales well) and do provider independent routing over it, managed by edge networks themselves. You could tunnel over the core, do mapping on the locator part of 8+8 etc. So the hypothesis is that on-demand routing could work on the edges where each network is initiating traffic with limited number of PI addressed destination networks. Futher in all likelihood a domain name of the destination is resolved prior to such communication, and this could be used as a heuristic to fetch the on-demand routing info to the local domain (e.g. via reverse mapping the returned PI IP address to find ingress points to the destination network over the "core"). Also, typically communication with destinations starts with a handshake protocol, i.e. no need to buffer huge amounts of data. Might even work w/o buffering: do the look-up as a reaction to "destination unreachable" being returned from the DFZ. Source will re-transmit the 1st handshake packet. It would be nice to have the on-demand state in place by the time the 1st retransmit comes. Regards, Jarno _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 10:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzuG-0002y9-Fw; Tue, 14 Nov 2006 10:09:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzuF-0002wn-4p for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:08:59 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzuD-000893-NU for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:08:59 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAECoXwg002939; Tue, 14 Nov 2006 14:53:00 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 14:52:57 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 14:52:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was:Re:[arch-d][Off-topic]Further thoughts: about systems theoryandthe theory U) Date: Tue, 14 Nov 2006 14:52:54 +0200 Message-ID: <326A98184EC61140A2569345DB3614C103BF642E@esebe105.NOE.Nokia.com> In-Reply-To: <816DD9299957E547B5D758D7F977D6DCE8B228@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was:Re:[arch-d][Off-topic]Further thoughts: about systems theoryandthe theory U) Thread-Index: AccFlvxUV6hREB/qSwCkaDd/+uEFLQAMWanAAB2ueDAAavXiQA== From: To: , , X-OriginalArrivalTime: 14 Nov 2006 12:52:56.0213 (UTC) FILETIME=[CE3C8450:01C707EB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: eric.fleischman@boeing.com, jnc@mercury.lcs.mit.edu, terry.l.davis@boeing.com, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org How about starting with a denouncement of MIPv4/MIPv6 as they both are based on the assumption that the IP address can be used both as a locator and an identifier? /Mikael > >But it would be real great if we could write up the set of=20 >"what problems are we trying to solve".=20 > >/jim=20 > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 10:39:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0NA-0007Lu-Eo; Tue, 14 Nov 2006 10:38:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0N9-0007Lo-Dp for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:38:51 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0N3-0004FT-M4 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:38:51 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 09:38:45 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [CONTENT] RE: [arch-d] RE: Ok, so what should we do then? Date: Tue, 14 Nov 2006 09:40:08 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CONTENT] RE: [arch-d] RE: Ok, so what should we do then? Thread-Index: AccHuiGyYG9GGVwdQuiDi6gzOY4RDAAOveigAAG63zAAATr90A== From: "Schliesser, Benson" To: X-OriginalArrivalTime: 14 Nov 2006 15:38:45.0402 (UTC) FILETIME=[F86A47A0:01C70802] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org jarno.rajahalme@nokia.com [mailto:jarno.rajahalme@nokia.com] wrote: > The proposal was to keep routing in the "core" provider based (which > scales well) and do provider independent routing over it, managed by > edge networks themselves. Ah, I obviously misunderstood. Thanks for the clarification. > Futher in all likelihood a domain name of the destination is resolved > prior to such communication, and this could be used as a heuristic to > fetch the on-demand routing info to the local domain > [...] > no need to buffer huge amounts of data. Might even work > w/o buffering: do the look-up as a reaction to "destination unreachable" > being returned from the DFZ. Source will re-transmit the 1st handshake > packet. It would be nice to have the on-demand state in place by the > time the 1st retransmit comes. So, if I follow you correctly this time, typical end networks could use PA space and all traffic should use the path through their "primary" ISP, but during an outage the originating endpoint would do a lookup to find the address of the remote endpoint's "secondary" provider connection(s) and tunnel to it. End networks that use their own PI space would have to be tunneled for all communications. Do you envision that the host or the gateway is performing the tunneling? Is the tunnel endpoint to the remote host or the remote gateway? Do gateways need to be aware of ICMP unreachable messages destined for the host endpoint? What about load-balancing etc? I'm still quite doubtful that this could work well enough to satisfy end users and applications since it extends connection establishment time significantly. But it's worth exploring the properties to see what comes of it. Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 10:39:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0NS-0007RW-6u; Tue, 14 Nov 2006 10:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0NQ-0007RR-FT for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:39:08 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0NO-0004Ji-90 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:39:08 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kAEFd4kZ191206 for ; Tue, 14 Nov 2006 15:39:04 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAEFfpuR1786002 for ; Tue, 14 Nov 2006 15:41:51 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAEFd4HV023673 for ; Tue, 14 Nov 2006 15:39:04 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAEFd4FX023646; Tue, 14 Nov 2006 15:39:04 GMT Received: from zurich.ibm.com ([9.4.210.177]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA34980; Tue, 14 Nov 2006 16:39:02 +0100 Message-ID: <4559E315.9020100@zurich.ibm.com> Date: Tue, 14 Nov 2006 16:39:01 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [arch-d] RE: Ok, so what should we do then? References: <3C89027F-A6C1-47AF-9F62-68DCDF5BBD2F@muada.com> In-Reply-To: <3C89027F-A6C1-47AF-9F62-68DCDF5BBD2F@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Iljitsch van Beijnum wrote: > On 13-nov-2006, at 17:57, > wrote: > >> How about limiting DFZ only for provider aggregatable addressing and >> using some on-demand routing and tunneling over the DFZ for PI prefixes? > > > Something like this has been suggested by several people, including > myself. > > However, there are many details to be worked out. For instance, I'm not > a fan of doing this on-demand, I'd rather flood the mapping > information. That makes everything a lot faster and makes debugging > easier, as you have a full view of the state of the network. As I've tried to say a couple of times, i think a key design issue here is to conceptually and actually separate the way the map is computed and distributed from the way it is used for forwarding. That means the choice between (say) mapping on-demand, flooding, or some other method can be changed later, or even be different in different parts of the network. The same goes for rewriting addresses vs encapsulation and the decision whether it's host based or router based. We may need to recycle the MIB acronym (M for Mapping), so that we can conceptually have MIB -> RIB -> FIB. Brian > >> Initially this tunneling could be over existing IPv4. This could be >> pretty much like some of the tunneling based IPv6 transition methods, >> but you keep tunneling even if the DFZ transfers to IPv6. > > > The nice thing is that you can offer multiple tunnel options: over IPv4 > only, over both IPv4 and IPv6, or, in the future, over IPv6 only. And > the payload protocol can be IPv4 or IPv6. Note though that tunneling > isn't entirely problem-free: it reduces your MTU, and having a smaller > than 1500 MTU is a problem in IPv4, while a smaller than 1280 MTU isn't > allowed in IPv6. For IPv6 over IPv6, an alternative is address rewriting. > >> The border (where the tunneling happens) > > > I thinkt the tunneling/encapsulation should happen in service provider > networks, at least at first. This aids transparency and deployability, > and service providers have a bigger incentive to do this than > end-users. If end-users want to participate in this, so much the > better, but we shouldn't make this a requirement for succes. > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 10:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Xi-0004BU-OD; Tue, 14 Nov 2006 10:49:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Xg-0004Ao-Io for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:49:45 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0Xa-0006II-Tq for architecture-discuss@ietf.org; Tue, 14 Nov 2006 10:49:44 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAEFnWsj094944 for ; Tue, 14 Nov 2006 15:49:32 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAEFqkRp2920612 for ; Tue, 14 Nov 2006 16:52:46 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAEFnVhC018431 for ; Tue, 14 Nov 2006 16:49:31 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAEFnVFB018411; Tue, 14 Nov 2006 16:49:31 +0100 Received: from zurich.ibm.com ([9.4.210.177]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA58942; Tue, 14 Nov 2006 16:49:30 +0100 Message-ID: <4559E589.4070400@zurich.ibm.com> Date: Tue, 14 Nov 2006 16:49:29 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Noel Chiappa Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U) References: <20061111173657.75E3886AE9@mercury.lcs.mit.edu> In-Reply-To: <20061111173657.75E3886AE9@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, ... > Anyway, the diagrams are here: > > http://ana-3.lcs.mit.edu/~jnc/tech/DisDFZ.jpg > > which shows the problems with discontiguous chunks of new-style DFZ (i.e. the > repeated conversion from new-style locators back to old-style addresses), and > here: > > http://ana-3.lcs.mit.edu/~jnc/tech/ContDFZ.jpg > > which shows how the same technical issue (the reverse mapping from new-style > addresses back to old-style) occurs with a large, continugous new-style DFZ > on the edge, but how it's more manageable since it's only happening on a > single boundary. > > So, try rereading my other message (Fri, 10 Nov 2006 21:18:28 -0500) with > these diagrams, and see if what I'm wondering about makes sense. It confirms my view that we need to focus on the mapping in itself, without worrying too much exactly how it will be used. Bizarrely enough, the issue you raise with islands of new-DFZ needing different mappings is very similar to the issues in 6to4 about why 6to4 can't work if the IPv4 DFZ fragments, because the trivial mapping that 6to4 relies on is no longer universal. (End of section 5.5 of RFC 3056). Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 12:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1eo-00053g-Ar; Tue, 14 Nov 2006 12:01:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1em-00053V-OH for architecture-discuss@ietf.org; Tue, 14 Nov 2006 12:01:08 -0500 Received: from webmail.tropos.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk1el-0001UD-24 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 12:01:08 -0500 Received: (qmail 9728 invoked from network); 14 Nov 2006 17:00:58 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 14 Nov 2006 17:00:58 -0000 Received: from LIPC ([192.168.1.176]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 09:00:58 -0800 From: "Tony Li" To: "'Schliesser, Benson'" , Subject: RE: [arch-d] It's the routing, people! Date: Tue, 14 Nov 2006 09:00:55 -0800 Message-ID: <003701c7080e$72ffce80$b001a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccGiIUQujMXwQ2LT8ut3PkOQ0S/NwA+5sJQAAr3xUAAEdDKIAAFo8Xw In-Reply-To: X-OriginalArrivalTime: 14 Nov 2006 17:00:58.0504 (UTC) FILETIME=[74C5E880:01C7080E] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Tony Li [mailto:tli@tropos.com] wrote: > > The whole point of doing proxy aggregation is to create an aggregate > > that is sufficiently remote from the originating AS so that > TE is not > > affected. An aggregate should be injected at the same > point that the > > longer prefixes are dropped, so connectivity should not suffer. > > In an ideal and well-engineered environment this is true. But as a > general rule I'm not so sure. For instance, when provider A announces > their PA space and provider B announces a proxy aggregate for the same > space, which path does network C follow? If A announces longer prefixes that C is hearing, C has no choice, he must follow the longer prefixes. If A is announcing an aggregate, then B has no business announcing an aggregate too. This is the problem: for proxy aggregation to be effective, all providers at a certain radius must collaborate to proxy aggregate. Otherwise, longer prefixes will pull traffic in non-intuitive directions. > Proxy aggregation in this case is nice to ensure that > downstream "default-free" networks which filter on prefix length can > still reach all endpoints, but it doesn't help the "core" > networks whom > still have to carry all routes. In the general case, it can help contain some of the longer prefixes used for TE. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 13:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk34y-0004Ks-Ja; Tue, 14 Nov 2006 13:32:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk34x-0004KR-0G for architecture-discuss@ietf.org; Tue, 14 Nov 2006 13:32:15 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk34v-0005Yu-O6 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 13:32:14 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0309F86AEF; Tue, 14 Nov 2006 13:32:10 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] It's the routing, people! Message-Id: <20061114183210.0309F86AEF@mercury.lcs.mit.edu> Date: Tue, 14 Nov 2006 13:32:10 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Tony Li" > Once all of the components of an aggregate share the same next hop, > then they can all be replaced by the aggregate. Actually, there are (admittedly unusual) circumstances in which this doesn't work (in the sense of "provide the best paths", although the traffic will still get there). (I really, really liked this algorithm until I discovered cases it didn't work in! :-) For instance, start with a large site X made up of pieces X.1 ... X.n. X is connected to A on one side, and B on the other side of X (i.e. the path from the X-A connection point to the X-B connection, through X, is long). A and B (as well as X) are part of a cycle in the topology, a cycle which is longer than the path A-B via X; let's call the far point of the cycle Q. Now, applying your algorithm at A will cause A to drop all paths to individual pieces of X, and pass only a summart route for X on towards Q; similarly at B. However, traffic arriving at Q for someplace X.i within X would really like to see data on paths to the individual elements of X, so they know whether to go the B-way around the cycle leaving Q, or the A-way, in order to use the optimal entry point into X (i.e. avoid having to traverse most of X to get to their partucular destination). The algorithm you mention (share next hop -> replace with aggregate) is a good heuristic, but alas doesn't always work. I conjecture that in Destination-Vector there's no optimal local aggregation algorithm (i.e. one which uses only data at a single node) because of cases like this, where you need information on the topology far-away, in order to decide if the information you are about to discard is really useful or not. > for proxy aggregation to be effective, all providers at a certain > radius must collaborate to proxy aggregate. Otherwise, longer prefixes > will pull traffic in non-intuitive directions. Rather than say "at a certain radius", I'd rather say "along a sensible aggregation boundary" (i.e. a continuous loop - surface, if the graph is not expressible in a plane - around the destination). To me, it's one of the major failings of our current routing architecture that we have such poor tools to manage what I call "abstraction action boundaries" (to differentiate them from what I call "abstraction action boundaries" - i.e. the line drawn around X.1 ... X.n to create an abstraction X). In fact, do we have any at all? (My apologies for my ignorance about this, but I'm not very up on the latest BGP stuff, since I've concluded that Destination-Vector designs are inherenly inferior, and therefore uninteresting.) Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 14:04:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3ZU-0000Ky-Sr; Tue, 14 Nov 2006 14:03:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3ZS-0000Kt-V7 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 14:03:46 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk3ZR-0002CE-J3 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 14:03:46 -0500 Received: (qmail 30014 invoked from network); 14 Nov 2006 19:03:38 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 14 Nov 2006 19:03:37 -0000 Received: from LIPC ([192.168.1.176]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 11:03:37 -0800 From: "Tony Li" To: "'Noel Chiappa'" , Subject: RE: [arch-d] It's the routing, people! Date: Tue, 14 Nov 2006 11:03:34 -0800 Message-ID: <004501c7081f$9548c0d0$b001a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccIGzY28QhiZTK4R0KyWFAntwh76wAA1juA In-Reply-To: <20061114183210.0309F86AEF@mercury.lcs.mit.edu> X-OriginalArrivalTime: 14 Nov 2006 19:03:37.0973 (UTC) FILETIME=[975BC250:01C7081F] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > Once all of the components of an aggregate share the > same next hop, > > then they can all be replaced by the aggregate. > > Actually, there are (admittedly unusual) circumstances in > which this doesn't > work (in the sense of "provide the best paths", although the > traffic will > still get there). (I really, really liked this algorithm > until I discovered > cases it didn't work in! :-) Noel, Your example points out again that aggregation breaks optimality. That's not news. I think it's a bit over the top to say that it "doesn't work". You still have reachability and failover. > I conjecture that in Destination-Vector there's no optimal > local aggregation > algorithm (i.e. one which uses only data at a single node) > because of cases > like this, where you need information on the topology > far-away, in order to > decide if the information you are about to discard is really > useful or not. The algorithm is irrelevant. The issue is the tradeoff between scalability and optimality. If we're not prepared to sacrifice some optimality, then we cannot possibility achieve scalability. Even in Nimrod, consider the scalability of a core router that does full optimal routing. The amount of data necessary is, if I understand local abstraction control correctly, effectively the full map of the Internet, down to every individual Ethernet. I think that you'll agree that this is untenable. > To me, it's one of the major failings of our current routing > architecture > that we have such poor tools to manage what I call "abstraction action > boundaries" (to differentiate them from what I call > "abstraction action > boundaries" - i.e. the line drawn around X.1 ... X.n to > create an abstraction > X). In fact, do we have any at all? (My apologies for my > ignorance about > this, but I'm not very up on the latest BGP stuff, since I've > concluded that > Destination-Vector designs are inherenly inferior, and therefore > uninteresting.) Thank you for the insult. Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 14:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3mR-0003qX-C2; Tue, 14 Nov 2006 14:17:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3mQ-0003qL-N9 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 14:17:10 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk3mP-0004PZ-HH for architecture-discuss@ietf.org; Tue, 14 Nov 2006 14:17:10 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CA66486AEF; Tue, 14 Nov 2006 14:17:01 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] It's the routing, people! Message-Id: <20061114191701.CA66486AEF@mercury.lcs.mit.edu> Date: Tue, 14 Nov 2006 14:17:01 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Tony Li" > I think it's a bit over the top to say that it "doesn't work". You > still have reachability and failover. Well, I did say "this doesn't work (in the sense of 'provide the best paths', although the traffic will still get there)". >> we have such poor tools to manage what I call "abstraction action >> boundaries" .. In fact, do we have any at all? (My apologies for my >> ignorance about this, but I'm not very up on the latest BGP stuff, >> since I've concluded that Destination-Vector designs are inherenly >> inferior, and therefore uninteresting.) > Thank you for the insult. I'm sad you feel that way, because none was intended. It's simply a statement of practicality; I have many major interests in life other than networking, and I therefore don't have the time to follow fine operation detail of things which strike me as not the best way to go. I cheerfully accept that the world will keep going in that direction, I just don't have time to pay detailed attention to it. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 14:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3qm-0007Yu-Qf; Tue, 14 Nov 2006 14:21:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3ql-0007Ym-DG for architecture-discuss@ietf.org; Tue, 14 Nov 2006 14:21:39 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk3qj-00050W-VP for architecture-discuss@ietf.org; Tue, 14 Nov 2006 14:21:39 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kAEJLG8I023613; Tue, 14 Nov 2006 11:21:16 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kAEJLGf3023610; Tue, 14 Nov 2006 11:21:16 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 14 Nov 2006 11:21:16 -0800 (PST) From: "william(at)elan.net" To: Fred Baker Subject: Re: [arch-d] RE: Ok, so what should we do then? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org To be sure I was not talking about pure on-demand with route received from far side of the Internet before packet can be sent, but I would note that most networks do have default transit path and it can be immediatly used for packet destined to something not in local RIB. At the same time when there are regular flows to some network the routing path is then learned and is directly available in the local RIB. And I agree that it would not really solve the issue for the core routers - perhaps for core pure DFZ network some sort of DHT-like approach for BGP routing table (among iBGP speakers on same network) maybe of some use. On Mon, 13 Nov 2006, Fred Baker wrote: > let's see. Having the FIB-equivalent-cache built route by route from a RIB > that was maintained on a neighboring card turned out to be a problem, so we > decided we needed to have a complete FIB (as in, a next hop for every > possible destination address) on every forwarding card. Now we want to build > the FIB-equivalent-cache built route by route by querying systems that might > be tens to hundreds of milliseconds away? > > I'll think about that one and let you know what I come up with... > > On Nov 13, 2006, at 10:39 PM, william(at)elan.net wrote: > >> >> On Mon, 13 Nov 2006 jarno.rajahalme@nokia.com wrote: >> >>> How about limiting DFZ only for provider aggregatable addressing and >>> using some on-demand routing and tunneling over the DFZ for PI prefixes? >> >> Actually how about doing on-demand routing in general - i.e. does >> each router really need/use all the entries in RIB? Can we do >> something similar to DNS where routes are received and cached >> but can then expire if not used [note that it would not be >> easy since you need route before you can do dns, etc]? >> >> Related research question - >> Has anyone actually done (or wants to do) a study how many routes >> from BGP each router actually does use for various size networks & >> organizations? >> >> -- >> William Leibzon >> Elan Networks >> william@elan.net >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 15:38:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk51o-00040A-9u; Tue, 14 Nov 2006 15:37:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk51n-0003zu-Q8 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 15:37:07 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk51Z-0007tF-K4 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 15:36:57 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kAEKajvd000253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Nov 2006 12:36:46 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kAEKajV9010633; Tue, 14 Nov 2006 12:36:45 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kAEKZfAY007531; Tue, 14 Nov 2006 12:35:45 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 12:35:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Tue, 14 Nov 2006 12:35:19 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584B8A@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccF9lkzxWe6Lk4/TzCTkGasDzMo0QAAS4/wAFad2fAADlCfIAAmnyXw From: "Fleischman, Eric" To: "Schliesser, Benson" , X-OriginalArrivalTime: 14 Nov 2006 20:35:44.0789 (UTC) FILETIME=[7598F450:01C7082C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Benson, You've mentioned some pretty important concepts, many of which are about topics that are outside of my visibility. The sole point about which I can authoritatively speak is that entities are unlikely to willingly pay financial or operational costs to solve problems about which they have no visibility. Concerning the topics you mentioned about which I have poor visibility: 1) We are only beginning to deploy IPv6 and so we don't yet have actual operational experience concerning how destabilizing multiple addresses are within huge operational networks. The problem from my knothole isn't the automated assigning of multiple addresses (i.e., the issue that you discussed) but it is rather accounting for them and managing devices in vast networks having many duplicate addresses in a security-viable manner. Network management is already far too difficult and expensive without making it significantly harder. Consider, for example, the increased burden to our intrusion detection systems (to mention only one affected subsystem). Our experience is that we operationally have significant problems whenever we have to ensure aligned configuration on large numbers of devices from multiple vendors enterprise-wide. For example, theoretically one can deploy many DiffServ PHBs, but in practice that is not the case. With great difficulty we have deployed 5 PHBs within the enterprise and most networks significantly smaller than us are only able to operationally deploy 4 (i.e., we have business reasons to bear the expense of supporting 5 PHBs rather than the more normal 4 for networks approaching our size). 2) I don't understand why you have concluded that ISPs will have expenses that will bleed-through to us end users in any significant way due to routing table explosion. To my simple mind, ISPs will perhaps have to continually upgrade their Internet-facing ASBRs such that they could not depreciate at the standard accounting rate but other than that what are their actual expenses due to this problem? The greater threat (to my simplistic mind) is that the routing table growth rate may exceed the capabilities of the ASBRs, which will impact actual Internet performance, but as long as that doesn't happen, this doesn't seem like a very large expense to "pass through" to us. For example, depending on their number of Internet-facing ASBRs, the overhead of their billing system (for those that have one) could dwarf many possible worse-case ASBR expense scenarios. --Eric -----Original Message----- From: Schliesser, Benson [mailto:bensons@savvis.net]=20 Sent: Monday, November 13, 2006 5:54 PM To: architecture-discuss@ietf.org Subject: RE: [arch-d] It's the routing, people! Fleischman, Eric [mailto:eric.fleischman@boeing.com] wrote: > Many Internet architects are apparently keen to burden us end users with > multiple addresses. > [...] > People who intend for us to physically assign different addresses for=20 > each of our ISPs to each of our computers have not really understood the > primary end user addressing requirement: no readdressing for something > as unimportant as who our ISPs are. [...] > Unless a monopoly situation exists, why would anybody maintain business > relationships with an uncooperative ISP? I think this is an excellent point, Eric, and I fundamentally agree with the sentiment. But I'm curious about your perception of multiple addresses as burdensome. For instance, with some of the auto-configuration options currently available this could be as simple as adding a prefix to your gateways for each ISP that you want to enable. Is there an acceptable-burden crossover point somewhere between "physically assign[ing]" addresses and the ideal zero-work "no readdressing" scenarios? > Shifting the burden from ISPs to the end user is just not going to cut > it. Why does anybody imagine that end users will willingly bear=20 > significant operational expenses for a problem that isn't even visible > to us? Well, here is my perspective: The scale problems in the global routing system are economic externalities from the end network's perspective. This may (probably?) eventually lead to relative rising costs for the provider. Which would ultimately become a cost to the customer, though perhaps not until the provider marketplace is turned upside down. Given the options of 1) higher monetary costs for services, 2) higher administrative costs for renumbering, or 3) the cost of adopting whatever cool new technology we come up with, I'm betting on end networks / customers choosing #3. (unless we totally screw up the technology, I suppose) > Rather, a clean solution that is equally good for everybody has to be=20 > found, which is why I personally have supported the loc/id split=20 > approach for many years now. Alternatively, we can NAT. One might argue that loc/id split methods that don't require endpoint involvement inherently require NAT. Though not all NAT methods are created equal... Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 17:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6On-0001zJ-GG; Tue, 14 Nov 2006 17:04:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6Om-0001zE-Jr for architecture-discuss@ietf.org; Tue, 14 Nov 2006 17:04:56 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk6Om-0004NL-BV for architecture-discuss@ietf.org; Tue, 14 Nov 2006 17:04:56 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id kAEM2o2u061746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Nov 2006 23:02:53 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4559E315.9020100@zurich.ibm.com> References: <3C89027F-A6C1-47AF-9F62-68DCDF5BBD2F@muada.com> <4559E315.9020100@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] RE: Ok, so what should we do then? Date: Tue, 14 Nov 2006 23:04:36 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 14-nov-2006, at 16:39, Brian E Carpenter wrote: >> I'm not a fan of doing this on-demand, I'd rather flood the >> mapping information. > As I've tried to say a couple of times, i think a key design issue > here is to conceptually and actually separate the way the map is > computed and distributed from the way it is used for forwarding. > That means the choice between (say) mapping on-demand, flooding, > or some other method can be changed later, or even be different > in different parts of the network. Yes, this is a good point. If we keep this at a high level we avoid making choices that turn out to be bad later, at least for now. > The same goes for rewriting addresses vs encapsulation and the > decision whether it's host based or router based. Right. > We may need to recycle the MIB acronym (M for Mapping), so that > we can conceptually have MIB -> RIB -> FIB. There may even be more levels if we look at the different sources of MIB information: static (just portable address space), multihoming- related (where the entire network may change connectivity at once and TE is an important consideration) and mobility-related (similar to multihoming but per host and TE is less important or even unimportant). _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 18:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7TS-0002z4-TJ; Tue, 14 Nov 2006 18:13:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7TR-0002yj-9y for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:13:49 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7TP-0001FL-KV for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:13:49 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kAENDMx8036444; Wed, 15 Nov 2006 10:13:23 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061115100809.01431910@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 15 Nov 2006 10:13:00 +1100 To: "Fleischman, Eric" , "Schliesser, Benson" , From: Geoff Huston Subject: RE: [arch-d] It's the routing, people! In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B8A@XCH-NW-6V1.nw.nos .boeing.com> References: <474EEBD229DF754FB83D256004D0210802584B8A@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 07:35 AM 15/11/2006, Fleischman, Eric wrote: >Benson, > >You've mentioned some pretty important concepts, many of which are about >topics that are outside of my visibility. The sole point about which I >can authoritatively speak is that entities are unlikely to willingly pay >financial or operational costs to solve problems about which they have >no visibility. Generally pain (cost) and gain (benefits) need to be very directly correlated for a deregulated and diverse industry to pick up and run with the concept. This topic came up at the Amsterdam workshop and the folk there were certainly aware of this - i.e. getting some folk to spend time effort and money for somewhat vague and general benefits is a deep problem, and the routing space today is an eloquent expression of the observation that so far we haven't been able to make a routing "economy" work. (that does not mean that it cannot work, nor does it imply that efforts to look at ways to scale routing by altering the information model are not valid - they are both valid and useful activities imho, but adoption is in itself a separable issue that requires particular consideration in terms of identifying the cost and benefits that ensue. Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 18:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7dv-00080D-47; Tue, 14 Nov 2006 18:24:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7du-000808-3X for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:24:38 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7ds-0002uo-O9 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:24:38 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kAENOUTV008043; Tue, 14 Nov 2006 15:24:30 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAENOUSX008042; Tue, 14 Nov 2006 15:24:30 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 14 Nov 2006 15:24:30 -0800 From: David Meyer To: Geoff Huston Subject: Re: [arch-d] It's the routing, people! Message-ID: <20061114232430.GA8016@1-4-5.net> References: <474EEBD229DF754FB83D256004D0210802584B8A@XCH-NW-6V1.nw.nos.boeing.com> <7.0.0.16.2.20061115100809.01431910@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <7.0.0.16.2.20061115100809.01431910@apnic.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Fleischman, Eric" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Wed, Nov 15, 2006 at 10:13:00AM +1100, Geoff Huston wrote: > At 07:35 AM 15/11/2006, Fleischman, Eric wrote: > >Benson, > > > >You've mentioned some pretty important concepts, many of which are about > >topics that are outside of my visibility. The sole point about which I > >can authoritatively speak is that entities are unlikely to willingly pay > >financial or operational costs to solve problems about which they have > >no visibility. >=20 > Generally pain (cost) and gain (benefits) need to be very directly=20 > correlated for a deregulated and diverse industry to pick up and run=20 > with the concept. This topic came up at the Amsterdam workshop and=20 > the folk there were certainly aware of this - i.e. getting some folk=20 > to spend time effort and money for somewhat vague and general=20 > benefits is a deep problem, and the routing space today is an=20 > eloquent expression of the observation that so far we haven't been=20 > able to make a routing "economy" work. (that does not mean that it=20 > cannot work, nor does it imply that efforts to look at ways to scale=20 > routing by altering the information model are not valid - they are=20 > both valid and useful activities imho, but adoption is in itself a=20 > separable issue that requires particular consideration in terms of=20 > identifying the cost and benefits that ensue. Well said. --dmm _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 18:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7p1-0003tq-VC; Tue, 14 Nov 2006 18:36:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7p0-0003pj-Vg for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:36:06 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7oy-000524-MR for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:36:06 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 60AFD86AF7; Tue, 14 Nov 2006 18:36:04 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] It's the routing, people! Message-Id: <20061114233604.60AFD86AF7@mercury.lcs.mit.edu> Date: Tue, 14 Nov 2006 18:36:04 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Geoff Huston > Generally pain (cost) and gain (benefits) need to be very directly > correlated for a deregulated and diverse industry to pick up and run > with the concept. > ... adoption is in itself a separable issue that requires particular > consideration in terms of identifying the cost and benefits that ensue. At one point it was suggested that people ought to be charged for routes (or rather, that they be charged for occupying routing table slots). This never took off, and I gather than in addition to the obvious policy issues (does a popular destination have to pay rent, how do ISP's balance payments to each other, etc, etc), it just didn't have much appeal in general. I assume this is still the case? Did you (or anyone) have any other suggestion(s) for ways we can "incentivize" (to use that wonderful/horrible neologism) routing costs? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 18:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7xk-0006eo-RX; Tue, 14 Nov 2006 18:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7xj-0006ea-Cy for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:45:07 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7xi-0006mS-Ng for architecture-discuss@ietf.org; Tue, 14 Nov 2006 18:45:07 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kAENiuOJ037020; Wed, 15 Nov 2006 10:44:56 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061115103857.014343b8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 15 Nov 2006 10:44:42 +1100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: Geoff Huston Subject: RE: [arch-d] It's the routing, people! In-Reply-To: <20061114233604.60AFD86AF7@mercury.lcs.mit.edu> References: <20061114233604.60AFD86AF7@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:36 AM 15/11/2006, Noel Chiappa wrote: > > From: Geoff Huston > > > Generally pain (cost) and gain (benefits) need to be very directly > > correlated for a deregulated and diverse industry to pick up and run > > with the concept. > > ... adoption is in itself a separable issue that requires particular > > consideration in terms of identifying the cost and benefits that ensue. > >At one point it was suggested that people ought to be charged for routes (or >rather, that they be charged for occupying routing table slots). This never >took off, and I gather than in addition to the obvious policy issues (does >a popular destination have to pay rent, how do ISP's balance payments to >each other, etc, etc), it just didn't have much appeal in general. I assume >this is still the case? I recall this discussion back at a Dallas IETF CIDR WG meeting - the issues where about route push vs route pull - how do you know who should pay whom for routing entries? It was never obvious then, and still not obvious now the difference between a routing economy and extortion! But I suspect that in general we are economic neophytes, and there may well be more space to explore here. >Did you (or anyone) have any other suggestion(s) for ways we can >"incentivize" (to use that wonderful/horrible neologism) routing costs? (Some years back an Australian election was fought with the key phrase from one side being "incentivation" They lost the election. Some would claim that the loss was related to the abuse of the language!) I don't - I've thought about this on and off for many years, and if there were easy solutions lying on the floor I'm sure that even I would've stumbled over them by now. I've tried to poke this onder the nose of some of the economists who venture into the same meetings as we do, but its never got very far yet. Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 14 19:06:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk8IL-0003Zm-UH; Tue, 14 Nov 2006 19:06:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk8IK-0003ZY-Hr for architecture-discuss@ietf.org; Tue, 14 Nov 2006 19:06:24 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk8IF-0003bH-5w for architecture-discuss@ietf.org; Tue, 14 Nov 2006 19:06:24 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1Gk8IA-0002rD-HT for architecture-discuss@ietf.org; Tue, 14 Nov 2006 16:06:15 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Nov 2006 01:03:59 +0100 To: Geoff Huston ,jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: Jefsey_Morfin Subject: RE: [arch-d] It's the routing, people! In-Reply-To: <7.0.0.16.2.20061115103857.014343b8@apnic.net> References: <20061114233604.60AFD86AF7@mercury.lcs.mit.edu> <7.0.0.16.2.20061115103857.014343b8@apnic.net> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0613334421==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0613334421== Content-Type: multipart/alternative; boundary="----MTepqyzgagfzyvdnhpniiucrxbkxmkucrw" ------MTepqyzgagfzyvdnhpniiucrxbkxmkucrw Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-43A95D3D At 00:44 15/11/2006, Geoff Huston wrote: >At 10:36 AM 15/11/2006, Noel Chiappa wrote: >> > From: Geoff Huston >> >> > Generally pain (cost) and gain (benefits) need to be very directly >> > correlated for a deregulated and diverse industry to pick up and run >> > with the concept. >> > ... adoption is in itself a separable issue that requires particular >> > consideration in terms of identifying the cost and benefits >> that ensue. >> >>At one point it was suggested that people ought to be charged for routes (or >>rather, that they be charged for occupying routing table slots). This never >>took off, and I gather than in addition to the obvious policy issues (does >>a popular destination have to pay rent, how do ISP's balance payments to >>each other, etc, etc), it just didn't have much appeal in general. I assume >>this is still the case? > >I recall this discussion back at a Dallas IETF CIDR WG meeting - the >issues where about route push vs route pull - how do you know who >should pay whom for routing entries? It was never obvious then, and >still not obvious now the difference between a routing economy and >extortion! But I suspect that in general we are economic neophytes, >and there may well be more space to explore here. Suppress the cost center. Make the routing costs included in domain name. If everyone has an IPv6 address everyone will have at least one domain name. My suggested DNSS does not resolve IP addresses but routes. I then do see no economic problem. All the more than there would then be additional services that would help the cost to be paid. Please do not think IPv4 1983 network when you want to address the issues of an IPv6 2010 environment. Start anew, just consider how to transition and if you can back-off in case of problem. jfc ------MTepqyzgagfzyvdnhpniiucrxbkxmkucrw Content-Type: text/html At 00:44 15/11/2006, Geoff Huston wrote:
>At 10:36 AM 15/11/2006, Noel Chiappa wrote:
>>     > From: Geoff Huston <gih@apnic.net>
>>
>>     > Generally pain (cost) and gain (benefits) need to be very directly
>>     > correlated for a deregulated and diverse industry to pick up and run
>>     > with the concept.
>>     > ... adoption is in itself a separable issue that requires particular
>>     > consideration in terms of identifying the cost and benefits
>> that ensue.
>>
>>At one point it was suggested that people ought to be charged for routes (or
>>rather, that they be charged for occupying routing table slots). This never
>>took off, and I gather than in addition to the obvious policy issues (does
>>a popular destination have to pay rent, how do ISP's balance payments to
>>each other, etc, etc), it just didn't have much appeal in general. I assume
>>this is still the case?
>
>I recall this discussion back at a Dallas IETF CIDR WG meeting - the
>issues where about route push vs route pull - how do you know who
>should pay whom for routing entries?  It was never obvious then, and
>still not obvious now the difference between a routing economy and
>extortion! But I suspect that in general we are economic neophytes,
>and there may well be more space to explore here.

Suppress the cost center. Make the routing costs included in domain
name. If everyone has an IPv6 address everyone will have at least one
domain name. My suggested DNSS does not resolve IP addresses but
routes. I then do see no economic problem. All the more than there
would then be additional services that would help the cost to be paid.

Please do not think IPv4 1983 network when you want to address the
issues of an IPv6 2010 environment.
Start anew, just consider how to transition and if you can back-off
in case of problem.
jfc

------MTepqyzgagfzyvdnhpniiucrxbkxmkucrw-- --===============0613334421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0613334421==-- From architecture-discuss-bounces@ietf.org Tue Nov 14 21:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkAE8-0002UK-GY; Tue, 14 Nov 2006 21:10:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkAE7-0002U0-88 for architecture-discuss@ietf.org; Tue, 14 Nov 2006 21:10:11 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkAE4-0004V4-Rp for architecture-discuss@ietf.org; Tue, 14 Nov 2006 21:10:11 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2006 18:10:07 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAF2A7t9000507; Tue, 14 Nov 2006 18:10:07 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAF2A4it002764; Tue, 14 Nov 2006 18:10:06 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 18:09:50 -0800 Received: from [171.70.255.13] ([171.70.255.13]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 18:09:50 -0800 Message-ID: <455A76ED.8040804@employees.org> Date: Tue, 14 Nov 2006 18:09:49 -0800 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) References: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> <4559980C.4080106@zurich.ibm.com> In-Reply-To: <4559980C.4080106@zurich.ibm.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 02:09:50.0166 (UTC) FILETIME=[2192BF60:01C7085B] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 11/14/2006 02:18 AM, Brian E Carpenter allegedly wrote: > Noel Chiappa wrote: >> We want to discourage people from passing around bare endpoint >> identifiers. (Such an identifier might e.g. identify one >> particular server in a pool - not what you really wanted anyway.) >> Rather, they *should* be passing around higher-level identifiers. > > In theory, I agree. In practice, real time apps really don't want > to pay the overhead of another lookup, once a multiparty session is > started. But when new parties join, they join at multiple layers. That is the application might have visibility into the IP address (as presented to the receiver), but it also gets higher layer identifiers, authentication etc. I don't see what you're saying. swb _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 15 05:42:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIAy-0004fJ-HX; Wed, 15 Nov 2006 05:39:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIAw-0004f9-Fl for architecture-discuss@ietf.org; Wed, 15 Nov 2006 05:39:27 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkIAu-0002c6-Ux for architecture-discuss@ietf.org; Wed, 15 Nov 2006 05:39:26 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFAcw9l002383; Wed, 15 Nov 2006 12:39:22 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 12:38:56 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 12:38:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [CONTENT] RE: [arch-d] RE: Ok, so what should we do then? Date: Wed, 15 Nov 2006 12:38:55 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CONTENT] RE: [arch-d] RE: Ok, so what should we do then? Thread-Index: AccHuiGyYG9GGVwdQuiDi6gzOY4RDAAOveigAAG63zAAATr90AAnTLog From: To: , X-OriginalArrivalTime: 15 Nov 2006 10:38:56.0186 (UTC) FILETIME=[406B81A0:01C708A2] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Schliesser, Benson [mailto:bensons@savvis.net] wrote: >jarno.rajahalme@nokia.com [mailto:jarno.rajahalme@nokia.com] wrote: >> The proposal was to keep routing in the "core" provider based (which=20 >> scales well) and do provider independent routing over it, managed by=20 >> edge networks themselves. > >Ah, I obviously misunderstood. Thanks for the clarification. > >> Futher in all likelihood a domain name of the destination is=20 >resolved=20 >> prior to such communication, and this could be used as a=20 >heuristic to=20 >> fetch the on-demand routing info to the local domain [...]=20 >no need to=20 >> buffer huge amounts of data. Might even work w/o buffering: do the=20 >> look-up as a reaction to "destination >unreachable" >> being returned from the DFZ. Source will re-transmit the 1st=20 >handshake=20 >> packet. It would be nice to have the on-demand state in place by the=20 >> time the 1st retransmit comes. > >So, if I follow you correctly this time, typical end networks=20 >could use PA space and all traffic should use the path through=20 >their "primary" >ISP, but during an outage the originating endpoint would do a=20 >lookup to find the address of the remote endpoint's=20 >"secondary" provider >connection(s) and tunnel to it. End networks that use their=20 >own PI space would have to be tunneled for all communications. > Rather all networks needing the provider independence would use PI space. However, it might be beneficial to use PA space for high-volume publicly accessable servers (e.g. web servers accessible from the Internet) this applies also to publicly accessible DNS servers etc. but the intranet would be PI addressed. Also, preferably multiple routes to the remote PI space would be discovered at the same time, allowing for TE, load balancing, failover, etc. Also this kind of explicit on-demand route discovery step would allow for "controlled transparency", policy-based securing the traffic in transit etc. >Do you envision that the host or the gateway is performing the=20 >tunneling? Is the tunnel endpoint to the remote host or the=20 It should be at gateways somewhere between the PI-addressed network and the DFZ "core". Major requirement being allowing edge network to use PI space and multihome, and having no PI routes in the DFZ. >remote gateway? Do gateways need to be aware of ICMP=20 >unreachable messages destined for the host endpoint? What=20 >about load-balancing etc? > Load balancing already addressed above. ICMP unreachable was only one possiblity I have not thought much further. It may also be that it is not needed, if the tunnel discovery is done on a gateway without any default routes, as it would notice locally that there is no route to destination, toss the packet to the slow-path SW processing where the on-demand routing could be done. Also, routing could be on-demand only as far as the FIB on the line card is considered, i.e. the "tunnel route" exists on the slow-path RIB but is instantiated on the fast-path FIB on-demand. This would be trivial to do if "destination unreachable" generation already happens on the slow-path. Is anyone doing this on current routers (e.g. for normal BGP routes)? >I'm still quite doubtful that this could work well enough to=20 >satisfy end users and applications since it extends connection=20 >establishment time significantly. But it's worth exploring the=20 >properties to see what comes of it. > Well, as Brian wrote, the routing info could be also fully distributed. But have PI tunnel-routes on-demand delivered to the HW fast-path, and tunneled (source-routed, wrapped, mapped, etc.) over the DFZ "core", as otherwise the core FIBs (on fast path) would grow too big, as they would need all the routes most of the time, I assume. I still think this kind of a system could be an off-spring of one of the tunneling based IPv6 transition methods. Run a v6-over-v4 "tunnel-routing-protocol" over the current IPv4 network, and go on from there. =20 Regards, Jarno _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 15 07:26:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkJpC-00029N-1b; Wed, 15 Nov 2006 07:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkJp9-00029H-Sl for architecture-discuss@ietf.org; Wed, 15 Nov 2006 07:25:03 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkJp8-00021y-F9 for architecture-discuss@ietf.org; Wed, 15 Nov 2006 07:25:03 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAFCP1hx320422 for ; Wed, 15 Nov 2006 12:25:01 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAFCSHRM3211454 for ; Wed, 15 Nov 2006 13:28:17 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAFCP1eJ031081 for ; Wed, 15 Nov 2006 13:25:01 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAFCP0Fs030942; Wed, 15 Nov 2006 13:25:00 +0100 Received: from zurich.ibm.com (sig-9-145-131-78.de.ibm.com [9.145.131.78]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA76238; Wed, 15 Nov 2006 13:24:52 +0100 Message-ID: <455AE595.7090307@zurich.ibm.com> Date: Wed, 15 Nov 2006 11:01:57 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Scott W Brim Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) References: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> <4559980C.4080106@zurich.ibm.com> <455A76ED.8040804@employees.org> In-Reply-To: <455A76ED.8040804@employees.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Scott W Brim wrote: > On 11/14/2006 02:18 AM, Brian E Carpenter allegedly wrote: > >>Noel Chiappa wrote: >> >>>We want to discourage people from passing around bare endpoint >>>identifiers. (Such an identifier might e.g. identify one >>>particular server in a pool - not what you really wanted anyway.) >>>Rather, they *should* be passing around higher-level identifiers. >> >>In theory, I agree. In practice, real time apps really don't want >>to pay the overhead of another lookup, once a multiparty session is >>started. > > > But when new parties join, they join at multiple layers. That is the > application might have visibility into the IP address (as presented to > the receiver), but it also gets higher layer identifiers, > authentication etc. I don't see what you're saying. In something like a massive multi-player game, it's OK to pay lookup/AAA overhead when a new player joins, or when you first encounter a new player, but from then on you need to pass a handle that does not generate further lookup. It seems a shame if we can't use network layer handles for that. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 15 07:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkK0d-0005lC-J0; Wed, 15 Nov 2006 07:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkK0c-0005l4-Sc for architecture-discuss@ietf.org; Wed, 15 Nov 2006 07:36:54 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkK0Z-0004A0-NJ for architecture-discuss@ietf.org; Wed, 15 Nov 2006 07:36:54 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GkK0Y-0006YP-GQ for architecture-discuss@ietf.org; Wed, 15 Nov 2006 04:36:51 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Nov 2006 12:36:59 +0100 To: Brian E Carpenter ,Fred Baker From: Jefsey_Morfin Subject: Re: [arch-d] RE: Ok, so what should we do then? In-Reply-To: <45599739.8030209@zurich.ibm.com> References: <45599739.8030209@zurich.ibm.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0025854453==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0025854453== Content-Type: multipart/alternative; boundary="----MTrrximhttoskopwrcmkcborcxvryhstmr" ------MTrrximhttoskopwrcmkcborcxvryhstmr Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7E630E1 Think of my proposed DNSS needle. The routing information is in the packet header: information is already here or a few microseconds away (read the header). If the numbering plan is adequately designed (topology dependent on the numbering plan) once in a while route computation and needle size can be very limited. jfc At 11:15 14/11/2006, Brian E Carpenter wrote: >Or another way to ask the question: how long a startup delay >is acceptable for a new flow, if remote lookup is needed? > >In the phone system, the answer seems to be up to several seconds, >but when sending short flows of 1500 byte packets on a 10 Gb link, >it doesn't seem like we can tolerate more than a few tens >of microseconds at most. > > Brian > >Fred Baker wrote: >>let's see. Having the FIB-equivalent-cache built route by route >>from a RIB that was maintained on a neighboring card turned out to be a >>problem, so we decided we needed to have a complete FIB (as in, >>a next hop for every possible destination address) on every >>forwarding card. Now we want to build the FIB-equivalent-cache >>built route by route by querying systems that might be tens to >>hundreds of milliseconds away? >>I'll think about that one and let you know what I come up with... >>On Nov 13, 2006, at 10:39 PM, william(at)elan.net wrote: >> >>> >>>On Mon, 13 Nov 2006 jarno.rajahalme@nokia.com wrote: >>> >>>>How about limiting DFZ only for provider aggregatable addressing and >>>>using some on-demand routing and tunneling over the DFZ for PI >>>>prefixes? >>> >>> >>>Actually how about doing on-demand routing in general - i.e. does >>>each router really need/use all the entries in RIB? Can we do >>>something similar to DNS where routes are received and cached >>>but can then expire if not used [note that it would not be >>>easy since you need route before you can do dns, etc]? >>> >>>Related research question - >>> Has anyone actually done (or wants to do) a study how many routes >>>from BGP each router actually does use for various size networks & >>>organizations? >>> >>>-- >>>William Leibzon >>>Elan Networks >>>william@elan.net >>> >>>_______________________________________________ >>>Architecture-discuss mailing list >>>Architecture-discuss@ietf.org >>>https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >>_______________________________________________ >>Architecture-discuss mailing list >>Architecture-discuss@ietf.org >>https://www1.ietf.org/mailman/listinfo/architecture-discuss > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > ------MTrrximhttoskopwrcmkcborcxvryhstmr Content-Type: text/html Think of my proposed DNSS needle. The routing information is in the
packet header: information is already here or a few microseconds away
(read the header). If the numbering plan is adequately designed
(topology dependent on the numbering plan) once in a while route
computation and needle size can be very limited.
jfc

At 11:15 14/11/2006, Brian E Carpenter wrote:

>Or another way to ask the question: how long a startup delay
>is acceptable for a new flow, if remote lookup is needed?
>
>In the phone system, the answer seems to be up to several seconds,
>but when sending short flows of 1500 byte packets on a 10 Gb link,
>it doesn't seem like we can tolerate more than a few tens
>of microseconds at most.
>
>     Brian
>
>Fred Baker wrote:
>>let's see. Having the FIB-equivalent-cache built route by route
>>from  a RIB that was maintained on a neighboring card turned out to be a
>>problem, so we decided we needed to have a complete FIB (as in,
>>a  next hop for every possible destination address) on every
>>forwarding  card. Now we want to build the FIB-equivalent-cache
>>built route by  route by querying systems that might be tens to
>>hundreds of  milliseconds away?
>>I'll think about that one and let you know what I come up with...
>>On Nov 13, 2006, at 10:39 PM, william(at)elan.net wrote:
>>
>>>
>>>On Mon, 13 Nov 2006 jarno.rajahalme@nokia.com wrote:
>>>
>>>>How about limiting DFZ only for provider aggregatable addressing and
>>>>using some on-demand routing and tunneling over the DFZ for PI
>>>>prefixes?
>>>
>>>
>>>Actually how about doing on-demand routing in general - i.e. does
>>>each router really need/use all the entries in RIB? Can we do
>>>something similar to DNS where routes are received and cached
>>>but can then expire if not used [note that it would not be
>>>easy since you need route before you can do dns, etc]?
>>>
>>>Related research question -
>>>  Has anyone actually done (or wants to do) a study how many routes
>>>from BGP each router actually does use for various size networks &
>>>organizations?
>>>
>>>--
>>>William Leibzon
>>>Elan Networks
>>>william@elan.net
>>>
>>>_______________________________________________
>>>Architecture-discuss mailing list
>>>Architecture-discuss@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>>
>>_______________________________________________
>>Architecture-discuss mailing list
>>Architecture-discuss@ietf.org
>>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>
>

------MTrrximhttoskopwrcmkcborcxvryhstmr-- --===============0025854453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0025854453==-- From architecture-discuss-bounces@ietf.org Wed Nov 15 08:08:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkKUI-0003PX-Vx; Wed, 15 Nov 2006 08:07:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkKUH-0003Ld-8D for architecture-discuss@ietf.org; Wed, 15 Nov 2006 08:07:33 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkKUF-0000Gp-NS for architecture-discuss@ietf.org; Wed, 15 Nov 2006 08:07:33 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFD6Cug019144; Wed, 15 Nov 2006 15:07:21 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:07:18 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:07:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Wed, 15 Nov 2006 15:07:15 +0200 Message-ID: In-Reply-To: <455AE595.7090307@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) Thread-Index: AccItMY9tB5Tsm31THyi4i+pNtI1VQAAPdDA From: To: , X-OriginalArrivalTime: 15 Nov 2006 13:07:18.0234 (UTC) FILETIME=[FA743BA0:01C708B6] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: jnc@mercury.lcs.mit.edu, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian E Carpenter [mailto:brc@zurich.ibm.com] wrote: > >Scott W Brim wrote: >> On 11/14/2006 02:18 AM, Brian E Carpenter allegedly wrote: >>=20 >>>Noel Chiappa wrote: >>> >>>>We want to discourage people from passing around bare endpoint=20 >>>>identifiers. (Such an identifier might e.g. identify one particular=20 >>>>server in a pool - not what you really wanted anyway.) Rather, they=20 >>>>*should* be passing around higher-level identifiers. >>> >>>In theory, I agree. In practice, real time apps really don't want to=20 >>>pay the overhead of another lookup, once a multiparty session is=20 >>>started. >>=20 >>=20 >> But when new parties join, they join at multiple layers. =20 >That is the=20 >> application might have visibility into the IP address (as=20 >presented to=20 >> the receiver), but it also gets higher layer identifiers,=20 >> authentication etc. I don't see what you're saying. > >In something like a massive multi-player game, it's OK to pay=20 >lookup/AAA overhead when a new player joins, or when you first=20 >encounter a new player, but from then on you need to pass a=20 >handle that does not generate further lookup. It seems a shame=20 >if we can't use network layer handles for that. > An application layer handle is needed to refer to a player. What if a player changes from one host to another? Why should his handle change? Why would you want to use network layer handles for that? Doing exactly that has gotten us in this inability to renumber mess (network layer handles used to refer to service/app layer stuff in config files etc.). Jarno _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 15 09:26:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLhD-0001c3-AX; Wed, 15 Nov 2006 09:24:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLhB-0001bu-DW for architecture-discuss@ietf.org; Wed, 15 Nov 2006 09:24:57 -0500 Received: from web54706.mail.yahoo.com ([206.190.49.196]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkLh6-0002nE-Ft for architecture-discuss@ietf.org; Wed, 15 Nov 2006 09:24:56 -0500 Received: (qmail 88200 invoked by uid 60001); 15 Nov 2006 14:24:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q3GFQNLfTLLPNSBQNrFEqWUyQX7ygjU0SgbZJjGg2HW6eLNjJZ3qmRYvakDz9xbkaRtb+2mf8dtoWtHPH1m6IFK3H2CQ62vamynWAR2Wt0cl1ny+5wf5LX9CosPcIeOqpmJsxn2VBrk+WFxs/+5oTj2zwaqD6QK5+Y17YEU+nMU= ; Message-ID: <20061115142447.88198.qmail@web54706.mail.yahoo.com> Received: from [207.107.50.100] by web54706.mail.yahoo.com via HTTP; Wed, 15 Nov 2006 06:24:47 PST Date: Wed, 15 Nov 2006 06:24:47 -0800 (PST) From: Peter Sherbin Subject: RE: [arch-d] It's the routing, people! To: Noel Chiappa , architecture-discuss@ietf.org In-Reply-To: <20061114233604.60AFD86AF7@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Did you (or anyone) have any other suggestion(s) for ways we can > "incentivize" (to use that wonderful/horrible neologism) routing costs? Hmmm... My experience so far was that IETF does Engineering only and consciously avoids any economical comment. Did this change? As a provider I expect from experts at the very least a guidance on what is the commonly accepted cost driver of the Internet so I can price services and settle with boarding networks. As an individual and/or a business I want PI addresses permanently allocated to me for as long as I need them. Thanks, PS --- Noel Chiappa wrote: > > From: Geoff Huston > > > Generally pain (cost) and gain (benefits) need to be very directly > > correlated for a deregulated and diverse industry to pick up and run > > with the concept. > > ... adoption is in itself a separable issue that requires particular > > consideration in terms of identifying the cost and benefits that ensue. > > At one point it was suggested that people ought to be charged for routes (or > rather, that they be charged for occupying routing table slots). This never > took off, and I gather than in addition to the obvious policy issues (does > a popular destination have to pay rent, how do ISP's balance payments to > each other, etc, etc), it just didn't have much appeal in general. I assume > this is still the case? > > Did you (or anyone) have any other suggestion(s) for ways we can > "incentivize" (to use that wonderful/horrible neologism) routing costs? > > Noel > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Sponsored Link Mortgage rates near 39yr lows. $420k for $1,399/mo. Calculate new payment! www.LowerMyBills.com/lre _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 15 09:33:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLo5-0002kT-NO; Wed, 15 Nov 2006 09:32:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLo5-0002kC-2J for architecture-discuss@ietf.org; Wed, 15 Nov 2006 09:32:05 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkLo2-0003xL-OU for architecture-discuss@ietf.org; Wed, 15 Nov 2006 09:32:05 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2006 06:31:57 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAFEVuCN012425 for ; Wed, 15 Nov 2006 06:31:56 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAFEVuW4025452 for ; Wed, 15 Nov 2006 06:31:56 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 06:31:55 -0800 Received: from [10.21.81.172] ([10.21.81.172]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 06:31:55 -0800 Message-ID: <455B24DB.6010400@employees.org> Date: Wed, 15 Nov 2006 06:31:55 -0800 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: architecture-discuss@ietf.org Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) References: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> <4559980C.4080106@zurich.ibm.com> <455A76ED.8040804@employees.org> <455AE595.7090307@zurich.ibm.com> In-Reply-To: <455AE595.7090307@zurich.ibm.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 14:31:55.0817 (UTC) FILETIME=[CCEDE990:01C708C2] Authentication-Results: sj-dkim-4; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 11/15/2006 02:01 AM, Brian E Carpenter allegedly wrote: > Scott W Brim wrote: >> But when new parties join, they join at multiple layers. That is the >> application might have visibility into the IP address (as presented to >> the receiver), but it also gets higher layer identifiers, >> authentication etc. I don't see what you're saying. > > In something like a massive multi-player game, it's OK to pay lookup/AAA > overhead when a new player joins, or when you first encounter a new player, > but from then on you need to pass a handle that does not generate > further lookup. It seems a shame if we can't use network layer handles > for that. I don't see where the further lookup comes from. Someone joins and the information is propagated, including persistent identifier and authentication information, as well as the (last known) network layer "handle". If & when he changes his NLH, the information that is important to the game is still there. It's like HIP at an application layer. The downside is that every application has to have such a mechanism, so it would be good to have a common mechanism at a common layer. Anyway I'm still missing something. Scott _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 15 12:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOKO-0002Uw-8F; Wed, 15 Nov 2006 12:13:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOKN-0002TG-F4 for architecture-discuss@ietf.org; Wed, 15 Nov 2006 12:13:35 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkOKL-0002Qk-4S for architecture-discuss@ietf.org; Wed, 15 Nov 2006 12:13:35 -0500 Received: from magenta.juniper.net (magenta.juniper.net [172.17.28.122]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id kAFHDW1Z018619; Wed, 15 Nov 2006 09:13:32 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.176]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id kAFHDVE85111; Wed, 15 Nov 2006 09:13:31 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20061115113138.03879cb0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 15 Nov 2006 12:13:27 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: Ross Callon Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) In-Reply-To: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 03:13 PM 11/10/2006 -0500, Noel Chiappa wrote: > > From: Brian E Carpenter > > > address ambiguity destroys the e2e identification property and third > > party referrals > >That's not a bug, that's a feature. > >We want to discourage people from passing around bare endpoint identifiers. >(Such an identifier might e.g. identify one particular server in a pool - not >what you really wanted anyway.) Rather, they *should* be passing around >higher-level identifiers. In principle I agree: Applications should deal with application identifiers (such as DNS names), not with network layer addresses. Having applications pass around network layer addresses (or network layer IDs) puts constraints on the network layer that is making it significantly more difficult to deal with various problems. However, I thought that the point of this ongoing discussion was to exchange information and ideas that will lead to a practical solution that can be deployed in the real Internet. In practice, we aren't going to get applications re-written to remove all of the cases where they carry around network layer addresses. Thus we are going to have to live with the fact that this isn't going to change. We could redefine the network layer thing that Applications already are carrying to be an "identifier" that is location-independent, but we can't stop them from carrying something that looks a whole lot like the IP addresses that they already carry. Ross _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 15 13:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkP6r-0007Kw-Dg; Wed, 15 Nov 2006 13:03:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkP6p-0007Km-Qa for architecture-discuss@ietf.org; Wed, 15 Nov 2006 13:03:39 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkP6o-0001KX-Bh for architecture-discuss@ietf.org; Wed, 15 Nov 2006 13:03:39 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GkP6c-0006z1-Bj for architecture-discuss@ietf.org; Wed, 15 Nov 2006 10:03:27 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Nov 2006 19:02:38 +0100 To: Ross Callon , jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: Jefsey_Morfin Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) In-Reply-To: <5.0.0.25.2.20061115113138.03879cb0@zircon.juniper.net> References: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> <5.0.0.25.2.20061115113138.03879cb0@zircon.juniper.net> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0738296995==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0738296995== Content-Type: multipart/alternative; boundary="----MTqbzuwlafpwbmywwszferveavomlduwcp" ------MTqbzuwlafpwbmywwszferveavomlduwcp Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7E630E1 Dear Ross, We already have IPv4 and IPv6 using 2 /3 blocks. That works and should not be changed, just fade away if a new solution works better. We have to devise a new system which works in _addition_. Using a different /3 block (so we are sure there is not conflict). That new system should not be too complex, nor to take too much room, on the machines, since it will have to be added. It should decrease the need for intelligence in routers and middle boxes (dumb network) sharing in the restauration of e2e. The DNS experience shows that architecturally that kind of parallel intelligent service went well. So an idea to dig into. Resolving routes instead of addresses? Which way these addresses are to be documented? Far easier and lighter if the topology is designed after the numbering plan. Now, you can try to develop it from existing concepts. You can use any entirely new concepts and a protocol variant. There is no harm trying. There is harm only in failing to find a solution. The more ideas and concepts, the more we have chances to succeed. And if all this was not necessary, never mind nothing will have changed. But I do think that value added routing services are the IPv6 "application" the IETF waits for 14 years. jfc At 18:13 15/11/2006, Ross Callon wrote: >At 03:13 PM 11/10/2006 -0500, Noel Chiappa wrote: >> > From: Brian E Carpenter >> >> > address ambiguity destroys the e2e identification property and third >> > party referrals >> >>That's not a bug, that's a feature. >> >>We want to discourage people from passing around bare endpoint identifiers. >>(Such an identifier might e.g. identify one particular server in a pool - not >>what you really wanted anyway.) Rather, they *should* be passing around >>higher-level identifiers. > >In principle I agree: Applications should deal with application >identifiers (such as DNS names), not with network layer >addresses. Having applications pass around network layer >addresses (or network layer IDs) puts constraints on the >network layer that is making it significantly more difficult to >deal with various problems. > >However, I thought that the point of this ongoing discussion >was to exchange information and ideas that will lead to a >practical solution that can be deployed in the real Internet. > >In practice, we aren't going to get applications re-written to >remove all of the cases where they carry around network >layer addresses. Thus we are going to have to live with the >fact that this isn't going to change. We could redefine the >network layer thing that Applications already are carrying >to be an "identifier" that is location-independent, but we >can't stop them from carrying something that looks a whole >lot like the IP addresses that they already carry. > >Ross > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > ------MTqbzuwlafpwbmywwszferveavomlduwcp Content-Type: text/html Dear Ross,
We already have IPv4 and IPv6 using 2 /3 blocks. That works and
should not be changed, just fade away if a new solution works better.
We have to devise a new system which works in _addition_. Using a
different /3 block (so we are sure there is not conflict).

That new system should not be too complex, nor to take too much room,
on the machines, since it will have to be added. It should decrease
the need for intelligence in routers and middle boxes (dumb network)
sharing in the restauration of e2e. The DNS experience shows that
architecturally that kind of parallel intelligent service went well.
So an idea to dig into. Resolving routes instead of addresses? Which
way these addresses are to be documented? Far easier and lighter if
the topology is designed after the numbering plan.

Now, you can try to develop it from existing concepts. You can use
any entirely new concepts and a protocol variant. There is no harm
trying. There is harm only in failing to find a solution. The more
ideas and concepts, the more we have chances to succeed.

And if all this was not necessary, never mind nothing will have changed.
But I do think that value added routing services are the IPv6
"application" the IETF waits for 14 years.
jfc


At 18:13 15/11/2006, Ross Callon wrote:

>At 03:13 PM 11/10/2006 -0500, Noel Chiappa wrote:
>>     > From: Brian E Carpenter <brc@zurich.ibm.com>
>>
>>     > address ambiguity destroys the e2e identification property and third
>>     > party referrals
>>
>>That's not a bug, that's a feature.
>>
>>We want to discourage people from passing around bare endpoint identifiers.
>>(Such an identifier might e.g. identify one particular server in a pool - not
>>what you really wanted anyway.) Rather, they *should* be passing around
>>higher-level identifiers.
>
>In principle I agree: Applications should deal with application
>identifiers (such as DNS names), not with network layer
>addresses. Having applications pass around network layer
>addresses (or network layer IDs) puts constraints on the
>network layer that is making it significantly more difficult to
>deal with various problems.
>
>However, I thought that the point of this ongoing discussion
>was to exchange information and ideas that will lead to a
>practical solution that can be deployed in the real Internet.
>
>In practice, we aren't going to get applications re-written to
>remove all of the cases where they carry around network
>layer addresses. Thus we are going to have to live with the
>fact that this isn't going to change. We could redefine the
>network layer thing that Applications already are carrying
>to be an "identifier" that is location-independent, but we
>can't stop them from carrying something that looks a whole
>lot like the IP addresses that they already carry.
>
>Ross
>
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>
>

------MTqbzuwlafpwbmywwszferveavomlduwcp-- --===============0738296995== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0738296995==-- From architecture-discuss-bounces@ietf.org Wed Nov 15 14:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQCg-0004er-Gf; Wed, 15 Nov 2006 14:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQCf-0004e3-B4 for architecture-discuss@ietf.org; Wed, 15 Nov 2006 14:13:45 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkQCb-0008Vp-SK for architecture-discuss@ietf.org; Wed, 15 Nov 2006 14:13:45 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAFJ9srG034479; Wed, 15 Nov 2006 11:09:59 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 15 Nov 2006 11:12:45 -0800 X-PGP-Universal: processed; by terminus.local on Wed, 15 Nov 2006 11:12:45 -0800 In-Reply-To: <5.0.0.25.2.20061115113138.03879cb0@zircon.juniper.net> References: <5.0.0.25.2.20061115113138.03879cb0@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0B43715E-55DD-4B93-AD06-37DE32D22352@virtualized.org> From: David Conrad Date: Wed, 15 Nov 2006 11:12:39 -0800 To: Ross Callon X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: architecture-discuss@ietf.org Subject: [arch-d] Indirection (was Re: Ok, so what should we do then?) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Ross, On Nov 15, 2006, at 9:13 AM, Ross Callon wrote: > In practice, we aren't going to get applications re-written to > remove all of the cases where they carry around network > layer addresses. Thus we are going to have to live with the > fact that this isn't going to change. Amen. > We could redefine the > network layer thing that Applications already are carrying > to be an "identifier" that is location-independent, but we > can't stop them from carrying something that looks a whole > lot like the IP addresses that they already carry. Exactly. The point of my presentation in AMS was simply, treat the 128 bit values as keys into a lookup table that can then return you the actual routing labels. That is, add a layer of indirection with the pros (flexibility, backwards compatibility, etc.) and cons (performance hit) that implies. The questions that then get generated include: - how do you distinguish between a key and the value? - where is the lookup table (hosts, first hop, customer edge, isp edge, core)? - how is the lookup table (or changes to the table) propagated (pull, e.g., DNS or push, e.g., BGP attribute)? - how can the performance hit be minimized (i.e., how do you cache)? I personally believe that if we set the constraint that we want to minimize changes in order to leverage what has been done to date and limit the cost (both monetary and labor), answers to some of these questions become relatively straight-forward. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 16 05:07:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gke6Y-00008v-Uq; Thu, 16 Nov 2006 05:04:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gke6Y-00008m-1F for architecture-discuss@ietf.org; Thu, 16 Nov 2006 05:04:22 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gke6R-000860-NO for architecture-discuss@ietf.org; Thu, 16 Nov 2006 05:04:22 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 56A373431C; Thu, 16 Nov 2006 05:04:13 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 05:04:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Furtherthoughts: about systems theory and the theory U) Date: Thu, 16 Nov 2006 05:04:11 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF24EC9@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Furtherthoughts: about systems theory and the theory U) Thread-Index: AccItMY9tB5Tsm31THyi4i+pNtI1VQAAPdDAACwvVlA= From: "Bound, Jim" To: , , X-OriginalArrivalTime: 16 Nov 2006 10:04:12.0734 (UTC) FILETIME=[90FFB5E0:01C70966] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: jnc@mercury.lcs.mit.edu, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I agree with Brian putting my IP stack developers hat on any time I don't have to pop up to the apps layer the better. ergo I think we need network layer handles too. /jim=20 > -----Original Message----- > From: jarno.rajahalme@nokia.com [mailto:jarno.rajahalme@nokia.com]=20 > Sent: Wednesday, November 15, 2006 8:07 AM > To: brc@zurich.ibm.com; swb@employees.org > Cc: jnc@mercury.lcs.mit.edu; architecture-discuss@ietf.org > Subject: RE: Ok, so what should we do then? (Was: Re:=20 > [arch-d][Off-topic]Furtherthoughts: about systems theory and=20 > the theory U) >=20 > Brian E Carpenter [mailto:brc@zurich.ibm.com] wrote: > > > >Scott W Brim wrote: > >> On 11/14/2006 02:18 AM, Brian E Carpenter allegedly wrote: > >>=20 > >>>Noel Chiappa wrote: > >>> > >>>>We want to discourage people from passing around bare endpoint=20 > >>>>identifiers. (Such an identifier might e.g. identify one=20 > particular=20 > >>>>server in a pool - not what you really wanted anyway.)=20 > Rather, they > >>>>*should* be passing around higher-level identifiers. > >>> > >>>In theory, I agree. In practice, real time apps really=20 > don't want to=20 > >>>pay the overhead of another lookup, once a multiparty session is=20 > >>>started. > >>=20 > >>=20 > >> But when new parties join, they join at multiple layers. =20 > >That is the > >> application might have visibility into the IP address (as > >presented to > >> the receiver), but it also gets higher layer identifiers,=20 > >> authentication etc. I don't see what you're saying. > > > >In something like a massive multi-player game, it's OK to pay=20 > >lookup/AAA overhead when a new player joins, or when you first=20 > >encounter a new player, but from then on you need to pass a=20 > handle that=20 > >does not generate further lookup. It seems a shame if we can't use=20 > >network layer handles for that. > > >=20 > An application layer handle is needed to refer to a player.=20 > What if a player changes from one host to another? Why should=20 > his handle change? > Why would you want to use network layer handles for that?=20 > Doing exactly that has gotten us in this inability to=20 > renumber mess (network layer handles used to refer to=20 > service/app layer stuff in config files etc.). >=20 > Jarno >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 16 10:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjDb-0003lF-SC; Thu, 16 Nov 2006 10:31:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjDZ-0003ky-J1 for architecture-discuss@ietf.org; Thu, 16 Nov 2006 10:31:57 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkjDY-0003lh-3m for architecture-discuss@ietf.org; Thu, 16 Nov 2006 10:31:57 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAGFVtWo320202 for ; Thu, 16 Nov 2006 15:31:55 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAGFZD8t3236012 for ; Thu, 16 Nov 2006 16:35:13 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAGFVso0027894 for ; Thu, 16 Nov 2006 16:31:54 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAGFVs6X027875; Thu, 16 Nov 2006 16:31:54 +0100 Received: from zurich.ibm.com ([9.4.210.177]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA114752; Thu, 16 Nov 2006 16:31:53 +0100 Message-ID: <455C8468.3060703@zurich.ibm.com> Date: Thu, 16 Nov 2006 16:31:52 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Scott W Brim Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U) References: <20061110201330.EE5AC872C0@mercury.lcs.mit.edu> <4559980C.4080106@zurich.ibm.com> <455A76ED.8040804@employees.org> <455AE595.7090307@zurich.ibm.com> <455B24DB.6010400@employees.org> In-Reply-To: <455B24DB.6010400@employees.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Scott W Brim wrote: > On 11/15/2006 02:01 AM, Brian E Carpenter allegedly wrote: > >>Scott W Brim wrote: >> >>>But when new parties join, they join at multiple layers. That is the >>>application might have visibility into the IP address (as presented to >>>the receiver), but it also gets higher layer identifiers, >>>authentication etc. I don't see what you're saying. >> >>In something like a massive multi-player game, it's OK to pay lookup/AAA >>overhead when a new player joins, or when you first encounter a new player, >>but from then on you need to pass a handle that does not generate >>further lookup. It seems a shame if we can't use network layer handles >>for that. > > > I don't see where the further lookup comes from. Someone joins and > the information is propagated, including persistent identifier and > authentication information, as well as the (last known) network layer > "handle". If & when he changes his NLH, the information that is > important to the game is still there. It's like HIP at an application > layer. The downside is that every application has to have such a > mechanism, so it would be good to have a common mechanism at a common > layer. Anyway I'm still missing something. Well, it's remarkably similar to multihoming when you describe it like that. The fact that the NLH has changed has to be detected and dealt with, with security threats covered. But my point was that as long as the NLH remains valid, it's more efficient to use it, and in real-time games efficiency matters. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 16 10:33:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjFF-00046w-Hs; Thu, 16 Nov 2006 10:33:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkjBU-0003Td-C4 for architecture-discuss@ietf.org; Thu, 16 Nov 2006 10:29:48 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkj2g-0001Wo-Hv for architecture-discuss@ietf.org; Thu, 16 Nov 2006 10:20:45 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAGFKfKG146790 for ; Thu, 16 Nov 2006 15:20:41 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAGFNw043281116 for ; Thu, 16 Nov 2006 16:23:58 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAGFKdtJ020761 for ; Thu, 16 Nov 2006 16:20:40 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAGFKd6G020746; Thu, 16 Nov 2006 16:20:39 +0100 Received: from zurich.ibm.com ([9.4.210.177]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA63626; Thu, 16 Nov 2006 16:20:38 +0100 Message-ID: <455C81C5.9060708@zurich.ibm.com> Date: Thu, 16 Nov 2006 16:20:37 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: jarno.rajahalme@nokia.com Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Furtherthoughts: about systems theory and the theory U) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: jnc@mercury.lcs.mit.edu, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org jarno.rajahalme@nokia.com wrote: > Brian E Carpenter [mailto:brc@zurich.ibm.com] wrote: > >>Scott W Brim wrote: >> >>>On 11/14/2006 02:18 AM, Brian E Carpenter allegedly wrote: >>> >>> >>>>Noel Chiappa wrote: >>>> >>>> >>>>>We want to discourage people from passing around bare endpoint >>>>>identifiers. (Such an identifier might e.g. identify one particular >>>>>server in a pool - not what you really wanted anyway.) Rather, they >>>>>*should* be passing around higher-level identifiers. >>>> >>>>In theory, I agree. In practice, real time apps really don't want to >>>>pay the overhead of another lookup, once a multiparty session is >>>>started. >>> >>> >>>But when new parties join, they join at multiple layers. >> >>That is the >> >>>application might have visibility into the IP address (as >> >>presented to >> >>>the receiver), but it also gets higher layer identifiers, >>>authentication etc. I don't see what you're saying. >> >>In something like a massive multi-player game, it's OK to pay >>lookup/AAA overhead when a new player joins, or when you first >>encounter a new player, but from then on you need to pass a >>handle that does not generate further lookup. It seems a shame >>if we can't use network layer handles for that. >> > > > An application layer handle is needed to refer to a player. What if a > player changes from one host to another? Why should his handle change? > Why would you want to use network layer handles for that? Doing exactly > that has gotten us in this inability to renumber mess (network layer > handles used to refer to service/app layer stuff in config files etc.). You clearly need to be able to invalidate a network layer handle if the upper layer entity migrates; and then you have to pay the lookup overhead. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 16 11:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkNx-0005qw-VX; Thu, 16 Nov 2006 11:46:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkNw-0005oe-4Z for architecture-discuss@ietf.org; Thu, 16 Nov 2006 11:46:44 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkkJS-0003iz-Kw for architecture-discuss@ietf.org; Thu, 16 Nov 2006 11:42:11 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id CFA6C34081; Thu, 16 Nov 2006 11:42:06 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 11:42:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Date: Thu, 16 Nov 2006 11:42:04 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF2517D@tayexc14.americas.cpqcorp.net> In-Reply-To: <5.0.0.25.2.20061115113138.03879cb0@zircon.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ok, so what should we do then? (Was: Re: [arch-d][Off-topic]Further thoughts: about systems theory and the theory U) Thread-Index: AccI2b5ptn6GwSAkQUGr69AME5T+uwAw2+WQ From: "Bound, Jim" To: "Ross Callon" , "Noel Chiappa" , X-OriginalArrivalTime: 16 Nov 2006 16:42:05.0919 (UTC) FILETIME=[2686A6F0:01C7099E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Shim6 has come up with a means to do what Ross asks and the question is will end node implementations move to the Shim6 (very close to HIP) model. I will share my day job view input is this is significant code base change and has significant effect to product IP stack implementation. But if all will move and all will go and support the separation of identity from location then we need to move with Shim6. Prototyping is a good thing and IETF Shim6 WG has done a good technical job on first incantation that I have seen for end nodes that is worth implementation and I have reviewed it with comments to the WG and authors in depth it is ready for PS I believe too. Caveat is I don't buy into CGA at all for anything or any protocol, but I also think all vendors should leave their IPR input at the door outside of the IETF or any Open Standards Development Organization I am tired of IPR we don't need it, require it, and have plenty of great minds here without having to adapt vendor IPR it has become abusive. But that gets into the security issues and we need to do one step at a time. > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net]=20 > Sent: Wednesday, November 15, 2006 12:13 PM > To: Noel Chiappa; architecture-discuss@ietf.org > Subject: Re: Ok, so what should we do then? (Was: Re:=20 > [arch-d][Off-topic]Further thoughts: about systems theory and=20 > the theory U) >=20 > At 03:13 PM 11/10/2006 -0500, Noel Chiappa wrote: > > > From: Brian E Carpenter > > > > > address ambiguity destroys the e2e identification=20 > property and third > > > party referrals > > > >That's not a bug, that's a feature. > > > >We want to discourage people from passing around bare=20 > endpoint identifiers. > >(Such an identifier might e.g. identify one particular=20 > server in a pool=20 > >- not what you really wanted anyway.) Rather, they *should*=20 > be passing=20 > >around higher-level identifiers. >=20 > In principle I agree: Applications should deal with=20 > application identifiers (such as DNS names), not with network=20 > layer addresses. Having applications pass around network=20 > layer addresses (or network layer IDs) puts constraints on=20 > the network layer that is making it significantly more=20 > difficult to deal with various problems. >=20 > However, I thought that the point of this ongoing discussion=20 > was to exchange information and ideas that will lead to a=20 > practical solution that can be deployed in the real Internet. >=20 > In practice, we aren't going to get applications re-written=20 > to remove all of the cases where they carry around network=20 > layer addresses. Thus we are going to have to live with the=20 > fact that this isn't going to change. We could redefine the=20 > network layer thing that Applications already are carrying to=20 > be an "identifier" that is location-independent, but we can't=20 > stop them from carrying something that looks a whole lot like=20 > the IP addresses that they already carry. >=20 > Ross >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 16 12:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl9s-0003FW-JU; Thu, 16 Nov 2006 12:36:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl9q-0003FK-Vs; Thu, 16 Nov 2006 12:36:14 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkl9p-0003qP-IL; Thu, 16 Nov 2006 12:36:14 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kAGHZtmN002972; Thu, 16 Nov 2006 09:35:55 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAGHZtjt002971; Thu, 16 Nov 2006 09:35:55 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 16 Nov 2006 09:35:55 -0800 From: David Meyer To: routingworkshop@lists.i1b.org, architecture-discuss@ietf.org Message-ID: <20061116173555.GA2700@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: iab@ietf.org, iesg@ietf.org Subject: [arch-d] New list: The Routing And Addressing Mailing List X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1094851821==" Errors-To: architecture-discuss-bounces@ietf.org --===============1094851821== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, We've created a new list, the Routing and Addressing Mailing list (ram@iab.org), which is reserved for the IETF community's discussion of the analysis of and potential solutions to the continued growth in the size and dynamics of the Internet's default free zone routing table. =20 Lixia and I will be moderating the list. We're hoping for focused discussions on the topic(s) at hand.=20 To subscribe, please see https://www1.ietf.org/mailman/listinfo/ram Finally, note that while the list is hosted @iab.org, this is an IETF (i.e., IESG and IAB) sponsored activity.=20 We're all looking forward to the discussion. Thanks, --dmm --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFXKF7ORgD1qCZ2KcRAvyUAKCSJkBMbVJGc/yRmusTW4TW7iIDlQCePuNs figPJS1ofWBn5ZR4VhBZM/4= =lPa9 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- --===============1094851821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1094851821==-- From architecture-discuss-bounces@ietf.org Fri Nov 17 13:21:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8JX-00076z-Kb; Fri, 17 Nov 2006 13:19:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8JV-00076s-S2 for architecture-discuss@ietf.org; Fri, 17 Nov 2006 13:19:45 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8Ik-000604-0d for architecture-discuss@ietf.org; Fri, 17 Nov 2006 13:19:45 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 9A0457944 for ; Fri, 17 Nov 2006 10:18:45 -0800 (PST) Resent-Message-Id: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Resent-Date: Fri, 17 Nov 2006 13:18:43 -0500 Message-Id: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> Content-Transfer-Encoding: 7bit Resent-To: architecture-discuss@ietf.org From: RJ Atkinson Resent-From: RJ Atkinson Date: Tue, 14 Nov 2006 15:21:08 -0500 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [arch-d] thoughts X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Resent-Date: Fri, 17 Nov 2006 13:19:47 -0500 An Identifier should name a node, rather than naming an interface of a node, a point of attachment, or a location. A given node will have one or more Identifiers at a given point in time. An Identifier has a high probability of being globally unique, but is not guaranteed to necessarily always be globally unique. An Identifier will be unique within the context of a given Locator. A typical node should easily be able to determine its Identifier(s) without consulting external sources of information. Some special case kinds of nodes might need to consult external information, but such special cases, if any, should be rare. A Locator should name a single sub-network, rather than naming a node or an interface. A given node will have at least one Locator for each different upstream connection. Example: a node with 2 interfaces where each interface connects to a different sub-network will have at least 2 Locators while those 2 interfaces are up and working. Example: If one has multiple logical sub-networks on a single physical link, then a node with only 1 interface (where that 1 interface were attached to that multi-netted link) might have more than one Locator concurrently. A transport-layer protocol will not be aware of the Locator(s) in use by any endpoint of any transport-layer session. Instead, transport-layer protocols will only include endpoint Identifiers in their session state. EXAMPLE: TCP pseudo-header checksum will include Identifiers, but not Locators. NOTA BENE: If one looks at real implementations, even "stateless" transport protocols such as UDP have some session state (e.g. the Protocol Control Block in 4.4 BSD). One ought to be able to learn a node's current set of Identifiers and current set of Locators if one knows the Fully Qualified Domain Name of that node. One need not be able to directly learn the FQDN of a node given only the Identifier of the node. NOTA BENE: This might sound unworkable, but consider that one might be able to first query a node to ask what its FQDN is (e.g. ICMP), then use a separate mechanism (e.g. DNSsec) to authenticate that answer. A non-cryptographic authentication mechanism should be available that protects against off-path active attacks on a session, for optional use in low threat environments. Cryptographic authentication and confidentiality mechanisms should be available in the network layer. These should bind to the Identifier and ignore the Locator. NOTA BENE: ESP/AH would have bound to an Identifier had one existed a decade ago. Only because there was no other option did ESP/AH bind to the whole IP address. I went to A LOT of trouble with ISAKMP/IKE to make sure that a wide range of name types are supported in key management. The better ESP/AH implementations can use FQDNs or such like in their Security Associations, in lieu of the IP address. A multi-homed node or site will never increase the entropy of the default-free zone of the inter-domain routing table. Instead, the Locator in use will vary as appropriate to achieve the multi-homing objectives. A mobile node or site will never increase the entropy of the default-free zone of the inter-domain routing table. Instead, the Locator in use will vary as appropriate to achieve the mobility objectives. Full backwards compatibility with deployed network-layer and transport-layer protocols is nice to have, but is not a requirement. Yours, Ran rja@extremenetworks.com PS: The lack of implementation detail is quite deliberate. As JNC might comment, this note is an attempt to talk about things architecturally. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 14:43:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9b6-0005Ba-Fm; Fri, 17 Nov 2006 14:42:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9b5-0005BP-F2 for architecture-discuss@ietf.org; Fri, 17 Nov 2006 14:41:59 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl9b0-0000Z0-Uq for architecture-discuss@ietf.org; Fri, 17 Nov 2006 14:41:59 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAHJc7rG039478; Fri, 17 Nov 2006 11:38:12 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Fri, 17 Nov 2006 11:41:27 -0800 X-PGP-Universal: processed; by terminus.local on Fri, 17 Nov 2006 11:41:27 -0800 In-Reply-To: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> From: David Conrad Subject: Re: [arch-d] thoughts Date: Fri, 17 Nov 2006 11:41:18 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Ran, The model I have is as follows: a) source and destination end points are labeled with identifiers b) the destination identifier is used at the edge (be it first hop router, customer/ISP boundary, or something in between) of the source network to look up the destination locator(s) c) the source edge device (router) picks an appropriate destination locator from the set returned by the lookup d) packets are encapsulated with locators in the source and destination fields for transit routing e) at the destination edge, the packet is de-encapsulated and forwarded to the destination end point identifier. With that model in mind, I have the following questions/comments: On Nov 14, 2006, at 12:21 PM, RJ Atkinson wrote: > An Identifier should name a node, rather than naming an > interface of a node, a point of attachment, or a location. Why wouldn't an identifier name an interface? What do you gain by labeling a node? > A given node will have one or more Identifiers at a given > point in time. Yes. > An Identifier has a high probability of being globally unique, > but is not guaranteed to necessarily always be globally unique. If an identifier is not globally unique, the lookup will be ambiguous and not securable. > An Identifier will be unique within the context of a > given Locator. This implies identifiers would potentially need to change should locators shift. This seems like a mistake to me as it removes one of the primary advantages I see is having identifiers. > A typical node should easily be able to determine its Identifier(s) > without consulting external sources of information. Some special > case kinds of nodes might need to consult external information, > but such special cases, if any, should be rare. I'm not sure what this means. Can you provide an example? > A Locator should name a single sub-network, rather than > naming a node or an interface. I believe a locator should name a connection to the routing system. What is on the other side of that connection is opaque and irrelevant to the routing system. > A given node will have at least one Locator for each > different upstream connection. Right. > A transport-layer protocol will not be aware of the Locator(s) > in use by any endpoint of any transport-layer session. Exactly. > One ought to be able to learn a node's current set of > Identifiers and current set of Locators if one knows > the Fully Qualified Domain Name of that node. Yes. > One need not be able to directly learn the FQDN of a node > given only the Identifier of the node. This is the case today in the sense that there is no global law saying you must set up the {in-addr,ip6}.arpa PTR to match the forward name. > A non-cryptographic authentication mechanism should be available > that protects against off-path active attacks on a session, for > optional use in low threat environments. Can you explain what a "non-cryptographic authentication mechanism" is in this context? > Cryptographic authentication and confidentiality mechanisms should > be available in the network layer. These should bind to the > Identifier and ignore the Locator. In my model, since encapsulation is used, you can have crypto auth/ confidentiality as an option for both locators and identifiers. > A multi-homed node or site will never increase the entropy of the > default-free zone of the inter-domain routing table. Instead, > the Locator in use will vary as appropriate to achieve the > multi-homing objectives. Right. > A mobile node or site will never increase the entropy of the > default-free zone of the inter-domain routing table. Instead, > the Locator in use will vary as appropriate to achieve the > mobility objectives. Yep. > Full backwards compatibility with deployed network-layer and > transport-layer protocols is nice to have, but is not a requirement. At this point, I suspect lack of backwards compatibility will likely result in non-deployability. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 15:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9yg-0001Yo-GN; Fri, 17 Nov 2006 15:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl9ye-0001UL-OL for architecture-discuss@ietf.org; Fri, 17 Nov 2006 15:06:20 -0500 Received: from centrmmtao05.cox.net ([70.168.83.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl9yX-0003mi-Fw for architecture-discuss@ietf.org; Fri, 17 Nov 2006 15:06:18 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao05.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061117200609.DVDX7904.centrmmtao05.cox.net@eastrmimpo01.cox.net>; Fri, 17 Nov 2006 15:06:09 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id nw5M1V00Y0pnMhQ0000000; Fri, 17 Nov 2006 15:05:21 -0500 In-Reply-To: <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Fri, 17 Nov 2006 15:06:03 -0500 To: David Conrad X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 17 Nov 2006, at 14:41, David Conrad wrote: > The model I have is as follows: > a) source and destination end points are labeled with identifiers "end point" means a stack, a node, an interface, or something else ? > b) the destination identifier is used at the edge (be it first hop > router, customer/ISP boundary, or something in between) of the > source network to look up the destination locator(s) This implies that one can *directly* go from Destination Identifier to Destination Locator, which is not one of my assumptions. In my model that can be done, through a layer of indirection, but not directly. > c) the source edge device (router) picks an appropriate destination > locator from the set returned by the lookup In my model, the originating node selects a Destination Locator from the list in the DNS for the destination node's FQDN. There is no requirement that this Destination Locator remain immutable end-to-end, but the Identifier does have to remain immutable end-to-end. Edge routers are not required to re-write a Locator, but if one does then no operational problem ensues. > d) packets are encapsulated with locators in the source and > destination fields for transit routing In my model, no tunnelling or packet encapsulation is required. Nothing prohibits, for example, GRE tunnelling done for the same reasons it might be done today in the IPv4 Internet. > e) at the destination edge, the packet is de-encapsulated and > forwarded to the destination end point identifier. Again, in my model, no decapsulation is ever required. As it happens, I know of silicon where encaps/decaps is nearly free, but there are always MTU issues with encapsulation and for more commonplace routers encaps/decaps is far from free. So for both architectural simplicity and operational considerations, I'd really prefer to avoid requiring encaps/decaps of ordinary traffic. > With that model in mind, I have the following questions/comments: First, we have somewhat different models in our heads, which probably accounts for the discrepancies. > On Nov 14, 2006, at 12:21 PM, RJ Atkinson wrote: >> An Identifier should name a node, rather than naming an >> interface of a node, a point of attachment, or a location. > > Why wouldn't an identifier name an interface? What do you gain by > labeling a node? Better native support for mobility. What I care about is which end system ("stack" if one thinks about an MLS OS or distributed OS) I am communicating with, not which interface on that node the packets happen to arrive-on/depart-from. If we're going to have a clean new architecture, mobility needs to be a native part of the new approach, not an add-on, IMHO. >> A given node will have one or more Identifiers at a given >> point in time. > > Yes. > >> An Identifier has a high probability of being globally unique, >> but is not guaranteed to necessarily always be globally unique. > > If an identifier is not globally unique, the lookup will be > ambiguous and not securable. This is what many think, but it isn't true. Again, in my model, one never starts with an Identifier to do any sort of lookup. One always does an ID lookup in the forward direction (FQDN-->Identifier), never the reverse (Identifier-->FQDN). If one is already communicating with a node, but does not know its FQDN, then one can send an control packet asking for its FQDN. One need not trust that result blindly, but instead can authenticate the FQDN answer by doing a forward lookup with DNS Security enabled. DNS Security should work fine to authenticate bindings to the FQDN. (I do assume there are new DNS resource records for L and I.) >> An Identifier will be unique within the context of a >> given Locator. > > This implies identifiers would potentially need to change should > locators shift. This seems like a mistake to me as it removes one > of the primary advantages I see is having identifiers. No. Identifiers never need to change even if the Locator set changes. This is a very important point. >> A typical node should easily be able to determine its Identifier(s) >> without consulting external sources of information. Some special >> case kinds of nodes might need to consult external information, >> but such special cases, if any, should be rare. > > I'm not sure what this means. Can you provide an example? I want to try to avoid situations where an Identifier is externally assigned (e.g. IANA-->RIR-->Organisation-->node), but instead have Identifiers based on something a typical node can find within itself. >> A Locator should name a single sub-network, rather than >> naming a node or an interface. > > I believe a locator should name a connection to the routing > system. What is on the other side of that connection is opaque and > irrelevant to the routing system. Your distinction seems subtle to me, please say more. (You seem to be saying that a Locator should name an SNPA, and also that an SNPA is not the same as a sub-network.) >> One need not be able to directly learn the FQDN of a node >> given only the Identifier of the node. > > This is the case today in the sense that there is no global law > saying you must set up the {in-addr,ip6}.arpa PTR to match the > forward name. See above where your earlier comments seemed to imply that one might want to make an Identifier-->something else lookup. >> A non-cryptographic authentication mechanism should be available >> that protects against off-path active attacks on a session, for >> optional use in low threat environments. > > Can you explain what a "non-cryptographic authentication mechanism" > is in this context? Something that does not involve expensive maths/computation and yet will protect a session against off-path attacks. >> Cryptographic authentication and confidentiality mechanisms should >> be available in the network layer. These should bind to the >> Identifier and ignore the Locator. > > In my model, since encapsulation is used, you can have crypto auth/ > confidentiality as an option for both locators and identifiers. In my model, AH/ESP can be used as originally desired. The current binding of AH/ESP to the IP Address was caused by the limitations of the Internet Architecture circa 1995. I never thought it was a good idea, but it was necessary at the time. This also relates to why I (vigorously) campaigned for ISAKMP and the IPsec DoI to support a *wide* range of Identity types. The key change to AH/ESP is that they ignore Locators and bind Security Associations only to Identifiers. This means multi-homing, NAT/NAPT, and mobility no longer have any adverse impact on native IPsec. No UDP-tunnel-hack-for-NAT extensions would ever be needed. >> Full backwards compatibility with deployed network-layer and >> transport-layer protocols is nice to have, but is not a requirement. > > At this point, I suspect lack of backwards compatibility will > likely result in non-deployability. Well, the currently deployed transport-layer protocols all bind to information used as a Locator, which tends to kill the idea of an Identifier/Locator approach. In turn, this forces one down the SHIM6 ("NAT inside the host stack") approach. However, ISPs said clearly at NANOG that SHIM6 was not an accceptable approach. The only change to on-the-wire transport protocols that I'd propose is to remove location information from the pseudo-header calculations. I think the network-layer can be implemented for either IPv4 or IPv6 as extensions -- and I think that this could be implemented so that both "old" IPv4/IPv6 and the I/L split variant could be supported concurrently (for different sessions, however). Cheers, Ran rja@extremenetworks.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 19:47:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlEK3-0006uV-0O; Fri, 17 Nov 2006 19:44:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlEK1-0006tr-DH for architecture-discuss@ietf.org; Fri, 17 Nov 2006 19:44:41 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlEK0-0002uJ-P5 for architecture-discuss@ietf.org; Fri, 17 Nov 2006 19:44:41 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAI0eorG039990; Fri, 17 Nov 2006 16:40:59 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Fri, 17 Nov 2006 16:44:15 -0800 X-PGP-Universal: processed; by terminus.local on Fri, 17 Nov 2006 16:44:15 -0800 In-Reply-To: <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [arch-d] thoughts Date: Fri, 17 Nov 2006 16:44:05 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Ran, I realized we have different models: I'm trying to understand yours by comparing to mine. On Nov 17, 2006, at 12:06 PM, RJ Atkinson wrote: > On 17 Nov 2006, at 14:41, David Conrad wrote: >> The model I have is as follows: >> a) source and destination end points are labeled with identifiers > "end point" means a stack, a node, an interface, or something else ? Interface (or perhaps more correctly, stack associated with an interface). >> b) the destination identifier is used at the edge (be it first hop >> router, customer/ISP boundary, or something in between) of the >> source network to look up the destination locator(s) > > This implies that one can *directly* go from Destination Identifier > to Destination Locator, which is not one of my assumptions. In > my model that can be done, through a layer of indirection, but > not directly. Hmm. I'm assuming a mapping function: mapping(identifier) = 1 or more locators Conceptually, the mapping function could be the DNS (although it doesn't have to be). If the DNS were used, it would be along the lines of: # ID RRType RRdata 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.id.arpa IN LOCATOR A000::0001 100 ... IN LOCATOR B000::0001 200 ... ... (which could obviously be DNSSEC signed to provide some level of data authenticatability). Could you explain a bit more about the way you're viewing getting from an identifier to a set of locators? >> c) the source edge device (router) picks an appropriate >> destination locator from the set returned by the lookup > In my model, the originating node selects a Destination Locator > from the list in the DNS for the destination node's FQDN. Just to be clear, your model requires modification to all nodes (that is, there is a layer inserted between the identifier and locator that does the DNS lookup)? >> d) packets are encapsulated with locators in the source and >> destination fields for transit routing > In my model, no tunnelling or packet encapsulation is required. > Nothing prohibits, for example, GRE tunnelling done for the > same reasons it might be done today in the IPv4 Internet. Do I understand correctly that the reason explicit tunnels are not necessary is that translation is being done in the end nodes, where a sort of implicit tunnel is created in between the transport and network layers (the place where the translation between identifier to locator at the source and between locator and identifier at the destination is being done)? >> e) at the destination edge, the packet is de-encapsulated and >> forwarded to the destination end point identifier. > As it happens, I know of silicon where encaps/decaps is nearly free, > but there are always MTU issues with encapsulation and for more > commonplace routers encaps/decaps is far from free. This was an issue I was concerned about and had come up with an approach that used destination field rewriting at both ends (edges). However, I've since become convinced that encapsulation is a more flexible and (with the exception of potential MTU problems) better approach. Debugging is much easier since the original packet as seen by the application is available, you have the option of popping off the encapsulation in mid-flight (e.g., a transit router detects destination unreachability and pops off the transit layer in order to try and discover an alternative locator in the multi-homing case), ability to have flow labels that have meaning both to the end points as well as different flow labels for transit networks, etc. >> On Nov 14, 2006, at 12:21 PM, RJ Atkinson wrote: >> Why wouldn't an identifier name an interface? What do you gain by >> labeling a node? > Better native support for mobility. In my model, transitioning across service provider boundaries is implemented by changing the identifier to locator mapping. In the simplest case (and using DNS as the mapping mechanism as an example only), a site changing ISPs would follow this basic process: a) buy new connectivity b) change the Rdata of the LOCATOR RR to reflect the new ISP's prefix c) wait for TTLs of LOCATOR RRs that had old ISP's prefix to expire d) disconnect old ISP Mobility is simply a special case of this basic process. Instead of 'buy connectivity', you transition across access provider boundaries. The old access network gets instructed to forward to the new access network until the TTL pointing to the old access network expires. > If we're going to have a clean new architecture, mobility needs > to be a native part of the new approach, not an add-on, IMHO. I'm too pessimistic (or cynical if you prefer) to believe we'll be able to have a clean new architecture. My model assumes there is too much inertia in the Internet already to throw out the existing IPv6 deployment. As such, I'm trying to minimize changes to existing deployments. The _only_ change necessary in my model is at the edges. No change to existing stacks (either in end hosts or in most routers) necessary. >> If an identifier is not globally unique, the lookup will be >> ambiguous and not securable. > This is what many think, but it isn't true. > > Again, in my model, one never starts with an Identifier to do any sort > of lookup. One always does an ID lookup in the forward direction > (FQDN-->Identifier), never the reverse (Identifier-->FQDN). If > one is already communicating with a node, but does not know its > FQDN, then one can send an control packet asking for its FQDN. > > One need not trust that result blindly, but instead can authenticate > the FQDN answer by doing a forward lookup with DNS Security enabled. > > DNS Security should work fine to authenticate bindings to the FQDN. > (I do assume there are new DNS resource records for L and I.) I'm not sure I follow. An application does a DNS lookup to translate a fqdn to an identifier. The network stack translates the identifier into a locator. At the other end, how does the network stack unambiguously translate the locator back into the correct identifier? > I want to try to avoid situations where an Identifier is externally > assigned (e.g. IANA-->RIR-->Organisation-->node), but instead have > Identifiers based on something a typical node can find within itself. I see. In my model, I assume identifiers are globally unique and are propagated somehow into a globally available map (e.g., the DNS). This implies some allocation authority, albeit since there is no need for hierarchical allocation of identifiers, can be pretty much anyone. >> I believe a locator should name a connection to the routing >> system. What is on the other side of that connection is opaque >> and irrelevant to the routing system. > Your distinction seems subtle to me, please say more. I don't want to preclude one routing domain's identifiers being used as another routing domain's locators. For example, I can imagine the following encapsulations: 1. map(end point.ID.ARPA) -> ISP.NET global locator 2. forward toward ISP.NET 3. map(global locator.ISP.NET) -> traffic engineering locator 4. forward to ISP.NET's side of particular ISP.NET peering point defined by the traffic engineering locator 5. de-encap traffic engineering locator and give to peer/transit provider ... > (You seem to be saying that a Locator should name an SNPA, > and also that an SNPA is not the same as a sub-network.) SNPA? >> Can you explain what a "non-cryptographic authentication >> mechanism" is in this context? > Something that does not involve expensive maths/computation > and yet will protect a session against off-path attacks. Can you provide an example? Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 20:33:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlF4U-000366-Ms; Fri, 17 Nov 2006 20:32:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlF4T-00032N-94 for architecture-discuss@ietf.org; Fri, 17 Nov 2006 20:32:41 -0500 Received: from centrmmtao06.cox.net ([70.168.83.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlF4O-0008FM-LQ for architecture-discuss@ietf.org; Fri, 17 Nov 2006 20:32:39 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao06.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061118013232.FYOD14538.centrmmtao06.cox.net@eastrmimpo01.cox.net>; Fri, 17 Nov 2006 20:32:32 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id o1Xk1V00V0pnMhQ0000000; Fri, 17 Nov 2006 20:31:44 -0500 In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Fri, 17 Nov 2006 20:32:26 -0500 To: David Conrad X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 17 Nov 2006, at 19:44, David Conrad wrote: > On Nov 17, 2006, at 12:06 PM, RJ Atkinson wrote: >> On 17 Nov 2006, at 14:41, David Conrad wrote: >>> The model I have is as follows: >>> a) source and destination end points are labeled with identifiers >> "end point" means a stack, a node, an interface, or something else ? > > Interface (or perhaps more correctly, stack associated with an > interface). I'm not entirely clear yet what you mean. When I think of a "stack", for example on my laptop, that same stack might concurrently be associated with multiple link interfaces (e.g. 10/100/1000baseT, 802.11, & 1394). For a conventional system, I'm comfortable with "node" meaning roughly the same thing as "stack". For unusual systems, such as loosely coupled distributed systems, multi-level secure systems, or virtualised systems, the term "node" becomes less crisp -- because the lines are necessarily drawn somewhat arbitrarily in such cases. >>> b) the destination identifier is used at the edge (be it first >>> hop router, customer/ISP boundary, or something in between) of >>> the source network to look up the destination locator(s) >> >> This implies that one can *directly* go from Destination Identifier >> to Destination Locator, which is not one of my assumptions. In >> my model that can be done, through a layer of indirection, but >> not directly. > > Hmm. I'm assuming a mapping function: > > mapping(identifier) = 1 or more locators > > Conceptually, the mapping function could be the DNS (although it > doesn't have to be). If the DNS were used, it would be along the > lines of: > > # ID RRType RRdata > 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.id.arpa IN LOCATOR A000::0001 100 ... > IN LOCATOR B000::0001 200 ... > ... > > (which could obviously be DNSSEC signed to provide some level of > data authenticatability). > > Could you explain a bit more about the way you're viewing getting > from an identifier to a set of locators? Yes, but first please explain how would one end up with an Identifier in hand without also happening to have a Locator for that node ? If one knows the FQDN of a node, then one could find both Locator(s) and Identifier(s) from DNS records using forward resolution. >>> c) the source edge device (router) picks an appropriate >>> destination locator from the set returned by the lookup >> In my model, the originating node selects a Destination Locator >> from the list in the DNS for the destination node's FQDN. > > Just to be clear, your model requires modification to all nodes > (that is, there is a layer inserted between the identifier and > locator that does the DNS lookup)? I am talking architecturally, not about implementation. It isn't obvious to me that the layering would have to vary from now. Oh, and I think this architectural change could be done without modifying any existing routing protocols or forwarding engines. >>> d) packets are encapsulated with locators in the source and >>> destination fields for transit routing >> In my model, no tunnelling or packet encapsulation is required. >> Nothing prohibits, for example, GRE tunnelling done for the >> same reasons it might be done today in the IPv4 Internet. > > Do I understand correctly that the reason explicit tunnels are not > necessary is that translation is being done in the end nodes, where > a sort of implicit tunnel is created in between the transport and > network layers (the place where the translation between identifier > to locator at the source and between locator and identifier at the > destination is being done)? "Translation" covers a lot of possible meanings. I'm not sure which you mean. I am trying to avoid having NAT/NAPT in the hosts, so this is different architecturally from SHIM6 (as best I understand SHIM6). I am trying to avoid requiring tunnelling. >>> On Nov 14, 2006, at 12:21 PM, RJ Atkinson wrote: >>> Why wouldn't an identifier name an interface? What do you gain >>> by labeling a node? >> Better native support for mobility. > > In my model, transitioning across service provider boundaries is > implemented by changing the identifier to locator mapping. In the > simplest case (and using DNS as the mapping mechanism as an example > only), a site changing ISPs would follow this basic process: > > a) buy new connectivity > b) change the Rdata of the LOCATOR RR to reflect the new ISP's prefix > c) wait for TTLs of LOCATOR RRs that had old ISP's prefix to expire > d) disconnect old ISP > > Mobility is simply a special case of this basic process. Instead > of 'buy connectivity', you transition across access provider > boundaries. The old access network gets instructed to forward to > the new access network until the TTL pointing to the old access > network expires. Hmm. My concept is that if one were multi-homed to different providers, then one would necessarily have more than one Locator (at least one Locator per provider) and each Locator would be present concurrently in the DNS. If a service provider went away (e.g. backhoe), then one would update one's DNS to remove the associated Locator(s). Which provider gets used for outbound traffic would be the originating node's choice in the first instance, though nothing would preclude a Locator from being modified during transit for some reason (because Locators are used *only* for packet routing/forwarding). As you say, mobility and multi-homing are really the same case if one gets the architecture right, though I don't know that the old access network would necessarily have to forward packets. >> If we're going to have a clean new architecture, mobility needs >> to be a native part of the new approach, not an add-on, IMHO. > > I'm too pessimistic (or cynical if you prefer) to believe we'll be > able to have a clean new architecture. My model assumes there is > too much inertia in the Internet already to throw out the existing > IPv6 deployment. As such, I'm trying to minimize changes to > existing deployments. The _only_ change necessary in my model is > at the edges. No change to existing stacks (either in end hosts or > in most routers) necessary. I'm assuming that this list is about architecture and so I'm talking about architecture. I'm not necessarily talking about IAB RAW output, though clearly that has revived this list. I am definitely not talking about any IETF work at this point -- just architecture. It sounds like you are talking specifically about IETF work relating to IAB RAW, which maybe overlaps but is not exactly the same topic. The architecture I'm proposing would not require any changes to forwarding processes or routing protocols, nor to ARP/ND. It would change TCP/UDP by altering the pseudo-header checksum to include only Identifiers, never Locators. How would your system work in the case where the packet emitted from the origin node used both AH and ESP -- that is, the payload is opaque and (nearly) all of the header fields are authenticated (hence immutable) ?? Is this where the tunnelling comes in ? > An application does a DNS lookup to translate a fqdn to an identifier. One can get the Locator from DNS in the same transaction, right ? > The network stack translates the identifier into a locator. FQDN->Locator mapping is not necessarily in the network stack. (I'm not talking about implementation here. :-) > At the other end, how does the network stack unambiguously > translate the locator back into the correct identifier? There are several options. One possible alternative is to carry Source Identifier, Destination Identifier, Source Locator, and Destination Locator in each packet. That might or might not be the best option. I remain open minded. >> I want to try to avoid situations where an Identifier is externally >> assigned (e.g. IANA-->RIR-->Organisation-->node), but instead have >> Identifiers based on something a typical node can find within itself. > > I see. In my model, I assume identifiers are globally unique and > are propagated somehow into a globally available map (e.g., the > DNS). This implies some allocation authority, albeit since there > is no need for hierarchical allocation of identifiers, can be > pretty much anyone. There will need to be some centralised allocation authority if one wants absolutely globally unique identifiers. If that authority involves humans, there is a good chance of an accident at some point where a few identifiers would be duplicated. So I'd rather not require an absolutely globally unique identifier. >>> I believe a locator should name a connection to the routing >>> system. What is on the other side of that connection is opaque >>> and irrelevant to the routing system. >> Your distinction seems subtle to me, please say more. > > I don't want to preclude one routing domain's identifiers being > used as another routing domain's locators. For example, I can > imagine the following encapsulations: I want to always ensure that Locators are never Identifiers, and vice versa. Overloaded semantics is how we got into this mess. I really want to avoid overloaded semantics. >> (You seem to be saying that a Locator should name an SNPA, >> and also that an SNPA is not the same as a sub-network.) > > SNPA? sub-network point of attachment -- that old ISO CLNP term. :-) >>> Can you explain what a "non-cryptographic authentication >>> mechanism" is in this context? >> Something that does not involve expensive maths/computation >> and yet will protect a session against off-path attacks. > > Can you provide an example? I don't want to get into engineering. For now, maybe just take it as a design property for an alternative architecture. Cheers, Ran _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 20:57:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFQD-0004GS-Nz; Fri, 17 Nov 2006 20:55:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFQ8-00048U-Qb for architecture-discuss@ietf.org; Fri, 17 Nov 2006 20:55:04 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlFOP-0001VK-Lx for architecture-discuss@ietf.org; Fri, 17 Nov 2006 20:53:22 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5211C87307; Fri, 17 Nov 2006 20:53:17 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] thoughts Message-Id: <20061118015317.5211C87307@mercury.lcs.mit.edu> Date: Fri, 17 Nov 2006 20:53:17 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Conrad >> "end point" means a stack, a node, an interface, or something else ? > Interface (or perhaps more correctly, stack associated with an > interface). Well, there's a source of potential confusion, because to a lot of people, "endpoint" means about what "stack" seemingly does - i.e. an entity involved in end-end communication (e.g. the "thing" at one end of a reliable transport connection, which manages the state associated with that connection). This is especially true after my draft on "endpoint names" some years back (http://www.chiappa.net/~jnc/tech/endpoints.txt -yes, yes, I know I need to get it out as an RFC :-), which discussed adding a separate namespace for them, at some length. Time to roll out my favourite terminology quotation again: "I am far from thinking that nomenclature is a remedy for every defect in art or science: still I cannot but feel that confusion of terms generally springs from, and always leads to, confusion of ideas." -- John Louis Petit, "Architectural Studies in France", 1854 Maybe we should add that to the "welcome to the list" message? :-) I'd also like to point out that "stack associated with an interface" is really just "[end-end identity] associated with [a network location]" - which is what got us in trouble in the first place. I view the application of a single name to anything that mixes those two spheres with a very jaundiced eye. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 21:22:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFpM-0000sQ-Qx; Fri, 17 Nov 2006 21:21:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFpL-0000sL-Ql for architecture-discuss@ietf.org; Fri, 17 Nov 2006 21:21:07 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlFpK-0001x8-LU for architecture-discuss@ietf.org; Fri, 17 Nov 2006 21:21:07 -0500 Received: from [10.0.1.6] (failure[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <2006111802205001200ouuoae>; Sat, 18 Nov 2006 02:21:06 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061118015317.5211C87307@mercury.lcs.mit.edu> References: <20061118015317.5211C87307@mercury.lcs.mit.edu> Date: Fri, 17 Nov 2006 21:14:02 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel is correct. Terminology doesn't solve everything but my favorite quote is "A problem well stated is a problem half solved." Charles Kettering At 20:53 -0500 2006/11/17, Noel Chiappa wrote: > > From: David Conrad > > >> "end point" means a stack, a node, an interface, or something else ? > > > Interface (or perhaps more correctly, stack associated with an > > interface). One can not assume a 1:1 relation between interfaces and stacks. That is unless you are in 802. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 22:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlGbl-0006lD-UJ; Fri, 17 Nov 2006 22:11:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlGbk-0006l5-M8 for architecture-discuss@ietf.org; Fri, 17 Nov 2006 22:11:08 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlGbh-0008Gi-Dk for architecture-discuss@ietf.org; Fri, 17 Nov 2006 22:11:08 -0500 Received: from [10.0.1.6] (failure[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20061118031102m13004pud9e>; Sat, 18 Nov 2006 03:11:03 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> Date: Fri, 17 Nov 2006 22:07:10 -0500 To: David Conrad , RJ Atkinson From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org In reading the conversation between the three of you, I get the sense that you are still trying to solve the current engineering problem. This is one of the better abstract discussions I have seen on this list, but I don't think you have really boiled it down to its barest elements. There is still too much flesh on the bones. It is getting in the way of your thinking. You need to work out in a sense what the general theory is before trying to apply it to this specific architecture. I realize some think this is the only architecture, but for a moment consider the idea that there are rules that might underlie this one and as well as others. Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 17 23:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlHcZ-0000YT-R3; Fri, 17 Nov 2006 23:16:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlHcZ-0000XK-AT for architecture-discuss@ietf.org; Fri, 17 Nov 2006 23:16:03 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlHcX-0007dh-VV for architecture-discuss@ietf.org; Fri, 17 Nov 2006 23:16:03 -0500 Received: from [10.0.1.6] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc15) with ESMTP id <2006111804155501500pq5cae>; Sat, 18 Nov 2006 04:16:01 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> Date: Fri, 17 Nov 2006 23:14:50 -0500 To: David Conrad , RJ Atkinson From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org The primary problem you are both struggling with is that there are two location-dependent identifiers: one for points of attachment and one for nodes. You are trying to make one thing do for both. It doesn't work in Operating Systems and it doesn't work here. This is just like OSs. You need a logical and physical address spaces under the application name space. For the last 35 years, we have only had a physical address space. The point of attachment id does not have to be global. Neither does the node address, but if it isn't then you have to do relaying at the Application. You keep talking about nodes having more than one identifier. No. There may be more than one point of attachment (interface) bound to a node. But the identifiers for the points of attachment and the node are all distinct. The Loc/Id discussion is misleading. It is a red-herring. It isn't the real issue. The architecture you are working in only has point of attachment identifiers. Your endpoints are what I would have to call names for instances of application-protocols, not applications. That makes your Loc/Id discussion about the mapping of identifiers between application-protocol-instances and points of attachments. You are still tying everything to the physical. You have still failed to create the logical address space you need. Look we were building an experimental network. Passing data was a much bigger worry than the nuances of addressing. We didn't really think about addressing. We expected our experimental network to be replaced based on what we learned. Using only switch port numbers was a mistake. Well it was okay for early experimenting but not for production. We knew that by 72. So quit trying to build solutions that make it work. They will always be kludges. Take care, John At 11:41 -0800 2006/11/17, David Conrad wrote: >Ran, > >The model I have is as follows: > >a) source and destination end points are labeled with identifiers >b) the destination identifier is used at the edge (be it first hop >router, customer/ISP boundary, or something in between) of the >source network to look up the destination locator(s) >c) the source edge device (router) picks an appropriate destination >locator from the set returned by the lookup >d) packets are encapsulated with locators in the source and >destination fields for transit routing >e) at the destination edge, the packet is de-encapsulated and >forwarded to the destination end point identifier. > >With that model in mind, I have the following questions/comments: > >On Nov 14, 2006, at 12:21 PM, RJ Atkinson wrote: >>An Identifier should name a node, rather than naming an >>interface of a node, a point of attachment, or a location. > >Why wouldn't an identifier name an interface? What do you gain by >labeling a node? > >>A given node will have one or more Identifiers at a given >>point in time. > >Yes. > >>An Identifier has a high probability of being globally unique, >>but is not guaranteed to necessarily always be globally unique. > >If an identifier is not globally unique, the lookup will be >ambiguous and not securable. > >>An Identifier will be unique within the context of a >>given Locator. > >This implies identifiers would potentially need to change should >locators shift. This seems like a mistake to me as it removes one >of the primary advantages I see is having identifiers. > >>A typical node should easily be able to determine its Identifier(s) >>without consulting external sources of information. Some special >>case kinds of nodes might need to consult external information, >>but such special cases, if any, should be rare. > >I'm not sure what this means. Can you provide an example? > >>A Locator should name a single sub-network, rather than >>naming a node or an interface. > >I believe a locator should name a connection to the routing system. >What is on the other side of that connection is opaque and >irrelevant to the routing system. > >>A given node will have at least one Locator for each >>different upstream connection. > >Right. > >>A transport-layer protocol will not be aware of the Locator(s) >>in use by any endpoint of any transport-layer session. > >Exactly. > >>One ought to be able to learn a node's current set of >>Identifiers and current set of Locators if one knows >>the Fully Qualified Domain Name of that node. > >Yes. > >>One need not be able to directly learn the FQDN of a node >>given only the Identifier of the node. > >This is the case today in the sense that there is no global law >saying you must set up the {in-addr,ip6}.arpa PTR to match the >forward name. > >>A non-cryptographic authentication mechanism should be available >>that protects against off-path active attacks on a session, for >>optional use in low threat environments. > >Can you explain what a "non-cryptographic authentication mechanism" >is in this context? > >>Cryptographic authentication and confidentiality mechanisms should >>be available in the network layer. These should bind to the >>Identifier and ignore the Locator. > >In my model, since encapsulation is used, you can have crypto >auth/confidentiality as an option for both locators and identifiers. > >>A multi-homed node or site will never increase the entropy of the >>default-free zone of the inter-domain routing table. Instead, >>the Locator in use will vary as appropriate to achieve the >>multi-homing objectives. > >Right. > >>A mobile node or site will never increase the entropy of the >>default-free zone of the inter-domain routing table. Instead, >>the Locator in use will vary as appropriate to achieve the >>mobility objectives. > >Yep. > >>Full backwards compatibility with deployed network-layer and >>transport-layer protocols is nice to have, but is not a requirement. > >At this point, I suspect lack of backwards compatibility will likely >result in non-deployability. > >Rgds, >-drc > > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 18 05:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlN49-0003bm-TF; Sat, 18 Nov 2006 05:04:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlN47-0003bg-WC for architecture-discuss@ietf.org; Sat, 18 Nov 2006 05:04:52 -0500 Received: from imo-m17.mx.aol.com ([64.12.138.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlN46-0001F6-Ny for architecture-discuss@ietf.org; Sat, 18 Nov 2006 05:04:51 -0500 Received: from HeinerHummel@aol.com by imo-m17.mx.aol.com (mail_out_v38_r7.6.) id 9.c0d.a053da0 (43930); Sat, 18 Nov 2006 05:04:40 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sat, 18 Nov 2006 05:04:40 EST Subject: Re: [arch-d] thoughts To: jnc@mercury.lcs.mit.edu, architecture-discuss@ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0289442984==" Errors-To: architecture-discuss-bounces@ietf.org --===============0289442984== Content-Type: multipart/alternative; boundary="-----------------------------1163844280" -------------------------------1163844280 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hello all, I am new on this mailing-list and I am also interested on the real =20 architectual problems wrt. addressing, routing, and a one-face-only model (= rather than=20 a model that glues together orthogonal pieces like BGP, initial OSPF,=20 OSPF-areas). =20 Nevertheless I like to respond to the following bon-mot of John Louis Petit=20= =20 first: =20 Only the differences between what some speaker A wants to say and some=20 listener B believes to be told will induce progress in the discussion. Of=20= course=20 not if the differences were too big (e.g. if A and B do not speak the same=20 language). But also not if there is no difference in understanding at all.=20= If=20 A says 1+1=3D2, that won't trigger any new idea by B. It's the slight=20 misunderstanding which is valuable. =20 Heiner Hummel =20 =20 In einer eMail vom 18.11.2006 02:58:32 Westeurop=E4ische Normalzeit schreibt= =20 jnc@mercury.lcs.mit.edu: Time to roll out my favourite terminology quotation again: "I am far from thinking that nomenclature is a remedy for every defect in art or science: still I cannot but feel that confusion of terms generally springs from, and always leads to, confusion of ideas." -- John Louis Petit, "Architectural Studies in France", 1854 Maybe we should add that to the "welcome to the list" message? :-) -------------------------------1163844280 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
I am new on this mailing-list and I am also interested on the real=20 architectual problems wrt. addressing, routing, and a one-face-only model=20 (rather than a model that glues together orthogonal pieces like BG= P,=20 initial OSPF, OSPF-areas).
 
Nevertheless I like to respond to the following bon-mot of John Louis P= etit=20 first:
 
Only the differences between what some speaker A wants to say  and= =20 some listener B believes to be told  will induce progress in the=20 discussion. Of course not if the differences were too big (e.g. if A an= d B=20 do not speak the same language). But also not if there is no difference in=20 understanding at all. If A says 1+1=3D2, that won't trigger any new idea by=20= B.=20 It's the slight misunderstanding which is valuable.
 
Heiner Hummel
 
 
In einer eMail vom 18.11.2006 02:58:32 Westeurop=E4ische Normalzeit sch= reibt=20 jnc@mercury.lcs.mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Time to=20 roll out my favourite terminology quotation again:

  "I am far= =20 from thinking that nomenclature is a remedy for every defect in
 =20= art=20 or science: still I cannot but feel that confusion of terms=20 generally
  springs from, and always leads to, confusion of=20 ideas."

       -- John Louis Petit, "Architectu= ral=20 Studies in France", 1854

Maybe we should add that to the "welcome t= o=20 the list" message? :-)

 
-------------------------------1163844280-- --===============0289442984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0289442984==-- From architecture-discuss-bounces@ietf.org Sat Nov 18 10:30:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlS75-0001rv-Fg; Sat, 18 Nov 2006 10:28:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlS74-0001rp-Qh for architecture-discuss@ietf.org; Sat, 18 Nov 2006 10:28:14 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlS73-0007cm-Fa for architecture-discuss@ietf.org; Sat, 18 Nov 2006 10:28:14 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2C70B872C5; Sat, 18 Nov 2006 10:28:13 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] thoughts Message-Id: <20061118152813.2C70B872C5@mercury.lcs.mit.edu> Date: Sat, 18 Nov 2006 10:28:13 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day Let me start with a few thoughts of my own, and then I'll reply to some points in your message. I think the best way to start is by totally divorcing the questions of: - 1) What classes of things do we name, and - 2) What do the names of those things look like. Too much (all?) of the discussion here mushes the two together, which has a whole range of problems. (One big one is that it's hard to clearly think about the issues when it's just one big knotted ball of string.) So I think it's wise to first thing about what are the things that need names. Once that's settled, I think it becomes a lot easier to figure out what the names look like, because by then you are thinking about how you want to use the names, what you want to be able to do with them, and so makes it clear what characteristics those names need to have. When I think like this, it's clear that we need a class of objects which is "place to deliver packets to", but it's not totally clear what higher-level objects we need to name; do we need to name transport-level entities, or should we go straight a higher-level thing (some sort of application name)? > This is just like OSs. You need a logical and physical address spaces > under the application name space. Not necessarily (although perhaps I'm misunderstanding what you're trying to say). In OS's, we have classes of objects (disk blocks) which only have physical names; other objects (e.g. files) only have logical names. Sure, they are both names for permanent storage, but their semantics are very different. > The point of attachment id does not have to be global. I would argue that it does, in practise, because otherwise path computation becomes a nightmare. To find a path from any arbitrary point to any other, you really need names that are global in scope. > You keep talking about nodes having more than one identifier. No. There > may be more than one point of attachment (interface) bound to a node. I tend to not like the term "node" because it makes a lot of people think of "physical machine", and the classes of designs you come up with to handle that then have issues when it comes to things like virtul machine OS's (particularly ones where you have a pool of physical machines, and application VM's can get moved from physical machine to machine, to balance load). E.g. how about one interface having more than one node attached to it? How about having the binding to the interface of one of those nodes changing, but not the others? Etc... Are you sold on naming machines, for some reason, or are you OK with a more abstract thing? > The Loc/Id discussion is misleading. It is a red-herring. It isn't the > real issue. (Added later: I think I see what your point was here, and it wasn't what I thought it was, so the rest of this bit is probably stuff you already agree with, but I'll leave it for now.) Well, I partly agree with that, if you come at it the way I suggested, because first you need to think about what kinds of things you are naming, and yes, there, the characteristics of the name aren't in play yet. At the same time, I disagree, when it comes to the part about what the names are like. If we are naming two different classes of thing, then you get more bang for your naming buck if one class of name is location-dependent (well, something at some level has to be, to get the packets there :-), and the other is location-independent, so that the binding between the two gives you all sorts of useful tools (e.g. the ability to support multiple location-names, while hiding all the details of that). > The architecture you are working in only has point of attachment > identifiers. Currently, yes. But the current architecture's not that much of an issue, since we're trying to go beyond it. It's only an issue insofar it's a legacy we have to manage to work with. > Your endpoints are what I would have to call names for instances of > application-protocols, not applications. True, but I'd go further - they are really (depending on which definition of "endpoint" you are using :-) names for transport-level entities. We no doubt have use for both i) names for applications, and ii) names for instances of applicataions, but the question I am pondering is whether we need transport-level names as well... > That makes your Loc/Id discussion about the mapping of identifiers > between application-protocol-instances and points of attachments. Um, no, I think - I think most people are proposing naming transport-level entities in some location-independent way, and having some sort of binding between those and location-dependent point-of-attachment names. Actually, let me take that back! Now that I think about it, David and Ran are both (if I understand them correctly) talking about having the names for transport-level entities say a little bit about where they are (within a local scope), and those names are also to some degree naming point-of-attachments, so yeah, I guess you are right. > You are still tying everything to the physical. You have still failed > to create the logical address space you need. When I first read this, I didn't understand your point, until the penny dropped that neither scheme clearly separates out what is being named, and also doesn't give each one names with clearly different characteristics. On the other hand, we may be stuck with that kind of ugliness, given that we have to modify an existing, deployed architecture... Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 18 11:51:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlTNe-0007D4-0g; Sat, 18 Nov 2006 11:49:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlTNc-0007Bs-Fk for architecture-discuss@ietf.org; Sat, 18 Nov 2006 11:49:24 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlTNc-0003OU-2C for architecture-discuss@ietf.org; Sat, 18 Nov 2006 11:49:24 -0500 Received: from [10.0.1.6] (failure[24.34.102.194]) by comcast.net (alnrmhc13) with ESMTP id <20061118164909b130000up6e>; Sat, 18 Nov 2006 16:49:23 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061118152813.2C70B872C5@mercury.lcs.mit.edu> References: <20061118152813.2C70B872C5@mercury.lcs.mit.edu> Date: Sat, 18 Nov 2006 11:48:46 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > From: John Day > >Let me start with a few thoughts of my own, and then I'll reply to some >points in your message. > >I think the best way to start is by totally divorcing the questions of: > >- 1) What classes of things do we name, and >- 2) What do the names of those things look like. > >Too much (all?) of the discussion here mushes the two together, which has a >whole range of problems. (One big one is that it's hard to clearly think >about the issues when it's just one big knotted ball of string.) > >So I think it's wise to first thing about what are the things that need >names. Once that's settled, I think it becomes a lot easier to figure out >what the names look like, because by then you are thinking about how you want >to use the names, what you want to be able to do with them, and so makes it >clear what characteristics those names need to have. > >When I think like this, it's clear that we need a class of objects which is >"place to deliver packets to", but it's not totally clear what higher-level >objects we need to name; do we need to name transport-level entities, or >should we go straight a higher-level thing (some sort of application name)? Agreed that we need to distinguish the two things. However, I would characterize what we need to name a little differently. We need a name for every locus of shared state with a different scope. As near as I can tell, we have a minimum of three different scopes. What we have traditionally called data link, network and application. > > > This is just like OSs. You need a logical and physical address spaces > > under the application name space. > >Not necessarily (although perhaps I'm misunderstanding what you're trying to >say). In OS's, we have classes of objects (disk blocks) which only have >physical names; other objects (e.g. files) only have logical names. Sure, they >are both names for permanent storage, but their semantics are very different. I was thinking more of memory management, as was Saltzer. > > The point of attachment id does not have to be global. > >I would argue that it does, in practise, because otherwise path computation >becomes a nightmare. To find a path from any arbitrary point to any other, >you really need names that are global in scope. It does if the mistake was made of only naming points of attachments, which we did with the IMPs and have promulgated. Point of attachments should correspond to data link addresses. As I mentioned in another email to you, Saltzer missed (legitimately, I think) that one might have more than one path between hops. To find a route from any arbitrary point to any other, you do indeed names with scope of the layer in which they reside. In some specific cases that is global. But these should be node addresses not point of attachment addresses, unless it is a fairly small network. > > > You keep talking about nodes having more than one identifier. No. There > > may be more than one point of attachment (interface) bound to a node. > >I tend to not like the term "node" because it makes a lot of people think of >"physical machine", and the classes of designs you come up with to handle that >then have issues when it comes to things like virtul machine OS's >(particularly ones where you have a pool of physical machines, and application >VM's can get moved from physical machine to machine, to balance load). ;-) I was using node because it was the fairly neutral term that Salzter used that didn't really apply to any particular object. I still contend that the physical machine is not relevant to this discussion. It is nice it is there to execute the code, but it doesn't impinge on this issue at all. > >E.g. how about one interface having more than one node attached to it? How >about having the binding to the interface of one of those nodes changing, but >not the others? Etc... Are you sold on naming machines, for some reason, or >are you OK with a more abstract thing? As I said I have no desire and have found no requirement to name machines for the purposes of creating and maintaining communications. I am not sure what you mean by interface. I do understand local bindings between protocol machines (PM) with different scope. And have no problems with a PM of smaller scope having bindings with more than one PM (having greater scope) in the same system. > > > The Loc/Id discussion is misleading. It is a red-herring. It isn't the > > real issue. > >(Added later: I think I see what your point was here, and it wasn't what I >thought it was, so the rest of this bit is probably stuff you already agree >with, but I'll leave it for now.) ;-) >Well, I partly agree with that, if you come at it the way I suggested, because >first you need to think about what kinds of things you are naming, and yes, >there, the characteristics of the name aren't in play yet. At the same time, >I disagree, when it comes to the part about what the names are like. > >If we are naming two different classes of thing, then you get more bang for >your naming buck if one class of name is location-dependent (well, something >at some level has to be, to get the packets there :-), and the other is >location-independent, so that the binding between the two gives you all sorts >of useful tools (e.g. the ability to support multiple location-names, while >hiding all the details of that). Agreed. > > > The architecture you are working in only has point of attachment > > identifiers. > >Currently, yes. But the current architecture's not that much of an issue, >since we're trying to go beyond it. It's only an issue insofar it's a legacy >we have to manage to work with. > > > Your endpoints are what I would have to call names for instances of > > application-protocols, not applications. > >True, but I'd go further - they are really (depending on which definition of >"endpoint" you are using :-) names for transport-level entities. We no doubt >have use for both i) names for applications, and ii) names for instances of >applicataions, but the question I am pondering is whether we need >transport-level names as well... > No. we don't. It turns out that transport isn't as important as we thought. ;-) All we need in transport is a connection-id to distinguish flows. And we have that. The application naming does need to be a bit richer, but we don't need to go into that here, now. > > That makes your Loc/Id discussion about the mapping of identifiers > > between application-protocol-instances and points of attachments. > >Um, no, I think - I think most people are proposing naming transport-level >entities in some location-independent way, and having some sort of binding >between those and location-dependent point-of-attachment names. That is because the community seems to have blinders on and believes that the only two layers they know they have are network and transport so everything has to be solved there. >Actually, let me take that back! Now that I think about it, David and Ran are >both (if I understand them correctly) talking about having the names for >transport-level entities say a little bit about where they are (within a >local scope), and those names are also to some degree naming >point-of-attachments, so yeah, I guess you are right. > > > You are still tying everything to the physical. You have still failed > > to create the logical address space you need. > >When I first read this, I didn't understand your point, until the penny >dropped that neither scheme clearly separates out what is being named, and >also doesn't give each one names with clearly different characteristics. This is hard. And it is really hard with email. The points are subtle and they require screwing your head around where it hasn't been. Believe me, I know! It was hell figuring it out! >On the other hand, we may be stuck with that kind of ugliness, given that we >have to modify an existing, deployed architecture... That is entirely different question. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 18 12:04:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlTaz-0004uH-Fv; Sat, 18 Nov 2006 12:03:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlTay-0004uC-LX for architecture-discuss@ietf.org; Sat, 18 Nov 2006 12:03:12 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlTav-0005b4-0o for architecture-discuss@ietf.org; Sat, 18 Nov 2006 12:03:12 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GlTau-00018I-10 for architecture-discuss@ietf.org; Sat, 18 Nov 2006 09:03:08 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 18 Nov 2006 18:03:35 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org, jeanjour@comcast.net From: Jefsey_Morfin Subject: Re: [arch-d] thoughts In-Reply-To: <20061118152813.2C70B872C5@mercury.lcs.mit.edu> References: <20061118152813.2C70B872C5@mercury.lcs.mit.edu> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1802690067==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1802690067== Content-Type: multipart/alternative; boundary="----MTepqyzgagfzyvdnhpniiucrxbkxmkucrw" ------MTepqyzgagfzyvdnhpniiucrxbkxmkucrw Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7E36273B >I think the best way to start is by totally divorcing the questions of: >- 1) What classes of things do we name, and OK. except that who is the "we". Is that a unique plan, or is it a multiple plan? With registrar attached to the "things" or to "ends"? I think it is a thrid point only to be addressed at the time you consider how addresses look like. >- 2) What do the names of those things look like. Except that they must be universal, hence numerics. >When I think like this, it's clear that we need a class of objects which is >"place to deliver packets to", but it's not totally clear what higher-level >objects we need to name; do we need to name transport-level entities, or >should we go straight a higher-level thing (some sort of application name)? IMHO you go too fast. Are you sure that all the transport-level are equal. Think of MTAs and UAs. > > This is just like OSs. You need a logical and physical address spaces > > under the application name space. Correct. All the /etc/named directories will work the same, whatever the machine and where they are located on disks. And all the .../db.mit.edu will be treated by Bind the same whatever the physical address of the machine/disk and the logical directory you chose to put in named.conf. This permits to see that the data in these three layers are orthogonal. >Not necessarily (although perhaps I'm misunderstanding what you're trying to >say). In OS's, we have classes of objects (disk blocks) which only have >physical names; other objects (e.g. files) only have logical names. Sure, they >are both names for permanent storage, but their semantics are very different. The semantic is for looking simpler to you. All of them are actually pointers, like IP addresses are domain name pointers. The semantic is of low interest. What counts is: - the layer - if there is a layer violation or not, i.e. if there is a dependance on an other layer. > > The point of attachment id does not have to be global. > >I would argue that it does, in practise, because otherwise path computation >becomes a nightmare. To find a path from any arbitrary point to any other, >you really need names that are global in scope. No. Path computation would be segmented and therefore simplified (distributed, fractal, iterative). You can ask it to be carried by a smart DNS, segment by segment in a similar way as you resolve iteratively a domain name. First ISP computes to the Gateway, then to the destionation ISP, then the destination ISP to the end, then the end in the intranet. Some kind of an inter-NAT protocol could be used. > > You keep talking about nodes having more than one identifier. No. There > > may be more than one point of attachment (interface) bound to a node. > >I tend to not like the term "node" because it makes a lot of people think of >"physical machine", and the classes of designs you come up with to handle that >then have issues when it comes to things like virtul machine OS's >(particularly ones where you have a pool of physical machines, and application >VM's can get moved from physical machine to machine, to balance load). > >E.g. how about one interface having more than one node attached to it? How >about having the binding to the interface of one of those nodes changing, but >not the others? Etc... Are you sold on naming machines, for some reason, or >are you OK with a more abstract thing? The notion should be: logical nodes at that layer. Physical nodes at machine level. Metanodes for human/application layer. > > The Loc/Id discussion is misleading. It is a red-herring. It isn't the > > real issue. There are (at least) four layers you are to consider addressingplan-location-identification-application. - the environment - the plug - then end - the brain (application, user) They are orthogonal. You can consider more as you may refer metadata to external registries (ISO 11172). > > The architecture you are working in only has point of attachment > > identifiers. > >Currently, yes. But the current architecture's not that much of an issue, >since we're trying to go beyond it. It's only an issue insofar it's a legacy >we have to manage to work with. No. The first thing to agree is that what is involved is not a replacement or a transtion but an addition in parallel. Current operations and plans must stay untouched. There is already a problem no body foresaw, let not make it potentially worse in trying to fix it. > > Your endpoints are what I would have to call names for instances of > > application-protocols, not applications. actually in many cases they will be metadata holes. DNS + IPv6 addresses are particularly apt to support them. > > You are still tying everything to the physical. You have still failed > > to create the logical address space you need. I see what you name physical nodes, but I wander what you really call logical space here: logical nodes or deeper metanodes? >On the other hand, we may be stuck with that kind of ugliness, given that we >have to modify an existing, deployed architecture... No. You can support all this without problem using the DNS and numeric labels. It will only be slower and more resource consuming. But this permits to test and transition. The FQDN will then look like: http://metanode_id.logicalnode_id.physicalnode_id.testsystem_name.org That you can map into IPv6 testsystem_address:physicalnode_address:logicalnode_address:metanode_address Or into an IPv4 address with an access engine sorting the vitual corresponding virtual_host, virtual_metaregistry addresses. The only problem is that before developping application using that scheme, it is better to know about the size of the final address space, meaning if a /3 block is allocated to it or not or if a brand new core is to be built which will support 256 bytes addresses (I documented the interlink/syllodata issue which may mean to refer long numbering schemes). Otherwise everyone can make it work today. The only real new issue is the metadata layer. jfc ------MTepqyzgagfzyvdnhpniiucrxbkxmkucrw Content-Type: text/html
>I think the best way to start is by totally divorcing the questions of:
>- 1) What classes of things do we name, and

OK.
except that who is the "we". Is that a unique plan, or is it a
multiple plan? With registrar attached to the "things" or to "ends"?
I think it is a thrid point only to be addressed at the time you
consider how addresses look like.

>- 2) What do the names of those things look like.

Except that they must be universal, hence numerics.

>When I think like this, it's clear that we need a class of objects which is
>"place to deliver packets to", but it's not totally clear what higher-level
>objects we need to name; do we need to name transport-level entities, or
>should we go straight a higher-level thing (some sort of application name)?

IMHO you go too fast. Are you sure that all the transport-level are
equal. Think of MTAs and UAs.

>     > This is just like OSs. You need a logical and physical address spaces
>     > under the application name space.

Correct.
All the /etc/named directories will work the same, whatever the
machine and where they are located on disks. And all the
.../db.mit.edu will be treated by Bind the same whatever the physical
address of the machine/disk and the logical directory you chose to
put in named.conf.

This permits to see that the data in these three layers are orthogonal.

>Not necessarily (although perhaps I'm misunderstanding what you're trying to
>say). In OS's, we have classes of objects (disk blocks) which only have
>physical names; other objects (e.g. files) only have logical names. Sure, they
>are both names for permanent storage, but their semantics are very different.

The semantic is for looking simpler to you. All of them are actually
pointers, like IP addresses are domain name pointers. The semantic is
of low interest.

What counts is:
- the layer
- if there is a layer violation or not, i.e. if there is a dependance
on an other layer.

>     > The point of attachment id does not have to be global.
>
>I would argue that it does, in practise, because otherwise path computation
>becomes a nightmare. To find a path from any arbitrary point to any other,
>you really need names that are global in scope.

No. Path computation would be segmented and therefore simplified
(distributed, fractal, iterative). You can ask it to be carried by a
smart DNS, segment by segment in a similar way as you resolve
iteratively a domain name. First ISP computes to the Gateway, then to
the destionation ISP, then the destination ISP to the end, then the
end in the intranet. Some kind of an inter-NAT protocol could be used.

>     > You keep talking about nodes having more than one identifier. No. There
>     > may be more than one point of attachment (interface) bound to a node.
>
>I tend to not like the term "node" because it makes a lot of people think of
>"physical machine", and the classes of designs you come up with to handle that
>then have issues when it comes to things like virtul machine OS's
>(particularly ones where you have a pool of physical machines, and application
>VM's can get moved from physical machine to machine, to balance load).
>
>E.g. how about one interface having more than one node attached to it? How
>about having the binding to the interface of one of those nodes changing, but
>not the others? Etc... Are you sold on naming machines, for some reason, or
>are you OK with a more abstract thing?

The notion should be: logical nodes at that layer. Physical nodes at
machine level. Metanodes for human/application layer.

>     > The Loc/Id discussion is misleading. It is a red-herring. It isn't the
>     > real issue.

There are (at least) four layers you are to consider
addressingplan-location-identification-application.
- the environment
- the plug
- then end
- the brain (application, user)
They are orthogonal.

You can consider more as you may refer metadata to external
registries (ISO 11172).

>     > The architecture you are working in only has point of attachment
>     > identifiers.
>
>Currently, yes. But the current architecture's not that much of an issue,
>since we're trying to go beyond it. It's only an issue insofar it's a legacy
>we have to manage to work with.

No. The first thing to agree is that what is involved is not a
replacement or a transtion but an addition in parallel. Current
operations and plans must stay untouched. There is already a problem
no body foresaw, let not make it potentially worse in trying to fix it.

>     > Your endpoints are what I would have to call names for instances of
>     > application-protocols, not applications.

actually in many cases they will be metadata holes. DNS + IPv6
addresses are particularly apt to support them.

>     > You are still tying everything to the physical. You have still failed
>     > to create the logical address space you need.

I see what you name physical nodes, but I wander what you really call
logical space here: logical nodes or deeper metanodes?

>On the other hand, we may be stuck with that kind of ugliness, given that we
>have to modify an existing, deployed architecture...

No. You can support all this without problem using the DNS and
numeric labels. It will only be slower and more resource consuming.
But this permits to test and transition. The FQDN will then look like:

               http://metanode_id.logicalnode_id.physicalnode_id.testsystem_name.org

That you can map into IPv6
testsystem_address:physicalnode_address:logicalnode_address:metanode_address
Or into an IPv4 address with an access engine sorting the vitual
corresponding virtual_host, virtual_metaregistry addresses.

The only problem is that before developping application using that
scheme, it is better to know about the size of the final address
space, meaning if a /3 block is allocated to it or not or if a brand
new core is to be built which will support 256 bytes addresses (I
documented the interlink/syllodata issue which may mean to refer long
numbering schemes). Otherwise everyone can make it work today. The
only real new issue is the metadata layer.

jfc


------MTepqyzgagfzyvdnhpniiucrxbkxmkucrw-- --===============1802690067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1802690067==-- From architecture-discuss-bounces@ietf.org Sat Nov 18 14:57:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlWH3-0002bD-Tl; Sat, 18 Nov 2006 14:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlWH2-0002Uy-KI for architecture-discuss@ietf.org; Sat, 18 Nov 2006 14:54:48 -0500 Received: from centrmmtao04.cox.net ([70.168.83.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlWCk-0004n0-Gs for architecture-discuss@ietf.org; Sat, 18 Nov 2006 14:50:24 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061118195027.FRWC1440.centrmmtao04.cox.net@eastrmimpo02.cox.net>; Sat, 18 Nov 2006 14:50:27 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id oKpS1V00P0pnMhQ0000000; Sat, 18 Nov 2006 14:49:26 -0500 In-Reply-To: <20061118152813.2C70B872C5@mercury.lcs.mit.edu> References: <20061118152813.2C70B872C5@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20250CC7-E2E1-4D53-9FC5-BFB416445689@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Sat, 18 Nov 2006 14:50:20 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 18 Nov 2006, at 10:28, Noel Chiappa wrote: > Actually, let me take that back! > Now that I think about it, David and Ran are both (if I understand > them correctly) talking about having the names for transport-level > entities say a little bit about where they are (within a > local scope), and those names are also to some degree naming > point-of-attachments, so yeah, I guess you are right. I must not have been clear. In my mind, transport-layer entities are oblivious to where they are (i.e. location) and only use location-independent Identifiers (never Locators) and are NOT naming point-of-attachment in any way. In my concept, interfaces are named only at/within the link-layer and the scope of the name is local to the particular link. Nodes ("protocol stacks") have one or more Identifiers, used only for end-to-end identity, and one or more Locators, used only for routing/forwarding network-layer packets. Identifiers have global scope, but are not absolutely guaranteed to be unique. Locators have global scope. Unicast Locators must be unique in order for routing/fowarding to work. (I can imagine having multicast Locators, but lets leave that aside for the moment please.) I agree with Noel that terminology for "Nodes" is very fuzzy as soon as one talks about things like distributed systems, virtualised systems, or MLS systems. However, "Node" is a pretty good description for my laptop, which is neither distributed, virtualised, nor MLS. >> You are still tying everything to the physical. You have still failed >> to create the logical address space you need. > > When I first read this, I didn't understand your point, until the > penny > dropped that neither scheme clearly separates out what is being > named, and > also doesn't give each one names with clearly different > characteristics. In which way is my concept not clear in separating what is being named ? I suspect this is mostly a matter of my writing or terminology, because in my head I think the objects being named are pretty distinct and separate. Thanks, Ran _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 18 15:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlWQ9-0006Gr-8s; Sat, 18 Nov 2006 15:04:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlWQ8-0006Gl-Iw for architecture-discuss@ietf.org; Sat, 18 Nov 2006 15:04:12 -0500 Received: from eastrmmtao02.cox.net ([68.230.240.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlWQ6-0006f7-9E for architecture-discuss@ietf.org; Sat, 18 Nov 2006 15:04:12 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao02.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061118200415.CDDH28530.eastrmmtao02.cox.net@eastrmimpo02.cox.net>; Sat, 18 Nov 2006 15:04:15 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id oL3E1V00Q0pnMhQ0000000; Sat, 18 Nov 2006 15:03:14 -0500 In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A5B4F04-49E6-43FC-90C9-110F0C02E044@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Sat, 18 Nov 2006 15:04:08 -0500 To: John Day X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 17 Nov 2006, at 23:14, John Day wrote: > The primary problem you are both struggling with is that there are > two location-dependent identifiers: one for points of attachment > and one for nodes. It is not clear to me why a node identifier is "location-dependent". A goal of mine is to have the node Identifier be location independent. > You keep talking about nodes having more than one identifier. No. Please explain why having more than one Identifier (note capitalisation) per "node" or "stack" is undesirable. > There may be more than one point of attachment (interface) bound to > a node. Agree. > But the identifiers for the points of attachment and the node are > all distinct. Well, I'd agree that names for "points of attachment" are different from names for a "node" (or "stack"). > The architecture you are working in only has point of attachment > identifiers. Your endpoints are what I would have to call names > for instances of application-protocols, not applications. That > makes your Loc/Id discussion about the mapping of identifiers > between application-protocol-instances and points of attachments. The above is not obvious to me. Cheers, Ran rja@extremenetworks.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 18 18:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZJE-00048l-2L; Sat, 18 Nov 2006 18:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZJC-00046Z-7m for architecture-discuss@ietf.org; Sat, 18 Nov 2006 18:09:14 -0500 Received: from eastrmmtao05.cox.net ([68.230.240.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlZJA-0002p7-V5 for architecture-discuss@ietf.org; Sat, 18 Nov 2006 18:09:14 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao05.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061118230909.WCCL18065.eastrmmtao05.cox.net@eastrmimpo02.cox.net> for ; Sat, 18 Nov 2006 18:09:09 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id oP881V00b0pnMhQ0000000; Sat, 18 Nov 2006 18:08:08 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: architecture-discuss@ietf.org From: RJ Atkinson Date: Sat, 18 Nov 2006 18:09:02 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [arch-d] On Names and Namespaces X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Earlier, Noel Chiappa said, in part: % ...the question I am pondering is whether % we need transport-level names as well... Then, John Day responded, in part: > No. we don't. It turns out that transport isn't as important > as we thought. ;-) All we need in transport is a connection-id > to distinguish flows. And we have that. It is not obvious over here that a transport-layer name is not needed and not useful architecturally. So maybe someone could expand a bit further on that topic ? A bit more rationale, perhaps ? I suppose your notion is that one could use an application-layer name (e.g. FQDN) at the transport-layer. Maybe that's true, I'm not sure, but I think there are architectural advantages to having an additional level of indirection at the transport-layer. Earlier, Noel Chiappa said, in part: % David and Ran are both (if I understand them correctly) talking % about having the names for transport-level entities say a little bit % about where they are (within a local scope), and those names are also % to some degree naming point-of-attachments, so yeah, % I guess you are right. If this was the conclusion from my notes, I was somehow unclear. Identifiers say *nothing* about where they are -- they are only naming "stacks" or, if one prefers, "nodes". Identifiers are location-independent -- and this property seems crucial for enabling mobility and multi-homing as first-order capabilities. Locators are the names with location-dependence, and they specifically name sub-networks. And there are separate link-layer names besides the Locator. Yours, Ran rja@extremenetworks.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 18 19:48:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glap5-0003OJ-9u; Sat, 18 Nov 2006 19:46:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glap4-0003Ln-3z for architecture-discuss@ietf.org; Sat, 18 Nov 2006 19:46:14 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glap2-0001Aj-S4 for architecture-discuss@ietf.org; Sat, 18 Nov 2006 19:46:14 -0500 Received: from [10.0.1.6] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20061119004611b1200mu799e>; Sun, 19 Nov 2006 00:46:12 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 18 Nov 2006 19:45:08 -0500 To: RJ Atkinson , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] On Names and Namespaces Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 18:09 -0500 2006/11/18, RJ Atkinson wrote: >Earlier, Noel Chiappa said, in part: >% ...the question I am pondering is whether >% we need transport-level names as well... > >Then, John Day responded, in part: >> No. we don't. It turns out that transport isn't as important >> as we thought. ;-) All we need in transport is a connection-id >> to distinguish flows. And we have that. > >It is not obvious over here that a transport-layer name is not needed >and not useful architecturally. So maybe someone could expand >a bit further on that topic ? A bit more rationale, perhaps ? What would a transport layer identifier do for you that an application name would not? >I suppose your notion is that one could use an application-layer >name (e.g. FQDN) at the transport-layer. Maybe that's true, >I'm not sure, but I think there are architectural advantages >to having an additional level of indirection at the transport-layer. What advantages? Transport is just an error and flow control protocol, another version of LLC or HDLC. Furthermore, Transport only deals with per flow state. Instance are nice, but not that important to this discussion. To put that kind of identifier in transport is a major structural change. > >Earlier, Noel Chiappa said, in part: >% David and Ran are both (if I understand them correctly) talking >% about having the names for transport-level entities say a little bit >% about where they are (within a local scope), and those names are also >% to some degree naming point-of-attachments, so yeah, >% I guess you are right. > >If this was the conclusion from my notes, I was somehow unclear. > >Identifiers say *nothing* about where they are -- they are only >naming "stacks" or, if one prefers, "nodes". Identifiers are >location-independent -- and this property seems crucial for >enabling mobility and multi-homing as first-order capabilities. Ah, I see. You want this transport identifier to be the short cut handle so when the system moves I don't have to change the mapping of application to address. So what is the big deal? Applications may move without the system moving and you have to do it anyway. > >Locators are the names with location-dependence, and they specifically >name sub-networks. And there are separate link-layer names besides >the Locator. I still don't understand why the data link layer isn't part of the "stack." Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 01:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlgPH-0008Or-SX; Sun, 19 Nov 2006 01:43:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlgPG-0008OU-8b for architecture-discuss@ietf.org; Sun, 19 Nov 2006 01:43:58 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlgPE-0004bJ-L2 for architecture-discuss@ietf.org; Sun, 19 Nov 2006 01:43:58 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id TAA17588; Sun, 19 Nov 2006 19:43:34 +1300 In-Reply-To: <3A5B4F04-49E6-43FC-90C9-110F0C02E044@extremenetworks.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <3A5B4F04-49E6-43FC-90C9-110F0C02E044@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44CCAAD2-A5F4-487F-A209-C1F6CB77F907@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] thoughts Date: Sun, 19 Nov 2006 19:43:42 +1300 To: RJ Atkinson X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 19/11/2006, at 9:04 AM, RJ Atkinson wrote: > > On 17 Nov 2006, at 23:14, John Day wrote: >> The primary problem you are both struggling with is that there are >> two location-dependent identifiers: one for points of attachment >> and one for nodes. > > It is not clear to me why a node identifier is "location-dependent". > A goal of mine is to have the node Identifier be location independent. That's kind of the point of having it, right? > >> You keep talking about nodes having more than one identifier. No. > > Please explain why having more than one Identifier (note > capitalisation) > per "node" or "stack" is undesirable. How about: there can be more than one Identifier per physical node/OS instance/application/whatever, but BY DEFINITION, each one defines a different node or stack. > >> There may be more than one point of attachment (interface) bound >> to a node. > > Agree. > >> But the identifiers for the points of attachment and the node are >> all distinct. > > Well, I'd agree that names for "points of attachment" are different > from names for a "node" (or "stack"). I *think* he was saying that identifier for the node must not be one of the identifiers for points of attachment. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 03:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glhkr-0003li-N5; Sun, 19 Nov 2006 03:10:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glhkp-0003lK-CG for architecture-discuss@ietf.org; Sun, 19 Nov 2006 03:10:19 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glhkl-0001wZ-Rq for architecture-discuss@ietf.org; Sun, 19 Nov 2006 03:10:17 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4850D213028 for ; Sun, 19 Nov 2006 10:09:42 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EA342213027 for ; Sun, 19 Nov 2006 10:09:41 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Pekka Nikander Date: Sun, 19 Nov 2006 10:09:44 +0200 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [arch-d] Primary and lesser names, or layers of indirection? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Maybe one difficulty in this discussion is that there are so many needs or "requirements"? Disregarding mobility, multi-path, etc, to me it looks like that we need two classes of primary names: 1) Application-level names. Handles that applications can refer to. 2) Routing-level names. Handles for the routing/forwarding system to use for directing traffic. The needs for these two types of names seem to be genuinely different, but I won't go into that here. My point is, for various mobility/security/efficiency/administrative needs, it seems plausible that we would benefit from a number of classes of "lesser" names. I call these tentatively "lesser" since they are not strictly needed; I could imagine an architecture with just application-level and routing-level names. However, these lesser names seem to reduce the amount of signalling in various mobility situations, they seem to offer possibilities for making the system more easily secureable, and they seem to help system administration by allowing better application-level flexibility (multiple versions of apps), identification of nodes, etc. As a starting point, I could imagine the following "lesser" names to be useful: a) Application-instance names. "Dynamic" variants of 1) above. b) Flow or transport names. Primarily needed for QoS/multi-path. c) Node or stack names. Primary units of mobility, with fate sharing. d) Interface or link-layer names. To give an idea how these could work, consider the following: 1. Application requests a service/whatever using an application-level name (1). 2. The Application-level name (1) is (optionally) resolved into an application-instance name (a). The benefit of this step is that it makes it easier to support distributed/location dependent/time dependent/etc applications. In general, any kinds of applications whose instance identification depends also on other attributes but the primary Application-level name (1). 3. If fulfilling of the application-level request involves one or more flows, new flow or transport names (b) are formed. These seem to be needed for QoS and flow control. Apparently, they should be visible to the intermediate nodes that care about QoS and flows, such as network-side nodes that control radio or other scarce resources. 4. A node or stack name (c) merely aggregates a number of flow names (b) for the primary purpose of node-level mobility. However, the node or stack name also allows easier implementation of baseline security and privacy, can make systems administration easier, etc. 5. The node or stack name (c) is mapped onto a Routing-level name (2). 6. The Routing-level name (2) is used to deliver the packet to the right location. This may involve additional names locally within the routing system, such as those used today in MPLS and GMPLS. As far as I understand, there may be administrative needs to classify flows based on various attributes; using names as short-hand notification seems to help efficiency. 7. Apparently, the routing-level name (2) is finally mapped into an interface or link-layer name (d). However, I have to admit that I don't quite understand why this is beneficial. (Clearly, it is not necessary.) Anyway, that's the way how the systems work today, and since I don't understand this level, it looks better to preserve this piece of the current architecture. A useful exercise (left for the reader to keep this message manageable) is to consider the _exact_ benefits and drawbacks caused by each of the proposed layers of indirection. The relevant corollary is to consider if (a)-(d) is the right choice of lesser names, or if there would be better ones. One that is missing but has been repeatedly suggested is explicitly naming (mobile) sub- networks. However, I happen to think that it can be "emulated" well enough with stack or node names and delegation. Note that I didn't say anything about how the various resolutions are performed in detail, nor where the mapping state is stored, etc. In some cases that may be implied by the nature of the names; in other cases I can see quite a lot of freedom and potential choices. Another important issue here is that I don't believe we could fulfil all the needs for application-level names with just one name space. There seem to be fundamental conflicts between usability, economic aspects, and security, that make it impossible. Hence, most probably we will need different representations for naming the application- level entities. That also implies that we'll need some kind of infrastructures (either local or global) for maintaining mappings between those different representations. But again, that's another issue. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 03:30:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gli4M-00012e-Td; Sun, 19 Nov 2006 03:30:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gli4M-00012W-5k for architecture-discuss@ietf.org; Sun, 19 Nov 2006 03:30:30 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gli4K-0003Sz-On for architecture-discuss@ietf.org; Sun, 19 Nov 2006 03:30:30 -0500 Received: from webmail46.lax.untd.com (webmail46.lax.untd.com [10.131.27.186]) by smtpout08.lax.untd.com with SMTP id AABCYAFSEAB6UTGS for (sender ); Sun, 19 Nov 2006 00:29:56 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKK4M+6RS027priRkqX/ajRw== Received: (from fergdawg@netzero.net) by webmail46.lax.untd.com (jqueuemail) id L7JCEPCK; Sun, 19 Nov 2006 00:29:33 PST Received: from [24.23.201.115] by webmail46.lax.untd.com with HTTP: Sun, 19 Nov 2006 08:29:08 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Sun, 19 Nov 2006 08:29:08 GMT To: pekka.nikander@nomadiclab.com Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061119.002933.716.1014170@webmail46.lax.untd.com> X-ContentStamp: 7:3:603629035 X-MAIL-INFO: 3bddf454d189f4898919dd453930ad5959b1f1f059b461398d2d31511d9494f471d0d454 X-UNTD-Peer-Info: 10.131.27.186|webmail46.lax.untd.com|webmail46.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Pekka Nikander wrote: >Maybe one difficulty in this discussion is that there are so many = needs or "requirements"? > I don't think so. The primary "problem" has been stated -- he growth of the routing system beyond what is maintainable. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFYBXNq1pz9mNUZTMRAsT9AJ90Y+m4TeqeCzvqTxI6Ad5yl36JMACeOoMD iinb9bWj/iThYetkUwJlrcE=3D =3DCkfK -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 07:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GllWg-0001RR-Pj; Sun, 19 Nov 2006 07:11:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GllWf-0001RL-IY for architecture-discuss@ietf.org; Sun, 19 Nov 2006 07:11:57 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GllWe-0007m8-Aa for architecture-discuss@ietf.org; Sun, 19 Nov 2006 07:11:57 -0500 Received: from [10.0.1.6] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc13) with ESMTP id <20061119121154b130000smqe>; Sun, 19 Nov 2006 12:11:55 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <44CCAAD2-A5F4-487F-A209-C1F6CB77F907@indranet.co.nz> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <3A5B4F04-49E6-43FC-90C9-110F0C02E044@extremenetworks.com> <44CCAAD2-A5F4-487F-A209-C1F6CB77F907@indranet.co.nz> Date: Sun, 19 Nov 2006 07:09:06 -0500 To: Andrew McGregor , RJ Atkinson From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 19:43 +1300 2006/11/19, Andrew McGregor wrote: >On 19/11/2006, at 9:04 AM, RJ Atkinson wrote: > >> >>On 17 Nov 2006, at 23:14, John Day wrote: >>>The primary problem you are both struggling with is that there are >>>two location-dependent identifiers: one for points of attachment >>>and one for nodes. >> >>It is not clear to me why a node identifier is "location-dependent". >>A goal of mine is to have the node Identifier be location independent. > >That's kind of the point of having it, right? No, Read Saltzer. RFC 1498. >> >>>You keep talking about nodes having more than one identifier. No. >> >>Please explain why having more than one Identifier (note capitalisation) >>per "node" or "stack" is undesirable. > >How about: there can be more than one Identifier per physical >node/OS instance/application/whatever, but BY DEFINITION, each one >defines a different node or stack. You missed the point of Ran's comment. Ran was distinguishing interface from stack. For him, interfaces and stacks have distinct fate sharing properties. My view is that one can not assume that is always the case, so you can't make it a property of the architecture. (Ran and I were having off-list discussions.) >> >>>There may be more than one point of attachment (interface) bound to a node. >> >>Agree. >> >>>But the identifiers for the points of attachment and the node are >>>all distinct. >> >>Well, I'd agree that names for "points of attachment" are different >>from names for a "node" (or "stack"). > >I *think* he was saying that identifier for the node must not be one >of the identifiers for points of attachment. We all agree on that. I believe that the node identifier must be location dependent as Saltzer found. Ran wants a location-independent identifier associated with Transport as a short handle way of getting all applications on this system. This is a radical change to Transport. But more such a name has more to do with application management, not IPC. And thus belongs in the application layer. Transport is not as important as we have thought. It is just the mechanism for creating per flow IPC. The only identifier it needs is a connection-id and it has that. Transport, LLC, HDLC are all instances of the same thing. Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 07:59:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmFj-0000nO-NM; Sun, 19 Nov 2006 07:58:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmFi-0000nJ-Pz for architecture-discuss@ietf.org; Sun, 19 Nov 2006 07:58:30 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlmFh-0002Z7-51 for architecture-discuss@ietf.org; Sun, 19 Nov 2006 07:58:30 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2006 04:58:28 -0800 X-IronPort-AV: i="4.09,438,1157353200"; d="scan'208"; a="88414075:sNHT40907727" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAJCwRgd028970 for ; Sun, 19 Nov 2006 07:58:27 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAJCwRYJ004664 for ; Sun, 19 Nov 2006 07:58:27 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 07:58:26 -0500 Received: from cisco.com ([10.86.242.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 07:58:26 -0500 Date: Sun, 19 Nov 2006 07:57:38 -0500 From: Scott W Brim To: architecture-discuss@ietf.org Subject: Re: [arch-d] thoughts Message-ID: <20061119125737.GA2584@sbrim-wxp01> Mail-Followup-To: Scott W Brim , architecture-discuss@ietf.org References: <20061118015317.5211C87307@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061118015317.5211C87307@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 19 Nov 2006 12:58:26.0549 (UTC) FILETIME=[67328A50:01C70BDA] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I'm just catching up but I wanted to toss this in to start with ... Excerpts from Noel Chiappa on Fri, Nov 17, 2006 08:53:17PM -0500: > Time to roll out my favourite terminology quotation again: > > "I am far from thinking that nomenclature is a remedy for every defect in > art or science: still I cannot but feel that confusion of terms generally > springs from, and always leads to, confusion of ideas." > > -- John Louis Petit, "Architectural Studies in France", 1854 > > Maybe we should add that to the "welcome to the list" message? :-) By this it appears how necessary it is for any man that aspires to true knowledge, to examine the definitions of former authors; and either to correct them, where they are negligently set down, or to make them himself. For the errors of definitions multiply themselves according as the reckoning proceeds, and lead men into absurdities, which at least they see, but cannot avoid, without reckoning anew from the beginning. Hobbes, Leviathan (1651) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 08:08:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmOn-0004WC-4N; Sun, 19 Nov 2006 08:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmOm-0004W5-1S for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:07:52 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlmOk-0003Es-Q0 for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:07:52 -0500 Received: from [10.0.1.6] (failure[24.34.102.194]) by comcast.net (alnrmhc11) with ESMTP id <20061119130725b1100slqdne>; Sun, 19 Nov 2006 13:07:50 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061119125737.GA2584@sbrim-wxp01> References: <20061118015317.5211C87307@mercury.lcs.mit.edu> <20061119125737.GA2584@sbrim-wxp01> Date: Sun, 19 Nov 2006 08:06:59 -0500 To: Scott W Brim , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org So with all of these good minds saying the same thing, why do we continually insist on not doing it? Even belittling those who do. Rhetorical question, of course. ;-) At 7:57 -0500 2006/11/19, Scott W Brim wrote: >I'm just catching up but I wanted to toss this in to start with ... > >Excerpts from Noel Chiappa on Fri, Nov 17, 2006 08:53:17PM -0500: >> Time to roll out my favourite terminology quotation again: >> >> "I am far from thinking that nomenclature is a remedy for every defect in >> art or science: still I cannot but feel that confusion of terms generally >> springs from, and always leads to, confusion of ideas." >> >> -- John Louis Petit, "Architectural Studies in France", 1854 >> >> Maybe we should add that to the "welcome to the list" message? :-) > > By this it appears how necessary it is for any man that aspires to > true knowledge, to examine the definitions of former authors; and > either to correct them, where they are negligently set down, or to > make them himself. For the errors of definitions multiply > themselves according as the reckoning proceeds, and lead men into > absurdities, which at least they see, but cannot avoid, without > reckoning anew from the beginning. > > Hobbes, Leviathan (1651) > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 08:17:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmVH-0006Xu-Jk; Sun, 19 Nov 2006 08:14:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmVF-0006Xa-1h for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:14:33 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlmVA-0003ns-Eb for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:14:33 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0AD5F212FF6; Sun, 19 Nov 2006 15:14:27 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 32E96212FF2; Sun, 19 Nov 2006 15:14:24 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <232DC679-50C8-4CCC-84DB-BE4A97975F83@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Sun, 19 Nov 2006 15:14:26 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org (These are all old thoughts, but perhaps I've got something wrong. Or perhaps I'm missing something altogether. Besides, it looks like some people are failing to remember the implication, below.) In the note below, I use the term "address" in its routing-related meaning, i.e., I'm referring to a piece of data that is affixed to a packet for the purposes of affecting its forwarding through the network. From an information placement point of view, the current prefix- encoding hop-by-hop routing architecture can be considered to be mid- way between pure source routing and pure host-based routing. In a pure source routing architecture, the source node encodes each next hop to the packet. Consequently, the packet contains all information needed for forwarding. No state at all needed in the middle boxes; you can hardly even call them routers, as they become pure forwarders. (I know, such an architecture is unrealistic; I'm simplifying in trying to make a point.) In a pure host-based routing architecture, the addresses have no structure at all and contain no forwarding information. For example, they could be random. Each router separately resolves the address into the next hop, potentially using all bits from the address. Full network topology and host location information is needed at each router. Host-based routing is used in MANETs, and scale badly. The recent SIGCOMM ROFL paper explores some of the limitations as seen in the light of current technology. http://project-iris.net/irisbib/papers/flatlabels:sigcomm2006/paper.pdf In the current architecture, the addresses encode some network topology information into the routing prefix, thereby reducing the amount of information needed to be stored at the routers or forwarding tables. The closer the prefixes match with the actual network topology, the bigger savings. From a mathematical point of view, one could say that the better the topology of the addressing space can be matched with the topology with of the network, the less information needs to be stored elsewhere. From here we get into two factors on how addresses do matter to routing: 1. If there are external forces (such as difficulty of renumbering) that make it hard to change addresses as needed, it becomes harder to maintain the match between the addressing topology and the real network topology. 2. The way we use the bits in the address to create the topological addressing space affects the ways we can match the address space with the network topology. I will skip the second issue for now. It is an important one, but can be studied in relative isolation from the larger architecture. For example, using other than tree structures to store network topology information into addresses might be something that might help with the pressures on the global routing table. However, my understanding of the graph theory is insufficient so that I could suggest anything sensible there. Considering the first issue, we can isolate a largish number issues in the overall architecture that make addresses more rigid or more agile. I won't go into examples; most of us know enough of them. However, from an economic point of view, I still maintain that the current APIs are the main issue in the medium, 10-20 years, perspective. But what I find most important, for the sake of the current discussions, the implication from above: If we can change the overall architecture, either fundamentally or through some kind of shim-patch hack, so that the applications become isolated from the addresses used by the routing and forwarding system, it becomes easier to change the addresses as needed. That, in turn, makes it easier to make the address space topology to match with the network topology. That's the reason why the overall architectural discussion matters, even to the current crisis of "the routing system [growing] beyond what is maintainable." It will not provide any short term remedy ("symptomatic solution"); for that we've now got the separate mailing list, see: http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ msg00638.html But I regard the larger architectural discussion as a necessity to make any progress with the larger problems, hopefully eventually reaching a longer-term solution ("fundamental solution"). For that discussion, we seem to have a plethora of needs or "requirements", many of which are fuzzy or hard to nail down exactly. Therefore I find it easier to discuss in terms of concrete architectural structures, like what I did in my previous message: http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ msg00657.html --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 08:42:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glmvf-0007dG-8o; Sun, 19 Nov 2006 08:41:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glmvd-0007dB-Ks for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:41:49 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glmvc-0006Bn-8F for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:41:49 -0500 Received: from [10.0.1.6] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc11) with ESMTP id <20061119134136b1100sjssre>; Sun, 19 Nov 2006 13:41:47 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> References: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> Date: Sun, 19 Nov 2006 08:36:26 -0500 To: Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:09 +0200 2006/11/19, Pekka Nikander wrote: >Maybe one difficulty in this discussion is that there are so many >needs or "requirements"? > >Disregarding mobility, multi-path, etc, to me it looks like that we >need two classes of primary names: > >1) Application-level names. Handles that applications can refer to. > >2) Routing-level names. Handles for the routing/forwarding system >to use for directing traffic. > >The needs for these two types of names seem to be genuinely >different, but I won't go into that here. This is where John Shoch's paper gets to. >My point is, for various mobility/security/efficiency/administrative >needs, it seems plausible that we would benefit from a number of >classes of "lesser" names. I call these tentatively "lesser" since >they are not strictly needed; I could imagine an architecture with >just application-level and routing-level names. However, these >lesser names seem to reduce the amount of signalling in various >mobility situations, they seem to offer possibilities for making the >system more easily secureable, and they seem to help system >administration by allowing better application-level flexibility >(multiple versions of apps), identification of nodes, etc. I will go back to my earlier characterization: Names are needed for all loci of shared state with different scope. >As a starting point, I could imagine the following "lesser" names to >be useful: > >a) Application-instance names. "Dynamic" variants of 1) above. As well as other possible names or naming conventions for aggregations of applications. >b) Flow or transport names. Primarily needed for QoS/multi-path. We have this. It is the connection-id in TCP, i.e. the port-ids. > >c) Node or stack names. Primary units of mobility, with fate sharing. > >d) Interface or link-layer names. > >To give an idea how these could work, consider the following: > >1. Application requests a service/whatever using an >application-level name (1). > >2. The Application-level name (1) is (optionally) resolved into an >application-instance name (a). The benefit of this step is that it >makes it easier to support distributed/location dependent/time >dependent/etc applications. In general, any kinds of applications >whose instance identification depends also on other attributes but >the primary Application-level name (1). This was all worked out 15 years ago. >3. If fulfilling of the application-level request involves one or >more flows, new flow or transport names (b) are formed. These seem >to be needed for QoS and flow control. Apparently, they should be >visible to the intermediate nodes that care about QoS and flows, >such as network-side nodes that control radio or other scarce >resources. Take a look at how IPC works in most OSs. This should be the model. >4. A node or stack name (c) merely aggregates a number of flow names >(b) for the primary purpose of node-level mobility. However, the >node or stack name also allows easier implementation of baseline >security and privacy, can make systems administration easier, etc. There is a problem here. What I would call the node address is what you are calling the routing level name. What you are calling the node name I would see as additional structure on the application naming scheme. To use your nomenclature then, As I argued before, this is an application aggregation name. It belongs in the application layer. There are cases where this kind of aggregation is not desirable and others are, So this would get in the way. Some may argue that a large number of instances today are of this sort and that may be. But we have no idea if that will continue to be the case and end up being in the way later. If we make it part of the application layer then we can use when and if we need to and not if we don't. We don't need to force this inflexibility here. > >5. The node or stack name (c) is mapped onto a Routing-level name (2). The primary purposes of the routing name or the functions behind it is multiplexing and relaying. > >6. The Routing-level name (2) is used to deliver the packet to the >right location. This may involve additional names locally within >the routing system, such as those used today in MPLS and GMPLS. As >far as I understand, there may be administrative needs to classify >flows based on various attributes; using names as short-hand >notification seems to help efficiency. > >7. Apparently, the routing-level name (2) is finally mapped into an >interface or link-layer name (d). However, I have to admit that I >don't quite understand why this is beneficial. (Clearly, it is not >necessary.) Anyway, that's the way how the systems work today, and >since I don't understand this level, it looks better to preserve >this piece of the current architecture. Once the Next Hop is chosen, this information is required to pick the path to the next hop. This is only needed if there are multiple paths or if the media is multi-access. > >A useful exercise (left for the reader to keep this message >manageable) is to consider the _exact_ benefits and drawbacks caused >by each of the proposed layers of indirection. The relevant >corollary is to consider if (a)-(d) is the right choice of lesser >names, or if there would be better ones. One that is missing but >has been repeatedly suggested is explicitly naming (mobile) >sub-networks. However, I happen to think that it can be "emulated" >well enough with stack or node names and delegation. This is unnecessary. No special considerations are required for naming and addressing to support mobility. Mobility is just dynamic multihoming. > >Note that I didn't say anything about how the various resolutions >are performed in detail, nor where the mapping state is stored, etc. >In some cases that may be implied by the nature of the names; in >other cases I can see quite a lot of freedom and potential choices. > > >Another important issue here is that I don't believe we could fulfil >all the needs for application-level names with just one name space. >There seem to be fundamental conflicts between usability, economic >aspects, and security, that make it impossible. Hence, most >probably we will need different representations for naming the >application-level entities. That also implies that we'll need some >kind of infrastructures (either local or global) for maintaining >mappings between those different representations. But again, that's >another issue. I would tend to agree. But these names should all resolve to the one we are positing here. This will allow accountability. Those are for our purpose for the most part outside the scope of creating and maintaining communication and we can exclude them for now. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 08:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmzT-0000au-21; Sun, 19 Nov 2006 08:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmzR-0000ap-VH for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:45:45 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlmzP-0006RA-Ha for architecture-discuss@ietf.org; Sun, 19 Nov 2006 08:45:45 -0500 Received: from [10.0.1.6] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061119134542b1400s50kje>; Sun, 19 Nov 2006 13:45:42 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <232DC679-50C8-4CCC-84DB-BE4A97975F83@nomadiclab.com> References: <232DC679-50C8-4CCC-84DB-BE4A97975F83@nomadiclab.com> Date: Sun, 19 Nov 2006 08:45:39 -0500 To: Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org For the most part, I agree totally with you. The fundamental problem here as laid out but not pointed out in Saltzer's paper (RFC 1498) is that we have been operating with half an addressing architecture. Second, I would suggest that progress could be made if we were more careful about how use the word "topology" and not use it when we mean "graph." Which I believe you did a couple of times. Take care, John At 15:14 +0200 2006/11/19, Pekka Nikander wrote: >(These are all old thoughts, but perhaps I've got something wrong. >Or perhaps I'm missing something altogether. Besides, it looks like >some people are failing to remember the implication, below.) > >In the note below, I use the term "address" in its routing-related >meaning, i.e., I'm referring to a piece of data that is affixed to a >packet for the purposes of affecting its forwarding through the >network. > > >From an information placement point of view, the current >prefix-encoding hop-by-hop routing architecture can be considered to >be mid-way between pure source routing and pure host-based routing. > >In a pure source routing architecture, the source node encodes each >next hop to the packet. Consequently, the packet contains all >information needed for forwarding. No state at all needed in the >middle boxes; you can hardly even call them routers, as they become >pure forwarders. (I know, such an architecture is unrealistic; I'm >simplifying in trying to make a point.) > >In a pure host-based routing architecture, the addresses have no >structure at all and contain no forwarding information. For >example, they could be random. Each router separately resolves the >address into the next hop, potentially using all bits from the >address. Full network topology and host location information is >needed at each router. Host-based routing is used in MANETs, and >scale badly. The recent SIGCOMM ROFL paper explores some of the >limitations as seen in the light of current technology. >http://project-iris.net/irisbib/papers/flatlabels:sigcomm2006/paper.pdf > >In the current architecture, the addresses encode some network >topology information into the routing prefix, thereby reducing the >amount of information needed to be stored at the routers or >forwarding tables. The closer the prefixes match with the actual >network topology, the bigger savings. From a mathematical point of >view, one could say that the better the topology of the addressing >space can be matched with the topology with of the network, the less >information needs to be stored elsewhere. > > >From here we get into two factors on how addresses do matter to routing: > >1. If there are external forces (such as difficulty of renumbering) >that make it hard to change addresses as needed, it becomes harder >to maintain the match between the addressing topology and the real >network topology. > >2. The way we use the bits in the address to create the topological >addressing space affects the ways we can match the address space >with the network topology. > >I will skip the second issue for now. It is an important one, but >can be studied in relative isolation from the larger architecture. >For example, using other than tree structures to store network >topology information into addresses might be something that might >help with the pressures on the global routing table. However, my >understanding of the graph theory is insufficient so that I could >suggest anything sensible there. > >Considering the first issue, we can isolate a largish number issues >in the overall architecture that make addresses more rigid or more >agile. I won't go into examples; most of us know enough of them. >However, from an economic point of view, I still maintain that the >current APIs are the main issue in the medium, 10-20 years, >perspective. > > >But what I find most important, for the sake of the current >discussions, the implication from above: > >If we can change the overall architecture, either fundamentally or >through some kind of shim-patch hack, so that the applications >become isolated from the addresses used by the routing and >forwarding system, it becomes easier to change the addresses as >needed. That, in turn, makes it easier to make the address space >topology to match with the network topology. > >That's the reason why the overall architectural discussion matters, >even to the current crisis of "the routing system [growing] beyond >what is maintainable." It will not provide any short term remedy >("symptomatic solution"); for that we've now got the separate >mailing list, see: >http://www1.ietf.org/mail-archive/web/architecture-discuss/current/msg00638.html > >But I regard the larger architectural discussion as a necessity to >make any progress with the larger problems, hopefully eventually >reaching a longer-term solution ("fundamental solution"). For that >discussion, we seem to have a plethora of needs or "requirements", >many of which are fuzzy or hard to nail down exactly. Therefore I >find it easier to discuss in terms of concrete architectural >structures, like what I did in my previous message: >http://www1.ietf.org/mail-archive/web/architecture-discuss/current/msg00657.html > >--Pekka Nikander > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 09:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glo57-0007As-Md; Sun, 19 Nov 2006 09:55:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glo55-00079t-MR for architecture-discuss@ietf.org; Sun, 19 Nov 2006 09:55:39 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glo54-000449-6L for architecture-discuss@ietf.org; Sun, 19 Nov 2006 09:55:39 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2006 06:55:33 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAJEtWos010891; Sun, 19 Nov 2006 09:55:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAJEtVDM005974; Sun, 19 Nov 2006 09:55:32 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 09:55:31 -0500 Received: from cisco.com ([10.86.240.237]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 09:55:31 -0500 Date: Sun, 19 Nov 2006 09:54:39 -0500 From: Scott W Brim To: John Day Subject: Re: [arch-d] thoughts Message-ID: <20061119145438.GB2584@sbrim-wxp01> Mail-Followup-To: Scott W Brim , John Day , David Conrad , RJ Atkinson , architecture-discuss@ietf.org References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 19 Nov 2006 14:55:31.0434 (UTC) FILETIME=[C25AECA0:01C70BEA] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: RJ Atkinson , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Excerpts from John Day on Fri, Nov 17, 2006 11:14:50PM -0500: > You keep talking about nodes having more than one identifier. No. > There may be more than one point of attachment (interface) bound to a > node. But the identifiers for the points of attachment and the node > are all distinct. Small issue ... Point of attachment identifiers are distinct from node identifiers as you say, but you should also allow for nodes to have multiple identifiers. I am known as Scott, swb, Honey, Daddy, punk, etc. In the Internet a node could be known by multiple topology-independent names, each unique within its appropriate scope -- all might be globally unique. Honey _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 10:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloE9-0002Gt-Me; Sun, 19 Nov 2006 10:05:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloE8-0002Gk-4W for architecture-discuss@ietf.org; Sun, 19 Nov 2006 10:05:00 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GloE6-0004xB-SK for architecture-discuss@ietf.org; Sun, 19 Nov 2006 10:05:00 -0500 Received: from [10.0.1.6] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20061119150448m1100t7ibbe>; Sun, 19 Nov 2006 15:04:55 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061119145438.GB2584@sbrim-wxp01> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <20061119145438.GB2584@sbrim-wxp01> Date: Sun, 19 Nov 2006 10:04:45 -0500 To: Scott W Brim , John Day From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: RJ Atkinson , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Gee, Honey! ;-) At 9:54 -0500 2006/11/19, Scott W Brim wrote: >Excerpts from John Day on Fri, Nov 17, 2006 11:14:50PM -0500: >> You keep talking about nodes having more than one identifier. No. >> There may be more than one point of attachment (interface) bound to a >> node. But the identifiers for the points of attachment and the node >> are all distinct. > >Small issue ... Point of attachment identifiers are distinct from node >identifiers as you say, but you should also allow for nodes to have >multiple identifiers. I am known as Scott, swb, Honey, Daddy, punk, >etc. In the Internet a node could be known by multiple >topology-independent names, each unique within its appropriate scope >-- all might be globally unique. Not to throw you too large a curve, and to agree with you. I have through a separate analysis come to the conclusion that a layer (not consisting of quite what we thought) is a distributed application that provides IPC (Interprocess Communication). The distributed application is composed of cooperating application processes on separate systems. As applications they have application names. Addresses are identifiers *internal* to this distributed application and used only within it for its internal coordination in order to provide IPC. Application names are external. Addresses are internal. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 10:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloGJ-0003R8-AR; Sun, 19 Nov 2006 10:07:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloGH-0003Qx-GY for architecture-discuss@ietf.org; Sun, 19 Nov 2006 10:07:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GloGG-00056v-4Q for architecture-discuss@ietf.org; Sun, 19 Nov 2006 10:07:13 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2006 16:07:10 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAJF79jY027066; Sun, 19 Nov 2006 16:07:09 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAJF76wv016554; Sun, 19 Nov 2006 16:07:06 +0100 (MET) Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 16:07:06 +0100 Received: from 10.61.65.144 ([10.61.65.144]) by xmb-ams-33b.emea.cisco.com ([144.254.231.86]) with Microsoft Exchange Server HTTP-DAV ; Sun, 19 Nov 2006 15:07:05 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 19 Nov 2006 16:06:55 +0100 Subject: Re: [arch-d] thoughts From: Peter Tomsu To: Scott W Brim , John Day Message-ID: Thread-Topic: [arch-d] thoughts Thread-Index: AccL7FnKmI1x4HffEdusFgAWy5aa4Q== In-Reply-To: <20061119145438.GB2584@sbrim-wxp01> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Nov 2006 15:07:06.0315 (UTC) FILETIME=[608959B0:01C70BEC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1001; t=1163948829; x=1164812829; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ptomsu@cisco.com; z=From:=20Peter=20Tomsu=20 |Subject:=20Re=3A=20[arch-d]=20thoughts |Sender:=20; bh=0t5BTlSpg8r/bJO57lEpCwQcGsESi+noS62Wh1PsAzU=; b=Tnoq99R++ZV2r3hPQ9IV6oc8wlxKMc89M+dUSqO/YutCRXe2t9+FG9IPmM68OKlInOzCPJbv rTFwhxBrx/xiuC/TauFqLBpdUNoLWuKGX3iQvmz+UvBvtsAgnh/sVbyn; Authentication-Results: ams-dkim-2; header.From=ptomsu@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: RJ Atkinson , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I do agree with that ! Peter On 19.11.2006 15:54 Uhr, "Scott W Brim" wrote: > Excerpts from John Day on Fri, Nov 17, 2006 11:14:50PM -0500: >> You keep talking about nodes having more than one identifier. No. >> There may be more than one point of attachment (interface) bound to a >> node. But the identifiers for the points of attachment and the node >> are all distinct. > > Small issue ... Point of attachment identifiers are distinct from node > identifiers as you say, but you should also allow for nodes to have > multiple identifiers. I am known as Scott, swb, Honey, Daddy, punk, > etc. In the Internet a node could be known by multiple > topology-independent names, each unique within its appropriate scope > -- all might be globally unique. > > Honey > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 11:13:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpFR-0000Gm-2g; Sun, 19 Nov 2006 11:10:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpFP-0000GM-Ts for architecture-discuss@ietf.org; Sun, 19 Nov 2006 11:10:23 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlpFO-0002BP-NV for architecture-discuss@ietf.org; Sun, 19 Nov 2006 11:10:23 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 51B2B86ADB; Sun, 19 Nov 2006 11:10:22 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Message-Id: <20061119161022.51B2B86ADB@mercury.lcs.mit.edu> Date: Sun, 19 Nov 2006 11:10:22 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.6 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day > progress could be made if we were more careful about how use the word > "topology" and not use it when we mean "graph." We have fallen, for decades now, into the habit of using the term "topology" to mean "connectivity pattern of network elements". I hesitate to use the word "graph" there, as in "connectivity graph", because a graph is, after all, merely a representation system, and one that doesn't work well in some circumstances, e.g. a radio network. Classical node-and-arc graphs are not well-suited to representing connectivity patterns in such networks. I don't think "topology" is entirely inappropriate terminology. For one, the strict definition of "topology" ("properties of geometric figures or solids that are not changed by homeomorphisms, such as stretching or bending") is kind of apt, because network diagrams - and network routing - usually don't care what the actual physical layout is, rather they only care what is connected to what (which is, after all, basically the definition of the topology of a geometric figure). E.g. the things you are interested in about a particular connectivity pattern remain invariant if you "stretch or bend" a graphical representation projected onto a plane. Also, the topology of some object tells you about its properties, and the "topology" of the network's connectivity pattern similarly tells you things about the network. So, yes, I know it's not the canonical use of the term, but I think it's at least as apt a word as any other non-neologism. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 12:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glq2r-00080g-S3; Sun, 19 Nov 2006 12:01:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glq2o-0007zD-4X for architecture-discuss@ietf.org; Sun, 19 Nov 2006 12:01:26 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlprX-0005R0-4Q for architecture-discuss@ietf.org; Sun, 19 Nov 2006 11:49:48 -0500 Received: from [10.0.1.6] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006111916494601100rfp1le>; Sun, 19 Nov 2006 16:49:46 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061119161022.51B2B86ADB@mercury.lcs.mit.edu> References: <20061119161022.51B2B86ADB@mercury.lcs.mit.edu> Date: Sun, 19 Nov 2006 11:49:40 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 11:10 -0500 2006/11/19, Noel Chiappa wrote: > > From: John Day > > > progress could be made if we were more careful about how use the word > > "topology" and not use it when we mean "graph." > >We have fallen, for decades now, into the habit of using the term "topology" >to mean "connectivity pattern of network elements". > >I hesitate to use the word "graph" there, as in "connectivity graph", because >a graph is, after all, merely a representation system, and one that doesn't >work well in some circumstances, e.g. a radio network. Classical node-and-arc >graphs are not well-suited to representing connectivity patterns in such >networks. > >I don't think "topology" is entirely inappropriate terminology. For one, the >strict definition of "topology" ("properties of geometric figures or solids >that are not changed by homeomorphisms, such as stretching or bending") is The more formal definition states that the topology is the homeomorphism. So my test as to when I use graph or topology is whether or not the thing I am talking about might be construed as a mapping between a set of graphs. If not, then it is a graph. If I could imagine a mapping (and I have a pretty good imagination!), then it is a topology. >kind of apt, because network diagrams - and network routing - usually don't >care what the actual physical layout is, rather they only care what is >connected to what (which is, after all, basically the definition of the >topology of a geometric figure). E.g. the things you are interested in about >a particular connectivity pattern remain invariant if you "stretch or bend" a >graphical representation projected onto a plane. Also, the topology of some >object tells you about its properties, and the "topology" of the network's >connectivity pattern similarly tells you things about the network. Correct. See above. > >So, yes, I know it's not the canonical use of the term, but I think it's at >least as apt a word as any other non-neologism. And there are times I want to use the difference. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 12:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlqtC-0003jG-Qp; Sun, 19 Nov 2006 12:55:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlqtB-0003j6-LE for architecture-discuss@ietf.org; Sun, 19 Nov 2006 12:55:33 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glqt9-0003aS-6k for architecture-discuss@ietf.org; Sun, 19 Nov 2006 12:55:33 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kAJHtSqk029779 for ; Sun, 19 Nov 2006 09:55:28 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kAJHtR7s029776 for ; Sun, 19 Nov 2006 09:55:28 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 19 Nov 2006 09:55:27 -0800 (PST) From: "william(at)elan.net" To: architecture-discuss@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [arch-d] on design of ASN-based BGP routing table X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Before several times (and as part of several proposals) it has been mentioned that we should consider ASN BGP routing table as base and build on top of that. I want to give some thoughts on advantages of this and how it could potentially be implemented without radical routing architecture changes that could come later. First note that even though you may see several ip blocks right now being advertised by same network AS, more often then not the routing policies for those blocks are the same. So imagine that instead of having full routing entry for each block: 10.0.1.0/24 10.0.2.0/24 You would have entry like: 65001 <10.0.1.0/24 10.0.2.0/24> I know it may look like that's almost same space but it actually is not because there is considerable overhead for each BGP entry due to path and other attributes and ip blocks can also be compressed and not require sending entire 64/128bit+mask for each IPv6 entry. There is also potential here to combine both IPv4 and IPv6 into single routing table (which may not be good for some but see below how you can separate routing entries by adding suffix to ASN). Another thing is that some time in the past its been proposed that IPv6 allocations be done by default based on ASN, i.e. there is specific rule that says that say AS65001 gets ip block :: If that is done then we'd not even need to include ip block and just ASN entry would be enough for remote end to know how to reach certain network using BGP. As far as design if somebody needs multiple routing policies for their blocks it could be done so that they add suffix of their choice to make full ASN (yeh, it looks more like ip block then...) i.e.: 65001.1 <10.0.1.0/24> 65001.2 <10.0.2.0/24> The above is basically equivalent to current situation with how you use BGP but this is more rare and if you look at routing entries per ASN, largest number of them have basically same routing policy information. There is also potential for small network that want to be multi-homed but may not be good choice for having its own ASN and ip block to do it so that their blocks are directly listed by multiple ASNs: 65001 <10.0.1.0/24> 65002 <10.0.1.0/24> (the above 10.0.1.0/24 would part of ip block from either 65001 or 65002) The final hop would be some private ASN used between this small network and 65001 & 65002 which does end up in public BGP. I know above is not quite a radical change to architecture as some are suggesting, but I think it can go long way towards managing BGP table growth. And having ASN-based routing also gives advantages for trying different architecture schemes later (for example no public ip blocks at all where DNS would point to ASN and for each IP packet, it would include URL and when delivered to final note it can use that for deciding how to route on local network). -- William Leibzon Elan Networks william@elan.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 14:20:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlsBQ-0008Hg-67; Sun, 19 Nov 2006 14:18:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlsBP-0008HZ-Gq for architecture-discuss@ietf.org; Sun, 19 Nov 2006 14:18:27 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlsBN-0001LD-1d for architecture-discuss@ietf.org; Sun, 19 Nov 2006 14:18:27 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAJJEZrG047129; Sun, 19 Nov 2006 11:14:39 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 19 Nov 2006 11:17:57 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 19 Nov 2006 11:17:57 -0800 In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> From: David Conrad Subject: Re: [arch-d] thoughts Date: Sun, 19 Nov 2006 11:17:51 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org [Sorry for the slow response, life got in the way] Ran, >> Interface (or perhaps more correctly, stack associated with an >> interface). > I'm not entirely clear yet what you mean. When I think of a "stack", > for example on my laptop, that same stack might concurrently be > associated with multiple link interfaces (e.g. 10/100/1000baseT, > 802.11, & 1394). I see a "stack" as a set of instantiations of protocol implementations on top of an interface where an interface has associated with it an identifier (or, in today's world, an address). Within a stack, there are a set of protocol handles that permit communication between the higher and lower level protocols. Ideally, those handles are independent and opaque objects to all but the protocol in which they are defined (unfortunately, the ideal has frequently been violated, among the most egregious of which is applications knowing the format/length of addresses). The reason for the parenthetical "more correctly" is pragmatically, an interface is pretty pointless without a stack on top of it. > For a conventional system, I'm comfortable with "node" meaning > roughly the same thing as "stack". I would've thought a node was something that had zero or more interfaces, that is, I see a node as a terminal point of 0 or more links. >> Could you explain a bit more about the way you're viewing getting >> from an identifier to a set of locators? > Yes, but first please explain how would one end up with an Identifier > in hand without also happening to have a Locator for that node ? I think it critical to decouple identifiers and locators, although I'm not that religious about "once a locator, always a locator". An identifier can be configured in a variety of fashions, from statically assigned to DHCP to stateless auto-configuration. You discover those identifiers in the traditional fashion, e.g., by translating a name (fqdn) via the DNS or via something like Apple's Bonjour. In my model, the binding between an identifier and locator is done externally to the 'node'. > If one knows the FQDN of a node, then one could find both Locator(s) > and Identifier(s) from DNS records using forward resolution. I'm still a bit unclear as to how this would work, but if I understand correctly, we're suggesting similar things, just a different approach to establishing the binding between the identifier and the locator. (That is, delving into (a possible) implementation just to make sure I understand, your model has something like: # name rrtype rdata node.fqdn. IN ID A000::0001 ... IN LOCATOR B000::0001 ... ... where I have: node.fqdn IN AAAA A000::0001 1.0.0...0.0.A.ip6.arpa IN LOCATOR B000:0001 ... (all of which can be DNSSEC signed) If I'm close to what you are thinking, how would the identifier be associated with the locator as the packet traverses the stack?) >> Just to be clear, your model requires modification to all nodes >> (that is, there is a layer inserted between the identifier and >> locator that does the DNS lookup)? > I am talking architecturally, not about implementation. My apologies: I tend to drop down to implementation to make sure I understand the theory. > It isn't obvious to me that the layering would have to vary from now. > > Oh, and I think this architectural change could be done without > modifying any existing routing protocols or forwarding engines. I must not understand. I would be very interested in understanding how these would be the case. > "Translation" covers a lot of possible meanings. I'm not sure > which you mean. Translation of identifier to locator and back to identifier. > Hmm. My concept is that if one were multi-homed to different > providers, > then one would necessarily have more than one Locator (at least one > Locator per provider) and each Locator would be present concurrently > in the DNS. Yes. > If a service provider went away (e.g. backhoe), then one would update > one's DNS to remove the associated Locator(s). Right. One of the possibilities in my model is that if a transit router discovers there has been backhoe fade of the destination locator, that router has the option of popping off the topmost encapsulation, doing a lookup of the destination identifier at the next layer, getting back (potentially) alternate locators and forwarding the packet on. Of course, this won't work if there is security protecting the top-most encapsulation layer, and it may be questionable that transit routers would have the cycles/interest to do this, but the capability is there. Note that something like this capability would be necessary to emulate multi-homed PI space. > Which provider gets used for outbound traffic would be the originating > node's choice in the first instance, This gets a bit into implementation, but in my model, I assume the destination node has the ability to specify advisory preferences (e.g., a priority value in the rdata associated with each locator associated with an identifier). The originating edge device SHOULD use that preference information for choosing the locator, but does not have to. > As you say, mobility and multi-homing are really the same case > if one gets the architecture right, though I don't know that the > old access network would necessarily have to forward packets. In my model, it depends on how the mapping information between identifier and locator can be propagated fast enough. I assume something like DNS TTLs, so when a transition between access networks occur, data in caches will need to expire. During that expiration period, the old access network will need to forward to the new access network or the packets will get dropped on the floor. Obviously, if you can pre-establish the new access network while traffic is still going to the old access network, you don't need the forwarding but I don't think that's something that can be guaranteed. > The architecture I'm proposing would not require any changes to > forwarding processes or routing protocols, nor to ARP/ND. It > would change TCP/UDP by altering the pseudo-header checksum > to include only Identifiers, never Locators. Which, of course, implies a change to all end point network stacks deployed to date. > How would your system work in the case where the packet emitted > from the origin node used both AH and ESP -- that is, the payload > is opaque and (nearly) all of the header fields are authenticated > (hence immutable) ?? Is this where the tunnelling comes in ? Yep. The end-to-end connectivity is completely unmolested and the "identity-dependent layer" is completely ignorant of the "location- dependent layer". >> An application does a DNS lookup to translate a fqdn to an >> identifier. > One can get the Locator from DNS in the same transaction, right ? Not in my model, as the identifier and locator are completely decoupled. The application doing the DNS lookup would not fetch anything related to the locator. The edge device takes the identifier and does the lookup to establish the locator. >> The network stack translates the identifier into a locator. > FQDN->Locator mapping is not necessarily in the network stack. > (I'm not talking about implementation here. :-) Right. >> At the other end, how does the network stack unambiguously >> translate the locator back into the correct identifier? > > There are several options. > > One possible alternative is to carry Source Identifier, Destination > Identifier, Source Locator, and Destination Locator in each packet. This is, of course, what you get when you tunnel. > There will need to be some centralised allocation authority if > one wants absolutely globally unique identifiers. > > If that authority involves humans, there is a good chance of an > accident at some point where a few identifiers would be duplicated. > So I'd rather not require an absolutely globally unique identifier. In my model, since I assume something like ip6.arpa, lack of global uniqueness would be discovered quite quickly (given an attempt to update the appropriate identifer to locator mapping would not be possible unless you owned the signing key for that mapping). > I want to always ensure that Locators are never Identifiers, > and vice versa. Overloaded semantics is how we got into this > mess. I really want to avoid overloaded semantics. Ideally, yes. Pragmatically speaking... Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 14:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlslN-0003C2-Hv; Sun, 19 Nov 2006 14:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlslM-0003Bx-2L for architecture-discuss@ietf.org; Sun, 19 Nov 2006 14:55:36 -0500 Received: from eastrmmtao01.cox.net ([68.230.240.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlslJ-00078p-Gk for architecture-discuss@ietf.org; Sun, 19 Nov 2006 14:55:34 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061119195530.EYS18146.eastrmmtao01.cox.net@eastrmimpo01.cox.net>; Sun, 19 Nov 2006 14:55:30 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id ojug1V00K0pnMhQ0000000; Sun, 19 Nov 2006 14:54:40 -0500 In-Reply-To: <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Sun, 19 Nov 2006 14:55:23 -0500 To: David Conrad X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 19 Nov 2006, at 14:17, David Conrad wrote: > I see a "stack" as a set of instantiations of protocol > implementations on top of an interface where an interface has > associated with it an identifier (or, in today's world, an address). In the IP Internet, I think of an interface as having at least two different identifiers (little "i"), used for different purposes: - Link address (e.g. 802 MAC) - IP address (IPv4 or IPv6) > Within a stack, there are a set of protocol handles that permit > communication between the higher and lower level protocols. > Ideally, those handles are independent and opaque objects to all > but the protocol in which they are defined (unfortunately, the > ideal has frequently been violated, among the most egregious of > which is applications knowing the format/length of addresses). To the extent I'm understanding, I think I agree (definitely about the inappropriateness of ordinary applications knowing about network layer names). >> For a conventional system, I'm comfortable with "node" meaning >> roughly the same thing as "stack". > > I would've thought a node was something that had zero or more > interfaces, that is, I see a node as a terminal point of 0 or more > links. I view a node as having at least one interface. A node with no links and no interfaces is somewhat outside the concept boundary of a network architecture, IMHO. >>> Could you explain a bit more about the way you're viewing getting >>> from an identifier to a set of locators? >> Yes, but first please explain how would one end up with an Identifier >> in hand without also happening to have a Locator for that node ? > > I think it critical to decouple identifiers and locators, > although I'm not that religious about "once a locator, always a > locator". I am not keen on overloaded semantics. This is my big issue with MIPv6/SHIM6. Each of those overloads the semantics of an IPv6 address, so that sometimes it is used a Locator and other times it is used as an Identifier (big "I"). Based on the experience with overloaded semantics that we have to live with, I'd prefer an architecture that eliminated or minimised such overloaded semantics. > An identifier can be configured in a variety of fashions, from > statically assigned to DHCP to stateless auto-configuration. I think that in order for an Identifier (big "I") to remain constant across a location change, the Identifier ought not be assigned dynamically (e.g. DHCP). I have no issues with a Locator being assigned dynamically (e.g. via Router Advertisement messages). > You discover those identifiers in the traditional fashion, > e.g., by translating a name (fqdn) via the DNS or via something > like Apple's Bonjour. That's fine with me. (Aside: BonJour (TM) appears to mostly be IETF ZeroConf.) > In my model, the binding between an identifier and locator is done > externally to the 'node'. I don't understand what you mean by the above. >> If one knows the FQDN of a node, then one could find both Locator(s) >> and Identifier(s) from DNS records using forward resolution. > > I'm still a bit unclear as to how this would work, but if I > understand correctly, we're suggesting similar things, just a > different approach to establishing the binding between the > identifier and the locator. > > (That is, delving into (a possible) implementation just to make > sure I understand, your model has something like: > > # name rrtype rdata > node.fqdn. IN ID A000::0001 ... > IN LOCATOR B000::0001 ... > ... > > where I have: > > node.fqdn IN AAAA A000::0001 > > 1.0.0...0.0.A.ip6.arpa IN LOCATOR B000:0001 ... > > (all of which can be DNSSEC signed) That's reasonably close, though I'm open about the engineering. > If I'm close to what you are thinking, how would the identifier be > associated with the locator as the packet traverses the stack?) The network-layer would be aware of both Identifier and Locator. Only the Locator would be used for forwarding/routing packets. The transport-layer would only be aware of the Identifier -- no location information (neither address nor Locator) would be in any transport-layer state. I probably would include both Identifier and Locator in each packet. >> It isn't obvious to me that the layering would have to vary from now. >> >> Oh, and I think this architectural change could be done without >> modifying any existing routing protocols or forwarding engines. > > I must not understand. I would be very interested in understanding > how these would be the case. If one takes IPv4, purely as an example, and ignores implementation consequences, then one could redefine the IPv4 address to be a Locator and carry an Identifier (some or all of the time) in something like an IP option. Note that I am *not* advocating this particular engineering approach -- I'm focused on architecture, not engineering -- but you asked for an example. (Existing routers can forward such packets, perhaps slow-path but none the less without change, and existing routing protocols don't need any modifications.) A nice feature of not modifying the routers/forwarding process is that one probably could have incremental deployment. In a trivial example, and I don't suggest this is the right engineering approach, packets with the new IP option would use a different pseudo-header calculation than packets without that new IP option. I emphasise that I'm giving trivial examples to explain the concepts. If/when there were agreement on the right architecture, then one could get down to doing engineering. At that point, depending on whether one wanted to be backwards compatible with something, or not, there would be a range of engineering options that could be contemplated. >> "Translation" covers a lot of possible meanings. I'm not sure >> which you mean. > > Translation of identifier to locator and back to identifier. I think it matters which object is doing the translation, under which circumstances, and for what purpose. Nodes sharing a session might do some translation back and forth internally. External nodes initiating a session would use DNS to make forward lookups to find Identifier and Locator from a FQDN (or via ZeroConf or some other TBD mechanism). >> If a service provider went away (e.g. backhoe), then one would update >> one's DNS to remove the associated Locator(s). > > Right. One of the possibilities in my model is that if a transit > router discovers there has been backhoe fade of the destination > locator, that router has the option of popping off the topmost > encapsulation, doing a lookup of the destination identifier at the > next layer, getting back (potentially) alternate locators and > forwarding the packet on. Of course, this won't work if there is > security protecting the top-most encapsulation layer, and it may be > questionable that transit routers would have the cycles/interest to > do this, but the capability is there. Because Locators are not covered by AH/ESP in my model, and are not included in any state above the network layer, Locators would be mutable, at least conceptually. I'm neither requiring nor prohibiting routers from modifying Locators, just ensuring that the session won't necessarily break due to Locator modification during transit (e.g. because of a NAT/NAPT/other middlebox). Support for PI unicast addressing is not a goal in my concept, nor is it particularly valuable to have, unlike today, because of the native support for mobility and multi-homing. >> As you say, mobility and multi-homing are really the same case >> if one gets the architecture right, though I don't know that the >> old access network would necessarily have to forward packets. > > In my model, it depends on how the mapping information between > identifier and locator can be propagated fast enough. I assume > something like DNS TTLs, so when a transition between access > networks occur, data in caches will need to expire. During that > expiration period, the old access network will need to forward to > the new access network or the packets will get dropped on the > floor. Obviously, if you can pre-establish the new access network > while traffic is still going to the old access network, you don't > need the forwarding but I don't think that's something that can be > guaranteed. Shorter TTLS for the Locator records, to a TTL value appropriate for the frequency of layer-3 location changes, probably would obviate the need for such special-case forwarding. Also, small amounts of packet loss happen today, regardless of mobility handoff. This is a datagram network, there aren't guarantees about packets being delivered, though we don't want to gratuitously drop packets that reasonably can be avoided. >> The architecture I'm proposing would not require any changes to >> forwarding processes or routing protocols, nor to ARP/ND. It >> would change TCP/UDP by altering the pseudo-header checksum >> to include only Identifiers, never Locators. > > Which, of course, implies a change to all end point network stacks > deployed to date. Yes, but only to stacks that want to use the new architecture. I think a dual-stack (triple-stack ??) approach is possible so that migration can occur slowly and incrementally (i.e. without necessarily requiring application changes). >>> An application does a DNS lookup to translate a fqdn to an >>> identifier. >> One can get the Locator from DNS in the same transaction, right ? > > Not in my model, as the identifier and locator are completely > decoupled. The application doing the DNS lookup would not fetch > anything related to the locator. The edge device takes the > identifier and does the lookup to establish the locator. That seems to be a difference. Conceptually, how would the edge device do that sort of lookup ? Some sort of other directory service ? >>> At the other end, how does the network stack unambiguously >>> translate the locator back into the correct identifier? >> >> There are several options. >> >> One possible alternative is to carry Source Identifier, Destination >> Identifier, Source Locator, and Destination Locator in each packet. > > This is, of course, what you get when you tunnel. Albeit with overloaded semantics -- outer IP address as Locator, inner IP address as Identifier. I'm not a fan of overloaded semantics. I'd also like to avoid mandatory tunnelling. So there are some other conceptual differences. >> There will need to be some centralised allocation authority if >> one wants absolutely globally unique identifiers. >> >> If that authority involves humans, there is a good chance of an >> accident at some point where a few identifiers would be duplicated. >> So I'd rather not require an absolutely globally unique identifier. > > In my model, since I assume something like ip6.arpa, lack of global > uniqueness would be discovered quite quickly (given an attempt to > update the appropriate identifer to locator mapping would not be > possible unless you owned the signing key for that mapping). OK, so this implies a pretty strong dependence on DNS and DNSsec deployment and maybe also a strong dependence on being able to somehow sign delegations from RIRs. Cheers, Ran rja@extremenetworks.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 15:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glsvz-0007XA-Hp; Sun, 19 Nov 2006 15:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glsvy-0007X4-MN for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:06:35 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glsvw-0000jM-8m for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:06:34 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAJK37rG047201; Sun, 19 Nov 2006 12:03:07 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 19 Nov 2006 12:06:25 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 19 Nov 2006 12:06:25 -0800 In-Reply-To: <20061118015317.5211C87307@mercury.lcs.mit.edu> References: <20061118015317.5211C87307@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [arch-d] thoughts Date: Sun, 19 Nov 2006 12:06:24 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, On Nov 17, 2006, at 5:53 PM, Noel Chiappa wrote: >>> "end point" means a stack, a node, an interface, or something else ? >> Interface (or perhaps more correctly, stack associated with an >> interface). > Well, there's a source of potential confusion, because to a lot of > people, > "endpoint" means about what "stack" seemingly does - i.e. an entity > involved > in end-end communication (e.g. the "thing" at one end of a reliable > transport > connection, which manages the state associated with that connection). Right. From my perspective, an interface is a piece of (potentially virtual) hardware. A stack associated with an interface turns that interface into an "end point" (at each layer in the stack). > I'd also like to point out that "stack associated with an > interface" is > really just "[end-end identity] associated with [a network > location]" - which > is what got us in trouble in the first place. I don't really see it this way. I view a stack as a set of protocol implementations, each one of which has a set of 'handles' that allow for communication upwards and downwards in the stack. Where we got into trouble is that because one 'handle' was used to name multiple points in the stack, we overloaded multiple semantics onto those handles. But maybe that's saying the same thing. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 15:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glsxu-000889-LK; Sun, 19 Nov 2006 15:08:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glsxt-000883-L1 for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:08:33 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glsxs-0001Fi-8r for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:08:33 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAJK4wrG047205; Sun, 19 Nov 2006 12:05:03 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 19 Nov 2006 12:08:21 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 19 Nov 2006 12:08:21 -0800 In-Reply-To: References: <20061118015317.5211C87307@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8A1D9FCF-E08B-4D0E-A891-83D368AC5D8F@virtualized.org> From: David Conrad Subject: Re: [arch-d] thoughts Date: Sun, 19 Nov 2006 12:08:15 -0800 To: John Day X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, On Nov 17, 2006, at 6:14 PM, John Day wrote: > One can not assume a 1:1 relation between interfaces and stacks. Right. That's why I said "instantiations". I'm aware that the relationship can be 1 to many, many to one, etc. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 15:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glsza-0000Fr-G9; Sun, 19 Nov 2006 15:10:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlszZ-0000FB-50 for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:10:17 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlszW-0001U4-MS for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:10:17 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAJK6jrG047216; Sun, 19 Nov 2006 12:06:46 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 19 Nov 2006 12:10:04 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 19 Nov 2006 12:10:04 -0800 In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8733365E-4A94-4C10-89B5-C37B291E4906@virtualized.org> From: David Conrad Subject: Re: [arch-d] thoughts Date: Sun, 19 Nov 2006 12:10:02 -0800 To: John Day X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, On Nov 17, 2006, at 7:07 PM, John Day wrote: > In reading the conversation between the three of you, I get the > sense that you are still trying to solve the current engineering > problem. This is one of the better abstract discussions I have seen > on this list, but I don't think you have really boiled it down to > its barest elements. There is still too much flesh on the bones. I suspect this is my fault since, as I said in a different note, I tend to drop down to implementation scenarios to insure I understand what is being discussed and that it makes sense. A fatal character flaw, I know... Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Nov 19 15:41:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltS7-0002M2-Kd; Sun, 19 Nov 2006 15:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltS6-0002JF-An for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:39:46 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GltS0-0006Py-Ut for architecture-discuss@ietf.org; Sun, 19 Nov 2006 15:39:42 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAJKZtrG047266; Sun, 19 Nov 2006 12:35:56 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 19 Nov 2006 12:39:14 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 19 Nov 2006 12:39:14 -0800 In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> From: David Conrad Subject: Re: [arch-d] thoughts Date: Sun, 19 Nov 2006 12:39:12 -0800 To: John Day X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, On Nov 17, 2006, at 8:14 PM, John Day wrote: > You need a logical and physical address spaces under the > application name space. Agreed. By analogy, I am suggesting the identifier space is the virtual address that is mapped into the locator space which is the physical address space. One might argue that the logical address space should be the fqdn, and in an ideal world, I might agree. However, pragmatically speaking, that won't fly as long as there are applications and protocol stacks that _know_ an "address" is 32 or 128 bits and that certain bit patterns have special meanings. > The point of attachment id does not have to be global. No, but the mapping between the id and the locator must be globally unique. It is possible to come up with a variety of mechanisms to ensure that global uniqueness, but since the amount of name space isn't an issue, it just seems simpler to require both id and locator be globally unique and avoid the question completely. > So quit trying to build solutions that make it work. They will > always be kludges. Well, yes. However, it is hard to boil the ocean. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 04:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5GY-0005ZI-S5; Mon, 20 Nov 2006 04:16:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5GX-0005Z5-Ab for architecture-discuss@ietf.org; Mon, 20 Nov 2006 04:16:37 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm5GV-00006B-Rh for architecture-discuss@ietf.org; Mon, 20 Nov 2006 04:16:37 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5BBB7213027; Mon, 20 Nov 2006 11:16:14 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id F1686212FF6; Mon, 20 Nov 2006 11:16:13 +0200 (EET) In-Reply-To: <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41E83450-2C92-4971-9E16-A3063F2CECC6@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] thoughts Date: Mon, 20 Nov 2006 11:16:16 +0200 To: David Conrad X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org A couple of details: On Nov 19, 2006, at 22:39, David Conrad wrote: > One might argue that the logical address space should be the fqdn, > and in an ideal world, I might agree. There are lots of problems with FQDNs. Consequently, there is a lot of pressure to gradually get rid of the FQDNs in the application space, and to replace them with something better. Unfortunately, my knowledge of the efforts in the application space are very limited, but my understanding is that some of the the CRISP/IRIS effort aims to experiment in an alternative space. This is related to my other note, where I mentioned that due to conflicting needs we are unlikely to be able to use just one application-level name space. In particular, security, privacy, and usability requirements seem to form here such conflicting goals that it seems likely that we'll need at least two types name of names spaces: user friendly ones (which may be non-global), and a secure one. The latter is unlikely to be user-unfriendly due to they probably being cryptographic. >> The point of attachment id does not have to be global. > > No, but the mapping between the id and the locator must be globally > unique. Strictly speaking, maybe no. It may be feasible to live with a limited amount of unintended multicasting. That is, there may be benefits from allowing a very limited amount of "unicast" packets to be sent to a few hosts instead of to a single one. For example, it may turn out such limited amounts of limited multicasting may result if we decide to use statistically unique identifiers. That is, if the identifiers in question are only statistically unique, then in some rare cases the same identifier may be used, simultaneously, at two or more different locations in the network. Consequently, most probably the network should be engineered so that it will deliver data to all of the locations. The stacks/nodes at the locations can then filter out those packets that are not really intended to them, based on upper-layer information. The question is basically an economic one: the flexibility benefits from allowing rare conflicts may be larger than the performance penalty. For example, the cost of ensuring 100% global uniqueness may turn out to be so high that we just don't want to pay it. [A side issue here is that statistical uniqueness opens up a possibility for "interesting" traffic amplification, eavesdropping, etc attacks. However, I don't see any real obstacles there; at least the most obvious vulnerabilities seem to be mitigable.] --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 04:48:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5kN-0008WK-5h; Mon, 20 Nov 2006 04:47:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5kM-0008WC-EE for architecture-discuss@ietf.org; Mon, 20 Nov 2006 04:47:26 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gm5kK-00077n-Lw for architecture-discuss@ietf.org; Mon, 20 Nov 2006 04:47:26 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id ED1E0213027; Mon, 20 Nov 2006 11:47:22 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1E6B0212FF6; Mon, 20 Nov 2006 11:47:22 +0200 (EET) In-Reply-To: References: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24FD43BD-207B-44D9-9F73-4C19EC6AF649@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Date: Mon, 20 Nov 2006 11:47:25 +0200 To: John Day X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, One question, one plea for pointers to insight, and one issue where =20 our thinking seems to differ: On Nov 19, 2006, at 15:36, John Day wrote: > This is where John Shoch's paper gets to. This one? Shoch, J. F.; Hupp, J. A. The "Worm" programs - early experience with =20= a distributed computation (reprint of a 1980 paper). In Milojicic, =20 D.; Douglis, F.; Wheeler, R., editors. Mobility: Processes, Computers =20= and Agents. NY: ACM; 1999; 19-27 --- > I will go back to my earlier characterization: Names are needed =20 > for all loci of shared state with different scope. Hmm. Is a corollary of that that names are needed at all loci where =20 demultiplexing must be performed based on data received from the =20 network, in order to find the right piece of shared state? What remains somewhat obscure to me is the relationship of this to =20 security and signalling efficiency. Insight here would help =20 tremendously, I think. Any papers on this? --- Now, let's dwell a little bit on mobility. We seem to see the =20 situation slightly differently. Or, alternatively, I was just =20 unclear in my writing. >> 4. A node or stack name (c) merely aggregates a number of flow =20 >> names (b) for the primary purpose of node-level mobility. =20 >> However, the node or stack name also allows easier implementation =20 >> of baseline security and privacy, can make systems administration =20 >> easier, etc. > > There is a problem here. What I would call the node address is =20 > what you are calling the routing level name. What you are calling =20 > the node name I would see as additional structure on the =20 > application naming scheme. To use your nomenclature then, > > As I argued before, this is an application aggregation name. It =20 > belongs in the application layer. There are cases where this kind =20 > of aggregation is not desirable and others are, So this would get =20 > in the way. Some may argue that a large number of instances today =20 > are of this sort and that may be. But we have no idea if that will =20= > continue to be the case and end up being in the way later. If we =20 > make it part of the application layer then we can use when and if =20 > we need to and not if we don't. We don't need to force this =20 > inflexibility here. ... >> A useful exercise (left for the reader to keep this message =20 >> manageable) is to consider the _exact_ benefits and drawbacks =20 >> caused by each of the proposed layers of indirection. The =20 >> relevant corollary is to consider if (a)-(d) is the right choice =20 >> of lesser names, or if there would be better ones. One that is =20 >> missing but has been repeatedly suggested is explicitly naming =20 >> (mobile) sub-networks. However, I happen to think that it can be =20 >> "emulated" well enough with stack or node names and delegation. > > This is unnecessary. No special considerations are required for =20 > naming and addressing to support mobility. Mobility is just dynamic =20= > multihoming. While I completely agree with mobility being dynamic multi-homing =20 from an architectural point of view, there are practical differences =20 that lead, via engineering considerations, to small but apparently =20 necessary differences at the architecture, once we get down one level =20= of details. That is, while at the uppermost structural level we can =20 and should unify mobility and multi-homing, once we start go consider =20= the network dynamics in terms of signalling efficiency, propagation =20 delays, and state synchronisation, there seems to emerge some =20 differences. Now, I sincerely hope to be wrong here, since if I am =20 wrong, I could further simplify my thinking. But unfortunately I'm =20 afraid that I happen to be right. So sad :-) But we'll see. Let me first consider node names. While I can agree with your point =20 that node names can be considered as merely application aggregation =20 names, I don't quite understand why should aggregation would not be =20 desirable. Such aggregation should be dynamic, anyway. That is, the =20= mapping from an application-level name to a node name should always =20 be a dynamic one, internal to the stack, and modifiable in the case =20 that the application instance needs to be moved to another node. However, if I look at node names from the mobility point of view, I =20 would imagine node mobility to be by-and-far the most common case. =20 In my imagination, nearly all of the end-nodes in the future internet =20= will be mobile. While most of the mobility will most probably be =20 hidden from the routing/forwarding layer, I still imagine that there =20 will be huge amount of mobility / dynamic multi-homing events taking =20 place, by-far the largest majority of these taking place at the level =20= of "nodes", or small "subnets" (stable collections of nodes). Now, from an architectural point of view I don't see any real =20 difference between a number of applications, with active flows, =20 running within a mobile node and a number of mobile nodes moving =20 together within a mobile subnet. In both cases we have aggregate =20 mobility or dynamic multi-homing, basically meaning that all the apps/=20= flows within the mobility domain show the same mobility behaviour. In order to be able to handle the large amount of signalling =20 resulting from handing this dynamic behaviour, it seems beneficial of =20= making these "node/stack/end-point" names explicit. Sure, from an =20 architectural point of view they are just dynamic aggregations of =20 applications and associated active flo=05ws. Explicit names just make =20= it easier to inform the rest of the system about a dynamic change in =20 the mapping from application names to location names. Additionally, =20 they ease system administration since the node names are something =20 that matches nicely with the cognitive models of system admins. So, as far as I can see, I am not advocating any inflexibility here. =20= I am just trying to identify another class of beneficial "lesser" =20 names. Nodes/stacks/hosts/end-points seem to be entities that =20 benefit from being explicitly named, even though from an overall =20 architectural point of view they can and probably should be =20 considered merely as dynamic aggregations of applications. --Pekka Nikander PS. BTW, I understood this point of view only fairly recently, maybe =20= a year ago. Until that I always considered node/stack/host/end-point =20= names as primary ones, application-layer names somehow being either =20 completely independent or "lesser". Fool me. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 09:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9qd-0005QU-8V; Mon, 20 Nov 2006 09:10:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9qc-0005QG-8q for architecture-discuss@ietf.org; Mon, 20 Nov 2006 09:10:10 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gm9qZ-0004FM-OB for architecture-discuss@ietf.org; Mon, 20 Nov 2006 09:10:10 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAKE9E2M030291; Mon, 20 Nov 2006 16:09:57 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 16:08:00 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 16:07:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] thoughts Date: Mon, 20 Nov 2006 16:07:58 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] thoughts Thread-Index: AccMFRZ8eBeSAI2dRLW5Xu8G9xS2pAAlIkVA From: To: , X-OriginalArrivalTime: 20 Nov 2006 14:07:59.0867 (UTC) FILETIME=[491A14B0:01C70CAD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org RJ Atkinson [mailto:rja@extremenetworks.com] wrote: >I am not keen on overloaded semantics. This is my big issue=20 >with MIPv6/SHIM6. Each of those overloads the semantics of an=20 >IPv6 address, so that sometimes it is used a Locator and other=20 >times it is used as an Identifier (big "I"). > Thus it would be beneficial to allocate part of the reserved IPv6 address space (with some of the first couple of bits) for the ID usage. This way they would be unambiguous. Have sufficient number of bits in an "ID prefix" to enable scalable reverse lookup (might be useful), and most (e.g. at least 100) bits for the "random" ID part (more bits for higher security). Jarno _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 09:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmA9n-00080h-Du; Mon, 20 Nov 2006 09:29:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmA9m-00080b-2E for architecture-discuss@ietf.org; Mon, 20 Nov 2006 09:29:58 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmA9k-0002Sp-Jq for architecture-discuss@ietf.org; Mon, 20 Nov 2006 09:29:58 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 174C2213030; Mon, 20 Nov 2006 16:29:55 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B53CF212DBA; Mon, 20 Nov 2006 16:29:54 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] thoughts Date: Mon, 20 Nov 2006 16:29:59 +0200 To: X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rja@extremenetworks.com, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >> I am not keen on overloaded semantics. This is my big issue >> with MIPv6/SHIM6. Each of those overloads the semantics of an >> IPv6 address, so that sometimes it is used a Locator and other >> times it is used as an Identifier (big "I"). >> > > Thus it would be beneficial to allocate part of the reserved IPv6 > address space (with some of the first couple of bits) for the ID > usage. > This way they would be unambiguous. Have sufficient number of bits > in an > "ID prefix" to enable scalable reverse lookup (might be useful), and > most (e.g. at least 100) bits for the "random" ID part (more bits for > higher security). Do you mean http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt https://datatracker.ietf.org/public/idindex.cgi? command=id_detail&id=13628 Currently in an extended IETF Last Call for 4 weeks, on its last week. Some apps folks have voiced their concerns, but most people seem to be supportive for such an experiment. Or do you have something else in your mind? --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 09:47:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAPi-0006cL-Mh; Mon, 20 Nov 2006 09:46:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAPh-0006cB-R1 for architecture-discuss@ietf.org; Mon, 20 Nov 2006 09:46:25 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAPf-0004RU-Kt for architecture-discuss@ietf.org; Mon, 20 Nov 2006 09:46:25 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 43F63872D4; Mon, 20 Nov 2006 09:46:23 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Message-Id: <20061120144623.43F63872D4@mercury.lcs.mit.edu> Date: Mon, 20 Nov 2006 09:46:23 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Pekka Nikander > On Nov 19, 2006, at 15:36, John Day wrote: >> This is where John Shoch's paper gets to. > This one? > Shoch, J. F.; Hupp, J. A. The "Worm" programs - early experience with > a distributed computation No, he almost certainly meant IEN-19, "Inter-Network Naming, Addressing, and Routing". I believe the IEN repository at ISI has this one now. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 10:14:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmApf-0003S8-0A; Mon, 20 Nov 2006 10:13:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmApe-0003Ry-Le for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:13:14 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmApd-0006Pd-BX for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:13:14 -0500 Received: from [71.254.21.62] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GmApc-0001Ul-Kt for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:13:13 -0500 Message-Id: <7.0.1.0.0.20061120094548.034291a8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 20 Nov 2006 10:09:41 -0500 To: architecture-discuss@ietf.org From: "Joel M. Halpern" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711206fa72f94d6af898275b624cd09fdde3b8a4b8a4ee4b2abb2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.21.62 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [arch-d] Whose job is it, anyway? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org In watching the discussion of things to be named and how they are named, I think there are a number of unstated assumptions people are making. I think some are agreed. Some are subtle enough that I am only going to allude to them. But some I think can be usefully surfaced and discussed on their merits. For this purpose, I will take certain things as given. 1) There ought to be identifiers for certain objects in the system which are independent of the location of those objects. Application instances need to have such identifiers. 2) There are (and ought to be) identifiers which are location dependent. subnets (and interfaces to subnets) ought to be identified based on their placement in the network graph. 3) It is expected that in most of the net, packet forwarding will be based on location dependent identifiers (locators.) Note, point 3 does not deal with whether that is a single identifier, a cascade or nested set of identifiers, different locators for local and global use, or any of the many other variations in forwarding paradigms. It is just saying that forwarding is working in terms of location sensitive identifiers. I have seen some research work where that is not the case.] I will use "locator" for an identifier which is location dependent. (Lots of folks use that, but I don't think we have yet settled on it.) If we take that as given, and we assume that applications normally operate in terms of location, then there are a couple of interesting tasks for the collective system, and a couple of operations relating to those tasks. The tasks are: a) coping with multi-pathing b) coping with multi-homing c) coping with mobility Folks have sometimes treated various of these as interchangeably solved by the id / locator split. While that separation of notions helps us, it does not "solve" these issues. It does not even necessitate that these issues be solved in the same place. Functionally, one can talk about the functions of i) determining the locator(s) that go with a location independent identifier ii) selecting a locator to use for communication iii) route determination forwarding packets based on that selected locator (ii) is sometimes treated as a non-issue, if one assumes that there is only one such locator. (ii) is also sometimes assumed to go in specific places. Looking at the tasks above, multi-path is the problem (opportunity) of dealing with the fact that there are multiple paths to a location across the network. We assume (correctly I believe) that coping with this is the job of the routing / packet forwarding functions. On the other end, mobility seems to imply the changing of the locator(s) associated with a location independent identifier. Hence, it seems to me that wherever it lives it is not part of the routing / packet forwarding system. Yes, this re-mapping is helped by the separation of identifiers. Yes, there can be functions required of packet handling systems that can help this. But routing isn't going to tell you about it, and packet forwarding based on locators isn't going to cope with it. The middle task raises, coping with multi-homing, some interesting questions. And I think we have been mixing the answers. If one assumes that one can have a singular, meaningful, location dependent identifier for a (multi-connected) node then one might well expect to use that identifier in packets, and expect the routing / packet forwarding system to cope with it. If on the other hand, the location dependent identifiers are associated with subnets / interfaces, then it is hard to see how locator based forwarding can cope with this. Rather, it would seem to be the locator selection function which has to cope with it. The question I am wondering about is, assuming for the moment that it can be made to work either way, does coping with multi-homing conceptually belong with one or the other of multi-pathing and mobility? (We may have to put it somewhere it does not belong for pragmatic reasons, but it seems useful to know if that is what we are doing.) Yours, Joel M. Halpern PS: I am deliberately being vague about where the locator selection function is being done, and whether it is colocated with the locator determination. Whether it looks like shim6, GSE, or something, and whether it is done in the host or in an edge does not, I think, affect the question here. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 10:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB4M-000495-ML; Mon, 20 Nov 2006 10:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB4L-000490-0z for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:28:25 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmB4I-0007oU-MX for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:28:25 -0500 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 74316C26E for ; Mon, 20 Nov 2006 10:28:19 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kAKFSI6v027766; Mon, 20 Nov 2006 10:28:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kAKFSI67007473; Mon, 20 Nov 2006 10:28:18 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id u4OxVEgdDOCf; Mon, 20 Nov 2006 10:28:17 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kAKFSEYS007453;Mon, 20 Nov 2006 10:28:14 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 4AE794FD9F; Mon, 20 Nov 2006 10:27:10 -0500 (EST) Date: Mon, 20 Nov 2006 10:27:10 -0500 From: Wesley Eddy To: Noel Chiappa Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Message-ID: <20061120152710.GA27266@grc.nasa.gov> References: <20061120144623.43F63872D4@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061120144623.43F63872D4@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.044 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, Nov 20, 2006 at 09:46:23AM -0500, Noel Chiappa wrote: > > From: Pekka Nikander > > > On Nov 19, 2006, at 15:36, John Day wrote: > > >> This is where John Shoch's paper gets to. > > > This one? > > Shoch, J. F.; Hupp, J. A. The "Worm" programs - early experience with > > a distributed computation > > No, he almost certainly meant IEN-19, "Inter-Network Naming, Addressing, and > Routing". I believe the IEN repository at ISI has this one now. > There is a citation in RFC 1498 for: 1. Shoch, John F., "Inter-Network Naming, Addressing, and Routing," IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K. (ed.), Tutorial: Distributed Processor Communication Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287. I wasn't able to find this in IEEE Xplore, though. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 10:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB95-0006Ei-H2; Mon, 20 Nov 2006 10:33:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB94-0006Ea-9H for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:33:18 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmB92-0008Cj-3F for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:33:18 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C462B872DD; Mon, 20 Nov 2006 10:33:15 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Message-Id: <20061120153315.C462B872DD@mercury.lcs.mit.edu> Date: Mon, 20 Nov 2006 10:33:15 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >> IEN-19, "Inter-Network Naming, Addressing, and Routing". I believe the >> IEN repository at ISI has this one now. > There is a citation in RFC 1498 Yes, there would be, now that I think of it... > I wasn't able to find this in IEEE Xplore, though. Like I said, the IEN repository at ISI: ftp://ftp.isi.edu/in-notes/ien/ien19.txt Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 10:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBEn-0001Mh-Do; Mon, 20 Nov 2006 10:39:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBEm-0001KN-7B for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:39:12 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBEj-0000WN-Jc for architecture-discuss@ietf.org; Mon, 20 Nov 2006 10:39:12 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAKFcagV012636; Mon, 20 Nov 2006 17:38:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 17:38:56 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 17:38:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] thoughts Date: Mon, 20 Nov 2006 17:38:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] thoughts Thread-Index: AccMsILpnS4NhenIQPqbc0FErZBtDQAAP1CA From: To: X-OriginalArrivalTime: 20 Nov 2006 15:38:55.0864 (UTC) FILETIME=[FD212780:01C70CB9] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rja@extremenetworks.com, jari.arkko@ericsson.com, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka Nikander wrote: >Rajahalme Jarno wrote: > >>> I am not keen on overloaded semantics. This is my big issue with=20 >>> MIPv6/SHIM6. Each of those overloads the semantics of an >>> IPv6 address, so that sometimes it is used a Locator and=20 >other times=20 >>> it is used as an Identifier (big "I"). >>> >> >> Thus it would be beneficial to allocate part of the reserved IPv6=20 >> address space (with some of the first couple of bits) for the ID=20 >> usage. >> This way they would be unambiguous. Have sufficient number=20 >of bits in=20 >> an "ID prefix" to enable scalable reverse lookup (might be useful),=20 >> and most (e.g. at least 100) bits for the "random" ID part=20 >(more bits=20 >> for higher security). > >Do you mean > >http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt >https://datatracker.ietf.org/public/idindex.cgi?command=3Did_deta >il&id=3D13628 > >Currently in an extended IETF Last Call for 4 weeks, on its last week. > >Some apps folks have voiced their concerns, but most people=20 >seem to be supportive for such an experiment. > >Or do you have something else in your mind? > Almost, but not exactly. I think ORCHID is asking for too little, and is in no way facilitating effective lookups, or localizing identities (which I expect to be a requirement in some jurisdictions). IMO, ORCHID is also plainly wrong: - 1st of all, the ORCHID proposal is contradicting itself. It calls for conformity with RFC 3513 section 2.5.4, but breaks this: "All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m =3D 64), " - Therefore it is wrong to ask for allocation under IANA Special Purpose Address Block (which starts with binary 001). - Ask for something like 0400::/6 (binary 0000 01), claiming 1/8 of the address space starting with binary 000 - Maybe should be asked for limited time experimentation (e.g. 5 years), and all systems could be mandated to cease using these addresses after the dead line. Unless the status is changed before expiration? - If bit 7 is clear, the whole ID MUST be registered (see below) - Use bits 8-28 for regional/national (RIRs/NIRs) level aggregation for efficient, localized lookups. David has expressed examples of IN RR in .id.arpa on this list before). - maybe each DNS top-level domain should get piece in this ID address space? Maybe 9 bits are needed for these (8-16), bits 17-28 could then be further allocated beneath each top-level domain for lookup service providers. Part of the 9-bit space could be carved out for experimentation and collaborative, independent global lookup provision?? - bits 29-128 would be self assigned identity, as in ORCHID (exept the hash will need to change, see below) - If bit 7 is set, the ID MUST not be registered on the registry, but the regianal structure SHOULD still be used (if possible) - or altenatively mandate 0600::/7 to use 121-bit identifier hashes The hash function will need to be changed to include the prefix as input. But note that this in NOT network topology dependent prefix. If we are lucky this difference will be enough to get past some of the existing IPR on CGAs (can you verify this?). If I recall right, one of the expressed concerns against ORCHID has been semantical overloading. By using address space starting with binary 000 this overloading is avoided. If what I propose above is too much, please feel free to utilized what you find useful (if any). Regards, Jarno Rajahalme _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 14:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFEE-0001wF-Or; Mon, 20 Nov 2006 14:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFED-0001wA-TI for architecture-discuss@ietf.org; Mon, 20 Nov 2006 14:54:53 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFEC-0001ob-Bx for architecture-discuss@ietf.org; Mon, 20 Nov 2006 14:54:53 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAKJomrG050443; Mon, 20 Nov 2006 11:51:01 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 20 Nov 2006 11:54:19 -0800 X-PGP-Universal: processed; by terminus.local on Mon, 20 Nov 2006 11:54:19 -0800 In-Reply-To: <24FD43BD-207B-44D9-9F73-4C19EC6AF649@nomadiclab.com> References: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> <24FD43BD-207B-44D9-9F73-4C19EC6AF649@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> From: David Conrad Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Date: Mon, 20 Nov 2006 11:54:04 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi, On Nov 20, 2006, at 1:47 AM, Pekka Nikander wrote: >> This is unnecessary. No special considerations are required for >> naming and addressing to support mobility. Mobility is just >> dynamic multihoming. > > While I completely agree with mobility being dynamic multi-homing > from an architectural point of view, Actually, I disagree. Mobility is simply renumbering on a constrained time scale. Architecturally, support for multi-homing (in the sense of a network- attached-thingie having more than one name-thingie) is not required for mobility. I would agree that multi-homing makes implementation easier. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 19:10:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJAO-0008Ah-CG; Mon, 20 Nov 2006 19:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJAN-0008AZ-1R for architecture-discuss@ietf.org; Mon, 20 Nov 2006 19:07:11 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJAL-0002Cf-ND for architecture-discuss@ietf.org; Mon, 20 Nov 2006 19:07:11 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAL077HO016217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Nov 2006 16:07:08 -0800 Received: from [129.46.225.224] (carbuncle.qualcomm.com [129.46.225.224]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAL073nC009955; Mon, 20 Nov 2006 16:07:05 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <41E83450-2C92-4971-9E16-A3063F2CECC6@nomadiclab.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <41E83450-2C92-4971-9E16-A3063F2CECC6@nomadiclab.com> Date: Mon, 20 Nov 2006 16:06:59 -0800 To: Pekka Nikander , David Conrad From: Ted Hardie Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 11:16 AM +0200 11/20/06, Pekka Nikander wrote: >There are lots of problems with FQDNs. Consequently, there is a lot of pressure to gradually get rid of the FQDNs in the application space, and to replace them with something better. Unfortunately, my knowledge of the efforts in the application space are very limited, but my understanding is that some of the the CRISP/IRIS effort aims to experiment in an alternative space. I am fairly familiar with CRISP (the WG) and IRIS (the protocol), but I do not understand what you mean by this. Nothing in either attempts to get rid of FQDNs in application space, as far as I know. regards, Ted Hardie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 20 20:57:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmKsH-0003Tc-0N; Mon, 20 Nov 2006 20:56:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmKsF-0003TU-M5 for architecture-discuss@ietf.org; Mon, 20 Nov 2006 20:56:35 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmKsE-0001iu-32 for architecture-discuss@ietf.org; Mon, 20 Nov 2006 20:56:35 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GmKs9-0006lk-2p for architecture-discuss@ietf.org; Mon, 20 Nov 2006 17:56:31 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Nov 2006 02:56:52 +0100 To: "Joel M. Halpern" ,architecture-discuss@ietf.org From: Jefsey_Morfin Subject: Re: [arch-d] Whose job is it, anyway? In-Reply-To: <7.0.1.0.0.20061120094548.034291a8@stevecrocker.com> References: <7.0.1.0.0.20061120094548.034291a8@stevecrocker.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0332741819==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0332741819== Content-Type: multipart/alternative; boundary="----MThepttcbbcuujpltmivvdcbbfrfogjvii" ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-73204ABC Dear Joel, This looks a good approach. Thx. It might be interesting that you detail multi-pathing and multi-homing operations the same. Also consider what you think can be end-driven (both ends). Then to consider the information needed for each operation, and where can it be located. jfc At 16:09 20/11/2006, Joel M. Halpern wrote: >In watching the discussion of things to be named and how they are >named, I think there are a number of unstated assumptions people are >making. I think some are agreed. Some are subtle enough that I am >only going to allude to them. But some I think can be usefully >surfaced and discussed on their merits. > >For this purpose, I will take certain things as given. >1) There ought to be identifiers for certain objects in the system >which are independent of the location of those objects. Application >instances need to have such identifiers. >2) There are (and ought to be) identifiers which are location >dependent. subnets (and interfaces to subnets) ought to be >identified based on their placement in the network graph. >3) It is expected that in most of the net, packet forwarding will be >based on location dependent identifiers (locators.) > >Note, point 3 does not deal with whether that is a single >identifier, a cascade or nested set of identifiers, different >locators for local and global use, or any of the many other >variations in forwarding paradigms. It is just saying that >forwarding is working in terms of location sensitive identifiers. I >have seen some research work where that is not the case.] >I will use "locator" for an identifier which is location dependent. >(Lots of folks use that, but I don't think we have yet settled on it.) > >If we take that as given, and we assume that applications normally >operate in terms of location, then there are a couple of interesting >tasks for the collective system, and a couple of operations relating >to those tasks. > >The tasks are: >a) coping with multi-pathing >b) coping with multi-homing >c) coping with mobility > >Folks have sometimes treated various of these as interchangeably >solved by the id / locator split. While that separation of notions >helps us, it does not "solve" these issues. It does not even >necessitate that these issues be solved in the same place. > >Functionally, one can talk about the functions of >i) determining the locator(s) that go with a location independent identifier >ii) selecting a locator to use for communication >iii) route determination forwarding packets based on that selected locator > >(ii) is sometimes treated as a non-issue, if one assumes that there >is only one such locator. (ii) is also sometimes assumed to go in >specific places. > >Looking at the tasks above, multi-path is the problem (opportunity) >of dealing with the fact that there are multiple paths to a location >across the network. We assume (correctly I believe) that coping >with this is the job of the routing / packet forwarding functions. > >On the other end, mobility seems to imply the changing of the >locator(s) associated with a location independent >identifier. Hence, it seems to me that wherever it lives it is not >part of the routing / packet forwarding system. Yes, this >re-mapping is helped by the separation of identifiers. Yes, there >can be functions required of packet handling systems that can help >this. But routing isn't going to tell you about it, and packet >forwarding based on locators isn't going to cope with it. > >The middle task raises, coping with multi-homing, some interesting >questions. And I think we have been mixing the answers. If one >assumes that one can have a singular, meaningful, location dependent >identifier for a (multi-connected) node then one might well expect >to use that identifier in packets, and expect the routing / packet >forwarding system to cope with it. >If on the other hand, the location dependent identifiers are >associated with subnets / interfaces, then it is hard to see how >locator based forwarding can cope with this. Rather, it would seem >to be the locator selection function which has to cope with it. > >The question I am wondering about is, assuming for the moment that >it can be made to work either way, does coping with multi-homing >conceptually belong with one or the other of multi-pathing and >mobility? (We may have to put it somewhere it does not belong for >pragmatic reasons, but it seems useful to know if that is what we are doing.) > >Yours, >Joel M. Halpern > >PS: I am deliberately being vague about where the locator selection >function is being done, and whether it is colocated with the locator >determination. Whether it looks like shim6, GSE, or something, and >whether it is done in the host or in an edge does not, I think, >affect the question here. > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/html Dear Joel,
This looks a good approach. Thx. It might be interesting that you
detail multi-pathing and multi-homing operations the same. Also
consider what you think can be end-driven (both ends). Then to
consider the information needed for each operation, and where can it
be located.
jfc


At 16:09 20/11/2006, Joel M. Halpern wrote:

>In watching the discussion of things to be named and how they are
>named, I think there are a number of unstated assumptions people are
>making.  I think some are agreed.  Some are subtle enough that I am
>only going to allude to them.  But some I think can be usefully
>surfaced and discussed on their merits.
>
>For this purpose, I will take certain things as given.
>1) There ought to be identifiers for certain objects in the system
>which are independent of the location of those objects.  Application
>instances need to have such identifiers.
>2) There are (and ought to be) identifiers which are location
>dependent.  subnets (and interfaces to subnets) ought to be
>identified based on their placement in the network graph.
>3) It is expected that in most of the net, packet forwarding will be
>based on location dependent identifiers (locators.)
>
>Note, point 3 does not deal with whether that is a single
>identifier, a cascade or nested set of identifiers, different
>locators for local and global use, or any of the many other
>variations in forwarding paradigms.  It is just saying that
>forwarding is working in terms of location sensitive identifiers.  I
>have seen some research work where that is not the case.]
>I will use "locator" for an identifier which is location dependent.
>(Lots of folks use that, but I don't think we have yet settled on it.)
>
>If we take that as given, and we assume that applications normally
>operate in terms of location, then there are a couple of interesting
>tasks for the collective system, and a couple of operations relating
>to those tasks.
>
>The tasks are:
>a) coping with multi-pathing
>b) coping with multi-homing
>c) coping with mobility
>
>Folks have sometimes treated various of these as interchangeably
>solved by the id / locator split.  While that separation of notions
>helps us, it does not "solve" these issues.  It does not even
>necessitate that these issues be solved in the same place.
>
>Functionally, one can talk about the functions of
>i) determining the locator(s) that go with a location independent identifier
>ii) selecting a locator to use for communication
>iii) route determination forwarding packets based on that selected locator
>
>(ii) is sometimes treated as a non-issue, if one assumes that there
>is only one such locator.  (ii) is also sometimes assumed to go in
>specific places.
>
>Looking at the tasks above, multi-path is the problem (opportunity)
>of dealing with the fact that there are multiple paths to a location
>across the network.  We assume (correctly I believe) that coping
>with this is the job of the routing / packet forwarding functions.
>
>On the other end, mobility seems to imply the changing of the
>locator(s) associated with a location independent
>identifier.  Hence, it seems to me that wherever it lives it is not
>part of the routing / packet forwarding system.  Yes, this
>re-mapping is helped by the separation of identifiers.  Yes, there
>can be functions required of packet handling systems that can help
>this.  But routing isn't going to tell you about it, and packet
>forwarding based on locators isn't going to cope with it.
>
>The middle task raises, coping with multi-homing, some interesting
>questions.  And I think we have been mixing the answers.  If one
>assumes that one can have a singular, meaningful, location dependent
>identifier for a (multi-connected) node then one might well expect
>to use that identifier in packets, and expect the routing / packet
>forwarding system to cope with it.
>If on the other hand, the location dependent identifiers are
>associated with subnets / interfaces, then it is hard to see how
>locator based forwarding can cope with this.  Rather, it would seem
>to be the locator selection function which has to cope with it.
>
>The question I am wondering about is, assuming for the moment that
>it can be made to work either way, does coping with multi-homing
>conceptually belong with one or the other of multi-pathing and
>mobility?  (We may have to put it somewhere it does not belong for
>pragmatic reasons, but it seems useful to know if that is what we are doing.)
>
>Yours,
>Joel M. Halpern
>
>PS: I am deliberately being vague about where the locator selection
>function is being done, and whether it is colocated with the locator
>determination.  Whether it looks like shim6, GSE, or something, and
>whether it is done in the host or in an edge does not, I think,
>affect the question here.
>
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>

------MThepttcbbcuujpltmivvdcbbfrfogjvii-- --===============0332741819== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0332741819==-- From architecture-discuss-bounces@ietf.org Tue Nov 21 01:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmP1Q-0004NJ-DE; Tue, 21 Nov 2006 01:22:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmP1P-0004NA-Qj for architecture-discuss@ietf.org; Tue, 21 Nov 2006 01:22:19 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmP1M-0006w7-6Q for architecture-discuss@ietf.org; Tue, 21 Nov 2006 01:22:17 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAL6I3rG051375; Mon, 20 Nov 2006 22:18:12 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 20 Nov 2006 22:21:31 -0800 X-PGP-Universal: processed; by terminus.local on Mon, 20 Nov 2006 22:21:31 -0800 In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> From: David Conrad Subject: Re: [arch-d] thoughts Date: Mon, 20 Nov 2006 22:21:20 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Ran, On Nov 19, 2006, at 11:55 AM, RJ Atkinson wrote: >> In my model, the binding between an identifier and locator is done >> externally to the 'node'. > I don't understand what you mean by the above. This is mostly an implementation detail. Architecturally, what I meant was that the mapping between locator and identifier is not dependent on either. That is, the binding is a simple mapping function that takes as input the identifier and spits back a set of zero or more locators. How/where that mapping is done does not depend on the locator or identifier (other than the identifier is the input that results in zero or more locators as output). > Because Locators are not covered by AH/ESP in my model, and are > not included in any state above the network layer, Locators would > be mutable, at least conceptually. When I raised this approach before, people complained about MITM and spoofing attacks. > Shorter TTLS for the Locator records, to a TTL value appropriate > for the frequency of layer-3 location changes, probably would > obviate the need for such special-case forwarding. You get into a tradeoff here, between load on the DNS servers and the ability for mapping changes to be implemented. I believe that for scalability reasons, you want to keep a reasonable level of caching. >> Which, of course, implies a change to all end point network stacks >> deployed to date. > Yes, but only to stacks that want to use the new architecture. Right. As I've become a bit cynical about what is possible to change on the Internet, I've consciously been assuming that the only way to get stuff deployed is to minimize what has to be changed, thus the "change only the edge" approach. Changing host stacks is a fairly significant change in my mind. > That seems to be a difference. Conceptually, how would the edge > device > do that sort of lookup ? Some sort of other directory service ? DNS or something like it would work for a "pull" model. A push model (e.g., flooding a map via BGP or something similar) might also work. > OK, so this implies a pretty strong dependence on DNS and DNSsec > deployment and maybe also a strong dependence on being able to > somehow sign delegations from RIRs. Not necessarily. The mechanism used for propagating the mapping can be either pull (e.g., something that looks and smells like the DNS +DNSSEC, but does not have to be) or push. I just use the DNS in examples because it is easier to explain. As for signing delegations, I feel that would be useful for other reasons, but isn't required by my model. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 02:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQBR-0006Wa-KR; Tue, 21 Nov 2006 02:36:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQBP-0006WM-M9 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 02:36:43 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmQBO-00031G-AM for architecture-discuss@ietf.org; Tue, 21 Nov 2006 02:36:43 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2006 08:36:41 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAL7afUO023220; Tue, 21 Nov 2006 08:36:41 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAL7aewv011475; Tue, 21 Nov 2006 08:36:40 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 08:36:40 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 23:36:40 -0800 In-Reply-To: <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> References: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> <24FD43BD-207B-44D9-9F73-4C19EC6AF649@nomadiclab.com> <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <756B2967-D5AB-462D-96C6-6EFC3D254D1C@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Date: Tue, 21 Nov 2006 08:36:30 +0100 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Nov 2006 07:36:40.0196 (UTC) FILETIME=[C88A5C40:01C70D3F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1581; t=1164094601; x=1164958601; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[arch-d]=20Primary=20and=20lesser=20names, =20or=20lay ers=20of=20indirection? |Sender:=20; bh=FMWQfQR3Jzvr/Jk3NEVOWNkH5hbg7COJUX+Qg33YvH8=; b=pVvziZjDvMedRyI/cjsJ3IxZshHHKblExpRNZNqG8ioa4/J47QChH7VtWMmwlWPVCETi0VXf HQxHGw5HJvkIw8oAjT0AVl49E8J2J66aXzdvghfwJXBjyfcmVBUVQJKq; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 20 nov 2006, at 20.54, David Conrad wrote: > On Nov 20, 2006, at 1:47 AM, Pekka Nikander wrote: >>> This is unnecessary. No special considerations are required for >>> naming and addressing to support mobility. Mobility is just >>> dynamic multihoming. >> >> While I completely agree with mobility being dynamic multi-homing >> from an architectural point of view, > > Actually, I disagree. > > Mobility is simply renumbering on a constrained time scale. > Architecturally, support for multi-homing (in the sense of a > network-attached-thingie having more than one name-thingie) is not > required for mobility. I would agree that multi-homing makes > implementation easier. I sort of agree with you David, but I do not think renumbering is always needed. I see "mobility" as a feature a human or service have, and whether renumbering is needed or not is dependent on what identifiers(!) are used to identify the endpoint that "moves around". Further, we also have different feature requirements with mobility in the IETF. Some people think it is important to be able to keep flows up during a "move". Other people say a TCP (in the classic sense) can restart so the "experience" on application layer is that things "just work". Today the identifiers we have are URI's of some sort, and they include domain names as the key ingredient. Because of this, mobility include having a stable domain name. The rest is an implementation issue :-) Oh, is that why we have this discussion? :-) :-) Patrik _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 03:54:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRMy-0004JJ-V0; Tue, 21 Nov 2006 03:52:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRMx-0004Hb-RA for architecture-discuss@ietf.org; Tue, 21 Nov 2006 03:52:43 -0500 Received: from imo-m17.mx.aol.com ([64.12.138.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmRMw-0006Hd-6W for architecture-discuss@ietf.org; Tue, 21 Nov 2006 03:52:43 -0500 Received: from HeinerHummel@aol.com by imo-m17.mx.aol.com (mail_out_v38_r7.6.) id l.cb3.423c97f (39329); Tue, 21 Nov 2006 03:49:25 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 21 Nov 2006 03:49:25 EST Subject: Re: [arch-d] Whose job is it, anyway? To: jefsey@jefsey.com, joel@stevecrocker.com, architecture-discuss@ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1229636657==" Errors-To: architecture-discuss-bounces@ietf.org --===============1229636657== Content-Type: multipart/alternative; boundary="-----------------------------1164098965" -------------------------------1164098965 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I am also aware of even a product which did routing location-independently: It was a military network developed by Siemens whereby a channel was used =20 only for sending out search messages all over the (remaining entire) network= - =20 for each call setup. That was 35 years ago. Well, it was done in lack of any knowledge about=20 topology determination and may serve now as an example how NOT to do. Just= the=20 opposite: topology determination can and should be improved. This may start with discussing location identifiers.Can they be improved ? User address and router address: How is the binding? Should it stay as it i= s=20 now ? Is a single address family enough, or is it more appropriate to cater for =20 multiple address families (which requests some AFI) ? VoIP:E164 is done by D= NS =20 translation.Why not (of course in the future) as one of many families? Is =20 there demand for address families by applications which are enabled just by=20= =20 futural technologies (sensor technology) ? And how is the correlation with router addresses ? Note: On a letter you indicate name and address of the receiver. Sometimes=20 however a post office resp. P.O.Box number. =20 Heiner Hummel =20 =20 =20 =20 =20 =20 In einer eMail vom 21.11.2006 02:59:35 Westeurop=E4ische Normalzeit schreibt= =20 jefsey@jefsey.com: Dear Joel, This looks a good approach. Thx. It might be interesting that you =20 detail multi-pathing and multi-homing operations the same. Also =20 consider what you think can be end-driven (both ends). Then to =20 consider the information needed for each operation, and where can it =20 be located. jfc At 16:09 20/11/2006, Joel M. Halpern wrote: >In watching the discussion of things to be named and how they are=20 >named, I think there are a number of unstated assumptions people are=20 >making. I think some are agreed. Some are subtle enough that I am=20 >only going to allude to them. But some I think can be usefully=20 >surfaced and discussed on their merits. > >For this purpose, I will take certain things as given. >1) There ought to be identifiers for certain objects in the system=20 >which are independent of the location of those objects. Application=20 >instances need to have such identifiers. >2) There are (and ought to be) identifiers which are location=20 >dependent. subnets (and interfaces to subnets) ought to be=20 >identified based on their placement in the network graph. >3) It is expected that in most of the net, packet forwarding will be=20 >based on location dependent identifiers (locators.) > >Note, point 3 does not deal with whether that is a single=20 >identifier, a cascade or nested set of identifiers, different =20 >locators for local and global use, or any of the many other =20 >variations in forwarding paradigms. It is just saying that =20 >forwarding is working in terms of location sensitive identifiers. I=20 >have seen some research work where that is not the case.] >I will use "locator" for an identifier which is location dependent.=20 >(Lots of folks use that, but I don't think we have yet settled on it.) > >If we take that as given, and we assume that applications normally=20 >operate in terms of location, then there are a couple of interesting=20 >tasks for the collective system, and a couple of operations relating=20 >to those tasks. > >The tasks are: >a) coping with multi-pathing >b) coping with multi-homing >c) coping with mobility > >Folks have sometimes treated various of these as interchangeably=20 >solved by the id / locator split. While that separation of notions=20 >helps us, it does not "solve" these issues. It does not even =20 >necessitate that these issues be solved in the same place. > >Functionally, one can talk about the functions of >i) determining the locator(s) that go with a location independent identifi= er >ii) selecting a locator to use for communication >iii) route determination forwarding packets based on that selected locato= r > >(ii) is sometimes treated as a non-issue, if one assumes that there=20 >is only one such locator. (ii) is also sometimes assumed to go in=20 >specific places. > >Looking at the tasks above, multi-path is the problem (opportunity)=20 >of dealing with the fact that there are multiple paths to a location=20 >across the network. We assume (correctly I believe) that coping=20 >with this is the job of the routing / packet forwarding functions. > >On the other end, mobility seems to imply the changing of the=20 >locator(s) associated with a location independent =20 >identifier. Hence, it seems to me that wherever it lives it is not=20 >part of the routing / packet forwarding system. Yes, this=20 >re-mapping is helped by the separation of identifiers. Yes, there=20 >can be functions required of packet handling systems that can help=20 >this. But routing isn't going to tell you about it, and packet=20 >forwarding based on locators isn't going to cope with it. > >The middle task raises, coping with multi-homing, some interesting=20 >questions. And I think we have been mixing the answers. If one=20 >assumes that one can have a singular, meaningful, location dependent=20 >identifier for a (multi-connected) node then one might well expect=20 >to use that identifier in packets, and expect the routing / packet=20 >forwarding system to cope with it. >If on the other hand, the location dependent identifiers are=20 >associated with subnets / interfaces, then it is hard to see how=20 >locator based forwarding can cope with this. Rather, it would seem=20 >to be the locator selection function which has to cope with it. > >The question I am wondering about is, assuming for the moment that=20 >it can be made to work either way, does coping with multi-homing=20 >conceptually belong with one or the other of multi-pathing and=20 >mobility? (We may have to put it somewhere it does not belong for=20 >pragmatic reasons, but it seems useful to know if that is what we are =20 doing.) > >Yours, >Joel M. Halpern > >PS: I am deliberately being vague about where the locator selection=20 >function is being done, and whether it is colocated with the locator =20 >determination. Whether it looks like shim6, GSE, or something, and=20 >whether it is done in the host or in an edge does not, I think,=20 >affect the question here. > > >_______________________________________________ >Architecture-discuss mailing list >_Architecture-discuss@ietf.org_ (mailto:Architecture-discuss@ietf.org)=20 >_https://www1.ietf.org/mailman/listinfo/architecture-discuss_=20 (https://www1.ietf.org/mailman/listinfo/architecture-discuss)=20 > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1164098965 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I am also aware of even a product which did routing=20 location-independently:
It was a military network developed by Siemens whereby a channel was us= ed=20 only for sending out search messages all over the (remaining entire) network= -=20 for each call setup.
That was 35 years ago. Well, it was done in lack of any knowl= edge=20 about topology determination and may serve now as an example how  NOT t= o=20 do. Just the opposite: topology determination can and should be improved.
This may start with discussing location identifiers.Can they be improve= d=20 ?
User address and router address: How is the binding? Should it stay as=20= it=20 is now ?
Is a single address family enough, or is it more appropriate to cater f= or=20 multiple address families (which requests some AFI) ? VoIP:E164 is done by D= NS=20 translation.Why not (of course in the future) as one of many families? = Is=20 there demand for address families by applications which are enabled just by=20 futural technologies (sensor technology) ?
And how is the correlation with router addresses ?
Note: On a letter you indicate name and address of the receiver.=20 Sometimes however  a post office resp. P.O.Box number.
 
Heiner Hummel
 
 
 
 
 
 
In einer eMail vom 21.11.2006 02:59:35 Westeurop=E4ische Normalzeit sch= reibt=20 jefsey@jefsey.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Dear=20 Joel,
This looks a good approach. Thx. It might be interesting that you= =20
detail multi-pathing and multi-homing operations the same. Also=20
consider what you think can be end-driven (both ends). Then to=20
consider the information needed for each operation, and where can it=20
be located.
jfc


At 16:09 20/11/2006, Joel M. Halpern=20 wrote:

>In watching the discussion of things to be named and how= =20 they are
>named, I think there are a number of unstated assumptions= =20 people are
>making.  I think some are agreed.  = Some=20 are subtle enough that I am
>only going to allude to=20 them.  But some I think can be usefully
>surfaced and=20 discussed on their merits.
>
>For this purpose, I will take=20 certain things as given.
>1) There ought to be identifiers for certa= in=20 objects in the system
>which are independent of the location of tho= se=20 objects.  Application
>instances need to have such=20 identifiers.
>2) There are (and ought to be) identifiers which are=20 location
>dependent.  subnets (and interfaces to subnets)= =20 ought to be
>identified based on their placement in the network=20 graph.
>3) It is expected that in most of the net, packet forwarding= =20 will be
>based on location dependent identifiers=20 (locators.)
>
>Note, point 3 does not deal with whether that i= s a=20 single
>identifier, a cascade or nested set of identifiers, differe= nt=20
>locators for local and global use, or any of the many other=20
>variations in forwarding paradigms.  It is just saying t= hat=20
>forwarding is working in terms of location sensitive=20 identifiers.  I
>have seen some research work where that=20= is=20 not the case.]
>I will use "locator" for an identifier which is loca= tion=20 dependent.
>(Lots of folks use that, but I don't think we have yet=20 settled on it.)
>
>If we take that as given, and we assume tha= t=20 applications normally
>operate in terms of location, then there are= a=20 couple of interesting
>tasks for the collective system, and a coupl= e of=20 operations relating
>to those tasks.
>
>The tasks=20 are:
>a) coping with multi-pathing
>b) coping with=20 multi-homing
>c) coping with mobility
>
>Folks have=20 sometimes treated various of these as interchangeably
>solved by th= e id=20 / locator split.  While that separation of notions
>helps= us,=20 it does not "solve" these issues.  It does not even=20
>necessitate that these issues be solved in the same=20 place.
>
>Functionally, one can talk about the functions=20 of
>i) determining the locator(s) that go with a location independen= t=20 identifier
>ii) selecting a locator to use for communication
>= iii)=20 route determination forwarding packets based on that selected=20 locator
>
>(ii) is sometimes treated as a non-issue, if one=20 assumes that there
>is only one such locator.  (ii) is al= so=20 sometimes assumed to go in
>specific places.
>
>Looking= at=20 the tasks above, multi-path is the problem (opportunity)
>of dealin= g=20 with the fact that there are multiple paths to a location
>across t= he=20 network.  We assume (correctly I believe) that coping
>wi= th=20 this is the job of the routing / packet forwarding=20 functions.
>
>On the other end, mobility seems to imply the=20 changing of the
>locator(s) associated with a location independent=20
>identifier.  Hence, it seems to me that wherever it live= s it=20 is not
>part of the routing / packet forwarding system.  = Yes,=20 this
>re-mapping is helped by the separation of=20 identifiers.  Yes, there
>can be functions required of pa= cket=20 handling systems that can help
>this.  But routing isn't=20 going to tell you about it, and packet
>forwarding based on locator= s=20 isn't going to cope with it.
>
>The middle task raises, coping= =20 with multi-homing, some interesting
>questions.  And I th= ink=20 we have been mixing the answers.  If one
>assumes that on= e=20 can have a singular, meaningful, location dependent
>identifier for= a=20 (multi-connected) node then one might well expect
>to use that=20 identifier in packets, and expect the routing / packet
>forwarding=20 system to cope with it.
>If on the other hand, the location dependen= t=20 identifiers are
>associated with subnets / interfaces, then it is h= ard=20 to see how
>locator based forwarding can cope with=20 this.  Rather, it would seem
>to be the locator selection= =20 function which has to cope with it.
>
>The question I am wonde= ring=20 about is, assuming for the moment that
>it can be made to work eith= er=20 way, does coping with multi-homing
>conceptually belong with one or= the=20 other of multi-pathing and
>mobility?  (We may have to pu= t it=20 somewhere it does not belong for
>pragmatic reasons, but it seems=20 useful to know if that is what we are=20 doing.)
>
>Yours,
>Joel M. Halpern
>
>PS: I=20= am=20 deliberately being vague about where the locator selection
>functio= n is=20 being done, and whether it is colocated with the locator=20
>determination.  Whether it looks like shim6, GSE, or=20 something, and
>whether it is done in the host or in an edge does n= ot,=20 I think,
>affect the question=20 here.
>
>
>_____________________________________________= __
>Architecture-discuss=20 mailing list
>Architecture-discuss@ietf.or= g
>https= ://www1.ietf.org/mailman/listinfo/architecture-discuss
>

=20

_______________________________________________
Architecture-di= scuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164098965-- --===============1229636657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1229636657==-- From architecture-discuss-bounces@ietf.org Tue Nov 21 04:03:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRWx-00006t-2b; Tue, 21 Nov 2006 04:03:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRWu-00006V-Px; Tue, 21 Nov 2006 04:03:00 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmRWt-0000YC-7g; Tue, 21 Nov 2006 04:03:00 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAL91LdY018276; Tue, 21 Nov 2006 11:02:51 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 11:01:20 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 11:01:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Nov 2006 11:01:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call comments on draft-laganier-ipv6-khi-05 ORCHID Thread-Index: AccNAbUzCpTzCXEKTpqW+1AaBY00+AAP6YcQ From: To: , X-OriginalArrivalTime: 21 Nov 2006 09:01:19.0842 (UTC) FILETIME=[9C3ED420:01C70D4B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: architecture-discuss@ietf.org Subject: [arch-d] Last Call comments on draft-laganier-ipv6-khi-05 ORCHID X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org All, I presented these thoughts on the architecture-discuss@ietf.org list yesterday, and was told it would be useful to send these in as Last Call comments for draft-laganier-ipv6-khi-05 (ORCHID). I have thought a bit more about this, so this is a bit more developed than what I wrote yesterday. I think ORCHID is asking for too little, and is in no way facilitating effective lookups, or localizing identities (which I expect to be a requirement in some jurisdictions). IMO, ORCHID is also plainly wrong: - 1st of all, the ORCHID proposal is contradicting itself. It calls for conformity with RFC 3513 section 2.5.4, but breaks this: "All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m =3D 64), " - Therefore it is wrong to ask for allocation under IANA Special=20 Purpose Address Block (which starts with binary 001). - ORCHID should ask for something like 0400::/6 (binary 0000 01), claiming 1/8 of the address space starting with binary 000 - Maybe should be asked for limited time experimentation (e.g. 5=20 years), and all systems could be mandated to cease using these=20 addresses after the dead line. Unless the status is changed=20 before expiration? - If bit 7 is clear, the whole ID MUST be registered (see below) - If bit 8 is clear, the bits 9-28 are used for regional/national (RIRs/NIRs? and/or DNS top level domain structure?) level aggregation for efficient, localized lookups. Here is an example what DNS records for an identity could look like: $ORIGIN 5.4.3.2.1.4.0.ip6.arpa 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.e.d.c.b.a.9.8.7.6 IN PTR example.test.com IN AAAA 3ffe:400:10:100:201:2ff:feb5:3806 IN A 153.43.23.1 ... - the $ORIGIN part has the bits 1-28 (7 nibbles). Nibbles "5.4.3.2.1" are the bits 9-28 for regional aggregation. - PTR points to a FQDN for the ID (if any), and AAAA and/or A records give locators for the identity - New RR type would be needed to map from a FQDN or a locator to an identity (e.g. "ID") - If the bit 8 is set, the bits 9-28 are used for experimentation and collaborative, independent global lookup provision?? - bits 29-128 would be self assigned identity, as in ORCHID=20 (exept the hash will need to change, see below). See the PTR, AAAA, and A RRs in the example above. - If bit 7 is set, the ID MUST not be registered on any registry. In this case the bit 8 would be reserved (set to zero), and use bits 9-128 for a 120-bit identifier hashes for better security and lower chance for statistical collisions The hash function will need to be changed to include the prefix as input. But note that this in NOT network topology dependent=20 prefix. If we are lucky this difference will be enough to get past some of the existing IPR on CGAs. If I recall right, one of the expressed concerns against ORCHID has=20 been semantical overloading. By using address space starting with=20 binary 000 this overloading is avoided. If what I propose above is too much, please feel free to=20 utilized what you find useful (if any). Regards, Jarno Rajahalme Some context for the above: Pekka Nikander wrote: >Rajahalme Jarno wrote: > >> Thus it would be beneficial to allocate part of the reserved IPv6=20 >> address space (with some of the first couple of bits) for the ID=20 >> usage. >> This way they would be unambiguous. Have sufficient number of bits in >> an "ID prefix" to enable scalable reverse lookup (might be useful),=20 >> and most (e.g. at least 100) bits for the "random" ID part(more bits >> for higher security). > >Do you mean > >http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt >https://datatracker.ietf.org/public/idindex.cgi?command=3Did_deta >il&id=3D13628 > >Currently in an extended IETF Last Call for 4 weeks, on its last week. > >Some apps folks have voiced their concerns, but most people seem to be=20 >supportive for such an experiment. > >Or do you have something else in your mind? > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 04:41:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmS6t-00026N-1M; Tue, 21 Nov 2006 04:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmS6r-00025U-RF for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:40:09 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmS6q-00005i-A1 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:40:09 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAL9e5OV235608 for ; Tue, 21 Nov 2006 09:40:05 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAL9hWRU3129354 for ; Tue, 21 Nov 2006 10:43:32 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAL9e5pd032188 for ; Tue, 21 Nov 2006 10:40:05 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAL9e4cZ032167; Tue, 21 Nov 2006 10:40:04 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA114216; Tue, 21 Nov 2006 10:40:03 +0100 Message-ID: <4562C973.1090103@zurich.ibm.com> Date: Tue, 21 Nov 2006 10:40:03 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: David Conrad Subject: Re: [arch-d] thoughts References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> In-Reply-To: <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Let me get absurd for a moment: David Conrad wrote: > John, > > On Nov 17, 2006, at 8:14 PM, John Day wrote: > >> You need a logical and physical address spaces under the application >> name space. > > > Agreed. By analogy, I am suggesting the identifier space is the > virtual address that is mapped into the locator space which is the > physical address space. OK, we have layers, and the layers each have namespaces, which may or may not be externally significant. But trying to say that one namespace is virtual and another is physical strikes me as bogus; they are all virtual. (MAC addresses aren't really physical - maybe you can consider that the numbers on wall sockets are physical addresses, but even they can be changed.) So I think we should consider all namespaces to be virtual or logical, and not try to find a specific "physical" namespace. This makes it a lot easier to think about VPNs for example - they merge and map parts of a namespace, but they are not 2nd class namespaces. > One might argue that the logical address space should be the fqdn, and > in an ideal world, I might agree. However, pragmatically speaking, > that won't fly as long as there are applications and protocol stacks > that _know_ an "address" is 32 or 128 bits and that certain bit > patterns have special meanings. > >> The point of attachment id does not have to be global. > > > No, but the mapping between the id and the locator must be globally > unique. Define "global." In other words, what is the scope of the namespace within which you require uniqueness? Brian It is possible to come up with a variety of mechanisms to > ensure that global uniqueness, but since the amount of name space isn't > an issue, it just seems simpler to require both id and locator be > globally unique and avoid the question completely. > >> So quit trying to build solutions that make it work. They will >> always be kludges. > > > Well, yes. However, it is hard to boil the ocean. > > Rgds, > -drc > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 04:44:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSAv-00062d-QQ; Tue, 21 Nov 2006 04:44:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSAu-00062Y-Vy for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:44:20 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmSAt-0001GO-E8 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:44:20 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F215D89879; Tue, 21 Nov 2006 11:44:17 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6F11289873; Tue, 21 Nov 2006 11:44:17 +0200 (EET) Message-ID: <4562CA71.3080002@piuha.net> Date: Tue, 21 Nov 2006 11:44:17 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: jarno.rajahalme@nokia.com Subject: ORCHIDs (Was: Re: [arch-d] thoughts) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: pekka.nikander@nomadiclab.com, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jarno, > > Almost, but not exactly. I think ORCHID is asking for too little, and is > in no way facilitating effective lookups, or localizing identities > (which I expect to be a requirement in some jurisdictions). IMO, ORCHID > is also plainly wrong: > > - 1st of all, the ORCHID proposal is contradicting itself. It calls for > conformity with RFC 3513 section 2.5.4, but breaks this: > > "All global unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), " > > - Therefore it is wrong to ask for allocation under IANA Special Purpose > Address Block (which starts with binary 001). > > - Ask for something like 0400::/6 (binary 0000 01), claiming 1/8 of the > address space starting with binary 000 > > - Maybe should be asked for limited time experimentation (e.g. 5 > years), and all systems could be mandated to cease using these addresses > after the dead line. Unless the status is changed before expiration? > > - If bit 7 is clear, the whole ID MUST be registered (see below) > > - Use bits 8-28 for regional/national (RIRs/NIRs) level aggregation for > efficient, localized lookups. David has expressed examples of IN RR in > .id.arpa on this list before). > > - maybe each DNS top-level domain should get piece in this ID address > space? Maybe 9 bits are needed for these (8-16), bits 17-28 could then > be further allocated beneath each top-level domain for lookup service > providers. Part of the 9-bit space could be carved out for > experimentation and collaborative, independent global lookup provision?? > > - bits 29-128 would be self assigned identity, as in ORCHID (exept the > hash will need to change, see below) > > - If bit 7 is set, the ID MUST not be registered on the registry, but > the regianal structure SHOULD still be used (if possible) > > - or altenatively mandate 0600::/7 to use 121-bit identifier hashes > > The hash function will need to be changed to include the prefix as > input. But note that this in NOT network topology dependent prefix. If > we are lucky this difference will be enough to get past some of the > existing IPR on CGAs (can you verify this?). > > If I recall right, one of the expressed concerns against ORCHID has been > semantical overloading. By using address space starting with binary 000 > this overloading is avoided. > > If what I propose above is too much, please feel free to utilized what > you find useful (if any). > The issue of which part of the address space to use has certainly been discussed already. I have to look into your comment about RFC 3513 rule. Thanks for pointing this out. However, there are some important issues that you should be aware of: First of all, ORCHIDs are not intended as the final solution for the routing and addressing problem. They indeed fall short in the question of identifier lookups. But that's by design. What this allows is that people can run HIP (or other) experiments without changing the APIs that the applications see. Indeed, new routing mechanisms such as those operating on "overlays" should be part of the experimentation, but they are not part of the allocation, and I don't think we are ready to specify all the details yet. On the other hand I think it is very valuable for an experiments like this to proceed. If there is one new feature that needs to be tried first before its adopted for the Internet, its the identity-locator split. Your ideas above sound interesting, please document them and consider running an experiment of your own to convince the rest of us that it works great. ORCHIDs might even be used for your experiment, just that you have a different use of the remaining bits than the HIP experiment has. Similarly, since this is an experiment I don't think we should burn any significant part of the address space for this. If it turns out that people run a lot of experiments in this space and the results are successful, we can revisit this. The big question mark related to ORCHIDs is the overloading. We could, of course, use a different prefix. But this does not necessarily solve the issues associated with the overloading. For instance, since applications do not understand one part of the address space to have a different semantics than another one, they would still be equally easy to leak through referrals to legacy nodes, etc. One important result from experiments in this space is determining how widespread that problem is. --Jari (P.S. Sorry if you get this twice. I sent one mail accidentally using an address that I am not subscribed to arch-d with.) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 04:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSGP-0007p5-LG; Tue, 21 Nov 2006 04:50:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSGO-0007od-9r for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:50:00 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmSGM-0002iP-S6 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:50:00 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kAL9ntGb133938 for ; Tue, 21 Nov 2006 09:49:55 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAL9qji02854986 for ; Tue, 21 Nov 2006 09:52:45 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAL9ns9H014109 for ; Tue, 21 Nov 2006 09:49:54 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAL9nskD014088; Tue, 21 Nov 2006 09:49:54 GMT Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA52366; Tue, 21 Nov 2006 10:49:53 +0100 Message-ID: <4562CBC1.1000705@zurich.ibm.com> Date: Tue, 21 Nov 2006 10:49:53 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: David Conrad Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? References: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> <24FD43BD-207B-44D9-9F73-4C19EC6AF649@nomadiclab.com> <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> In-Reply-To: <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Conrad wrote: > Hi, > > On Nov 20, 2006, at 1:47 AM, Pekka Nikander wrote: > >>> This is unnecessary. No special considerations are required for >>> naming and addressing to support mobility. Mobility is just dynamic >>> multihoming. >> >> >> While I completely agree with mobility being dynamic multi-homing >> from an architectural point of view, > > > Actually, I disagree. > > Mobility is simply renumbering on a constrained time scale. But, renumbering is simply multihoming on a relaxed time scale (see RFC 4192). Personally, I think *roaming* is dynamic multi-homing, which is a slightly different statement. Brian > Architecturally, support for multi-homing (in the sense of a network- > attached-thingie having more than one name-thingie) is not required for > mobility. I would agree that multi-homing makes implementation easier. > > Rgds, > -drc > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 04:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSKI-0000HJ-OG; Tue, 21 Nov 2006 04:54:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSKH-0000Fp-G3 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:54:01 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmSKG-0003LM-2q for architecture-discuss@ietf.org; Tue, 21 Nov 2006 04:54:01 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAL9rxGW142120 for ; Tue, 21 Nov 2006 09:53:59 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAL9vPnb2498580 for ; Tue, 21 Nov 2006 10:57:25 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAL9rwEi005739 for ; Tue, 21 Nov 2006 10:53:58 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAL9rwpv005727; Tue, 21 Nov 2006 10:53:58 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA88050; Tue, 21 Nov 2006 10:53:57 +0100 Message-ID: <4562CCB5.80700@zurich.ibm.com> Date: Tue, 21 Nov 2006 10:53:57 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: David Conrad Subject: Re: [arch-d] thoughts References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> In-Reply-To: <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: RJ Atkinson , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Conrad wrote: > Ran, ... >> Because Locators are not covered by AH/ESP in my model, and are >> not included in any state above the network layer, Locators would >> be mutable, at least conceptually. > > > When I raised this approach before, people complained about MITM and > spoofing attacks. Hence the cryptographic protection of locator sets in shim6. This problem is valid, but soluble as long as you have some state to keep track of the locator set. If you attempt to do it stateless, you are exposed. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 07:37:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmUpq-0001Gy-JI; Tue, 21 Nov 2006 07:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmUpp-0001Gt-CR for architecture-discuss@ietf.org; Tue, 21 Nov 2006 07:34:45 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmUpn-0006sT-5T for architecture-discuss@ietf.org; Tue, 21 Nov 2006 07:34:45 -0500 Received: from [71.254.21.62] (helo=JMHLap3.stevecrocker.com) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GmUpm-0003kU-QR for architecture-discuss@ietf.org; Tue, 21 Nov 2006 07:34:43 -0500 Message-Id: <7.0.1.0.0.20061121073103.035c35a0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 21 Nov 2006 07:34:40 -0500 To: architecture-discuss@ietf.org From: "Joel M. Halpern" Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? In-Reply-To: <4562CBC1.1000705@zurich.ibm.com> References: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> <24FD43BD-207B-44D9-9F73-4C19EC6AF649@nomadiclab.com> <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> <4562CBC1.1000705@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120be4af5f4a86229f8037d50832372f3a77c148ff696ae7f78350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.21.62 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 04:49 AM 11/21/2006, Brian E Carpenter wrote: >But, renumbering is simply multihoming on a relaxed time scale >(see RFC 4192). > >Personally, I think *roaming* is dynamic multi-homing, which >is a slightly different statement. > > Brian Clearly, renumbering and mobility are closely related. Renumbering has certain advantages (like the fact that you can count on / arrange overlap between the old and new numbering (connectivity, locators, etc.) One can, and some folks have built good answers were multi-homing is also akin to mobility. But it does not actual seem to me that the ability to get a useful currently defined locator / locator set is the same as the ability to update that locator / locator set on the fly among communicating parties. At the time scale of re-performing the identifier->locator mapping they ought to look the same. And it may be advantageous to make the updating mechanism inherent in the mapping maintenance mechanism. But that does not make them the same mechanism in terms of the architecture as we have usually discussed it. Yours, Joel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 08:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVcU-0002jP-OM; Tue, 21 Nov 2006 08:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVcT-0002jH-Iz for architecture-discuss@ietf.org; Tue, 21 Nov 2006 08:25:01 -0500 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmVcQ-0002XX-8n for architecture-discuss@ietf.org; Tue, 21 Nov 2006 08:24:59 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061121132455.JWKM13537.eastrmmtao03.cox.net@eastrmimpo02.cox.net>; Tue, 21 Nov 2006 08:24:55 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id pRPs1V00C0pnMhQ0000000; Tue, 21 Nov 2006 08:23:52 -0500 In-Reply-To: <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Tue, 21 Nov 2006 08:24:48 -0500 To: David Conrad X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 21 Nov 2006, at 01:21, David Conrad wrote: > On Nov 19, 2006, at 11:55 AM, RJ Atkinson wrote: >> Because Locators are not covered by AH/ESP in my model, and are >> not included in any state above the network layer, Locators would >> be mutable, at least conceptually. > > When I raised this approach before, people complained about MITM > and spoofing attacks. Maybe some people are confused then. MITM and spoofing attacks are possible today in the IP Internet -- unless one uses ESP/AH. Period. And there are ample CERT advisories (and equivalent advisories from organisations outside the US) that show such active attacks are practical. There exist non-cryptographic mechanisms that could virtually preclude off-path active attacks. To my mind, the security goal would be that the new approach does not significantly increase the risks versus the current approach, while retaining the ability to operate in a secured mode (as today with AH/ESP) if one wants to use cryptography. >> Shorter TTLS for the Locator records, to a TTL value appropriate >> for the frequency of layer-3 location changes, probably would >> obviate the need for such special-case forwarding. > > You get into a tradeoff here, between load on the DNS servers and > the ability for mapping changes to be implemented. I believe that > for scalability reasons, you want to keep a reasonable level of > caching. It is a fair question. My intuition is that the critical things to cache are the NS records, not the Locator records. This is best addressed by running some experiments in some friendly DNS Zones, so that one can talk about measurements rather than intuition. Yours, Ran rja@extremenetworks.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 08:28:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVg4-0004vy-I9; Tue, 21 Nov 2006 08:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVg3-0004ve-54 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 08:28:43 -0500 Received: from centrmmtao02.cox.net ([70.168.83.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmVg0-0002vz-Ry for architecture-discuss@ietf.org; Tue, 21 Nov 2006 08:28:43 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao02.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061121132841.VESX2490.centrmmtao02.cox.net@eastrmimpo02.cox.net>; Tue, 21 Nov 2006 08:28:41 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id pRTe1V00C0pnMhQ0000000; Tue, 21 Nov 2006 08:27:38 -0500 In-Reply-To: <4562CCB5.80700@zurich.ibm.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> <4562CCB5.80700@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CD5490F-7CDA-4D05-84E2-496CD0AED7AC@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Tue, 21 Nov 2006 08:28:35 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 21 Nov 2006, at 04:53, Brian E Carpenter wrote: > David Conrad wrote: >>> Because Locators are not covered by AH/ESP in my model, and are >>> not included in any state above the network layer, Locators would >>> be mutable, at least conceptually. >> When I raised this approach before, people complained about MITM >> and spoofing attacks. > > Hence the cryptographic protection of locator sets in shim6. This > problem is valid, but soluble as long as you have some state to > keep track of the locator set. If you attempt to do it stateless, > you are exposed. The proposed approach is no more exposed than ordinary IPv6 (without AH/ESP) is. I did not ever say "stateless". I simply said that nothing precluded a Locator from being rewritten -- and then in the next breath noted that nothing required a Locator to be rewritten either. The simple reality is that NAT/NAPT boxes exist and will continue to exist and they will continue to rewrite fields used for packet forwarding as those packets traverse the middle box. Perhaps people want to outline specific attacks that they believe would apply only to this new concept (or to SHIM6), but would not apply to ordinary IPv6 (without AH/ESP) ?? Yours, Ran _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 08:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmW93-0007Qu-EQ; Tue, 21 Nov 2006 08:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmW92-0007Qo-AV for architecture-discuss@ietf.org; Tue, 21 Nov 2006 08:58:40 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmW8y-0005jO-U4 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 08:58:40 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kALDwZb3157830 for ; Tue, 21 Nov 2006 13:58:35 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kALE1P2B2592806 for ; Tue, 21 Nov 2006 14:01:25 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kALDwY7T018659 for ; Tue, 21 Nov 2006 13:58:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kALDwYu9018640; Tue, 21 Nov 2006 13:58:34 GMT Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA65418; Tue, 21 Nov 2006 14:58:33 +0100 Message-ID: <45630609.9070706@zurich.ibm.com> Date: Tue, 21 Nov 2006 14:58:33 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [arch-d] thoughts References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> <4562CCB5.80700@zurich.ibm.com> <9CD5490F-7CDA-4D05-84E2-496CD0AED7AC@extremenetworks.com> In-Reply-To: <9CD5490F-7CDA-4D05-84E2-496CD0AED7AC@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Perhaps people want to outline specific attacks that they > believe would apply only to this new concept (or to SHIM6), > but would not apply to ordinary IPv6 (without AH/ESP) ?? In a word, session hijacking by injecting a fraudulent locator rewrite. It's distinct from simple source address spoofing because you can persuade Alice that Bob's address has changed. In many words, RFC 4218. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 09:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWFU-0000H2-Gj; Tue, 21 Nov 2006 09:05:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWFS-0000GV-Qf for architecture-discuss@ietf.org; Tue, 21 Nov 2006 09:05:18 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmWFQ-0006P0-5e for architecture-discuss@ietf.org; Tue, 21 Nov 2006 09:05:18 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GmWFC-0001Sk-Tz for architecture-discuss@ietf.org; Tue, 21 Nov 2006 06:05:04 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Nov 2006 15:04:45 +0100 To: Brian E Carpenter , David Conrad From: Jefsey_Morfin Subject: Re: [arch-d] thoughts In-Reply-To: <4562C973.1090103@zurich.ibm.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1310768850==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1310768850== Content-Type: multipart/alternative; boundary="----MThepttcbbcuujpltmivvdcbbfrfogjvii" ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-6DFE35B1 Dear Brian, you start being in tune with me about externets, continuity and relational spaces ... and ISO 3166, 639, etc. (see below) However do not go too far. The addresses of hardware belonging to a namespace are definitely virtual, but they indirectly relate to hardware, logical power, and people/people's agents and their characteristics, properties, and purposes must be kept in mind. This is why you do not consider the network chart but its current topology. And that externally what counts is not the way the network works, but the way the users collectively believe (brainware) it works. One of the layer violations in the WG-LTRU is that they confuse languages IDs and language names IDs. What you document here is that it is a basic mistake. The addresses do not relate to a machine, but to the number someone gave to that machine. This means that a machine may be "missing" but interfering, and a machine can have several numbers and addresses. This is why you can consider externets (external look-alike networks within the network system) as virtual hardware spaces. This is why you can consider the convergence of all the hardware systems as a single multitechnology/multinetwork continuity. This is also why you can consider all the users' relational spaces (real life human organised spaces of exchanges) as a manageable large multilateral system, however it is so big that as a mono-system it would be a very very large system subject to all the RFC 3439 complexity problems. This is why you MUST consider orthogonal address systems in each of these namespaces. This makes a three (even more if to support several addressing schemes) degree of liberty vector the scalars of each of its dimensions can be conveniently concatenated into an IPv6 address as I indicated. This way each scheme/routing/identification/serialisation information can be sequentially used (and encrypted) independently for analysis (what scheme), routing (net to net - can be simplified in being topology oriented), lodging (which system on the network - or new address to use in case of a mobile), access (which virtual location on the target system). With a routing table or computation function at the internetwork transit, at the network routing, at the user system access levels. If you use a routing computation function it can be located at the network DNS, locating the destination address (net and system) and providing the routing from the origin to the destination network (with all the necessary information/constraints for multi-....). At the destination network the local "DNSS" will route it to the system on the network or bounce it towards its real current address. Each time the user address segment can be encrypted. An externet will be an "physically empty" network made of its own net address, the group of destination systems, the class of accepted users, and their updated "DNSS" knowledge. jfc At 10:40 21/11/2006, Brian E Carpenter wrote: >Let me get absurd for a moment: > >David Conrad wrote: >>John, >>On Nov 17, 2006, at:14 PM, John Day wrote: >> >>>You need a logical and physical address spaces under >>>the application name space. >> >>Agreed. By analogy, I am suggesting the identifier space is the >>virtual address that is mapped into the locator space which is the >>physical address space. > >OK, we have layers, and the layers each have namespaces, which may or >may not be externally significant. But trying to say that one namespace >is virtual and another is physical strikes me as bogus; they are all >virtual. (MAC addresses aren't really physical - maybe you can consider >that the numbers on wall sockets are physical addresses, but even they >can be changed.) > >So I think we should consider all namespaces to be virtual or logical, >and not try to find a specific "physical" namespace. > >This makes it a lot easier to think about VPNs for example - they >merge and map parts of a namespace, but they are not 2nd class namespaces. > >>One might argue that the logical address space should be the >>fqdn, and in an ideal world, I might agree. However, >>pragmatically speaking, that won't fly as long as there are >>applications and protocol stacks that _know_ an "address" is 32 or >>128 bits and that certain bit patterns have special meanings. >> >>>The point of attachment id does not have to be global. >> >>No, but the mapping between the id and the locator must be globally >>unique. > >Define "global." In other words, what is the scope of the namespace >within which you require uniqueness? > > Brian > >It is possible to come up with a variety of mechanisms to >>ensure that global uniqueness, but since the amount of name >>space isn't an issue, it just seems simpler to require both id and >>locator be globally unique and avoid the question completely. >> >>>So quit trying to build solutions that make it work. They will >>>always be kludges. >> >>Well, yes. However, it is hard to boil the ocean. >>Rgds, >>-drc >> >>_______________________________________________ >>Architecture-discuss mailing list >>Architecture-discuss@ietf.org >>https://www1.ietf.org/mailman/listinfo/architecture-discuss > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/html Dear Brian,
you start being in tune with me about externets, continuity and
relational spaces ... and ISO 3166, 639, etc. (see below)

However do not go too far.  The addresses of hardware belonging to a
namespace are definitely virtual, but they indirectly relate to
hardware, logical power, and people/people's agents and their
characteristics, properties, and purposes must be kept in mind. This
is why you do not consider the network chart but its current
topology. And that externally what counts is not the way the network
works, but the way the users collectively believe (brainware) it works.

One of the layer violations in the WG-LTRU is that they confuse
languages IDs and language names IDs. What you document here is that
it is a basic mistake. The addresses do not relate to a machine, but
to the number someone gave to that machine. This means that a machine
may be "missing" but interfering, and a machine can have several
numbers and addresses.

This is why you can consider externets (external look-alike networks
within the network system) as virtual hardware spaces. This is why
you can consider the convergence of all the hardware systems as a
single multitechnology/multinetwork continuity. This is also why you
can consider all the users' relational spaces (real life human
organised spaces of exchanges) as a manageable large multilateral
system, however it is so big that as a mono-system it would be a very
very large system subject to all the RFC 3439 complexity problems.

This is why you MUST consider orthogonal address systems in each of
these namespaces. This makes a three (even more if to support several
addressing schemes) degree of liberty vector the scalars of each of
its dimensions can be conveniently concatenated into an IPv6 address
as I indicated.

This way each scheme/routing/identification/serialisation information
can be sequentially used (and encrypted) independently for analysis
(what scheme), routing (net to net - can be simplified in being
topology oriented), lodging (which system on the network - or new
address to use in case of a mobile), access (which virtual location
on the target system). With a routing table or computation function
at the internetwork transit, at the network routing, at the user
system access levels.

If you use a routing computation function it can be located at the
network DNS, locating the destination address (net and system) and
providing the routing from the origin to the destination network
(with all the necessary information/constraints for multi-....). At
the destination network the local "DNSS" will route it to the system
on the network or bounce it towards its real current address. Each
time the user address segment can be encrypted. An externet will be
an "physically empty" network made of its own net address, the group
of destination systems, the class of accepted users, and their
updated "DNSS" knowledge.

jfc

At 10:40 21/11/2006, Brian E Carpenter wrote:

>Let me get absurd for a moment:
>
>David Conrad wrote:
>>John,
>>On Nov 17, 2006, at:14 PM, John Day wrote:
>>
>>>You need a logical and physical address spaces under
>>>the  application name space.
>>
>>Agreed.  By analogy, I am suggesting the identifier space is the
>>virtual address that is mapped into the locator space which is the
>>physical address space.
>
>OK, we have layers, and the layers each have namespaces, which may or
>may not be externally significant. But trying to say that one namespace
>is virtual and another is physical strikes me as bogus; they are all
>virtual. (MAC addresses aren't really physical - maybe you can consider
>that the numbers on wall sockets are physical addresses, but even they
>can be changed.)
>
>So I think we should consider all namespaces to be virtual or logical,
>and not try to find a specific "physical" namespace.
>
>This makes it a lot easier to think about VPNs for example - they
>merge and map parts of a namespace, but they are not 2nd class namespaces.
>
>>One might argue that the logical address space should be the
>>fqdn,  and in an ideal world, I might agree.  However,
>>pragmatically  speaking, that won't fly as long as there are
>>applications and  protocol stacks that _know_ an "address" is 32 or
>>128 bits and that  certain bit patterns have special meanings.
>>
>>>The point of attachment id does not have to be global.
>>
>>No, but the mapping between the id and the locator must be globally
>>unique.
>
>Define "global." In other words, what is the scope of the namespace
>within which you require uniqueness?
>
>     Brian
>
>It is possible to come up with a variety of mechanisms to
>>ensure that global uniqueness, but since the amount of name
>>space  isn't an issue, it just seems simpler to require both id and
>>locator  be globally unique and avoid the question completely.
>>
>>>So quit trying to build solutions that make it work.  They will
>>>always be kludges.
>>
>>Well, yes.  However, it is hard to boil the ocean.
>>Rgds,
>>-drc
>>
>>_______________________________________________
>>Architecture-discuss mailing list
>>Architecture-discuss@ietf.org
>>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>

------MThepttcbbcuujpltmivvdcbbfrfogjvii-- --===============1310768850== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1310768850==-- From architecture-discuss-bounces@ietf.org Tue Nov 21 12:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZhe-0007VM-Fr; Tue, 21 Nov 2006 12:46:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZhd-0007Pq-RU for architecture-discuss@ietf.org; Tue, 21 Nov 2006 12:46:37 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmZha-0003E7-Ap for architecture-discuss@ietf.org; Tue, 21 Nov 2006 12:46:35 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kALHgerG052793; Tue, 21 Nov 2006 09:42:46 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 21 Nov 2006 09:46:05 -0800 X-PGP-Universal: processed; by terminus.local on Tue, 21 Nov 2006 09:46:05 -0800 In-Reply-To: <4562CBC1.1000705@zurich.ibm.com> References: <244271E1-CF58-4589-B7AD-9A3A155CABF5@nomadiclab.com> <24FD43BD-207B-44D9-9F73-4C19EC6AF649@nomadiclab.com> <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> <4562CBC1.1000705@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <576DECE8-FF24-4F78-BC63-583750614904@virtualized.org> From: David Conrad Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Date: Tue, 21 Nov 2006 09:45:57 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian, On Nov 21, 2006, at 1:49 AM, Brian E Carpenter wrote: >> Mobility is simply renumbering on a constrained time scale. > But, renumbering is simply multihoming on a relaxed time scale > (see RFC 4192). This is getting a bit far afield, however I disagree. Multi-homing, particularly in the 4192 case, is a way of renumbering without risking the interruption of connectivity. It permits "make before break", that is "make a new connection before breaking the old connection" as opposed to "break before make" which is necessary if you do not support multi-homing. You _can_ implement mobility without multi-homing since the Internet is datagram based, relying on the remote side to retransmit any packets that might have been dropped while the renumbering event occurs. Not that you'd want to, of course. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 16:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmcor-0000ir-V0; Tue, 21 Nov 2006 16:06:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmcoq-0000iZ-CO for architecture-discuss@ietf.org; Tue, 21 Nov 2006 16:06:16 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmcoo-0003Cy-QO for architecture-discuss@ietf.org; Tue, 21 Nov 2006 16:06:16 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kALL2KrG053135; Tue, 21 Nov 2006 13:02:25 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 21 Nov 2006 13:05:43 -0800 X-PGP-Universal: processed; by terminus.local on Tue, 21 Nov 2006 13:05:43 -0800 In-Reply-To: <4562C973.1090103@zurich.ibm.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> From: David Conrad Subject: Re: [arch-d] thoughts Date: Tue, 21 Nov 2006 13:05:37 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian, On Nov 21, 2006, at 1:40 AM, Brian E Carpenter wrote: >> No, but the mapping between the id and the locator must be >> globally unique. > Define "global." In other words, what is the scope of the namespace > within which you require uniqueness? Good question. I have implicitly assumed there is a "global" scope that encompasses all potential entities prepared to communicate end-to-end. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 16:33:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdEL-0006wK-8L; Tue, 21 Nov 2006 16:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdEJ-0006wA-UM for architecture-discuss@ietf.org; Tue, 21 Nov 2006 16:32:35 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmdE2-0001HQ-QW for architecture-discuss@ietf.org; Tue, 21 Nov 2006 16:32:35 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc15) with ESMTP id <2006112121321801500pulc5e>; Tue, 21 Nov 2006 21:32:18 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> Date: Tue, 21 Nov 2006 16:25:20 -0500 To: David Conrad , Brian E Carpenter From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 13:05 -0800 2006/11/21, David Conrad wrote: >Brian, > >On Nov 21, 2006, at 1:40 AM, Brian E Carpenter wrote: >>>No, but the mapping between the id and the locator must be globally unique. >>Define "global." In other words, what is the scope of the namespace >>within which you require uniqueness? > >Good question. > >I have implicitly assumed there is a "global" scope that encompasses >all potential entities prepared to communicate end-to-end. We could say that "global" is defined by the fact that there is no scope greater. ;-) That is only half in jest. That *is* what it is, but you always have to allow for a larger one appearing. One of the things I have noticed with assignment of IP addresses is that we didn't start distinguishing between internet and Internet soon enough. In other words, that IP addresses were only being assigned for use on the public Internet. Those internets not connected to the public Internet did not need addresses from that space. Later of course we sort of recognized that with private addresses, but by that time we had allocated large blocks to internets. So in some sense, "global" might be the public Internet. However, if we had an "application name space" with a scope that encompassed the public Internet and internets as well. We could do relaying in the application layer across NATs, i.e. forwarding on application names. Now given that application names were suppose to be location-independent, that would seem to scale very well. Although it didn't bother us for along time that IP addresses were location-independent. So, I would global is the biggest scope you feel like worrying about! ;-) Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 17:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmdhe-000315-Cz; Tue, 21 Nov 2006 17:02:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmdhd-00030q-6D for architecture-discuss@ietf.org; Tue, 21 Nov 2006 17:02:53 -0500 Received: from eastrmmtao05.cox.net ([68.230.240.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GmdhZ-0004QL-Ha for architecture-discuss@ietf.org; Tue, 21 Nov 2006 17:02:52 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao05.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061121220251.CJLQ18065.eastrmmtao05.cox.net@eastrmimpo01.cox.net>; Tue, 21 Nov 2006 17:02:51 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id pa1z1V00n0pnMhQ0000000; Tue, 21 Nov 2006 17:02:00 -0500 In-Reply-To: <45630609.9070706@zurich.ibm.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> <4562CCB5.80700@zurich.ibm.com> <9CD5490F-7CDA-4D05-84E2-496CD0AED7AC@extremenetworks.com> <45630609.9070706@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4024408D-0AE0-47A5-BA3A-DEA929DC4C08@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [arch-d] thoughts Date: Tue, 21 Nov 2006 17:02:43 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.8 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 21 Nov 2006, at 08:58, Brian E Carpenter wrote: >> Perhaps people want to outline specific attacks that they >> believe would apply only to this new concept (or to SHIM6), >> but would not apply to ordinary IPv6 (without AH/ESP) ?? > > In a word, session hijacking by injecting a fraudulent > locator rewrite. It's distinct from simple source address > spoofing because you can persuade Alice that Bob's address > has changed. > > In many words, RFC 4218. Thanks very much for being specific. :-) I'd prefer to avoid delving into mechanism, so I'm going to remain somewhat abstract here for the moment. I have been thinking about the security issues that could lurk in any change. OK. Lets go through the case analysis for the Section on "Potential New Attacks" (Section 4 of RFC-4218): 4.1: RFC text says this is an existing threat to existing IP if the attacker is on-path. It also says the main concern is with off-path attackers. I've mentioned that non-cryptographic means exist to mitigate would-be off path attacks. (Of course, and I won't repeat it each time below, one can always use AH to authenticate any control message if one wants strong cryptography.) So this isn't an issue for what I've been discussing. 4.1.1: The RFC text says that solving this requires the existence of some practical to authenticate "I have moved" messages, rather than blindly trusting non-authenticated messages. That seems reasonable to me. Such mechanisms exist. So this isn't an issue either. 4.1.2: This says that if an on-path attacker moves off path, there ought to be a time-limit to the attackers continued ability to engage in an on-path-like attack on a session. The non-cryptographic methods can handle this case, too. 4.1.3: If B behaves properly, B will use DNS (with DNS Security) to authenticate any Identifier and Locator information associated with A. So attacker X won't be able to just tell B "I'm A and this is my location" and have any success. So this isn't an issue either. 4.1.4: This says control protocols ought not be vulnerable to replay attacks where the replay attempt is some non-trivial time after the initial packets. The non-cryptographic authentication can handle this. AH can also handle this. 4.2: A variant on one of the above, differing only in that instead of re-routing a packet to an attack node, the packet gets re-routed to a black-hole. Solution is the same as for the initial version above. 4.3: This has to do with attacker X causing intended victim A to send packets really intended for B towards C instead. The same DNS mechanisms used for 4.1.3 above eliminate this risk. (ASIDE: While the ability to engage in this attack at the network layer is more limited than at the application layer, this kind of (D)DOS attack is actually pretty commonly seen using application layer protocols today.) 4.3.1: The DNS solution works. An even simpler solution is described in the RFC. 4.3.2: This is a variant with on-path help. On-path help doesn't matter if one uses the DNS mechanisms in 4.1.3. Also, note that without DNS Security, this attack works fine today where the on-path attacker Y modifies the DNS responses heading for A to replace correct information with incorrect information. So it isn't a new risk if one chooses not to use DNS security. Other solutions are also outlined in the RFC. 4.4: Ingress filtering, while highly desirable, is not commonly deployed within ISPs. It is somewhat more commonplace at the edge, but it is not nearly as common as one would like it to be. So, in practice, source address forgery is not uncommon today in (D)DOS attacks that have been seen in the wild and reported upon by people like CERT. The RFC text acknowledges this in the 2nd paragraph of 4.4. In the same places where it is practical to deploy ingress address filtering today, it would be practical to deploy Locator filtering in the new concept. So there is no real change here. Other mitigation techniques are also described within 4.4. 4.5: The RFC suggests having multiple Identifiers concurrently would be a solution to the issues in this section. I have already said that in my concept a node could have more than one Identifier concurrently. 5: This does not discuss a specific vulnerability, instead its a general discussion of architectural issues. 6: Same as 5. I hope I didn't miss some case in the above analysis. If I did overlook one, I'm sure someone will point it out. Yours, Ran rja@extremenetworks.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 21:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmhkm-0004VK-4R; Tue, 21 Nov 2006 21:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmhkl-0004VA-8k for architecture-discuss@ietf.org; Tue, 21 Nov 2006 21:22:23 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmhkj-0005RM-U0 for architecture-discuss@ietf.org; Tue, 21 Nov 2006 21:22:23 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAM2MJI5015118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Nov 2006 18:22:19 -0800 Received: from [10.0.1.7] (vpn-10-50-0-31.qualcomm.com [10.50.0.31]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAM2MHmf007768; Tue, 21 Nov 2006 18:22:18 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> Date: Tue, 21 Nov 2006 18:22:16 -0800 To: John Day , David Conrad , Brian E Carpenter From: Ted Hardie Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 4:25 PM -0500 11/21/06, John Day wrote: >One of the things I have noticed with assignment of IP addresses is that we didn't start distinguishing between internet and Internet soon enough. In other words, that IP addresses were only being assigned for use on the public Internet. Those internets not connected to the public Internet did not need addresses from that space. As point of history, this was, at least at one point, a policy choice that was made quite openly. It was not an accident. During the period when I was at the SRI-NIC, the policy was to actively encourage folks who were using IP to get allocations. This was designed to make things easier if they were later to connect their networks to the Internet (in other words, to save them renumbering). It went along with an active effort to reclaim IP space that was not being used at all, so it was not completely wasteful. You would have to talk to someone much further up the food chain than I was to get the real details of why that policy was in place, but my naive view at the time (retained to now) was that it was part of an effort to encourage experimentation with IP and to extoll IP's "network effect" of connected sites. regards, Ted _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 21 21:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmi1T-0007S7-Hc; Tue, 21 Nov 2006 21:39:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmi1S-0007S2-KY for architecture-discuss@ietf.org; Tue, 21 Nov 2006 21:39:38 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmi1R-00009p-CU for architecture-discuss@ietf.org; Tue, 21 Nov 2006 21:39:38 -0500 Received: from [10.0.1.18] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061122023925b1400s8pnge>; Wed, 22 Nov 2006 02:39:36 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> Date: Tue, 21 Nov 2006 21:39:13 -0500 To: Ted Hardie , John Day , David Conrad , Brian E Carpenter From: John Day Subject: Re: [arch-d] thoughts Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Yes, that is all is well known. The point is that at some point the emphasis shifted and the 'Net took quite awhile (if they really have) to shift from a loose collection of cooperating researchers to "administering a production network." In some sense, it has been an experimental network since IP was deployed and probably long before that. If I had to guess there was probably some resistance (internally, i.e. we didn't want to admit) to the idea that we were no longer doing research and were minding a large network. ;-) At 18:22 -0800 2006/11/21, Ted Hardie wrote: >At 4:25 PM -0500 11/21/06, John Day wrote: >>One of the things I have noticed with assignment of IP addresses is >>that we didn't start distinguishing between internet and Internet >>soon enough. In other words, that IP addresses were only being >>assigned for use on the public Internet. Those internets not >>connected to the public Internet did not need addresses from that >>space. > >As point of history, this was, at least at one point, a policy choice that was >made quite openly. It was not an accident. During the period when I >was at the SRI-NIC, the policy was to actively encourage folks who were >using IP to get allocations. This was designed to make things easier if >they were later to connect their networks to the Internet (in other words, >to save them renumbering). It went along with an active effort to reclaim >IP space that was not being used at all, so it was not completely wasteful. > >You would have to talk to someone much further up the food chain than >I was to get the real details of why that policy was in place, but my naive >view at the time (retained to now) was that it was part of an effort to >encourage experimentation with IP and to extoll IP's "network effect" >of connected sites. > regards, > Ted _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 22 04:38:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmoW7-00083Q-7a; Wed, 22 Nov 2006 04:35:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmoW5-00083G-F9 for architecture-discuss@ietf.org; Wed, 22 Nov 2006 04:35:41 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmoW4-0004Vb-2Y for architecture-discuss@ietf.org; Wed, 22 Nov 2006 04:35:41 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kAM9ZaeE082556 for ; Wed, 22 Nov 2006 09:35:36 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAM9cRLj2248738 for ; Wed, 22 Nov 2006 09:38:27 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAM9ZZE0017590 for ; Wed, 22 Nov 2006 09:35:36 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAM9ZZJJ017584; Wed, 22 Nov 2006 09:35:35 GMT Received: from zurich.ibm.com (chv04513.de.ibm.com [9.145.132.236]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA66346; Wed, 22 Nov 2006 10:35:34 +0100 Message-ID: <456419E6.3010604@zurich.ibm.com> Date: Wed, 22 Nov 2006 10:35:34 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [arch-d] thoughts References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <0304EC36-7AF7-4A5F-9E6F-F439CBF7074D@extremenetworks.com> <9B94C9C8-C0B5-4177-A164-C3BBBBFE9841@virtualized.org> <537CAA98-95D0-4449-8D4B-909A54E72270@virtualized.org> <4562CCB5.80700@zurich.ibm.com> <9CD5490F-7CDA-4D05-84E2-496CD0AED7AC@extremenetworks.com> <45630609.9070706@zurich.ibm.com> <4024408D-0AE0-47A5-BA3A-DEA929DC4C08@extremenetworks.com> In-Reply-To: <4024408D-0AE0-47A5-BA3A-DEA929DC4C08@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Ran, RJ Atkinson wrote: > > On 21 Nov 2006, at 08:58, Brian E Carpenter wrote: > >>> Perhaps people want to outline specific attacks that they >>> believe would apply only to this new concept (or to SHIM6), >>> but would not apply to ordinary IPv6 (without AH/ESP) ?? >> >> >> In a word, session hijacking by injecting a fraudulent >> locator rewrite. It's distinct from simple source address >> spoofing because you can persuade Alice that Bob's address >> has changed. >> >> In many words, RFC 4218. > > > Thanks very much for being specific. :-) > > I'd prefer to avoid delving into mechanism, so I'm going to > remain somewhat abstract here for the moment. I have been > thinking about the security issues that could lurk in any change. > > OK. Lets go through the case analysis for the Section on > "Potential New Attacks" (Section 4 of RFC-4218): And I believed you when you used to deny having security expertise :-) Yes. At a quick glance, I think you're correct and all these threats can be countered; indeed the shim6 security mechanism is designed to do so (and there are no doubt other ways of doing so). So these threats don't prevent us from using relocator rewriting. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 22 09:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmsst-0006ut-Ud; Wed, 22 Nov 2006 09:15:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmsss-0006uo-TW for architecture-discuss@ietf.org; Wed, 22 Nov 2006 09:15:30 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmssn-0006JK-Kp for architecture-discuss@ietf.org; Wed, 22 Nov 2006 09:15:30 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0DCF034126; Wed, 22 Nov 2006 09:15:32 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 09:15:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] thoughts Date: Wed, 22 Nov 2006 09:15:22 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E4DC@tayexc14.americas.cpqcorp.net> In-Reply-To: <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] thoughts Thread-Index: AccNsQU+kcJ5FkyqTKS0hOcKaGWz2wAiK/Ew From: "Bound, Jim" To: "David Conrad" , "Brian E Carpenter" X-OriginalArrivalTime: 22 Nov 2006 14:15:24.0220 (UTC) FILETIME=[A6C877C0:01C70E40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I think global is required David and I like your initial proposal too, and Ran's too the diff is important to analyze between the two. Some points from the many mails and use cases are important for this work. If I am first responder and I move to different location IP topology (I agree with Noel on this word but the only one I can think of right now) my locator has to change because of this movement, but the identifier should remain the same. If I am NATO spec op force entity and I have to move to different geography my locator changes there too. I believe the identifiers have to be globally unique but realize that is going to be hard to do regarding what value can be used? NB: all - I thought we were supposed to move to RAM list for this discussion? =20 /jim=20 > -----Original Message----- > From: David Conrad [mailto:drc@virtualized.org]=20 > Sent: Tuesday, November 21, 2006 4:06 PM > To: Brian E Carpenter > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] thoughts >=20 > Brian, >=20 > On Nov 21, 2006, at 1:40 AM, Brian E Carpenter wrote: > >> No, but the mapping between the id and the locator must be=20 > globally =20 > >> unique. > > Define "global." In other words, what is the scope of the namespace=20 > > within which you require uniqueness? >=20 > Good question. >=20 > I have implicitly assumed there is a "global" scope that=20 > encompasses all potential entities prepared to communicate end-to-end. >=20 > Rgds, > -drc >=20 >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 01:38:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8CW-0002iw-5V; Thu, 23 Nov 2006 01:36:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8CT-0002iU-VG; Thu, 23 Nov 2006 01:36:45 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn8CS-0002qI-Eq; Thu, 23 Nov 2006 01:36:45 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E50972130AC; Thu, 23 Nov 2006 08:36:38 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 30C022130A6; Thu, 23 Nov 2006 08:36:38 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0225975A-1979-409D-9B82-9EB24071C219@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Last Call comments on draft-laganier-ipv6-khi-05 ORCHID Date: Thu, 23 Nov 2006 08:36:43 +0200 To: Jarno Rajahalme X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: architecture-discuss@ietf.org, Julien Laganier , IESG IESG , IETF Discussion X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jarno, Thanks for your valuable comments. While I largely agree with you, I'm afraid that what you ask below, and what we originally asked for in the first versions of the ORCHID draft, are just too much for the wider IETF community to swallow at this point of time. In other words, the original version of the ORCHID draft asked for more than the current one; not exactly in the way you did in your message, but still. The current draft represents a consensus that was achieved at the Internet Area mailing list. A watered down consensus if you will, but, hey, this is the IETF. :-) A few details: > - 1st of all, the ORCHID proposal is contradicting itself. It calls > for conformity with RFC 3513 section 2.5.4, but breaks this: > > "All global unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), " > > - Therefore it is wrong to ask for allocation under IANA Special > Purpose Address Block (which starts with binary 001). > > - ORCHID should ask for something like 0400::/6 (binary 0000 01), > claiming 1/8 of the address space starting with binary 000 We originally asked for 1000::/8 (binary 0001 0000), which falls within the binary 000. Then there would have been 120 bits of the hash, instead of the kind-of regional structure that you propose. Personally, I still think that the 100 bits of hash is problematic. It won't take that long before it will be vulnerable to brute force attacks. By Moore's law, 120 bits would give us some 20-30 years more. But that was deemed unsuitable by some old-time IETFers, including a former member of the IAB. Basically, if I understood correctly, the original proposal was felt to overstep the RIR policies. Secondly, apparently, some people feared that it would open up the floodgates to the 0000::/3 space, which was considered politically very bad. There were corridor rumours of fears that if this experiment was given something, then other SDOs would come and ask for similar pieces of space for non-addressing purposes. Personally, I don't understand what would be so bad there. But hey, apparently I don't understand the IETF power politics in any case; that I have bitterly felt enough of times. Hence, as I stated above, the current proposal is the compromise we were able to reach. Personally, I still think that allocation from 0000::/3 would be better than what we ask for in the current draft. As you indicated later, it would to make a distinction between ORCHIDs/Identifiers and "mere" addresses. However, at least one of the IESG members seems to think that there is no difference on where the prefix is allocated, from the apps point of view, and apparently not worth doing due to the reasons stated above. But I may be misreading people's words. On the other hand, personally, I think RFC 3513 makes a potential difference. > - Maybe should be asked for limited time experimentation (e.g. 5 > years), and all systems could be mandated to cease using these > addresses after the dead line. Unless the status is changed > before expiration? That is exactly what we asked for originally: a time-limited experiment, with by-default cease of use. Again, that was removed as a part of the drafting process. > The hash function will need to be changed to include the prefix > as input. I think that change was already done as per security review, but my memory may fail here. Julien took care of that change. > If I recall right, one of the expressed concerns against ORCHID has > been semantical overloading. By using address space starting with > binary 000 this overloading is avoided. I completely agree with you here, but some other people seem to bitterly disagree. --Pekka Nikander PS. I don't read ietf-discuss. If you want your replies to reach me, please include my personal address in the CC/To field. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 01:47:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8MF-00071u-Sv; Thu, 23 Nov 2006 01:46:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8MD-00071B-9B for architecture-discuss@ietf.org; Thu, 23 Nov 2006 01:46:49 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn8MB-0005Fz-EP for architecture-discuss@ietf.org; Thu, 23 Nov 2006 01:46:48 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BE1B221310A; Thu, 23 Nov 2006 08:46:46 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 403472130AD; Thu, 23 Nov 2006 08:46:46 +0200 (EET) In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <41E83450-2C92-4971-9E16-A3063F2CECC6@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E5C8504-41EA-4070-A8F5-1AA935B7DA74@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] SLS/IRIS, the handle system, and other potential DNS replacements (was Re: thoughts) Date: Thu, 23 Nov 2006 08:46:51 +0200 To: Ted Hardie X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Ted, At 11:16 AM +0200 11/20/06, Pekka Nikander wrote: >> There are lots of problems with FQDNs. Consequently, there is a >> lot of pressure to gradually get rid of the FQDNs in the >> application space, and to replace them with something better. >> Unfortunately, my knowledge of the efforts in the application >> space are very limited, but my understanding is that some of the >> the CRISP/IRIS effort aims to experiment in an alternative space. On Nov 21, 2006, at 2:06, Ted Hardie wrote: > I am fairly familiar with CRISP (the WG) and IRIS (the protocol), > but I do not > understand what you mean by this. Nothing in either attempts to > get rid > of FQDNs in application space, as far as I know. I must have misunderstood what Leslie said while I was at the IAB. IIRC, when we discussed some of the problems with the DNS, Leslie told us that some folks are trying to address some of the issues through IRIS and SLS. IIRC, she also told that it is painful and slow progress. Another piece of technology which was mentioned was the Handle system. SPKI/SDSI was also briefly mentioned, but some vocal IAB members readily offered their opinion that SPKI is dead and buried. That's basically all that I know. But my memory is probably failing here; it's over a year ago when that discussion took place. And, of course, to clarify, all this was unofficial discussions and have nothing to do with what the IAB is or does, even though there happened to be IAB members that were discussing. Sorry for the confusion. On the other hand, if someone could point out to any serious work in that space, I'd be very glad to spend some cycles in trying to understand. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 05:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBvS-0004O2-DQ; Thu, 23 Nov 2006 05:35:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBvQ-0004Nu-U0 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 05:35:24 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnBvP-0005Qe-La for architecture-discuss@ietf.org; Thu, 23 Nov 2006 05:35:24 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 23A4D21310A for ; Thu, 23 Nov 2006 12:35:15 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2E9222130AD for ; Thu, 23 Nov 2006 12:35:12 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <1122001D-83BE-408E-A11E-E21A0C8F6909@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Pekka Nikander Date: Thu, 23 Nov 2006 12:35:18 +0200 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Subject: [arch-d] Thoughts about mobility, multi-homing, and architecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John Day and I have expressed our opinions that mobility and multi- homing are architecturally similar, implying that maybe we could address them in a unified way. Some people disagreed. I think much depends on your point of view, and in this message I try to clarify that. In a way, I am restating much which Joel already stated, but from a subtly different point of view, trying both to dive still somewhat deeper and to expand the discussion to application-level aspects. Unfortunately, in order to get to my point, I must start from quite far away. Hence, for the impatient, it may be better to read this rather long message in the reverse order, starting from the discussion (search for "Discussion") and then referring back to the assumptions. Starting point ============== As a starting point, I take the following premises or assumptions: A1. Application-level resources are the main entities we are interested in. They may be named in different ways, the exact details of which is outside the scope of the current focus. A2. Application-level entities are often logically aggregated due to different factors, including fate sharing, security privileges, mobility, etc. This application-level aggregation should be kept distinct from network-address-level aggregation. A3. The routing system is based on the hop-by-hop paradigm, where the routers have forwarding tables that use routing-level addresses as input for the forwarding decision. A4. Completely flat addressing is out of scope due to practical constraints to the forwarding tables and the routing system. A5. To implement A4, the routing-level addresses (locators) are somehow aggregateable. That is, the addressing name space has internal structure (topology) that allows a larger or "more- aggregated" address range (e.g. one with a shorter prefix) to denote an area that confines a number of smaller or "less-aggregated" address ranges (e.g. ones with longer prefixes). [Note that this definition does not mandate a tree-like addressing name space topology that we have today, but still allows it.] Now, theoretically speaking, as the purpose of the aggress aggregation is to embed into the address some partial information about the location of the said address within the network graph, thereby relieving some burden from the forwarding tables and routing system, it immediately follows that the parts of the network graph where an address may be located at is confined by the address itself. In more practical terms, the addresses become names of locations within the network graph, i.e., locators. That is, given a specific address, there are only a limited number of locations within the network graph where the address may "be". In a typical system, such as those used today for IPv4 and IPv6, that "limited number of locations" equals to the subnet identified by the address prefix. Still more practically, what I mean is that due to the assumptions made about the forwarding parading and network layer addressing, the addresses in the system are names of locations (points of attachment) in the network, and not e.g. location-independent names of mobile hosts. Basics of multi-homing ====================== This structure leads to a situation where we apparently must make a distinction between two different types of "multi-path"*: P1. In the network graph, there may be alternative routing paths between two areas that are named with some given, unique address ranges. In today's terms, this would be reflected by having multiple routing table entries for a given prefix. This is what Joel called "multi-pathing" in his message (http://www1.ietf.org/mail-archive/web/ architecture-discuss/current/msg00682.html ). P2. In the network graph, there may be areas (including single nodes) that are identified by more than one address ranges. This is what Joel called "multi-homing". Note that the underlying network graph may be identical in cases P1 and P2. The only difference is how we decide to name locations, i.e., in address assignment. In P1 we assign only one range of addresses to the "multi-homed" location while in P2 we assign two or more. Further note that this naming decision is apparently motivated by the assumptions A4 and A5, in an attempt to make the address space topology and the topology of the network graph match in such a way that the size of the routing and forwarding tables can be reduced. [Footnote *) This is a point where I hope to be wrong. Making the distinction between multi-path at the routing level vs. multi-path at a level above does not "feel" nice. However, to me this seems to be an implication from assumptions A3-A5. Finding alternative solutions would be very good, but given the constraints on the size of the forwarding/routing tables, propagation times, and routing computation, I find it unlikely that any practical alternatives exist.] To summarise so far: Using hop-by-hop forwarding with aggregateable addresses leads to a situation where "area" (subnet) multi-homing can be solved either by adding alternative routes into the routing table or assigning multiple address ranges. Nothing new. Just dissecting the background assumptions. Generalisation I, or Application Multi-homing ============================================= So far we have only considered the network graph and the addressing name space. Let us now consider application-level entities. An application-level entity (resource) may be distributed, or be available through multiple points at the network graph. For example, the underlying server host may be multi-homed, the application entity may be location-dependent and implemented at several distinct server hosts, or the entity may be genuinely distributed and implemented by a distributed server farm. Now we seem to have even more choices than in the case of network- graph-level multi-homing. I'll describe these as chains of identifiers. C1. Top-most entity name -> One "multi-pathed" address (P1) -> Alternative routes C2. Top-most entity name -> Multiple alternative addresses (P2) -> One route C3. Top-most entity name -> Multiple alternative intermediate entity names (e.g. host names) -> P1 -> One Route Of course, if supported by the underlying system, these levels of flexibility can be combined: C4. Top-most entity name -> Alternative super-entity names -> P2 -> Alternative routes [Of course, intermediate indirections (C3) may be recursive.] To summarise and generalise the discussion so far, we can state that from a high-level architectural point of view, multi-homing is nothing more one-to-many mappings as one resolves higher-layer identifiers into lower-layer identifiers. The differences lie when there are one-to-many mappings and when simple one-to-one mappings. Considering a single indirection step, the most important design choice then is when, exactly, one of the alternative lower-layer identifiers is chosen for the purposes of delivery. To summarise the more-than-two-decades old wisdom: Be lazy, bind late. Mobility ======== Consider now mobility. From the present point of view, we can state that mobility is nothing more than dynamic mappings as one resolves higher-layer identifiers into lower layer identifiers. Analogous to the multi-homing chains C1-C4 above, we can present mobility chains: M1. Stable entity name -> Stable address -> Dynamic route updates (host routing) M2. Stable entity name -> Dynamic, updateable address -> Stable routes M3. Stable entity name -> Dynamic, updateable intermediate entity name -> Stable address -> Stable routes M4. Stable entity name -> Dynamic super-entity name -> Dynamic address -> Dynamic route I will skip the longer discussion here, as it would be isomorphic to the multi-homing discussion above, merely replacing mapping alternatives with temporal dynamics. MANETs are prototypical examples of M1. NetLMM can be also considered as a peculiar example of M1. MIP, NEMO, HIP (and potentially SHIM6 based mobility) are all examples of M2, with just different choices for the name spaces. I am not aware of any major examples of M3, but I could imagine they could be found in various middleware frameworks. And I think SIP could also offer such examples. Discussion ========== By now, the structural (architectural?) parallels between multi- homing and mobility should be clear: Layer Multi-homing Mobility Routing Traditional, routing- Micro mobility based site multi-homing e.g. MANETs Routing- (GSE?) So called edge mobility, Addressing e.g. NetLMM boundary Addressing Multi-address multi-homing, Most node mobility protocols, e.g. SHIM6, GSE e.g. MIP and HIP Tunnelling-based solutions, e.g. NEMO and MOBIKE Application- Multiple A/AAAA RRs DynDNS Addressing boundary Renumbering, (but on a different time scale) Application Distributed applications, Application mobility, e.g. location dependent ones e.g. process migration [Footnote: I am not sure about the "right" positioning of GSE. The position of NetLMM could also be discussed; I'd be tempted to classify it as a "routing" solution, but others apparently disagree.] Hence, it is this point of view that I say that mobility and multi- homing are architecturally quite similar. There is one thing that I haven't considered at all, on purpose: Time scales, including make-before-break vs. break-before-make. They make a difference. But that's one level down towards the details, in my opinion. They are still architectural, but not the highest point of view. Anyway, this message is long enough already now; the differences would warrant a separate message. The big question is whether the similarities and co-occurring usage scenarios are plausible enough so that mobility and multi-homing should be handled in an architecturally unified way, or whether the differences are so big and the phenomena so separate that the added minor complexity does not pay off. By now you should be able to guess my current opinion. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 06:05:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCNe-00026y-1I; Thu, 23 Nov 2006 06:04:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCNc-00023R-Gc for architecture-discuss@ietf.org; Thu, 23 Nov 2006 06:04:32 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnCNa-0002h1-0f for architecture-discuss@ietf.org; Thu, 23 Nov 2006 06:04:32 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 51A9F2130AC; Thu, 23 Nov 2006 13:04:29 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 34B132130A6; Thu, 23 Nov 2006 13:04:27 +0200 (EET) In-Reply-To: References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9497D679-8957-45D2-BBB3-6A291690B506@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts) Date: Thu, 23 Nov 2006 13:04:33 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org There's been some discussion on how to define "global" and "virtual" when speaking about identifiers, names, and name spaces. I must be missing something because I think we could have pretty simple definitions for both "global" and "virtual", both given below. However, we first have to understand a crucial point: An identifier is meaningless without a defining context. That is, an identifier is merely an non-interpretable string of bits unless we know the context in which we should understand it. Given this, we perhaps could define as follows: An identifier is global iff there is only one possible context in which we can interpreting it. That is, if an identifier drawn from a name space will always be interpreted in the same way, yielding the same behaviour, independent on where (and when?) it is used, then it is global. Along the same lines: An identifier is virtual iff there is a separate context, different from the "usual" context, in which we will interpret the identifier. That is, identifiers are "virtual" (as opposed to "real") if they are interpreted using some given, "virtual" context, different from the default context where they would be interpreted without virtualisation. This seems to match with our typical usage: - a virtual memory address is interpreted in terms of the MMU translation tables instead of being directly handled by the demultiplexing logic at the chip select and chip level - a VPN address is interpreted in terms of the routing internal to the VPN instead of being interpreted in terms of the global routing table --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 07:38:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDok-0004Ia-Lx; Thu, 23 Nov 2006 07:36:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnDoi-0004Hz-Sq for architecture-discuss@ietf.org; Thu, 23 Nov 2006 07:36:37 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnDoh-00012I-KQ for architecture-discuss@ietf.org; Thu, 23 Nov 2006 07:36:36 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20061123123624b1200mubgne>; Thu, 23 Nov 2006 12:36:34 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <9497D679-8957-45D2-BBB3-6A291690B506@nomadiclab.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> <9497D679-8957-45D2-BBB3-6A291690B506@nomadiclab.com> Date: Thu, 23 Nov 2006 07:36:16 -0500 To: Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 13:04 +0200 2006/11/23, Pekka Nikander wrote: >There's been some discussion on how to define "global" and "virtual" >when speaking about identifiers, names, and name spaces. I must be >missing something because I think we could have pretty simple >definitions for both "global" and "virtual", both given below. > >However, we first have to understand a crucial point: > > An identifier is meaningless without a defining context. Yes, in the past we have used "name" for this as the most general form of label. And always reserved "identifier" for things that we saw as short and probably numeric. But that was really a fairly informal convention. > >That is, an identifier is merely an non-interpretable string of bits >unless we know the context in which we should understand it. Agreed. When a name is defined, sorry identifier, one must also define what it names, the name space from which the names are taken, and the scope of the name. > >Given this, we perhaps could define as follows: > > An identifier is global iff there is only one possible context in >which we can interpreting it. Yes. The universal set in a different guise. >That is, if an identifier drawn from a name space will always be >interpreted in the same way, yielding the same behaviour, >independent on where (and when?) it is used, then it is global. If you add "when applied within the defined scope of the name space" then you have the general definition. >Along the same lines: > > An identifier is virtual iff there is a separate context, >different from the "usual" context, in which we will interpret the >identifier. I would prefer not to use this. I had used it before as analogy with operating systems to give an idea of what we needed to do. To help people think about it. This is where defining scope becomes important. In this sense, virtual is only virtual ;-) in the sense that higher layers of naming represent a higher level of abstraction than lower ones. But here I don't think the abstraction is as important as the property that scope tends to increase as one moves up in the layers. > >That is, identifiers are "virtual" (as opposed to "real") if they >are interpreted using some given, "virtual" context, different from >the default context where they would be interpreted without >virtualisation. > >This seems to match with our typical usage: > >- a virtual memory address is interpreted in terms of the MMU >translation tables instead of being directly handled by the >demultiplexing logic at the chip select and chip level > >- a VPN address is interpreted in terms of the routing internal to >the VPN instead of being interpreted in terms of the global routing >table Good show, Pekka. Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 07:59:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnE9M-0005YO-TS; Thu, 23 Nov 2006 07:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnE9L-0005YB-0i for architecture-discuss@ietf.org; Thu, 23 Nov 2006 07:57:55 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnE9J-00054l-NU for architecture-discuss@ietf.org; Thu, 23 Nov 2006 07:57:55 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GnE9C-0005Ah-WC for architecture-discuss@ietf.org; Thu, 23 Nov 2006 04:57:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Nov 2006 13:15:39 +0100 To: Pekka Nikander From: Jefsey_Morfin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts) In-Reply-To: <9497D679-8957-45D2-BBB3-6A291690B506@nomadiclab.com> References: <63703036-DE45-4FF5-A42F-6F48FF9DB53B@extremenetworks.com> <3F0F73A3-730C-4CFD-9011-CA24BBB9A116@virtualized.org> <91FAB9D8-B0A2-4789-9F6D-F3C334BA290C@virtualized.org> <4562C973.1090103@zurich.ibm.com> <38703048-6E71-425F-8DAF-4736ED4AA865@virtualized.org> <9497D679-8957-45D2-BBB3-6A291690B506@nomadiclab.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.8 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0779842810==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0779842810== Content-Type: multipart/alternative; boundary="----MTkfupcqyoilferzqroctdgwslzebeajkj" ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-13F81711 On 12:04 23/11/2006, Pekka Nikander said: >There's been some discussion on how to define "global" and "virtual" >when speaking about identifiers, names, and name spaces. I must be >missing something because I think we could have pretty simple >definitions for both "global" and "virtual", both given below. > >However, we first have to understand a crucial point: I am afraid you confuse names and identifiers. Names are intrinsic to something, to some people, in a given relational space. Home you will be Pekka, in Army you will Nikander. In a given virtuality (which may encompass many relational spaces) an Identifier is related to a name. For example in a group you can be nr 19 by alphabetical order and nr 37 by age order. This will be noted as a 19 or a 37 in front of your name, or printed on your T-Shirt. But you will stay Pekka Nikander. Global does not opposes to virtual but to intrinsic or real. Telephone numbers or IPv6 addresses build a global virtuality. If no one answers, their virtuality still exists. jfc ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/html On 12:04 23/11/2006, Pekka Nikander said:
>There's been some discussion on how to define "global" and "virtual"
>when speaking about identifiers, names, and name spaces.  I must be
>missing something because I think we could have pretty simple
>definitions for both "global" and "virtual", both given below.
>
>However, we first have to understand a crucial point:

I am afraid you confuse names and identifiers.
Names are intrinsic to something, to some people, in a given
relational space. Home you will be Pekka, in Army you will Nikander.

In a given virtuality (which may encompass many relational spaces) an
Identifier is related to a name. For example in a group you can be nr
19 by alphabetical order and nr 37 by age order. This will be noted
as a 19 or a 37 in front of your name, or printed on your T-Shirt.
But you will stay Pekka Nikander.

Global does not opposes to virtual but to intrinsic or real.
Telephone numbers or IPv6 addresses build a global virtuality. If no
one answers, their  virtuality still exists.
jfc

------MTkfupcqyoilferzqroctdgwslzebeajkj-- --===============0779842810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0779842810==-- From architecture-discuss-bounces@ietf.org Thu Nov 23 11:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHcD-0003dN-Ni; Thu, 23 Nov 2006 11:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHcB-0003dH-V5 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 11:39:55 -0500 Received: from imo-m21.mx.aol.com ([64.12.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnHcA-0002LO-K7 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 11:39:55 -0500 Received: from HeinerHummel@aol.com by imo-m21.mx.aol.com (mail_out_v38_r7.6.) id l.c5c.77ad16c (41811); Thu, 23 Nov 2006 11:39:37 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 23 Nov 2006 11:39:37 EST Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... To: jefsey@jefsey.com, pekka.nikander@nomadiclab.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154027907==" Errors-To: architecture-discuss-bounces@ietf.org --===============0154027907== Content-Type: multipart/alternative; boundary="-----------------------------1164299977" -------------------------------1164299977 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 virtual versus global? Isn't it more appropriate to speak of names and=20 alias'es. And of global addresses versus local addresses ? My main question however is: Why is it not feasable to integrate a 4 byte sized AS number (of the primar= y=20 service provider) into a 16 byte sized IPv6-address ? If a user changes his= =20 ISP then he would get a different address anyway! All these problems with=20 prefix building blocks would be gone, all this discussions on identifiers a= nd=20 locators and respective mapping became less virtual. =20 Heiner =20 In einer eMail vom 23.11.2006 13:59:46 Westeurop=E4ische Normalzeit schreibt= =20 jefsey@jefsey.com: On 12:04 23/11/2006, Pekka Nikander said: >There's been some discussion on how to define "global" and "virtual" >when speaking about identifiers, names, and name spaces. I must be >missing something because I think we could have pretty simple >definitions for both "global" and "virtual", both given below. > >However, we first have to understand a crucial point: I am afraid you confuse names and identifiers. Names are intrinsic to something, to some people, in a given =20 relational space. Home you will be Pekka, in Army you will Nikander. In a given virtuality (which may encompass many relational spaces) an=20 Identifier is related to a name. For example in a group you can be nr=20 19 by alphabetical order and nr 37 by age order. This will be noted =20 as a 19 or a 37 in front of your name, or printed on your T-Shirt.=20 But you will stay Pekka Nikander. Global does not opposes to virtual but to intrinsic or real.=20 Telephone numbers or IPv6 addresses build a global virtuality. If no=20 one answers, their virtuality still exists. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss =20 -------------------------------1164299977 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
virtual versus global?  Isn't it more appropriate to speak of name= s=20 and alias'es.
And of global addresses versus local addresses ?
My main question however is:
Why is it not feasable to integrate a 4 byte sized AS number=20= (of=20 the primary service provider) into a 16 byte sized IPv6-address ? If a user=20 changes his ISP then he would get a different address anyway! All=20 these problems with prefix building blocks would be gone, all this discussio= ns=20 on identifiers and locators and respective mapping became less virtual.
 
Heiner
 
In einer eMail vom 23.11.2006 13:59:46 Westeurop=E4ische Normalzeit sch= reibt=20 jefsey@jefsey.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On 12:04=20 23/11/2006, Pekka Nikander said:
>There's been some discussion on ho= w to=20 define "global" and "virtual"
>when speaking about identifiers, name= s,=20 and name spaces.  I must be
>missing something because I t= hink=20 we could have pretty simple
>definitions for both "global" and=20 "virtual", both given below.
>
>However, we first have to=20 understand a crucial point:

I am afraid you confuse names and=20 identifiers.
Names are intrinsic to something, to some people, in a giv= en=20
relational space. Home you will be Pekka, in Army you will=20 Nikander.

In a given virtuality (which may encompass many relationa= l=20 spaces) an
Identifier is related to a name. For example in a group you= can=20 be nr
19 by alphabetical order and nr 37 by age order. This will be no= ted=20
as a 19 or a 37 in front of your name, or printed on your T-Shirt. But=20 you will stay Pekka Nikander.

Global does not opposes to virtual bu= t to=20 intrinsic or real.
Telephone numbers or IPv6 addresses build a global=20 virtuality. If no
one answers, their  virtuality still=20 exists.
jfc

3D"=20

_______________________________________________
Architecture-di= scuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164299977-- --===============0154027907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0154027907==-- From architecture-discuss-bounces@ietf.org Thu Nov 23 13:13:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJ3Y-0001nd-SN; Thu, 23 Nov 2006 13:12:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJ3X-0001kg-Jy for architecture-discuss@ietf.org; Thu, 23 Nov 2006 13:12:15 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnJ3W-0002fF-Ba for architecture-discuss@ietf.org; Thu, 23 Nov 2006 13:12:15 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0AE1687315; Thu, 23 Nov 2006 13:12:13 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts) Message-Id: <20061123181213.0AE1687315@mercury.lcs.mit.edu> Date: Thu, 23 Nov 2006 13:12:13 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.6 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day >> At 13:04 +0200 2006/11/23, Pekka Nikander wrote: Generally, I'm in agreement with all you both say. I few comments: > in the past we have used "name" for this as the most general form of > label. And always reserved "identifier" for things that we saw as short > and probably numeric. But that was really a fairly informal convention. Yes, but it's a useful one - and remember, if one person writes "identifier" and means "generic name", and someone else reads "short and probably numeric name", it could be confusing, so if it's OK I'd like to suggest we stick with those usages. > When a name is defined, sorry identifier, one must also define what it > names, the name space from which the names are taken, and the scope of > the name. To be pedantic, one might also define the "context" (which basically means "directory") in which it is looked up. Context is similar to scope, but not exact. A slightly contrived example will make this clear (and my apologies in advance to all to whom the following is already completely clear). Assume we have two towns, A and C, with a third, B, in the middle. We have two companies, both named "Clean Pipes Plumbing" (CPP) - one in A, one in C. Both are willing to do work in town B; in other words, their "scopes" overlap. In the U.S.A., there are now competing "Yellow Pages" - i.e. phone directories organized by the kind of service they provide, and businesses have to pay to be listed. So I can imagine that in B we might have two different Yellow Pages books, Y and Z, and one has a listing for A's CPP, and the other has a listing for C's. So if you live in B, and a friend recommends CPP as being a good company, and you look in your Yellow Pages to call them up to hire them, which one you get depends on whether you look in the Y or the Z Yellow Pages. >> An identifier is virtual iff there is a separate context, different >> from the "usual" context, in which we will interpret the identifier. > I would prefer not to use this. ... In this sense, virtual is only > virtual ;-) in the sense that higher layers of naming represent a > higher level of abstraction than lower ones. Yes, I'm not too happy with this definition of "virtual" either. To me, the important quality about "virtual" comes from the thing that's being named, *not* the name itself. Moreover, I find that "virtual" is usually applied to a second class of instances of something, where the initial class is somehow "real", the second class is less real, i.e. "virtual". And usually the names for the two classes of things are syntactically identical. One good example is "virtual memory". There's real memory, which is actual memory cells, each with an individual, permanent, unchangeable name. Virtual memory refers to a different class of "virtual" instatations of the same basic concept; the names look the same (32 bits or whatever), but they refer to a different "level" of reality. Another is phone numbers, now that we have number portability in many countries. The phone number that your friends now memorize, or record in their phone, is now not really a "real" phone number, but a "virtual" phone number, which the telephone infrastructure maps to your "real" phone number (and phone "line") when someone calls it. I haven't said this quite as elegantly as your definition, but I think this is closer to the true nature of "virtual". Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 13:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJXu-0000We-LK; Thu, 23 Nov 2006 13:43:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJXt-0000WK-PM for architecture-discuss@ietf.org; Thu, 23 Nov 2006 13:43:37 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnJXs-0007DO-Ic for architecture-discuss@ietf.org; Thu, 23 Nov 2006 13:43:37 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 12:43:31 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] on design of ASN-based BGP routing table Date: Thu, 23 Nov 2006 12:45:11 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] on design of ASN-based BGP routing table Thread-Index: AccMBDRCQCAy+uJ+Sne1yDodGALIWwDIItCA From: "Schliesser, Benson" To: "william\(at\)elan.net" , X-OriginalArrivalTime: 23 Nov 2006 18:43:31.0933 (UTC) FILETIME=[463868D0:01C70F2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org william(at)elan.net [mailto:william@elan.net] wrote: > So imagine that instead of having full routing entry for each block: > 10.0.1.0/24 > 10.0.2.0/24 > You would have entry like: > 65001 <10.0.1.0/24 10.0.2.0/24> Today's self-described packets use the address, not the ASN, to direct their forwarding. Thus an AS-based routing system alone isn't adequate: each router still has to do a lookup against an address space FIB in order to forward. For AS-based routing to be useful we would have to have packets indicate their destination AS, too. However, gateways that do the address->ASN lookup would still need to manage an address-based table. (This includes a component of routers, since there are no routers that purely route i.e. routers also have host stacks for management etc.) So I'm not sure this solves the problem by itself. It might let core routers forward faster, with MPLS-like switching, but it doesn't reduce the scale problems for the routers near the edge. We need to introduce some sort of address compression/aggregation mechanism to achieve that in an AS-based architecture. (And with a good aggregation mechanism would we even need AS-based routing? Or with a real Loc/ID split would we even need a good aggregation mechanism?) Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 13:51:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJej-0001YP-1L; Thu, 23 Nov 2006 13:50:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnJeh-0001XG-A4 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 13:50:39 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnJeg-0000Ie-3N for architecture-discuss@ietf.org; Thu, 23 Nov 2006 13:50:39 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 12:50:37 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Primary and lesser names, or layers of indirection? Date: Thu, 23 Nov 2006 12:52:16 -0600 Message-ID: In-Reply-To: <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Primary and lesser names, or layers of indirection? Thread-Index: AccM3eE7gFbTOLw8ShKGqOPIkIgJ4gCUaWCw From: "Schliesser, Benson" To: X-OriginalArrivalTime: 23 Nov 2006 18:50:37.0800 (UTC) FILETIME=[440E8E80:01C70F30] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Conrad [mailto:drc@virtualized.org] wrote: > Mobility is simply renumbering on a constrained time scale. > Architecturally, support for multi-homing (in the sense of a network- > attached-thingie having more than one name-thingie) is not required > for mobility. I would agree that multi-homing makes implementation > easier. Though perhaps multi-homing can be treated as a sub-case of mobility, or vice versa? That is, multi-homing could be a case of mobility with multiple stable subnet connections, mobility could be a case of multi-homing with unstable/changing subnet connections. Conceivably we could have one solution for both views, no? Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 15:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKt5-0007rg-5s; Thu, 23 Nov 2006 15:09:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKsW-0006v3-IS for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:09:00 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnKoK-0002ht-MA for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:04:42 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kANK4bX9032214; Thu, 23 Nov 2006 12:04:37 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kANK4aSK032210; Thu, 23 Nov 2006 12:04:37 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 23 Nov 2006 12:04:36 -0800 (PST) From: "william(at)elan.net" To: "Schliesser, Benson" Subject: RE: [arch-d] on design of ASN-based BGP routing table In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Thu, 23 Nov 2006, Schliesser, Benson wrote: > william(at)elan.net [mailto:william@elan.net] wrote: >> So imagine that instead of having full routing entry for each block: >> 10.0.1.0/24 >> 10.0.2.0/24 >> You would have entry like: >> 65001 <10.0.1.0/24 > 10.0.2.0/24> > > Today's self-described packets use the address, not the ASN, If you notice I brought up old idea of having IPv6 blocks allocated based on ASN which should work for greater majority of networks. Some very large ones would still need allocations that are larger, but considering size of ip6 space available, we can make it a rare case. The issue still remains how to deal with small multi-homing networks well without greatly increasing rib. > to direct > their forwarding. Thus an AS-based routing system alone isn't adequate: > each router still has to do a lookup against an address space FIB in > order to forward. You can't ever avoid it entirely, but you can make this process a lot more efficient. > For AS-based routing to be useful we would have to > have packets indicate their destination AS, too. That would be optional MPLS-like optimization, which while not required for such a system would help for core routers processing billions of packets. You do bring interesting general engineering point that one of the options for new architecture maybe to add some sort of routing header to all packets leaving edge network and going through global Internet (of course IETF is full of packet engineers who often take this approach - in fact is maybe one of those a bit overused... so we'd have to think if its realy needed). And notice that to add such a routing header you still need a lookup table available at the origin - but do note that most systems send quite a larger number of packets to certain destinations (flows) so once first lookup is done this can be well hashed - that is in fact how dns works. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 15:26:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnL8e-0006iQ-5P; Thu, 23 Nov 2006 15:25:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnL8c-0006gE-6G for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:25:38 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnL8a-0005S5-NZ for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:25:38 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0B5D72130AC; Thu, 23 Nov 2006 22:25:33 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 919EF2130A6; Thu, 23 Nov 2006 22:25:32 +0200 (EET) In-Reply-To: <20061123181213.0AE1687315@mercury.lcs.mit.edu> References: <20061123181213.0AE1687315@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts) Date: Thu, 23 Nov 2006 22:25:36 +0200 To: Noel Chiappa , John Day X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.6 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >>> An identifier is virtual iff there is a separate context, different >>> from the "usual" context, in which we will interpret the identifier. > >> I would prefer not to use this. ... In this sense, virtual is only >> virtual ;-) in the sense that higher layers of naming represent a >> higher level of abstraction than lower ones. > > Yes, I'm not too happy with this definition of "virtual" either. > > To me, the important quality about "virtual" comes from the thing > that's > being named, *not* the name itself. Moreover, I find that "virtual" is > usually applied to a second class of instances of something, where the > initial class is somehow "real", the second class is less real, i.e. > "virtual". And usually the names for the two classes of things are > syntactically identical. I agree. What I was missing, at minimum, in the above definition is that a name being "virtual" seems to require another layer of indirection. Hence, in addition to being looked up in a separate context, the *entities* referred to by that separate context are "virtual" in the sense that they point to the "real" entities only _indirectly_, either through the "virtual entities" being mapped directly to the "real entities", or by the mapping taking place through first mapping the "virtual entities" to "real names". I believe the latter case is more usual. But maybe I'm still missing here something. > I haven't said this quite as elegantly as your definition, but I > think this > is closer to the true nature of "virtual". I don't know how to say it elegantly :-), but at minimum the case seems to be the following: 1. There is only one name space, S. 2. There are two or more naming contexts, each mapping the names in S into a different entity space E_i. 3. One entity space is considered "real", others "virtual". 4. There is at least one extra layer of indirection from "virtual names" to "real entities", compared to mapping "real names" to "real entities". There are obvious benefits and drawbacks stemming from the (re)use of the single name space. The next interesting question is what is the exact difference between virtualisation and delegation, both being examples of indirection, and both typically taking place within a single name space. (No, I don't have an answer to that right now here, but it's 10pm over here.) --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 15:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLHN-0004oW-7c; Thu, 23 Nov 2006 15:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLHL-0004nw-Lz for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:34:39 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnLHK-0006oZ-33 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:34:39 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kANKUtrG059075; Thu, 23 Nov 2006 12:30:56 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 23 Nov 2006 12:34:18 -0800 X-PGP-Universal: processed; by terminus.local on Thu, 23 Nov 2006 12:34:18 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Date: Thu, 23 Nov 2006 12:34:16 -0800 To: "Schliesser, Benson" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Benson, On Nov 23, 2006, at 10:52 AM, Schliesser, Benson wrote: > Though perhaps multi-homing can be treated as a sub-case of > mobility, or > vice versa? Yes. The point I've been trying to make is that if you create a layer of indirection that allows for the mapping of one object (the id that applications know about) into one or more other objects (the locators that the routing system knows about), renumbering, mobility, and multi-homing all come more or less for free. Right now, there is no indirection and you have id = locator. Both the routing system and applications have deep personal knowledge of the same object. As a result, if you want to change locator in order to facilitate aggregation, you have to change the id. Changing the id is painful and costly so nobody wants to do it. However, if you introduce a layer of indirection (call it the mapping function "map()"), you gain a tremendous amount of flexibility (at the cost of a hit on performance). That is: a) renumbering: 1) map(id) -> locator_A 2) map(id) -> locator_B b) mobility: 1) map(id) -> locator_A 2a) map(id) -> locator_B 2b) locator_A: forward(id) -> locator_B c) multi-homing: 1) map(id) -> locator_A 2) map(id) -> locator_A,locator_B Same mapping function. Same architecture. Different benefit depending on context. Note also that since the application name does not change, you get connection survivability in renumbering events (both nomadicity (changing providers) and mobility) for free. Architecturally, how the layer of indirection is done is irrelevant (engineering-wise, it matters how and where the mapping is done and there are a lot of ways to skin that particular cat (I use the DNS as an example), but that's not particularly relevant to this list). Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 15:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLJJ-0005aS-Hb; Thu, 23 Nov 2006 15:36:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLJI-0005aN-KH for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:36:40 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnLJH-0007G7-7v for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:36:40 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kANKWurG059081; Thu, 23 Nov 2006 12:33:00 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 23 Nov 2006 12:36:23 -0800 X-PGP-Universal: processed; by terminus.local on Thu, 23 Nov 2006 12:36:23 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... Date: Thu, 23 Nov 2006 12:36:18 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Heiner, On Nov 23, 2006, at 8:39 AM, HeinerHummel@aol.com wrote: > Why is it not feasable to integrate a 4 byte sized AS number (of > the primary service provider) into a 16 byte sized IPv6-address ? It is feasible, but since that ties location with identity, you aren't solving any real problem. > If a user changes his ISP then he would get a different address > anyway! This is what we're trying to avoid. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 15:49:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLV0-0001z6-Qy; Thu, 23 Nov 2006 15:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLUz-0001z1-BX for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:48:45 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnLUx-0000fa-P2 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 15:48:45 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 653F28731A; Thu, 23 Nov 2006 15:48:43 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... Message-Id: <20061123204843.653F28731A@mercury.lcs.mit.edu> Date: Thu, 23 Nov 2006 15:48:43 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Conrad >> If a user changes his ISP then he would get a different address anyway! > This is what we're trying to avoid. Use of "address", without making clear which meaning is intended, again! Let me say it with qualifiers, and see if you all agree: If you mean "get a new routing-name", that is exactly what we *do* want to happen, we don't want to avoid it. If you meant "get a new IPvN address" (once IPvN addresses are actually location-independent names for higher-level entities), yes, we do want to avoid that. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 16:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMQC-0006nE-HT; Thu, 23 Nov 2006 16:47:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMQA-0006lD-P7 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 16:47:50 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnMMr-0000J1-WD for architecture-discuss@ietf.org; Thu, 23 Nov 2006 16:44:27 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A3D8F87338; Thu, 23 Nov 2006 16:44:25 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts) Message-Id: <20061123214425.A3D8F87338@mercury.lcs.mit.edu> Date: Thu, 23 Nov 2006 16:44:25 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.6 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Pekka Nikander > What I was missing, at minimum, in the above definition is that a name > being "virtual" seems to require another layer of indirection. Yes, that (at least) is part of "virtual". > the *entities* referred to by that separate context are "virtual" in > the sense that they point to the "real" entities only _indirectly_, > either through the "virtual entities" being mapped directly to the > "real entities", or by the mapping taking place through first mapping > the "virtual entities" to "real names". I believe the latter case is > more usual. The ones I can think of quickly, yes, but I would not claim that is a complete survey! > 1. There is only one name space, S. Well, it depends on what you mean by "name space". If you mean i) "one set of syntactically possible names", yes. If you mean (as I usually do) ii) "a naming context" - your next line - no. But I assume you mean the former, and with that I kind of agree. Not totally, mind, because I can think of examples (e.g. Multics virtual memory, which was segmented and paged, but the machine's physical memory was not segmented) where the syntax of the virtual objects name-space was different from the syntax of the real objects name-space. > 2. There are two or more naming contexts, each mapping > the names in S into a different entity space E_i. Well, they could all map to the same single physical entity space (for example, processes in Unix, running on a single processor - each has a virtual address space, but they all map to a single physical memory space). Or there could be a set of physical entity spaces Ei (for example, processes running on a multi-processor box, where each CPU has its own unshared memory). 3. One entity space is considered "real", others "virtual". I'd change this to "One or more is considered real" - see example above with multiple CPU's. 4. There is at least one extra layer of indirection from "virtual names" to "real entities", compared to mapping "real names" to "real entities". Right. To go back to the CPU/memory example, mapping of physical addresses to memory cells is performed in hardware (via bank recognition logic, cell decoding logic, etc), and the mapping of virtual addresses to physical addresses is done by page tables. There are instances in which more than one layer of mapping is collapsed into one. For example, consider a cache which takes in virtual addresses and returns hits directly - the normal circuitry involved in turning physical addresses into physical memory cells is never utilized. If the cache is organized as a content-addressable-memory (i.e. each data cell is tagged with the address of the data it holds), there's no mapping at all, really: the virtual name turns directly into the data. > There are obvious benefits and drawbacks stemming from the (re)use of > the single name space. Indeed! > The next interesting question is what is the exact difference between > virtualisation and delegation, both being examples of indirection, and > both typically taking place within a single name space. Oh, that's easy. They involve different things entirely. Virtualisation involves mapping between different name-spaces (in the sense of "naming contexts"). Delegation typically involves handing authority for the assignment of names within a chunk of a given name-space (real or virtual, it doesn't matter) off to some other entity, away from the primary entity which has the responsibility/control of that namespace. > (No, I don't have an answer to that right now here, but it's 10pm over > here.) :-) I know that feeling! (And it's Thanksgiving on this side of the water! So I must go, for now, too....) Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 17:03:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMfR-0004ov-By; Thu, 23 Nov 2006 17:03:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMfP-0004gd-UP for architecture-discuss@ietf.org; Thu, 23 Nov 2006 17:03:35 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnMfO-00047L-Nx for architecture-discuss@ietf.org; Thu, 23 Nov 2006 17:03:35 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 16:03:33 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Date: Thu, 23 Nov 2006 16:04:54 -0600 Message-ID: In-Reply-To: <232DC679-50C8-4CCC-84DB-BE4A97975F83@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Thread-Index: AccL3QzPtu+v+ZwsRqWXnsf76O1VEwDPWmog From: "Schliesser, Benson" To: "Pekka Nikander" , X-OriginalArrivalTime: 23 Nov 2006 22:03:33.0830 (UTC) FILETIME=[37E88E60:01C70F4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] wrote: > In the current architecture [...] > From a mathematical point of > view, one could say that the better the topology of the addressing > space can be matched with the topology with of the network, the less > information needs to be stored elsewhere. Perhaps somebody with better mathematical understanding could comment... When I envision an Internet with lots of network-hierarchy, I understand your statement to mean that aggregation is possible if addressing and connectivity are essentially aligned. But when I envision an Internet with no hierarchy this is no longer true. (As an extreme example, picture an Internet where every AS was directly connected to every other AS; compression of the address space through aggregation is only possible at the expense of path information.) Of course, the current Internet is somewhere in between. But who knows about the future? It seems to me that this relationship between connectivity and routing system size could be made explicit: must we inherently make assumptions about the relationships between networks in order to produce a more scalable routing and addressing architecture? Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 17:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnN4i-0000ka-PF; Thu, 23 Nov 2006 17:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnN4i-0000jF-1R for architecture-discuss@ietf.org; Thu, 23 Nov 2006 17:29:44 -0500 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnN4g-0008BZ-Q8 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 17:29:44 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 16:29:42 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's the routing, people! Date: Thu, 23 Nov 2006 16:31:20 -0600 Message-ID: In-Reply-To: <474EEBD229DF754FB83D256004D0210802584B8A@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's the routing, people! Thread-Index: AccF9lkzxWe6Lk4/TzCTkGasDzMo0QAAS4/wAFad2fAADlCfIAAmnyXwAcSZLsA= From: "Schliesser, Benson" To: "Fleischman, Eric" X-OriginalArrivalTime: 23 Nov 2006 22:29:42.0303 (UTC) FILETIME=[DECA8AF0:01C70F4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org (Sorry for my delayed response; too much travel, work, etc, has kept me busy. I now get to use my holiday to catch up...) Fleischman, Eric [mailto:eric.fleischman@boeing.com] wrote: > 2) I don't understand why you have concluded that ISPs will have > expenses that will bleed-through to us end users in any significant way > due to routing table explosion. To my simple mind, ISPs will perhaps > have to continually upgrade their Internet-facing ASBRs such that they > could not depreciate at the standard accounting rate but other than that > what are their actual expenses due to this problem? The greater threat > (to my simplistic mind) is that the routing table growth rate may exceed > the capabilities of the ASBRs, which will impact actual Internet > performance, but as long as that doesn't happen, this doesn't seem like > a very large expense to "pass through" to us. For example, depending on > their number of Internet-facing ASBRs, the overhead of their billing > system (for those that have one) could dwarf many possible worse-case > ASBR expense scenarios. Overall you are right about the proportion of costs in a service provider today--administrative costs often predominate, and capital expenditures tend to be lower than operational expenditures regardless of the source. But providers have been competing fiercely, and prices in (parts of) the market are now approaching the fundamental cost of the service. Providers are attempting to implement automation and leaner business process, amongst other things, to reduce their costs further. (and searching for value-adds to build their business on, since network access clearly won't satisfy) And if some of the predictions I've heard about routing system growth versus Moore's law etc come true, then it's possible that the capacity of new equipment will not be able to keep up with the growth of the routing system, leading to a need for more equipment and/or relatively more expensive equipment. Over time this will mean that prices have to rise--there's nowhere else for the costs to be absorbed, that I'm aware of. Given how low market prices are today, and believing that administrative costs will decrease relatively over time, I expect that even a small increase in equipment costs could translate to a rather noticeable increase in costs to customers. I'd be happy to be wrong, though. :) Cheers, -Benson _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 17:38:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnNCb-0003oY-KO; Thu, 23 Nov 2006 17:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnNCZ-0003oI-Ty for architecture-discuss@ietf.org; Thu, 23 Nov 2006 17:37:51 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnNCY-0000yz-CT for architecture-discuss@ietf.org; Thu, 23 Nov 2006 17:37:51 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kANMY3rG059294; Thu, 23 Nov 2006 14:34:04 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 23 Nov 2006 14:37:27 -0800 X-PGP-Universal: processed; by terminus.local on Thu, 23 Nov 2006 14:37:27 -0800 In-Reply-To: <20061123204843.653F28731A@mercury.lcs.mit.edu> References: <20061123204843.653F28731A@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6BD1D16B-893C-4630-BA04-9FE1CE289FF4@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... Date: Thu, 23 Nov 2006 14:37:25 -0800 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, On Nov 23, 2006, at 12:48 PM, Noel Chiappa wrote: >> From: David Conrad >>> If a user changes his ISP then he would get a different address >>> anyway! >> This is what we're trying to avoid. > Use of "address", without making clear which meaning is intended, > again! I try to avoid the term "address" as it tends to result in people who dislike ambiguity in terminology using exclamation points. (:-)). More seriously, when I use the term "address", I am referencing the values used today for source or destination fields in the IPv4 and/or IPv6 protocols. That is, the bit patterns that encompass the functionality of both end point identifiers and routing locators. > If you mean "get a new routing-name", that is exactly what we *do* > want to > happen, we don't want to avoid it. Yes. However what was being suggested by Hiener was to use a 4 byte ASN as part of the 16 byte "address". If you do this _AND_ the same bit pattern is used for both "routing-name" (what I call a locator) and "application-name" (what I call an identifier), you have done nothing to solve the problems that have triggered this whole discussion. > If you meant "get a new IPvN address" (once IPvN addresses are > actually location-independent names for higher-level entities), > yes, we do want to avoid that. I don't know the term "address" means in this context. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 19:24:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnOpi-0000D4-Mg; Thu, 23 Nov 2006 19:22:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnOph-0000Cv-Aa for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:22:21 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnOpg-0002Ir-4T for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:22:21 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006112400221701400me2pqe>; Fri, 24 Nov 2006 00:22:17 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 23 Nov 2006 19:22:08 -0500 To: "Schliesser, Benson" , From: John Day Subject: RE: [arch-d] Primary and lesser names, or layers of indirection? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:52 -0600 2006/11/23, Schliesser, Benson wrote: >David Conrad [mailto:drc@virtualized.org] wrote: >> Mobility is simply renumbering on a constrained time scale. >> Architecturally, support for multi-homing (in the sense of a network- >> attached-thingie having more than one name-thingie) is not required >> for mobility. I would agree that multi-homing makes implementation >> easier. > >Though perhaps multi-homing can be treated as a sub-case of mobility, or >vice versa? That is, multi-homing could be a case of mobility with >multiple stable subnet connections, mobility could be a case of >multi-homing with unstable/changing subnet connections. Conceivably we >could have one solution for both views, no? I have been meaning to say this to the list, but if you work through it carefully you will find that mobility should be nothing more than frequently changing multihoming. But it isn't so much renumbering as the acquisition and release of points of attachment instances and node instances. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 19:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnOpg-0000Cm-Dk; Thu, 23 Nov 2006 19:22:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnOpf-0000Cf-2h for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:22:19 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnOpd-0002Ir-Ij for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:22:19 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006112400221601400me2ppe>; Fri, 24 Nov 2006 00:22:17 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061123181213.0AE1687315@mercury.lcs.mit.edu> References: <20061123181213.0AE1687315@mercury.lcs.mit.edu> Date: Thu, 23 Nov 2006 19:20:03 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thoughts) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > From: John Day > > >> At 13:04 +0200 2006/11/23, Pekka Nikander wrote: > >Generally, I'm in agreement with all you both say. I few comments: > > > > in the past we have used "name" for this as the most general form of > > label. And always reserved "identifier" for things that we saw as short > > and probably numeric. But that was really a fairly informal convention. > >Yes, but it's a useful one - and remember, if one person writes "identifier" >and means "generic name", and someone else reads "short and probably numeric >name", it could be confusing, so if it's OK I'd like to suggest we stick >with those usages. Good. (This is what we have definitions for!) We should really try to get a set of definitions that while we may not all agree with ;-) we at least try to use. > > > When a name is defined, sorry identifier, one must also define what it > > names, the name space from which the names are taken, and the scope of > > the name. > >To be pedantic, one might also define the "context" (which basically means >"directory") in which it is looked up. Context is similar to scope, but not >exact. A slightly contrived example will make this clear (and my apologies in >advance to all to whom the following is already completely clear). > >Assume we have two towns, A and C, with a third, B, in the middle. We have >two companies, both named "Clean Pipes Plumbing" (CPP) - one in A, one in C. >Both are willing to do work in town B; in other words, their "scopes" >overlap. In the U.S.A., there are now competing "Yellow Pages" - i.e. phone >directories organized by the kind of service they provide, and businesses >have to pay to be listed. So I can imagine that in B we might have two >different Yellow Pages books, Y and Z, and one has a listing for A's CPP, and >the other has a listing for C's. So if you live in B, and a friend recommends >CPP as being a good company, and you look in your Yellow Pages to call them >up to hire them, which one you get depends on whether you look in the Y or >the Z Yellow Pages. > Hmmm, Good example. This is the problem that humans run into and why we are able to make things work without getting too formal. Trouble is machines aren't that smart. So we really need to have a more or less formal system. > >> An identifier is virtual iff there is a separate context, different > >> from the "usual" context, in which we will interpret the identifier. > > > I would prefer not to use this. ... In this sense, virtual is only > > virtual ;-) in the sense that higher layers of naming represent a > > higher level of abstraction than lower ones. > >Yes, I'm not too happy with this definition of "virtual" either. Yea, I only used as analogy so people would have some idea what was I was talking about. It is more logical than virtual, but even that isn't really right. The point is that we need both levels of addressing just like we needed them in computers. > >To me, the important quality about "virtual" comes from the thing that's >being named, *not* the name itself. Moreover, I find that "virtual" is >usually applied to a second class of instances of something, where the >initial class is somehow "real", the second class is less real, i.e. >"virtual". And usually the names for the two classes of things are >syntactically identical. > >One good example is "virtual memory". There's real memory, which is actual >memory cells, each with an individual, permanent, unchangeable name. Virtual >memory refers to a different class of "virtual" instatations of the same >basic concept; the names look the same (32 bits or whatever), but they refer >to a different "level" of reality. > >Another is phone numbers, now that we have number portability in many >countries. The phone number that your friends now memorize, or record in >their phone, is now not really a "real" phone number, but a "virtual" phone >number, which the telephone infrastructure maps to your "real" phone number >(and phone "line") when someone calls it. Well, actually it is an application name. And if it is cellular, the phone also has a distinct node address and a point of attachment address. When you leave your area you are assigned a different node address but keep the same application name, i.e. your number. And of course the point of attachment is the cell tower. > >I haven't said this quite as elegantly as your definition, but I think this >is closer to the true nature of "virtual". Awww, shucks. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 19:33:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnP0B-0006mF-9V; Thu, 23 Nov 2006 19:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnP09-0006l2-5D for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:33:09 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnOzH-0004Hq-BC for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:32:16 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc15) with ESMTP id <2006112400320901500pro2he>; Fri, 24 Nov 2006 00:32:14 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 23 Nov 2006 19:27:39 -0500 To: David Conrad , "Schliesser, Benson" From: John Day Subject: Re: [arch-d] Primary and lesser names, or layers of indirection? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hey someone read Saltzer! ;-) But did you notice the piece he missed? PoAs don't map to routes. Nodes do. Then you need to know the node to PoA mapping of all nearest neighbors to pick the path to the next hop. Multiple paths to next hops didn't exist when Saltzer wrote. At 12:34 -0800 2006/11/23, David Conrad wrote: >Benson, > >On Nov 23, 2006, at 10:52 AM, Schliesser, Benson wrote: >>Though perhaps multi-homing can be treated as a sub-case of mobility, or >>vice versa? > >Yes. > >The point I've been trying to make is that if you create a layer of >indirection that allows for the mapping of one object (the id that >applications know about) into one or more other objects (the >locators that the routing system knows about), renumbering, >mobility, and multi-homing all come more or less for free. > >Right now, there is no indirection and you have id = locator. Both >the routing system and applications have deep personal knowledge of >the same object. As a result, if you want to change locator in order >to facilitate aggregation, you have to change the id. Changing the >id is painful and costly so nobody wants to do it. > >However, if you introduce a layer of indirection (call it the >mapping function "map()"), you gain a tremendous amount of >flexibility (at the cost of a hit on performance). That is: > >a) renumbering: > 1) map(id) -> locator_A > 2) map(id) -> locator_B >b) mobility: > 1) map(id) -> locator_A > 2a) map(id) -> locator_B > 2b) locator_A: forward(id) -> locator_B >c) multi-homing: > 1) map(id) -> locator_A > 2) map(id) -> locator_A,locator_B > >Same mapping function. Same architecture. Different benefit >depending on context. > >Note also that since the application name does not change, you get >connection survivability in renumbering events (both nomadicity >(changing providers) and mobility) for free. > >Architecturally, how the layer of indirection is done is irrelevant >(engineering-wise, it matters how and where the mapping is done and >there are a lot of ways to skin that particular cat (I use the DNS >as an example), but that's not particularly relevant to this list). > >Rgds, >-drc > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 19:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPLA-0008P9-NN; Thu, 23 Nov 2006 19:54:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPL9-0008P3-IG for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:54:51 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnPL3-00027A-Kv for architecture-discuss@ietf.org; Thu, 23 Nov 2006 19:54:51 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kAO0sMD3038642; Fri, 24 Nov 2006 11:54:22 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061124114728.045c9510@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 24 Nov 2006 11:52:25 +1100 To: John Day , "Schliesser, Benson" , From: Geoff Huston Subject: RE: [arch-d] Primary and lesser names, or layers of indirection? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >I have been meaning to say this to the list, but if you work through >it carefully you will find that mobility should be nothing more than >frequently changing multihoming. But it isn't so much renumbering >as the acquisition and release of points of attachment instances and >node instances. You appear to be re-covering some of the multi6 discussions with this. The critical distinction here is one that I've heard described as "nomadism" vs "mobility". Typically I've heard the term "mobility" to refer to a "home and away" model, where there is a fixed 'reference point' for rendezvous, while "nomadism" has no such 'home'. Multi6 highlighted this as there is no referential locator between the set of potential locators. This appears to suggest that mobility (in the 'home and away' sense) is not a multi-homing case, and while you could view all mobility as nomadism, this appears to be a sub-optimal route in that the referential point has come in useful, particularly in respect to security functions associated with mobility. regards, Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 20:22:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPle-000538-Rt; Thu, 23 Nov 2006 20:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPld-000533-9M for architecture-discuss@ietf.org; Thu, 23 Nov 2006 20:22:13 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnPlb-0005vc-2M for architecture-discuss@ietf.org; Thu, 23 Nov 2006 20:22:13 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc13) with ESMTP id <2006112401221001300arsu5e>; Fri, 24 Nov 2006 01:22:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.16.2.20061124114728.045c9510@apnic.net> References: <7.0.0.16.2.20061124114728.045c9510@apnic.net> Date: Thu, 23 Nov 2006 20:20:10 -0500 To: Geoff Huston , John Day , "Schliesser, Benson" , From: John Day Subject: RE: [arch-d] Primary and lesser names, or layers of indirection? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Yes, I believe the "home and away" model is probably more properly referred to as a "kludge." The nomadic mode as you call it, if properly done actually has better security properties. But then are so many ways to do it improperly. ;-) But it does seem to appeal to those partial to the phone company model of networking. Take care, John At 11:52 +1100 2006/11/24, Geoff Huston wrote: >>I have been meaning to say this to the list, but if you work >>through it carefully you will find that mobility should be nothing >>more than frequently changing multihoming. But it isn't so much >>renumbering as the acquisition and release of points of attachment >>instances and node instances. > >You appear to be re-covering some of the multi6 discussions with >this. The critical distinction here is one that I've heard described >as "nomadism" vs "mobility". Typically I've heard the term >"mobility" to refer to a "home and away" model, where there is a >fixed 'reference point' for rendezvous, while "nomadism" has no such >'home'. Multi6 highlighted this as there is no referential locator >between the set of potential locators. This appears to suggest that >mobility (in the 'home and away' sense) is not a multi-homing case, >and while you could view all mobility as nomadism, this appears to >be a sub-optimal route in that the referential point has come in >useful, particularly in respect to security functions associated >with mobility. > >regards, > > Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 20:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPvg-0000xd-UC; Thu, 23 Nov 2006 20:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPvf-0000xY-W9 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 20:32:35 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnPve-00009W-Nd for architecture-discuss@ietf.org; Thu, 23 Nov 2006 20:32:35 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc13) with ESMTP id <20061124013223b130001clte>; Fri, 24 Nov 2006 01:32:34 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 23 Nov 2006 20:28:20 -0500 To: "Schliesser, Benson" , "Pekka Nikander" , From: John Day Subject: RE: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka has this right. The alignment does not need to be precise and in fact it is best if it isn't. As one of my favorite phrases attributed to Frege (although I am sure he never said it), the sign "=" should be read as "is easily confused with." In all of his stuff I have read, I have never seen him allow that kind of wit, although he does essentially say it. How to do this is subtle until you see it. But it is possible and does facilitate routing. John At 16:04 -0600 2006/11/23, Schliesser, Benson wrote: >Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] wrote: >> In the current architecture [...] >> From a mathematical point of >> view, one could say that the better the topology of the addressing >> space can be matched with the topology with of the network, the less >> information needs to be stored elsewhere. > >Perhaps somebody with better mathematical understanding could comment... > >When I envision an Internet with lots of network-hierarchy, I understand >your statement to mean that aggregation is possible if addressing and >connectivity are essentially aligned. But when I envision an Internet >with no hierarchy this is no longer true. (As an extreme example, >picture an Internet where every AS was directly connected to every other >AS; compression of the address space through aggregation is only >possible at the expense of path information.) Of course, the current >Internet is somewhere in between. But who knows about the future? > >It seems to me that this relationship between connectivity and routing >system size could be made explicit: must we inherently make assumptions >about the relationships between networks in order to produce a more >scalable routing and addressing architecture? > >Cheers, >-Benson > > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 21:01:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnQMz-00052l-Cb; Thu, 23 Nov 2006 21:00:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnQMy-00052g-62 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 21:00:48 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnQMx-0004UM-0F for architecture-discuss@ietf.org; Thu, 23 Nov 2006 21:00:48 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A87FA86AF1; Thu, 23 Nov 2006 21:00:46 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... Message-Id: <20061124020046.A87FA86AF1@mercury.lcs.mit.edu> Date: Thu, 23 Nov 2006 21:00:46 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Conrad > what was being suggested by Hiener was to use a 4 byte ASN as part of > the 16 byte "address". If you do this _AND_ the same bit pattern is > used for both "routing-name" (what I call a locator) and > "application-name" (what I call an identifier), you have done nothing > to solve the problems that have triggered this whole discussion. Indeed... >> If you meant "get a new IPvN address" (once IPvN addresses are >> actually location-independent names for higher-level entities), yes, >> we do want to avoid that. > I don't know the term "address" means in this context. "IPvN" = "IPv4 or IPv6", so "IPvN address" = "IPv4 or IPv6 addresss". The architecture/semantics of the two IPvN protocols are (currently) so similar that when thinking at an architectural level they are the same. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 22:05:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRLp-0000DY-Vr; Thu, 23 Nov 2006 22:03:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRLp-0000DQ-0o for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:03:41 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnRLj-0004Ds-Nm for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:03:40 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 990E63406C; Thu, 23 Nov 2006 22:03:35 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 22:03:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (was Re:thoughts) Date: Thu, 23 Nov 2006 22:03:33 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E841@tayexc14.americas.cpqcorp.net> In-Reply-To: <9497D679-8957-45D2-BBB3-6A291690B506@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (was Re:thoughts) Thread-Index: AccO72sL2wiev6cUT/Srx3lvlFkobwAhHEFw From: "Bound, Jim" To: "Pekka Nikander" , X-OriginalArrivalTime: 24 Nov 2006 03:03:35.0335 (UTC) FILETIME=[21A43B70:01C70F75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I agree and in this definition I think an anycast address is virtual too the address in of itself does not identify what node the packet will be delivered. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, November 23, 2006 6:05 AM > To: architecture-discuss@ietf.org > Cc: John Day > Subject: [arch-d] On identifiers: what is virtual and what is=20 > global (was Re:thoughts) >=20 > There's been some discussion on how to define "global" and "virtual" =20 > when speaking about identifiers, names, and name spaces. I=20 > must be missing something because I think we could have=20 > pretty simple definitions for both "global" and "virtual",=20 > both given below. >=20 > However, we first have to understand a crucial point: >=20 > An identifier is meaningless without a defining context. >=20 > That is, an identifier is merely an non-interpretable string=20 > of bits unless we know the context in which we should understand it. >=20 > Given this, we perhaps could define as follows: >=20 > An identifier is global iff there is only one possible=20 > context in which we can interpreting it. >=20 > That is, if an identifier drawn from a name space will always=20 > be interpreted in the same way, yielding the same behaviour,=20 > independent on where (and when?) it is used, then it is global. >=20 > Along the same lines: >=20 > An identifier is virtual iff there is a separate context,=20 > different from the "usual" context, in which we will=20 > interpret the identifier. >=20 > That is, identifiers are "virtual" (as opposed to "real") if=20 > they are interpreted using some given, "virtual" context,=20 > different from the default context where they would be=20 > interpreted without virtualisation. >=20 > This seems to match with our typical usage: >=20 > - a virtual memory address is interpreted in terms of the MMU=20 > translation tables instead of being directly handled by the=20 > demultiplexing logic at the chip select and chip level >=20 > - a VPN address is interpreted in terms of the routing=20 > internal to the VPN instead of being interpreted in terms of=20 > the global routing table >=20 > --Pekka Nikander >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 22:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRL8-00009G-8h; Thu, 23 Nov 2006 22:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRL6-000097-CX for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:02:56 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnRKz-00047T-Q6 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:02:56 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6B07A34040; Thu, 23 Nov 2006 22:02:49 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 22:02:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Thoughts about mobility, multi-homing, and architecture Date: Thu, 23 Nov 2006 22:02:45 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E840@tayexc14.americas.cpqcorp.net> In-Reply-To: <1122001D-83BE-408E-A11E-E21A0C8F6909@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Thoughts about mobility, multi-homing, and architecture Thread-Index: AccO63HnUxXesfvuTkGuEuL6OPeRBQAiB0Ew From: "Bound, Jim" To: "Pekka Nikander" , X-OriginalArrivalTime: 24 Nov 2006 03:02:48.0944 (UTC) FILETIME=[05FD8700:01C70F75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka, Good analysis thanks I will think about this for some time now not input to take lightly. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, November 23, 2006 5:35 AM > To: architecture-discuss@ietf.org > Subject: [arch-d] Thoughts about mobility, multi-homing, and=20 > architecture >=20 > John Day and I have expressed our opinions that mobility and=20 > multi- homing are architecturally similar, implying that=20 > maybe we could address them in a unified way. Some people=20 > disagreed. I think much depends on your point of view, and=20 > in this message I try to clarify that. In a way, I am=20 > restating much which Joel already stated, but from a subtly=20 > different point of view, trying both to dive still somewhat=20 > deeper and to expand the discussion to application-level aspects. >=20 > Unfortunately, in order to get to my point, I must start from=20 > quite far away. Hence, for the impatient, it may be better=20 > to read this rather long message in the reverse order,=20 > starting from the discussion (search for "Discussion") and=20 > then referring back to the assumptions. >=20 >=20 > Starting point > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > As a starting point, I take the following premises or assumptions: >=20 > A1. Application-level resources are the main entities we are=20 > interested in. They may be named in different ways, the=20 > exact details of which is outside the scope of the current focus. >=20 > A2. Application-level entities are often logically aggregated=20 > due to different factors, including fate sharing, security=20 > privileges, mobility, etc. This application-level=20 > aggregation should be kept distinct from=20 > network-address-level aggregation. >=20 > A3. The routing system is based on the hop-by-hop paradigm,=20 > where the routers have forwarding tables that use=20 > routing-level addresses as input for the forwarding decision. >=20 > A4. Completely flat addressing is out of scope due to=20 > practical constraints to the forwarding tables and the routing system. >=20 > A5. To implement A4, the routing-level addresses (locators)=20 > are somehow aggregateable. That is, the addressing name=20 > space has internal structure (topology) that allows a larger=20 > or "more- aggregated" address range (e.g. one with a shorter=20 > prefix) to denote an area that confines a number of smaller=20 > or "less-aggregated" =20 > address ranges (e.g. ones with longer prefixes). [Note that=20 > this definition does not mandate a tree-like addressing name=20 > space topology that we have today, but still allows it.] >=20 > Now, theoretically speaking, as the purpose of the aggress=20 > aggregation is to embed into the address some partial=20 > information about the location of the said address within the=20 > network graph, thereby relieving some burden from the=20 > forwarding tables and routing system, it immediately follows=20 > that the parts of the network graph where an address may be=20 > located at is confined by the address itself. >=20 > In more practical terms, the addresses become names of=20 > locations within the network graph, i.e., locators. That is,=20 > given a specific address, there are only a limited number of=20 > locations within the network graph where the address may=20 > "be". In a typical system, such as those used today for IPv4=20 > and IPv6, that "limited number of locations" equals to the=20 > subnet identified by the address prefix. >=20 > Still more practically, what I mean is that due to the=20 > assumptions made about the forwarding parading and network=20 > layer addressing, the addresses in the system are names of=20 > locations (points of attachment) in the network, and not e.g.=20 > location-independent names of mobile hosts. >=20 > Basics of multi-homing > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This structure leads to a situation where we apparently must=20 > make a distinction between two different types of "multi-path"*: >=20 > P1. In the network graph, there may be alternative routing=20 > paths between two areas that are named with some given,=20 > unique address ranges. In today's terms, this would be=20 > reflected by having multiple routing table entries for a=20 > given prefix. This is what Joel called "multi-pathing" in=20 > his message (http://www1.ietf.org/mail-archive/web/ > architecture-discuss/current/msg00682.html ). >=20 > P2. In the network graph, there may be areas (including=20 > single nodes) that are identified by more than one address=20 > ranges. This is what Joel called "multi-homing". >=20 > Note that the underlying network graph may be identical in=20 > cases P1 and P2. The only difference is how we decide to=20 > name locations, i.e., in address assignment. In P1 we assign=20 > only one range of addresses to the "multi-homed" location=20 > while in P2 we assign two or more. Further note that this=20 > naming decision is apparently motivated by the assumptions A4=20 > and A5, in an attempt to make the address space topology and=20 > the topology of the network graph match in such a way that=20 > the size of the routing and forwarding tables can be reduced. >=20 > [Footnote *) This is a point where I hope to be wrong. =20 > Making the distinction between multi-path at the routing=20 > level vs. multi-path at a level above does not "feel" nice. =20 > However, to me this seems to be an implication from=20 > assumptions A3-A5. Finding alternative solutions would be=20 > very good, but given the constraints on the size of the=20 > forwarding/routing tables, propagation times, and routing=20 > computation, I find it unlikely that any practical=20 > alternatives exist.] >=20 > To summarise so far: Using hop-by-hop forwarding with=20 > aggregateable addresses leads to a situation where "area"=20 > (subnet) multi-homing can be solved either by adding=20 > alternative routes into the routing table or assigning=20 > multiple address ranges. >=20 > Nothing new. Just dissecting the background assumptions. >=20 > Generalisation I, or Application Multi-homing=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > So far we have only considered the network graph and the=20 > addressing name space. Let us now consider application-level=20 > entities. >=20 > An application-level entity (resource) may be distributed, or=20 > be available through multiple points at the network graph. =20 > For example, the underlying server host may be multi-homed,=20 > the application entity may be location-dependent and=20 > implemented at several distinct server hosts, or the entity=20 > may be genuinely distributed and implemented by a distributed=20 > server farm. >=20 > Now we seem to have even more choices than in the case of=20 > network- graph-level multi-homing. I'll describe these as=20 > chains of identifiers. >=20 > C1. Top-most entity name -> One "multi-pathed" address (P1)=20 > -> Alternative routes >=20 > C2. Top-most entity name -> Multiple alternative addresses=20 > (P2) -> One route >=20 > C3. Top-most entity name -> Multiple alternative intermediate=20 > entity names (e.g. host names) -> P1 -> One Route >=20 > Of course, if supported by the underlying system, these=20 > levels of flexibility can be combined: >=20 > C4. Top-most entity name -> Alternative super-entity names ->=20 > P2 -> Alternative routes >=20 > [Of course, intermediate indirections (C3) may be recursive.] >=20 > To summarise and generalise the discussion so far, we can=20 > state that from a high-level architectural point of view,=20 > multi-homing is nothing more one-to-many mappings as one=20 > resolves higher-layer identifiers into lower-layer=20 > identifiers. The differences lie when there are one-to-many=20 > mappings and when simple one-to-one mappings. >=20 > Considering a single indirection step, the most important=20 > design choice then is when, exactly, one of the alternative=20 > lower-layer identifiers is chosen for the purposes of=20 > delivery. To summarise the more-than-two-decades old wisdom:=20 > Be lazy, bind late. >=20 > Mobility > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > Consider now mobility. From the present point of view, we=20 > can state that mobility is nothing more than dynamic mappings=20 > as one resolves higher-layer identifiers into lower layer identifiers. >=20 > Analogous to the multi-homing chains C1-C4 above, we can=20 > present mobility chains: >=20 > M1. Stable entity name -> Stable address -> Dynamic route=20 > updates (host routing) >=20 > M2. Stable entity name -> Dynamic, updateable address -> Stable routes >=20 > M3. Stable entity name -> Dynamic, updateable intermediate=20 > entity name -> Stable address -> Stable routes >=20 > M4. Stable entity name -> Dynamic super-entity name ->=20 > Dynamic address -> Dynamic route >=20 > I will skip the longer discussion here, as it would be=20 > isomorphic to the multi-homing discussion above, merely=20 > replacing mapping alternatives with temporal dynamics. >=20 > MANETs are prototypical examples of M1. NetLMM can be also=20 > considered as a peculiar example of M1. >=20 > MIP, NEMO, HIP (and potentially SHIM6 based mobility) are all=20 > examples of M2, with just different choices for the name spaces. >=20 > I am not aware of any major examples of M3, but I could=20 > imagine they could be found in various middleware frameworks.=20 > And I think SIP could also offer such examples. >=20 > Discussion > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > By now, the structural (architectural?) parallels between=20 > multi- homing and mobility should be clear: >=20 > Layer Multi-homing Mobility >=20 > Routing Traditional, routing- Micro mobility > based site multi-homing e.g. MANETs >=20 > Routing- (GSE?) So called edge mobility, > Addressing e.g. NetLMM > boundary >=20 > Addressing Multi-address multi-homing, Most node mobility =20 > protocols, > e.g. SHIM6, GSE e.g. MIP and HIP >=20 > =20 > Tunnelling-based solutions, > e.g. NEMO and MOBIKE >=20 > Application- Multiple A/AAAA RRs DynDNS > Addressing > boundary Renumbering, > (but on a=20 > different time scale) >=20 > Application Distributed applications, Application mobility, > e.g. location dependent ones e.g. process migration >=20 > [Footnote: I am not sure about the "right" positioning of=20 > GSE. The position of NetLMM could also be discussed; I'd be=20 > tempted to classify it as a "routing" solution, but others=20 > apparently disagree.] >=20 > Hence, it is this point of view that I say that mobility and=20 > multi- homing are architecturally quite similar. >=20 > There is one thing that I haven't considered at all, on=20 > purpose: Time scales, including make-before-break vs.=20 > break-before-make. They make a difference. But that's one=20 > level down towards the details, in my opinion. They are=20 > still architectural, but not the highest point of view. =20 > Anyway, this message is long enough already now; the=20 > differences would warrant a separate message. >=20 > The big question is whether the similarities and co-occurring=20 > usage scenarios are plausible enough so that mobility and=20 > multi-homing should be handled in an architecturally unified=20 > way, or whether the differences are so big and the phenomena=20 > so separate that the added minor complexity does not pay off. >=20 > By now you should be able to guess my current opinion. >=20 > --Pekka Nikander >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 22:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRMn-0000XQ-J7; Thu, 23 Nov 2006 22:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRMm-0000XI-01 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:04:40 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnRMg-0004JT-Q1 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:04:39 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A816B340CD; Thu, 23 Nov 2006 22:04:34 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 22:04:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Thu, 23 Nov 2006 22:04:32 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E842@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccPPx64fCeuIQrUTWWYP6C4cq5CfgANVqsA From: "Bound, Jim" To: "David Conrad" , X-OriginalArrivalTime: 24 Nov 2006 03:04:34.0387 (UTC) FILETIME=[44D6DA30:01C70F75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 > > If a user changes his ISP then he would get a different address=20 > > anyway! >=20 > This is what we're trying to avoid. I don't think this can be avoided nor can it be assumed. If the address prefix used by the ISP is different a node should use it and this also has mobility implications per the use cases I sent. What should not change is the identifier. Thus here we may disagree. The complexity for routing for performance reasons will not scale ever in my view. Best /jim >=20 > Rgds, > -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 22:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRL8-00009G-8h; Thu, 23 Nov 2006 22:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRL6-000097-CX for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:02:56 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnRKz-00047T-Q6 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:02:56 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6B07A34040; Thu, 23 Nov 2006 22:02:49 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 22:02:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Thoughts about mobility, multi-homing, and architecture Date: Thu, 23 Nov 2006 22:02:45 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E840@tayexc14.americas.cpqcorp.net> In-Reply-To: <1122001D-83BE-408E-A11E-E21A0C8F6909@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Thoughts about mobility, multi-homing, and architecture Thread-Index: AccO63HnUxXesfvuTkGuEuL6OPeRBQAiB0Ew From: "Bound, Jim" To: "Pekka Nikander" , X-OriginalArrivalTime: 24 Nov 2006 03:02:48.0944 (UTC) FILETIME=[05FD8700:01C70F75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka, Good analysis thanks I will think about this for some time now not input to take lightly. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, November 23, 2006 5:35 AM > To: architecture-discuss@ietf.org > Subject: [arch-d] Thoughts about mobility, multi-homing, and=20 > architecture >=20 > John Day and I have expressed our opinions that mobility and=20 > multi- homing are architecturally similar, implying that=20 > maybe we could address them in a unified way. Some people=20 > disagreed. I think much depends on your point of view, and=20 > in this message I try to clarify that. In a way, I am=20 > restating much which Joel already stated, but from a subtly=20 > different point of view, trying both to dive still somewhat=20 > deeper and to expand the discussion to application-level aspects. >=20 > Unfortunately, in order to get to my point, I must start from=20 > quite far away. Hence, for the impatient, it may be better=20 > to read this rather long message in the reverse order,=20 > starting from the discussion (search for "Discussion") and=20 > then referring back to the assumptions. >=20 >=20 > Starting point > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > As a starting point, I take the following premises or assumptions: >=20 > A1. Application-level resources are the main entities we are=20 > interested in. They may be named in different ways, the=20 > exact details of which is outside the scope of the current focus. >=20 > A2. Application-level entities are often logically aggregated=20 > due to different factors, including fate sharing, security=20 > privileges, mobility, etc. This application-level=20 > aggregation should be kept distinct from=20 > network-address-level aggregation. >=20 > A3. The routing system is based on the hop-by-hop paradigm,=20 > where the routers have forwarding tables that use=20 > routing-level addresses as input for the forwarding decision. >=20 > A4. Completely flat addressing is out of scope due to=20 > practical constraints to the forwarding tables and the routing system. >=20 > A5. To implement A4, the routing-level addresses (locators)=20 > are somehow aggregateable. That is, the addressing name=20 > space has internal structure (topology) that allows a larger=20 > or "more- aggregated" address range (e.g. one with a shorter=20 > prefix) to denote an area that confines a number of smaller=20 > or "less-aggregated" =20 > address ranges (e.g. ones with longer prefixes). [Note that=20 > this definition does not mandate a tree-like addressing name=20 > space topology that we have today, but still allows it.] >=20 > Now, theoretically speaking, as the purpose of the aggress=20 > aggregation is to embed into the address some partial=20 > information about the location of the said address within the=20 > network graph, thereby relieving some burden from the=20 > forwarding tables and routing system, it immediately follows=20 > that the parts of the network graph where an address may be=20 > located at is confined by the address itself. >=20 > In more practical terms, the addresses become names of=20 > locations within the network graph, i.e., locators. That is,=20 > given a specific address, there are only a limited number of=20 > locations within the network graph where the address may=20 > "be". In a typical system, such as those used today for IPv4=20 > and IPv6, that "limited number of locations" equals to the=20 > subnet identified by the address prefix. >=20 > Still more practically, what I mean is that due to the=20 > assumptions made about the forwarding parading and network=20 > layer addressing, the addresses in the system are names of=20 > locations (points of attachment) in the network, and not e.g.=20 > location-independent names of mobile hosts. >=20 > Basics of multi-homing > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This structure leads to a situation where we apparently must=20 > make a distinction between two different types of "multi-path"*: >=20 > P1. In the network graph, there may be alternative routing=20 > paths between two areas that are named with some given,=20 > unique address ranges. In today's terms, this would be=20 > reflected by having multiple routing table entries for a=20 > given prefix. This is what Joel called "multi-pathing" in=20 > his message (http://www1.ietf.org/mail-archive/web/ > architecture-discuss/current/msg00682.html ). >=20 > P2. In the network graph, there may be areas (including=20 > single nodes) that are identified by more than one address=20 > ranges. This is what Joel called "multi-homing". >=20 > Note that the underlying network graph may be identical in=20 > cases P1 and P2. The only difference is how we decide to=20 > name locations, i.e., in address assignment. In P1 we assign=20 > only one range of addresses to the "multi-homed" location=20 > while in P2 we assign two or more. Further note that this=20 > naming decision is apparently motivated by the assumptions A4=20 > and A5, in an attempt to make the address space topology and=20 > the topology of the network graph match in such a way that=20 > the size of the routing and forwarding tables can be reduced. >=20 > [Footnote *) This is a point where I hope to be wrong. =20 > Making the distinction between multi-path at the routing=20 > level vs. multi-path at a level above does not "feel" nice. =20 > However, to me this seems to be an implication from=20 > assumptions A3-A5. Finding alternative solutions would be=20 > very good, but given the constraints on the size of the=20 > forwarding/routing tables, propagation times, and routing=20 > computation, I find it unlikely that any practical=20 > alternatives exist.] >=20 > To summarise so far: Using hop-by-hop forwarding with=20 > aggregateable addresses leads to a situation where "area"=20 > (subnet) multi-homing can be solved either by adding=20 > alternative routes into the routing table or assigning=20 > multiple address ranges. >=20 > Nothing new. Just dissecting the background assumptions. >=20 > Generalisation I, or Application Multi-homing=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > So far we have only considered the network graph and the=20 > addressing name space. Let us now consider application-level=20 > entities. >=20 > An application-level entity (resource) may be distributed, or=20 > be available through multiple points at the network graph. =20 > For example, the underlying server host may be multi-homed,=20 > the application entity may be location-dependent and=20 > implemented at several distinct server hosts, or the entity=20 > may be genuinely distributed and implemented by a distributed=20 > server farm. >=20 > Now we seem to have even more choices than in the case of=20 > network- graph-level multi-homing. I'll describe these as=20 > chains of identifiers. >=20 > C1. Top-most entity name -> One "multi-pathed" address (P1)=20 > -> Alternative routes >=20 > C2. Top-most entity name -> Multiple alternative addresses=20 > (P2) -> One route >=20 > C3. Top-most entity name -> Multiple alternative intermediate=20 > entity names (e.g. host names) -> P1 -> One Route >=20 > Of course, if supported by the underlying system, these=20 > levels of flexibility can be combined: >=20 > C4. Top-most entity name -> Alternative super-entity names ->=20 > P2 -> Alternative routes >=20 > [Of course, intermediate indirections (C3) may be recursive.] >=20 > To summarise and generalise the discussion so far, we can=20 > state that from a high-level architectural point of view,=20 > multi-homing is nothing more one-to-many mappings as one=20 > resolves higher-layer identifiers into lower-layer=20 > identifiers. The differences lie when there are one-to-many=20 > mappings and when simple one-to-one mappings. >=20 > Considering a single indirection step, the most important=20 > design choice then is when, exactly, one of the alternative=20 > lower-layer identifiers is chosen for the purposes of=20 > delivery. To summarise the more-than-two-decades old wisdom:=20 > Be lazy, bind late. >=20 > Mobility > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > Consider now mobility. From the present point of view, we=20 > can state that mobility is nothing more than dynamic mappings=20 > as one resolves higher-layer identifiers into lower layer identifiers. >=20 > Analogous to the multi-homing chains C1-C4 above, we can=20 > present mobility chains: >=20 > M1. Stable entity name -> Stable address -> Dynamic route=20 > updates (host routing) >=20 > M2. Stable entity name -> Dynamic, updateable address -> Stable routes >=20 > M3. Stable entity name -> Dynamic, updateable intermediate=20 > entity name -> Stable address -> Stable routes >=20 > M4. Stable entity name -> Dynamic super-entity name ->=20 > Dynamic address -> Dynamic route >=20 > I will skip the longer discussion here, as it would be=20 > isomorphic to the multi-homing discussion above, merely=20 > replacing mapping alternatives with temporal dynamics. >=20 > MANETs are prototypical examples of M1. NetLMM can be also=20 > considered as a peculiar example of M1. >=20 > MIP, NEMO, HIP (and potentially SHIM6 based mobility) are all=20 > examples of M2, with just different choices for the name spaces. >=20 > I am not aware of any major examples of M3, but I could=20 > imagine they could be found in various middleware frameworks.=20 > And I think SIP could also offer such examples. >=20 > Discussion > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > By now, the structural (architectural?) parallels between=20 > multi- homing and mobility should be clear: >=20 > Layer Multi-homing Mobility >=20 > Routing Traditional, routing- Micro mobility > based site multi-homing e.g. MANETs >=20 > Routing- (GSE?) So called edge mobility, > Addressing e.g. NetLMM > boundary >=20 > Addressing Multi-address multi-homing, Most node mobility =20 > protocols, > e.g. SHIM6, GSE e.g. MIP and HIP >=20 > =20 > Tunnelling-based solutions, > e.g. NEMO and MOBIKE >=20 > Application- Multiple A/AAAA RRs DynDNS > Addressing > boundary Renumbering, > (but on a=20 > different time scale) >=20 > Application Distributed applications, Application mobility, > e.g. location dependent ones e.g. process migration >=20 > [Footnote: I am not sure about the "right" positioning of=20 > GSE. The position of NetLMM could also be discussed; I'd be=20 > tempted to classify it as a "routing" solution, but others=20 > apparently disagree.] >=20 > Hence, it is this point of view that I say that mobility and=20 > multi- homing are architecturally quite similar. >=20 > There is one thing that I haven't considered at all, on=20 > purpose: Time scales, including make-before-break vs.=20 > break-before-make. They make a difference. But that's one=20 > level down towards the details, in my opinion. They are=20 > still architectural, but not the highest point of view. =20 > Anyway, this message is long enough already now; the=20 > differences would warrant a separate message. >=20 > The big question is whether the similarities and co-occurring=20 > usage scenarios are plausible enough so that mobility and=20 > multi-homing should be handled in an architecturally unified=20 > way, or whether the differences are so big and the phenomena=20 > so separate that the added minor complexity does not pay off. >=20 > By now you should be able to guess my current opinion. >=20 > --Pekka Nikander >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 22:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRMn-0000XQ-J7; Thu, 23 Nov 2006 22:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRMm-0000XI-01 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:04:40 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnRMg-0004JT-Q1 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:04:39 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A816B340CD; Thu, 23 Nov 2006 22:04:34 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 22:04:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Thu, 23 Nov 2006 22:04:32 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E842@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccPPx64fCeuIQrUTWWYP6C4cq5CfgANVqsA From: "Bound, Jim" To: "David Conrad" , X-OriginalArrivalTime: 24 Nov 2006 03:04:34.0387 (UTC) FILETIME=[44D6DA30:01C70F75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 > > If a user changes his ISP then he would get a different address=20 > > anyway! >=20 > This is what we're trying to avoid. I don't think this can be avoided nor can it be assumed. If the address prefix used by the ISP is different a node should use it and this also has mobility implications per the use cases I sent. What should not change is the identifier. Thus here we may disagree. The complexity for routing for performance reasons will not scale ever in my view. Best /jim >=20 > Rgds, > -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 22:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRfh-0001G5-0b; Thu, 23 Nov 2006 22:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRff-0001Fy-65 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:24:11 -0500 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnRfd-0006Ci-U1 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 22:24:11 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc15) with ESMTP id <20061124032403m1500aobjbe>; Fri, 24 Nov 2006 03:24:09 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DCF9E841@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCF9E841@tayexc14.americas.cpqcorp.net> Date: Thu, 23 Nov 2006 22:23:29 -0500 To: "Bound, Jim" , "Pekka Nikander" , From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global (was Re:thoughts) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 22:03 -0500 2006/11/23, Bound, Jim wrote: >I agree and in this definition I think an anycast address is virtual too >the address in of itself does not identify what node the packet will be >delivered. Neither an anycast address nor a multicast address are addresses. We have been sloppy in our terminology. They are names of sets of addresses such that when referenced the result is a list of one or more addresses according to some rule associated with the set. Since addresses are location-dependent, there is no meaningful way for a the name of a set of addresses to be location-dependent. (Now before any of you start suggesting some idea of maximum range or some such. Yes, you could attribute such a property to them. But as some on this list keep pointing out, "It's the routing!" Such interpretations of location-dependent are no help in routing or related issues. Furthermore, it is fairly easy to come up with "monsters" that will make any such use absurd. It is easier to just admit they are names and get on with it. ;-)) Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 23:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSF5-0007Xi-4G; Thu, 23 Nov 2006 23:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSF3-0007WR-0S for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:00:45 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnSEx-0000QT-P5 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:00:44 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 8C32B34174; Thu, 23 Nov 2006 23:00:39 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 23:00:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (was Re:thoughts) Date: Thu, 23 Nov 2006 23:00:38 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E849@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (was Re:thoughts) Thread-Index: AccPeAJyz0VZdDPbQpC5awGXsE9ikQABP2Ag From: "Bound, Jim" To: "John Day" , "Pekka Nikander" , X-OriginalArrivalTime: 24 Nov 2006 04:00:39.0339 (UTC) FILETIME=[1A81C7B0:01C70F7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Thanks for your opinion. Correct the conceptual model of anycast addressing is virtual. /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Thursday, November 23, 2006 10:23 PM > To: Bound, Jim; Pekka Nikander; architecture-discuss@ietf.org > Cc: John Day > Subject: RE: [arch-d] On identifiers: what is virtual and=20 > what is global (was Re:thoughts) >=20 > At 22:03 -0500 2006/11/23, Bound, Jim wrote: > >I agree and in this definition I think an anycast address is virtual=20 > >too the address in of itself does not identify what node the packet=20 > >will be delivered. >=20 > Neither an anycast address nor a multicast address are=20 > addresses. We have been sloppy in our terminology. They are=20 > names of sets of addresses such that when referenced the=20 > result is a list of one or more addresses according to some=20 > rule associated with the set. >=20 > Since addresses are location-dependent, there is no=20 > meaningful way for a the name of a set of addresses to be=20 > location-dependent. (Now before any of you start suggesting=20 > some idea of maximum range or some such. Yes, you could=20 > attribute such a property to them. But as some on this list=20 > keep pointing out, "It's the routing!" Such interpretations=20 > of location-dependent are no help in routing or related=20 > issues. Furthermore, it is fairly easy to come up with=20 > "monsters" that will make any such use absurd. It is easier=20 > to just admit they are names and get on with it. ;-)) >=20 > Take care, > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 23:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSKI-0000H8-Uj; Thu, 23 Nov 2006 23:06:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSKH-0000H3-D4 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:06:09 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnSKG-0000og-3K for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:06:09 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GnSKF-0001L5-Ab for architecture-discuss@ietf.org; Thu, 23 Nov 2006 20:06:07 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Nov 2006 03:29:29 +0100 To: "Schliesser, Benson" , From: Jefsey_Morfin In-Reply-To: References: <87D9C30C-D324-4812-8524-7B32020CF23B@virtualized.org> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.3 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Subject: [arch-d] RFC 1958 Ter (RFC 3439 Bis) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2121252117==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============2121252117== Content-Type: multipart/alternative; boundary="----MTnyyshirdffkqbhztdixfzjnakddrwkay" ------MTnyyshirdffkqbhztdixfzjnakddrwkay Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-4ED82A42 At 19:52 23/11/2006, Schliesser, Benson wrote: >David Conrad [mailto:drc@virtualized.org] wrote: > > Mobility is simply renumbering on a constrained time scale. > > Architecturally, support for multi-homing (in the sense of a network- > > attached-thingie having more than one name-thingie) is not required > > for mobility. I would agree that multi-homing makes implementation > > easier. > >Though perhaps multi-homing can be treated as a sub-case of mobility, or >vice versa? That is, multi-homing could be a case of mobility with >multiple stable subnet connections, mobility could be a case of >multi-homing with unstable/changing subnet connections. Conceivably we >could have one solution for both views, no? Yes. So easy to address all this if you do not conceive addresses as a solid number. Think of network spaces as mathematical multinormed spaces. May be some of us will remember what a vector and a vectorial addition are? If there is a problem, that problem comes from RFC 1958 ter. RFC 1958 Bis (RFC 3439) considered very large network complexity. No one wrote RFC 1958 Ter yet, about the very very large global network extended complexity. IMHO all this debate will go nowhere [at least at the IAB/IETF/IRTF] as long as we do not have the adquate thinking tools and architectural principles. Then we will also need a target requierement list. jfc ------MTnyyshirdffkqbhztdixfzjnakddrwkay Content-Type: text/html At 19:52 23/11/2006, Schliesser, Benson wrote:

>David Conrad [mailto:drc@virtualized.org] wrote:
> > Mobility is simply renumbering on a constrained time scale.
> > Architecturally, support for multi-homing (in the sense of a network-
> > attached-thingie having more than one name-thingie) is not required
> > for mobility.  I would agree that multi-homing makes implementation
> > easier.
>
>Though perhaps multi-homing can be treated as a sub-case of mobility, or
>vice versa? That is, multi-homing could be a case of mobility with
>multiple stable subnet connections, mobility could be a case of
>multi-homing with unstable/changing subnet connections. Conceivably we
>could have one solution for both views, no?

Yes. So easy to address all this if you do not conceive addresses as
a solid number.
Think of network spaces as mathematical multinormed spaces.
May be some of us will remember what a vector and a vectorial addition are?

If there is a problem, that problem comes from RFC 1958 ter.
RFC 1958 Bis (RFC 3439) considered very large network complexity.
No one wrote RFC 1958 Ter yet, about the very very large global
network extended complexity.

IMHO all this debate will go nowhere [at least at the IAB/IETF/IRTF]
as long as we do not have the adquate thinking tools and
architectural principles. Then we will also need a target requierement list.
jfc

------MTnyyshirdffkqbhztdixfzjnakddrwkay-- --===============2121252117== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============2121252117==-- From architecture-discuss-bounces@ietf.org Thu Nov 23 23:24:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSbN-0002tY-N0; Thu, 23 Nov 2006 23:23:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSbM-0002tN-0P for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:23:48 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnSbI-00026p-I7 for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:23:47 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAO4JrrG059823; Thu, 23 Nov 2006 20:19:54 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 23 Nov 2006 20:23:17 -0800 X-PGP-Universal: processed; by terminus.local on Thu, 23 Nov 2006 20:23:17 -0800 In-Reply-To: <816DD9299957E547B5D758D7F977D6DCF9E842@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCF9E842@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <95A9696D-68CC-457B-A235-2D2D23A0D48E@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Thu, 23 Nov 2006 20:23:14 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jim, On Nov 23, 2006, at 7:04 PM, Bound, Jim wrote: >>> If a user changes his ISP then he would get a different address >>> anyway! >> This is what we're trying to avoid. > I don't think this can be avoided nor can it be assumed. Separating identity from location via indirection would allow us to avoid folks having to renumber when they change providers and thus allowing locators to be highly aggregated. > If the address > prefix used by the ISP is different a node should use it and this also > has mobility implications per the use cases I sent. The whole point of this discussion is that the term "address" as it is used today implies the concepts of identity and location are merged. "Addresses" as they are used today simply will not scale. Period. Since I do not believe we have the luxury of coming up with and deploying IPv7, we have to backfit the separation of identity from location into IPv6. > What should not change is the identifier. Exactly. To bad identity and location is the same thing in IPv4 and IPv6. > Thus here we may disagree. The complexity > for routing for performance reasons will not scale ever in my view. As I'm sure you are aware, aggregation allows hiding of information thereby allowing for greater scalability. As long as identity and location are tied, the only way you can aggregate is by forcing identity to change when location changes. Since changing identity is hard, people don't do it and thus, scalability goes out the window. This does not have to be the case. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 23 23:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnT05-0006G7-U7; Thu, 23 Nov 2006 23:49:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnT05-0006Fy-4g for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:49:21 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnT03-0004Zn-Sh for architecture-discuss@ietf.org; Thu, 23 Nov 2006 23:49:21 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc13) with ESMTP id <20061124044908b1300t99kce>; Fri, 24 Nov 2006 04:49:19 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <95A9696D-68CC-457B-A235-2D2D23A0D48E@virtualized.org> References: <816DD9299957E547B5D758D7F977D6DCF9E842@tayexc14.americas.cpqcorp.net> <95A9696D-68CC-457B-A235-2D2D23A0D48E@virtualized.org> Date: Thu, 23 Nov 2006 23:48:32 -0500 To: David Conrad , "Bound, Jim" From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 20:23 -0800 2006/11/23, David Conrad wrote: >Jim, > >On Nov 23, 2006, at 7:04 PM, Bound, Jim wrote: >>>>If a user changes his ISP then he would get a different address anyway! >>>This is what we're trying to avoid. >>I don't think this can be avoided nor can it be assumed. > >Separating identity from location via indirection would allow us to >avoid folks having to renumber when they change providers and thus >allowing locators to be highly aggregated. > >>If the address >>prefix used by the ISP is different a node should use it and this also >>has mobility implications per the use cases I sent. > >The whole point of this discussion is that the term "address" as it >is used today implies the concepts of identity and location are >merged. "Addresses" as they are used today simply will not scale. >Period. Since I do not believe we have the luxury of coming up with >and deploying IPv7, we have to backfit the separation of identity >from location into IPv6. We had that opportunity 14 years ago and decided to stick with what doesn't work. Fundamentally one can not "locate" without "identifying." This is why this whole loc/id discussion has been such a red herring. Addresses as they are used today are being used in half an addressing architecture which is why they don't scale, not because they are addresses. >>What should not change is the identifier. > >Exactly. To bad identity and location is the same thing in IPv4 and IPv6. Only because you don't have a complete addressing architecture. If it was complete, you would all of the names whether addresses, names or identifiers, would do what they need to do quite well. > >>Thus here we may disagree. The complexity >>for routing for performance reasons will not scale ever in my view. > >As I'm sure you are aware, aggregation allows hiding of information >thereby allowing for greater scalability. As long as identity and >location are tied, the only way you can aggregate is by forcing >identity to change when location changes. Since changing identity is >hard, people don't do it and thus, scalability goes out the window. >This does not have to be the case. All of these arguments are an artifact of the current approach not universally the case. Perhaps we should figure out what does work and then worry about how we get there. Rather worry about how to fix what we have with no clear idea of where we need to go. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 00:40:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTmm-0004PJ-K3; Fri, 24 Nov 2006 00:39:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTmk-0004NK-Es for architecture-discuss@ietf.org; Fri, 24 Nov 2006 00:39:38 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnTme-0001Bw-5e for architecture-discuss@ietf.org; Fri, 24 Nov 2006 00:39:38 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id D70CD3409C; Fri, 24 Nov 2006 00:39:32 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 00:39:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Fri, 24 Nov 2006 00:39:27 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E84E@tayexc14.americas.cpqcorp.net> In-Reply-To: <95A9696D-68CC-457B-A235-2D2D23A0D48E@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccPgFINDpWb60ZbSKe0oTNqGkX6IAACWd8g From: "Bound, Jim" To: "David Conrad" X-OriginalArrivalTime: 24 Nov 2006 05:39:29.0437 (UTC) FILETIME=[E91EECD0:01C70F8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dave,=20 > On Nov 23, 2006, at 7:04 PM, Bound, Jim wrote: > >>> If a user changes his ISP then he would get a different address=20 > >>> anyway! > >> This is what we're trying to avoid. > > I don't think this can be avoided nor can it be assumed. >=20 > Separating identity from location via indirection would allow=20 > us to avoid folks having to renumber when they change=20 > providers and thus allowing locators to be highly aggregated. Agree and that aggregation is important but will not always be possible. We must separate entirely locator and identifier. Routing and the locator I use are to me entirely separate from the identification. >=20 > > If the address > > prefix used by the ISP is different a node should use it=20 > and this also=20 > > has mobility implications per the use cases I sent. >=20 > The whole point of this discussion is that the term "address"=20 > as it is used today implies the concepts of identity and=20 > location are =20 > merged. =20 That is where I believe I disagree. Open list and open discussion so we shall see where it goes. What Pekka N. proposed leaves this question open for now. If ISP1 has prefix for location as FFEE but ISP2 has prefix FEEF the aggregation is only for the first order bits (leaving undefined) and without more bits location cannot be known for routing. The identifier comes into play only for me between the two end-to-end applications, security enhancements, and transport end-points possibly. Whether that is part of an IP address with the locator for me is premature discussion and identifying the requirements. >"Addresses" as they are used today simply will not scale. =20 > Period. Since I do not believe we have the luxury of coming=20 > up with and deploying IPv7, we have to backfit the separation=20 > of identity from location into IPv6. >=20 > > What should not change is the identifier. >=20 > Exactly. To bad identity and location is the same thing in=20 > IPv4 and IPv6. Yes and that is the hard part of the work here to alleviate and I am hoping we hear a lot of different persons bright ideas to resolve this and analysis. >=20 > > Thus here we may disagree. The complexity for routing for=20 > performance=20 > > reasons will not scale ever in my view. >=20 > As I'm sure you are aware, aggregation allows hiding of=20 > information thereby allowing for greater scalability. As=20 > long as identity and location are tied, the only way you can=20 > aggregate is by forcing identity to change when location=20 > changes. Since changing identity is hard, people don't do it=20 > and thus, scalability goes out the window. =20 > This does not have to be the case. Agree with the problem statement and why I allude above that the identifier may not part of the IP address. Best, /jim >=20 > Rgds, > -drc >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 02:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnV8z-0004Bm-S6; Fri, 24 Nov 2006 02:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnV8x-00048R-9r for architecture-discuss@ietf.org; Fri, 24 Nov 2006 02:06:39 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnV8v-00052B-QM for architecture-discuss@ietf.org; Fri, 24 Nov 2006 02:06:39 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 51F97212F31; Fri, 24 Nov 2006 09:06:29 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0D744212C7C; Fri, 24 Nov 2006 09:06:29 +0200 (EET) In-Reply-To: <7.0.0.16.2.20061124114728.045c9510@apnic.net> References: <7.0.0.16.2.20061124114728.045c9510@apnic.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] Nomadism vs. Mobility (was Re:Primary and lesser names, or layers of indirection?) Date: Fri, 24 Nov 2006 09:06:35 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Geoff, > ... The critical distinction here is one that I've heard described > as "nomadism" vs "mobility". Typically I've heard the term > "mobility" to refer to a "home and away" model, where there is a > fixed 'reference point' for rendezvous, while "nomadism" has no > such 'home'. I can easily understand that being stuck in the typical IETF discussions today, that becomes the case. Unfortunately, when dealing with non-technical people, to them "mobility" means still something different. To them "mobility" means that some physical, networked things either move around or are being moved around. For example, that vehicles (embedded with nodes), humans (carrying nodes), etc, move around. Even understanding the difference between subnetwork mobility and node mobility is hard for them. Hence, when I am speaking about mobility I prefer to disregard the "home and away" model. In my humble opinion, the "home and away" model was -- and still is -- a dire architectural mistake. It was a hack that was designed to work for the then-current IPv4; rereading Charlie's et al 1996 IEEE Personal Communications paper may help. The mistake the IETF took was to stick to the "home and away" model while moving to IPv6. Today, even some ADs seem to agree that the orthodox or strict "home and away" model is causing more problems than solving. > Multi6 highlighted this as there is no referential locator between > the set of potential locators. This appears to suggest that > mobility (in the 'home and away' sense) is not a multi-homing case, > and while you could view all mobility as nomadism, So far I agree, but ... > this appears to be a sub-optimal route in that the referential > point has come in useful, particularly in respect to security > functions associated with mobility. ... with all respect, it is complete nonsense that the "referential point", i.e., the equivalent of Mobile IP home agent, would somehow be useful for security functions. It is useful for rendezvous and tackling with the double jump problem. However, you do not need to make the referential point as an architectural corner stone to achieve that. You can relatively easily design combined mobility and multi-homing first, with full security and without any referential points, and then *add* the referential points to the design in order to ease rendezvous and double jump. (That is what we did with HIP, as you should know. And the same exercise would be easily done on the top of SHIM6/CGAs. The latter exercise was alluded already before SHIM6 even existed, in the Roe & O'Shea 2001 CAM paper: http://research.microsoft.com/research/pubs/view.aspx? type=Publication&id=1382 ) If you want a respected, peer reviewed publication, most of the security argumentation should be in 'Tuomas Aura, Pekka Nikander, and Gonzalo Camarillo, "Effects of Mobility and Multihoming on Transport- Protocol Security," in Proc. 2004 IEEE Symposium on Security and Privacy (SSP'04), Berkeley, CA USA, May 2004.' I don't know if it gets it all, but at least we tried to get it there. On the other hand, if with "useful... to security functions associated with mobility" you want to say that such a referential point is useful in securing certain business models, then I must agree. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 04:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnWy7-0000Tl-Qh; Fri, 24 Nov 2006 04:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnWy6-0000OQ-6z for architecture-discuss@ietf.org; Fri, 24 Nov 2006 04:03:34 -0500 Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnWy4-00034S-US for architecture-discuss@ietf.org; Fri, 24 Nov 2006 04:03:34 -0500 Received: from HeinerHummel@aol.com by imo-d05.mx.aol.com (mail_out_v38_r7.6.) id b.d24.9a2689 (43930); Fri, 24 Nov 2006 04:03:18 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Fri, 24 Nov 2006 04:03:17 EST Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... To: drc@virtualized.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1223126656==" Errors-To: architecture-discuss-bounces@ietf.org --===============1223126656== Content-Type: multipart/alternative; boundary="-----------------------------1164358997" -------------------------------1164358997 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > Why is it not feasable to integrate a 4 byte sized AS number (of > the primary service provider) into a 16 byte sized IPv6-address ? It is feasible, but since that ties location with identity, you aren't solving any real problem. H.H: Well, that is a matter of how you deal/handle/operate/manipulate with the 16-Byte-sized entity. By choosing a sub-structure which is capable to support routing then I think something is accomplished. IMHO prefix block building is the most minimal support as it tries to make the routing task doable. But beyond that it does not support routing at all. And the same is true with respect to addressing=identifying : Look E164 is done via DNS which is fine for the moment. But if you go for the profound redesign then that should not be necessary anymore, should it? Heiner > If a user changes his ISP then he would get a different address > anyway! This is what we're trying to avoid. Rgds, -drc -------------------------------1164358997 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
 
 > Why is it not feasable to integrate a 4 byte sized AS nu= mber=20 (of 
> the primary service provider) into a 16 byte sized=20 IPv6-address ?

It is feasible, but since that ties location with=20 identity, you 
aren't solving any real problem.
 
H.H: Well, that is a matter of how you deal/handle/operate/manipula= te=20 with the 16-Byte-sized entity. By choosing a sub-structure which is capable=20= to=20 support routing then I think something is accomplished.
IMHO prefix block building is the most minimal support as it tries to m= ake=20 the routing task doable. But beyond that it does not support routing at=20 all.
 
And the same is true with respect to addressing=3Didentifying : Look E1= 64 is=20 done via DNS which is fine for the moment. But if you go for the profound=20 redesign then that should not be necessary anymore, should it?
 
Heiner
 
 
 > If a user changes his ISP then he would get a different=20 address 
> anyway!

This is what we're trying to=20 avoid.

Rgds,
-drc
 
-------------------------------1164358997-- --===============1223126656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1223126656==-- From architecture-discuss-bounces@ietf.org Fri Nov 24 04:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnXFu-0001vi-TG; Fri, 24 Nov 2006 04:21:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnXFu-0001vd-2X for architecture-discuss@ietf.org; Fri, 24 Nov 2006 04:21:58 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnXFs-0007Zx-Mt for architecture-discuss@ietf.org; Fri, 24 Nov 2006 04:21:58 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kAO9LttA167498 for ; Fri, 24 Nov 2006 09:21:55 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAO9Ojci2019370 for ; Fri, 24 Nov 2006 09:24:45 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAO9Ll8w004398 for ; Fri, 24 Nov 2006 09:21:50 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAO9LkKb004344; Fri, 24 Nov 2006 09:21:46 GMT Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA101556; Fri, 24 Nov 2006 10:21:44 +0100 Message-ID: <4566B9AA.5000806@zurich.ibm.com> Date: Fri, 24 Nov 2006 10:21:46 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [arch-d] Nomadism vs. Mobility (was Re:Primary and lesser names, or layers of indirection?) References: <7.0.0.16.2.20061124114728.045c9510@apnic.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: John Day , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > On the other hand, if with "useful... to security functions associated > with mobility" you want to say that such a referential point is useful > in securing certain business models, then I must agree. Why? That would imply that the reference point for AAA is in a layer 3 namespace. That doesn't seem right at all. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 05:42:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnYTm-0004fk-D9; Fri, 24 Nov 2006 05:40:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnYTl-0004fd-OZ for architecture-discuss@ietf.org; Fri, 24 Nov 2006 05:40:21 -0500 Received: from imo-m16.mx.aol.com ([64.12.138.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnYTk-0006T2-BM for architecture-discuss@ietf.org; Fri, 24 Nov 2006 05:40:21 -0500 Received: from HeinerHummel@aol.com by imo-m16.mx.aol.com (mail_out_v38_r7.6.) id i.bcd.7ba6fb3 (40523); Fri, 24 Nov 2006 05:39:44 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Fri, 24 Nov 2006 05:39:44 EST Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: jeanjour@comcast.net, drc@virtualized.org, Jim.Bound@hp.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0266247515==" Errors-To: architecture-discuss-bounces@ietf.org --===============0266247515== Content-Type: multipart/alternative; boundary="-----------------------------1164364784" -------------------------------1164364784 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Quote from below:Fundamentally one can not "locate" without "identifying." But also: Pure identifying does not help either. Try to send a letter to =20 somebody just by writing his passport number on the envelope. In the realm of ITU-T you would use address (locator) plus =20 sub-address(identifier). Heiner =20 In einer eMail vom 24.11.2006 05:51:05 Westeurop=E4ische Normalzeit schreibt= =20 jeanjour@comcast.net: At 20:23 -0800 2006/11/23, David Conrad wrote: >Jim, > >On Nov 23, 2006, at 7:04 PM, Bound, Jim wrote: >>>>If a user changes his ISP then he would get a different address anyway! >>>This is what we're trying to avoid. >>I don't think this can be avoided nor can it be assumed. > >Separating identity from location via indirection would allow us to=20 >avoid folks having to renumber when they change providers and thus=20 >allowing locators to be highly aggregated. > >>If the address >>prefix used by the ISP is different a node should use it and this also >>has mobility implications per the use cases I sent. > >The whole point of this discussion is that the term "address" as it=20 >is used today implies the concepts of identity and location are=20 >merged. "Addresses" as they are used today simply will not scale. =20 >Period. Since I do not believe we have the luxury of coming up with=20 >and deploying IPv7, we have to backfit the separation of identity=20 >from location into IPv6. We had that opportunity 14 years ago and decided to stick with what=20 doesn't work. Fundamentally one can not "locate" without "identifying." This is=20 why this whole loc/id discussion has been such a red herring.=20 Addresses as they are used today are being used in half an addressing=20 architecture which is why they don't scale, not because they are=20 addresses. >>What should not change is the identifier. > >Exactly. To bad identity and location is the same thing in IPv4 and IPv6. Only because you don't have a complete addressing architecture. If=20 it was complete, you would all of the names whether addresses, names=20 or identifiers, would do what they need to do quite well. > >>Thus here we may disagree. The complexity >>for routing for performance reasons will not scale ever in my view. > >As I'm sure you are aware, aggregation allows hiding of information=20 >thereby allowing for greater scalability. As long as identity and=20 >location are tied, the only way you can aggregate is by forcing=20 >identity to change when location changes. Since changing identity is=20 >hard, people don't do it and thus, scalability goes out the window.=20 >This does not have to be the case. All of these arguments are an artifact of the current approach not=20 universally the case. Perhaps we should figure out what does work and then worry about how=20 we get there. Rather worry about how to fix what we have with no=20 clear idea of where we need to go. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1164364784 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Quote from below:Fundamentally one can not "locate" without=20 "identifying."
But also: Pure identifying does not help either. Try to send a letter t= o=20 somebody just by writing his passport number on the envelope.
In the realm of ITU-T you would use address (locator) plus=20 sub-address(identifier).
Heiner
 
In einer eMail vom 24.11.2006 05:51:05 Westeurop=E4ische Normalzeit sch= reibt=20 jeanjour@comcast.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>At 20:23=20 -0800 2006/11/23, David Conrad wrote:
>Jim,
>
>On Nov 23= ,=20 2006, at 7:04 PM, Bound, Jim wrote:
>>>>If a user changes h= is=20 ISP then he would get a different address anyway!
>>>This is w= hat=20 we're trying to avoid.
>>I don't think this can be avoided nor ca= n it=20 be assumed.
>
>Separating identity from location via indirecti= on=20 would allow us to
>avoid folks having to renumber when they change=20 providers and thus
>allowing locators to be highly=20 aggregated.
>
>>If the address
>>prefix used by th= e=20 ISP is different a node should use it and this also
>>has mobilit= y=20 implications per the use cases I sent.
>
>The whole point of t= his=20 discussion is that the term "address" as it
>is used today implies=20= the=20 concepts of identity and location are
>merged.  "Addresses" as= =20 they are used today simply will not scale. 
>Period.  Sin= ce I=20 do not believe we have the luxury of coming up with
>and deploying=20 IPv7, we have to backfit the separation of identity
>from location=20= into=20 IPv6.

We had that opportunity 14 years ago and decided to stick wit= h=20 what
doesn't work.

Fundamentally one can not "locate" without=20 "identifying."  This is
why this whole loc/id discussion has been= =20 such a red herring.
Addresses as they are used today are being used in= =20 half an addressing
architecture which is why they don't scale, not bec= ause=20 they are
addresses.

>>What should not change is the=20 identifier.
>
>Exactly.  To bad identity and location is=20= the=20 same thing in IPv4 and IPv6.

Only because you don't have a complete= =20 addressing architecture.  If
it was complete, you would all of th= e=20 names whether addresses, names
or identifiers, would do what they need= to=20 do quite well.

>
>>Thus here we may disagree.  The= =20 complexity
>>for routing for performance reasons will not scale e= ver=20 in my view.
>
>As I'm sure you are aware, aggregation allows=20 hiding of information
>thereby allowing for greater scalability.&nb= sp;=20 As long as identity and
>location are tied, the only way you can=20 aggregate is by forcing
>identity to change when location changes.=20 Since changing identity is
>hard, people don't do it and thus,=20 scalability goes out the window.
>This does not have to be the=20 case.

All of these arguments are an artifact of the current approac= h=20 not
universally the case.

Perhaps we should figure out what doe= s=20 work and then worry about how
we get there.  Rather worry about h= ow=20 to fix what we have with no
clear idea of where we need to go.

= Take=20 care,
John

_______________________________________________
Ar= chitecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164364784-- --===============0266247515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0266247515==-- From architecture-discuss-bounces@ietf.org Fri Nov 24 06:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZeu-0008Hd-23; Fri, 24 Nov 2006 06:55:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnZes-0008HS-Eg; Fri, 24 Nov 2006 06:55:54 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnZer-0007Yh-No; Fri, 24 Nov 2006 06:55:54 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2C3F489873; Fri, 24 Nov 2006 13:55:48 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B1B6C8986A; Fri, 24 Nov 2006 13:55:47 +0200 (EET) Message-ID: <4566DDC4.3060109@piuha.net> Date: Fri, 24 Nov 2006 13:55:48 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: Pekka Nikander , Jarno Rajahalme Subject: Re: [arch-d] Last Call comments on draft-laganier-ipv6-khi-05 ORCHID References: <0225975A-1979-409D-9B82-9EB24071C219@nomadiclab.com> In-Reply-To: <0225975A-1979-409D-9B82-9EB24071C219@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: IESG IESG , IETF Discussion , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka, Jarno, Thank you Jarno for the comments. A few observations: 1) You are right Jarno that the document is inconsistent with its claim of RFC 3513 compliance. The document needs to change in some manner to resolve this. 2) Nevertheless, as we discussed this draft in the IESG, it was felt that while there are issues in the choice of the location of the prefix in the address space, it is more important to first look at the higher level issue that Ted Hardie raised. For discussion, see these e-mails: http://www1.ietf.org/mail-archive/web/ietf/current/msg44187.html http://www1.ietf.org/mail-archive/web/ietf/current/msg44183.html and please state your opinion! If we can't agree that this type of use of addresses is a good idea to begin with, arguing about the details make little difference. My personal opinion is that the benefits from this type of an allocation far outweigh the risks of referral leakage etc (and the type of leakage is already occurring from RFC 1918 address space). 3) Does the move to a different starting bits remove the above concern? Personally, I don't think it makes a lot of difference. Applications do not look at the bits. It is definately easier from a debugging point of view, however. 4) When I looked at the issue of prefix size I did not find any evidence that you would actually need more bits than the 100-or-so that the current draft states. But I'm not an expert in key lengths. Perhaps you have some specific arguments that we could look at? But lets still stay focused on the idea that this is an experiment and targeted for IP layer operations. This isn't your banking records archival system. And I don't think its a good idea to keep the same IP layer identifiers for decades; the required safety margins need to be designed accordingly. And its a temporary experiment. I do not think we should allocate more address space for this than is really necessary. And yes, it is a good idea to not to set a precedent that we can allocate more address space than needed. But if there's an argument that we actually DO need more bits, this can certainly be considered. 5) The suggested localized, DNS-based lookup scheme: none of this has ever been in the draft. I think we should experiment with ideas like the one that you have Jarno. And there are many ways to do it. But isn't the right approach for you to write a draft about it? I understand that there are many needs beyond the one that the khi draft is addressing. But it is not clear to me that we should hold up HIP experiments until we've decided how to do identifier lookups. And there are many ways to do it. I would also recommend experimenting and testing these techniques before we standardize them. Experimental allocations, experimental protocols in this space would be very welcome. Once we have some evidence that they actually work and are useful, we can start discussing moving them to real use and standards track. --Jari Pekka Nikander kirjoitti: > Jarno, > > Thanks for your valuable comments. While I largely agree with you, I'm > afraid that what you ask below, and what we originally asked for in > the first versions of the ORCHID draft, are just too much for the > wider IETF community to swallow at this point of time. In other words, > the original version of the ORCHID draft asked for more than the > current one; not exactly in the way you did in your message, but > still. The current draft represents a consensus that was achieved at > the Internet Area mailing list. A watered down consensus if you will, > but, hey, this is the IETF. :-) > > A few details: >> - 1st of all, the ORCHID proposal is contradicting itself. It calls >> for conformity with RFC 3513 section 2.5.4, but breaks this: >> >> "All global unicast addresses other than those that start with binary >> 000 have a 64-bit interface ID field (i.e., n + m = 64), " >> >> - Therefore it is wrong to ask for allocation under IANA Special >> Purpose Address Block (which starts with binary 001). >> >> - ORCHID should ask for something like 0400::/6 (binary 0000 01), >> claiming 1/8 of the address space starting with binary 000 > > We originally asked for 1000::/8 (binary 0001 0000), which falls > within the binary 000. Then there would have been 120 bits of the > hash, instead of the kind-of regional structure that you propose. > Personally, I still think that the 100 bits of hash is problematic. It > won't take that long before it will be vulnerable to brute force > attacks. By Moore's law, 120 bits would give us some 20-30 years more. > > But that was deemed unsuitable by some old-time IETFers, including a > former member of the IAB. Basically, if I understood correctly, the > original proposal was felt to overstep the RIR policies. Secondly, > apparently, some people feared that it would open up the floodgates to > the 0000::/3 space, which was considered politically very bad. There > were corridor rumours of fears that if this experiment was given > something, then other SDOs would come and ask for similar pieces of > space for non-addressing purposes. Personally, I don't understand what > would be so bad there. But hey, apparently I don't understand the IETF > power politics in any case; that I have bitterly felt enough of times. > > Hence, as I stated above, the current proposal is the compromise we > were able to reach. > > Personally, I still think that allocation from 0000::/3 would be > better than what we ask for in the current draft. As you indicated > later, it would to make a distinction between ORCHIDs/Identifiers and > "mere" addresses. However, at least one of the IESG members seems to > think that there is no difference on where the prefix is allocated, > from the apps point of view, and apparently not worth doing due to the > reasons stated above. But I may be misreading people's words. On the > other hand, personally, I think RFC 3513 makes a potential difference. > >> - Maybe should be asked for limited time experimentation (e.g. 5 >> years), and all systems could be mandated to cease using these >> addresses after the dead line. Unless the status is changed >> before expiration? > > That is exactly what we asked for originally: a time-limited > experiment, with by-default cease of use. Again, that was removed as a > part of the drafting process. > >> The hash function will need to be changed to include the prefix >> as input. > > I think that change was already done as per security review, but my > memory may fail here. Julien took care of that change. > >> If I recall right, one of the expressed concerns against ORCHID has >> been semantical overloading. By using address space starting with >> binary 000 this overloading is avoided. > > I completely agree with you here, but some other people seem to > bitterly disagree. > > --Pekka Nikander > > PS. I don't read ietf-discuss. If you want your replies to reach me, > please include my personal address in the CC/To field. > > > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 07:21:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gna3J-0004ks-Lk; Fri, 24 Nov 2006 07:21:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gna3I-0004km-9y for architecture-discuss@ietf.org; Fri, 24 Nov 2006 07:21:08 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gna3G-0001d4-QA for architecture-discuss@ietf.org; Fri, 24 Nov 2006 07:21:08 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0B0BC212C63; Fri, 24 Nov 2006 14:21:03 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 58480212C54; Fri, 24 Nov 2006 14:21:02 +0200 (EET) In-Reply-To: <4566B9AA.5000806@zurich.ibm.com> References: <7.0.0.16.2.20061124114728.045c9510@apnic.net> <4566B9AA.5000806@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CC56F14-0363-4882-B928-E688B2A5D99E@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Nomadism vs. Mobility (was Re:Primary and lesser names, or layers of indirection?) Date: Fri, 24 Nov 2006 14:21:07 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: John Day , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian, >> On the other hand, if with "useful... to security functions >> associated with mobility" you want to say that such a referential >> point is useful in securing certain business models, then I must >> agree. > > Why? That would imply that the reference point for AAA is in a layer 3 > namespace. That doesn't seem right at all. What I was alluding to was my impression that most, if not all, of the security mechanisms build for Mobile IP seem to be based on the operator-centric idea where access and mobility security are combined or at least very compatible. Of course, as such that does not directly favour any specific business models. However, if the access provides take an administrative stance where they require that the security credentials used for access and those used for mobility management must be drawn from the same security infrastructure (say AAA), that may be turned to necessitate the mobile users to have a "home operator" in order to gain local access in the first place. That, in turn, creates some sort of an oligopoly, through raising entry barriers. In other words, the only thing I was alluding to is that the Mobile IP security work seems to be designed to favour (but not necessarily enforce) an operator-centric, oligopolistic business model. Of course, that all is quite natural given who are defining those mechanism. Requiring traffic, or at least some signalling traffic, to go through a "home network" is good for an operator-centric business model, and it is easy to build the involved security mechanisms so that they even more support such business models. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 07:47:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaRn-0008QR-3q; Fri, 24 Nov 2006 07:46:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaRl-0008QM-3y for architecture-discuss@ietf.org; Fri, 24 Nov 2006 07:46:25 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnaRi-00050B-Qb for architecture-discuss@ietf.org; Fri, 24 Nov 2006 07:46:25 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20061124124610m1100t7p5ee>; Fri, 24 Nov 2006 12:46:21 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 24 Nov 2006 07:43:11 -0500 To: HeinerHummel@aol.com, jeanjour@comcast.net, drc@virtualized.org, Jim.Bound@hp.com From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1306041422==" Errors-To: architecture-discuss-bounces@ietf.org --===============1306041422== Content-Type: multipart/alternative; boundary="============_-1047750116==_ma============" --============_-1047750116==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:39 -0500 2006/11/24, HeinerHummel@aol.com wrote: >Quote from below:Fundamentally one can not "locate" without "identifying." >But also: Pure identifying does not help either. Try to send a >letter to somebody just by writing his passport number on the >envelope. Actually you can. For all intents and purposes, this is what an IP address was pre-CIDR, a name. >In the realm of ITU-T you would use address (locator) plus >sub-address(identifier). >Heiner The next thing to understand is why one should not use elements of a lower layer address as elements of a higher layer address. Take care, John --============_-1047750116==_ma============ Content-Type: text/html; charset="us-ascii" Re: [arch-d] On identifiers: what is virtual and what is g
At 5:39 -0500 2006/11/24, HeinerHummel@aol.com wrote:
Quote from below:Fundamentally one can not "locate" without "identifying."
But also: Pure identifying does not help either. Try to send a letter to somebody just by writing his passport number on the envelope.

Actually you can.  For all intents and purposes, this is what an IP address was pre-CIDR, a name.

In the realm of ITU-T you would use address (locator) plus sub-address(identifier).
Heiner

The next thing to understand is why one should not use elements of a lower layer address as elements of a higher layer address.


Take care,
John
--============_-1047750116==_ma============-- --===============1306041422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1306041422==-- From architecture-discuss-bounces@ietf.org Fri Nov 24 08:16:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnatl-0001Bk-36; Fri, 24 Nov 2006 08:15:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnatg-00012W-VV for architecture-discuss@ietf.org; Fri, 24 Nov 2006 08:15:17 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnaqx-0008Nq-Dc for architecture-discuss@ietf.org; Fri, 24 Nov 2006 08:12:33 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id CA69734048; Fri, 24 Nov 2006 08:12:24 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 08:12:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Fri, 24 Nov 2006 08:12:21 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E86C@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccPtPHbP2kpsAtkSzmtCZnhbP1RMwAFROWA From: "Bound, Jim" To: , , X-OriginalArrivalTime: 24 Nov 2006 13:12:24.0528 (UTC) FILETIME=[2EBCBD00:01C70FCA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1789083358==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============1789083358== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70FCA.2E561B6D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70FCA.2E561B6D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting. sub-address-identifier. makes me wonder should we use a = different term than identifier for that which does this and identifier = for end--to-end above IP and routing? =20 /jim ________________________________ From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: Friday, November 24, 2006 5:40 AM To: jeanjour@comcast.net; drc@virtualized.org; Bound, Jim Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] On identifiers: what is virtual and what is = global (wasRe: thou... =09 =09 =09 Quote from below:Fundamentally one can not "locate" without = "identifying." But also: Pure identifying does not help either. Try to send a letter = to somebody just by writing his passport number on the envelope. In the realm of ITU-T you would use address (locator) plus = sub-address(identifier). Heiner =20 In einer eMail vom 24.11.2006 05:51:05 Westeurop=E4ische Normalzeit = schreibt jeanjour@comcast.net: At 20:23 -0800 2006/11/23, David Conrad wrote: >Jim, > >On Nov 23, 2006, at 7:04 PM, Bound, Jim wrote: >>>>If a user changes his ISP then he would get a different address = anyway! >>>This is what we're trying to avoid. >>I don't think this can be avoided nor can it be assumed. > >Separating identity from location via indirection would allow us to=20 >avoid folks having to renumber when they change providers and thus=20 >allowing locators to be highly aggregated. > >>If the address >>prefix used by the ISP is different a node should use it and this = also >>has mobility implications per the use cases I sent. > >The whole point of this discussion is that the term "address" as it=20 >is used today implies the concepts of identity and location are=20 >merged. "Addresses" as they are used today simply will not scale. =20 >Period. Since I do not believe we have the luxury of coming up with=20 >and deploying IPv7, we have to backfit the separation of identity=20 >from location into IPv6. =09 We had that opportunity 14 years ago and decided to stick with what=20 doesn't work. =09 Fundamentally one can not "locate" without "identifying." This is=20 why this whole loc/id discussion has been such a red herring.=20 Addresses as they are used today are being used in half an addressing=20 architecture which is why they don't scale, not because they are=20 addresses. =09 >>What should not change is the identifier. > >Exactly. To bad identity and location is the same thing in IPv4 and = IPv6. =09 Only because you don't have a complete addressing architecture. If=20 it was complete, you would all of the names whether addresses, names=20 or identifiers, would do what they need to do quite well. =09 > >>Thus here we may disagree. The complexity >>for routing for performance reasons will not scale ever in my view. > >As I'm sure you are aware, aggregation allows hiding of information=20 >thereby allowing for greater scalability. As long as identity and=20 >location are tied, the only way you can aggregate is by forcing=20 >identity to change when location changes. Since changing identity is=20 >hard, people don't do it and thus, scalability goes out the window.=20 >This does not have to be the case. =09 All of these arguments are an artifact of the current approach not=20 universally the case. =09 Perhaps we should figure out what does work and then worry about how=20 we get there. Rather worry about how to fix what we have with no=20 clear idea of where we need to go. =09 Take care, John =09 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss =09 =20 ------_=_NextPart_001_01C70FCA.2E561B6D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Interesting. =20 sub-address-identifier.   makes me wonder should we use a = different=20 term than identifier for that which does this and identifier for = end--to-end=20 above IP and routing?
 
/jim

From: HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]
Sent: Friday, November 24, = 2006 5:40=20 AM
To: jeanjour@comcast.net; drc@virtualized.org; Bound,=20 Jim
Cc: architecture-discuss@ietf.org
Subject: Re: = [arch-d] On identifiers: what is virtual and what is global (wasRe:=20 thou...

Quote from below:Fundamentally one can not "locate" without=20 "identifying."
But also: Pure identifying does not help either. Try to send a = letter to=20 somebody just by writing his passport number on the = envelope.
In the realm of ITU-T you would use address (locator) plus=20 sub-address(identifier).
Heiner
 
In einer eMail vom 24.11.2006 05:51:05 Westeurop=E4ische = Normalzeit=20 schreibt jeanjour@comcast.net:
At 20:23 -0800 = 2006/11/23,=20 David Conrad wrote:
>Jim,
>
>On Nov 23, 2006, at = 7:04 PM,=20 Bound, Jim wrote:
>>>>If a user changes his ISP then = he would=20 get a different address anyway!
>>>This is what we're = trying to=20 avoid.
>>I don't think this can be avoided nor can it be=20 assumed.
>
>Separating identity from location via = indirection=20 would allow us to
>avoid folks having to renumber when they = change=20 providers and thus
>allowing locators to be highly=20 aggregated.
>
>>If the address
>>prefix used = by the=20 ISP is different a node should use it and this also
>>has = mobility=20 implications per the use cases I sent.
>
>The whole = point of=20 this discussion is that the term "address" as it
>is used = today=20 implies the concepts of identity and location are =
>merged. =20 "Addresses" as they are used today simply will not scale. =20
>Period.  Since I do not believe we have the luxury of = coming up=20 with
>and deploying IPv7, we have to backfit the separation = of=20 identity
>from location into IPv6.

We had that = opportunity 14=20 years ago and decided to stick with what
doesn't=20 work.

Fundamentally one can not "locate" without = "identifying." =20 This is
why this whole loc/id discussion has been such a red = herring.=20
Addresses as they are used today are being used in half an = addressing=20
architecture which is why they don't scale, not because they are =
addresses.

>>What should not change is the=20 identifier.
>
>Exactly.  To bad identity and = location is=20 the same thing in IPv4 and IPv6.

Only because you don't have = a=20 complete addressing architecture.  If
it was complete, you = would=20 all of the names whether addresses, names
or identifiers, would = do what=20 they need to do quite well.

>
>>Thus here we may=20 disagree.  The complexity
>>for routing for = performance=20 reasons will not scale ever in my view.
>
>As I'm sure = you are=20 aware, aggregation allows hiding of information
>thereby = allowing for=20 greater scalability.  As long as identity and
>location = are=20 tied, the only way you can aggregate is by forcing
>identity = to=20 change when location changes. Since changing identity is =
>hard,=20 people don't do it and thus, scalability goes out the window. =
>This=20 does not have to be the case.

All of these arguments are an = artifact=20 of the current approach not
universally the case.

Perhaps = we=20 should figure out what does work and then worry about how
we get = there.  Rather worry about how to fix what we have with no =
clear=20 idea of where we need to go.

Take=20 = care,
John

_______________________________________________
A= rchitecture-discuss=20 mailing=20 = list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/li= stinfo/architecture-discuss
 
------_=_NextPart_001_01C70FCA.2E561B6D-- --===============1789083358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1789083358==-- From architecture-discuss-bounces@ietf.org Fri Nov 24 08:44:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnbKz-0006dA-9J; Fri, 24 Nov 2006 08:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnbKy-0006d2-Ez for architecture-discuss@ietf.org; Fri, 24 Nov 2006 08:43:28 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnbKx-0005FS-5r for architecture-discuss@ietf.org; Fri, 24 Nov 2006 08:43:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2006 05:43:26 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAODhPR8014045; Fri, 24 Nov 2006 08:43:25 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAODhPYJ016574; Fri, 24 Nov 2006 08:43:25 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 08:43:24 -0500 Received: from [10.86.240.175] ([10.86.240.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 08:43:24 -0500 Message-ID: <4566F6FB.6080307@employees.org> Date: Fri, 24 Nov 2006 08:43:23 -0500 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [arch-d] Nomadism vs. Mobility (was Re:Primary and lesser names, or layers of indirection?) References: <7.0.0.16.2.20061124114728.045c9510@apnic.net> <4566B9AA.5000806@zurich.ibm.com> <2CC56F14-0363-4882-B928-E688B2A5D99E@nomadiclab.com> In-Reply-To: <2CC56F14-0363-4882-B928-E688B2A5D99E@nomadiclab.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2006 13:43:24.0603 (UTC) FILETIME=[836DA8B0:01C70FCE] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 11/24/2006 07:21 AM, Pekka Nikander allegedly wrote: > In other words, the only thing I was alluding to is that the Mobile IP > security work seems to be designed to favour (but not necessarily > enforce) an operator-centric, oligopolistic business model. An "operator" can provide home addresses, tunneling, authentication/authorization, charging and so on without actually running more than a server farm and something that speaks routing. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 09:44:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GncGi-0002mW-J0; Fri, 24 Nov 2006 09:43:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GncGh-0002lZ-GR for architecture-discuss@ietf.org; Fri, 24 Nov 2006 09:43:07 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GncGg-0004za-2D for architecture-discuss@ietf.org; Fri, 24 Nov 2006 09:43:07 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAOEgowx054058 for ; Fri, 24 Nov 2006 14:42:51 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAOEkKPX2412636 for ; Fri, 24 Nov 2006 15:46:20 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAOEgmcT020735 for ; Fri, 24 Nov 2006 15:42:48 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAOEgkrl020709; Fri, 24 Nov 2006 15:42:46 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA111322; Fri, 24 Nov 2006 15:42:45 +0100 Message-ID: <456704E5.9030404@zurich.ibm.com> Date: Fri, 24 Nov 2006 15:42:45 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Scott W Brim Subject: Re: [arch-d] Nomadism vs. Mobility (was Re:Primary and lesser names, or layers of indirection?) References: <7.0.0.16.2.20061124114728.045c9510@apnic.net> <4566B9AA.5000806@zurich.ibm.com> <2CC56F14-0363-4882-B928-E688B2A5D99E@nomadiclab.com> <4566F6FB.6080307@employees.org> In-Reply-To: <4566F6FB.6080307@employees.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Scott W Brim wrote: > On 11/24/2006 07:21 AM, Pekka Nikander allegedly wrote: > >>In other words, the only thing I was alluding to is that the Mobile IP >>security work seems to be designed to favour (but not necessarily >>enforce) an operator-centric, oligopolistic business model. > > > An "operator" can provide home addresses, tunneling, > authentication/authorization, charging and so on without actually > running more than a server farm and something that speaks routing. Not even that, if they are a fully virtual operator (like Tesco in the UK is a virtual gas supplier). But I think my point, and I think Pekka agrees, was that the nomadic entity that needs to be authenticated is, e.g., "Scott W Brim", and not some notionally fixed IP address. And a lot of practical nomadicity works like that already, and is remarkably indifferent to IP addresses. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 09:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GncKE-0004wu-Sm; Fri, 24 Nov 2006 09:46:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GncKD-0004vk-83 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 09:46:45 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GncK6-0005dC-VL for architecture-discuss@ietf.org; Fri, 24 Nov 2006 09:46:45 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A51A134102; Fri, 24 Nov 2006 09:46:38 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 09:46:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Nomadism vs. Mobility (was Re:Primary and lesser names, or layers of indirection?) Date: Fri, 24 Nov 2006 09:46:36 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E881@tayexc14.americas.cpqcorp.net> In-Reply-To: <456704E5.9030404@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Nomadism vs. Mobility (was Re:Primary and lesser names, or layers of indirection?) Thread-Index: AccP1x1elHpP1yDDQ920vkCSRGMdigAACJuw From: "Bound, Jim" To: "Brian E Carpenter" , "Scott W Brim" X-OriginalArrivalTime: 24 Nov 2006 14:46:38.0352 (UTC) FILETIME=[58ADD100:01C70FD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org well stated Brian and this has to be part of the list of things to work on per the mission. /jim=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Friday, November 24, 2006 9:43 AM > To: Scott W Brim > Cc: Pekka Nikander; architecture-discuss@ietf.org; John Day > Subject: Re: [arch-d] Nomadism vs. Mobility (was Re:Primary=20 > and lesser names, or layers of indirection?) >=20 > Scott W Brim wrote: > > On 11/24/2006 07:21 AM, Pekka Nikander allegedly wrote: > >=20 > >>In other words, the only thing I was alluding to is that=20 > the Mobile IP=20 > >>security work seems to be designed to favour (but not necessarily > >>enforce) an operator-centric, oligopolistic business model. =20 > >=20 > >=20 > > An "operator" can provide home addresses, tunneling,=20 > > authentication/authorization, charging and so on without actually=20 > > running more than a server farm and something that speaks routing. >=20 > Not even that, if they are a fully virtual operator (like=20 > Tesco in the UK is a virtual gas supplier). >=20 > But I think my point, and I think Pekka agrees, was that the=20 > nomadic entity that needs to be authenticated is, e.g.,=20 > "Scott W Brim", and not some notionally fixed IP address. And=20 > a lot of practical nomadicity works like that already, and is=20 > remarkably indifferent to IP addresses. >=20 > Brian >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 10:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gncdv-00066Y-D4; Fri, 24 Nov 2006 10:07:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gncdu-00066P-SG for architecture-discuss@ietf.org; Fri, 24 Nov 2006 10:07:06 -0500 Received: from web31808.mail.mud.yahoo.com ([68.142.207.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gncdq-00018K-IL for architecture-discuss@ietf.org; Fri, 24 Nov 2006 10:07:06 -0500 Received: (qmail 62576 invoked by uid 60001); 24 Nov 2006 15:06:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=0zlm+EA/wz+rkG9eoaWmIiQfZ8eEb7Gyap43G+F3BFzklU7pixoC+hMu1WCymXGKuc8Jlvp6fSRF659WM2+Bjo+jstQknZt/gST3yvAhYpbFyX0Jk07mFiYYUyeol5oXFW/9Q1En4yOgvas23BAMshxgw1qQqUh/ZRTcM52wN9Q= ; X-YMail-OSG: H6gdej4VM1mficVGeAOegE06GnM1Z59aZXgq8OjIijseYsssJaRy7r8pv.1NqMmAAA-- Received: from [68.35.81.49] by web31808.mail.mud.yahoo.com via HTTP; Fri, 24 Nov 2006 07:06:59 PST Date: Fri, 24 Nov 2006 07:06:59 -0800 (PST) From: David Barak Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: architecture-discuss@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <866404.59443.qm@web31808.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org --- John Day wrote: > At 5:39 -0500 2006/11/24, HeinerHummel@aol.com > wrote: > >Quote from below:Fundamentally one can not "locate" > without "identifying." > >But also: Pure identifying does not help either. > Try to send a > >letter to somebody just by writing his passport > number on the > >envelope. > > Actually you can. For all intents and purposes, > this is what an IP > address was pre-CIDR, a name. I don't understand - are you saying that knowledge of a unique identifier automatically provides locational information about that identifier? In the realm of the real, neither a passport number nor a US SSN (both of which uniquely identify humans) provide any useful locational information about the humans who are identified thereby. It is possible to derive some locational information (i.e. person gets job, uses SSN, that gets communicated to credit companies, ask them what city s/he's in) - but that is indirect, coarse, and often quite wrong (my job's in DC, but I'm in Albuquerque). And just to be clear, it is absolutely possible to locate 8199 parkway drive NW in New Mexico without having the foggiest idea what is there. I could develop algorithms which provide me the optimum route to reach that location without knowing anything about why I'm going or what's there. So location is a prerequisite of identification, not the other way around. > > >In the realm of ITU-T you would use address > (locator) plus > >sub-address(identifier). > >Heiner > > The next thing to understand is why one should not > use elements of a > lower layer address as elements of a higher layer > address. That was always one of my pet peeves with the IPv6 implementation of autoconf. -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 10:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GndLe-0000nG-Dp; Fri, 24 Nov 2006 10:52:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GndLd-0000nB-Q6 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 10:52:17 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GndLX-0001EJ-79 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 10:52:17 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id E72DB3400B; Fri, 24 Nov 2006 10:52:08 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 10:52:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Date: Fri, 24 Nov 2006 10:52:06 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E88A@tayexc14.americas.cpqcorp.net> In-Reply-To: <866404.59443.qm@web31808.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Thread-Index: AccP2mpUsjznUXtLQYW85w/k8VG8RgABd6sg From: "Bound, Jim" To: "David Barak" , X-OriginalArrivalTime: 24 Nov 2006 15:52:08.0564 (UTC) FILETIME=[7F449340:01C70FE0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org agree but think identification have many locations. also identification while we are here is important for nothing that has to do with location. If we can figure out identification transparent to location we can change how the SPI is determined/calculated/etc for IPsec not using location at all. =20 /jim=20 > -----Original Message----- > From: David Barak [mailto:thegameiam@yahoo.com]=20 > Sent: Friday, November 24, 2006 10:07 AM > To: architecture-discuss@ietf.org > Subject: Re: [arch-d] On identifiers: what is virtual and=20 > what is global(wasRe: thou... >=20 >=20 > --- John Day wrote: >=20 > > At 5:39 -0500 2006/11/24, HeinerHummel@aol.com > > wrote: > > >Quote from below:Fundamentally one can not "locate" > > without "identifying." > > >But also: Pure identifying does not help either. > > Try to send a > > >letter to somebody just by writing his passport > > number on the > > >envelope. > >=20 > > Actually you can. For all intents and purposes, this is what an IP=20 > > address was pre-CIDR, a name. >=20 > I don't understand - are you saying that knowledge of a=20 > unique identifier automatically provides locational=20 > information about that identifier? >=20 > In the realm of the real, neither a passport number nor a US=20 > SSN (both of which uniquely identify humans) provide any=20 > useful locational information about the humans who are=20 > identified thereby. It is possible to derive some locational=20 > information (i.e. person gets job, uses SSN, that gets=20 > communicated to credit companies, ask them what city s/he's=20 > in) - but that is indirect, coarse, and often quite wrong (my=20 > job's in DC, but I'm in Albuquerque). >=20 > And just to be clear, it is absolutely possible to locate=20 > 8199 parkway drive NW in New Mexico without having the=20 > foggiest idea what is there. I could develop algorithms=20 > which provide me the optimum route to reach that location=20 > without knowing anything about why I'm going or what's there. >=20 > So location is a prerequisite of identification, not the=20 > other way around. >=20 >=20 > >=20 > > >In the realm of ITU-T you would use address > > (locator) plus > > >sub-address(identifier). > > >Heiner > >=20 > > The next thing to understand is why one should not use=20 > elements of a=20 > > lower layer address as elements of a higher layer address. >=20 > That was always one of my pet peeves with the IPv6=20 > implementation of autoconf. >=20 > -David >=20 > David Barak > Need Geek Rock? Try The Franchise:=20 > http://www.listentothefranchise.com >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 11:07:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GndZI-000096-8Y; Fri, 24 Nov 2006 11:06:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GndZH-000091-Uw for architecture-discuss@ietf.org; Fri, 24 Nov 2006 11:06:23 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GndZE-0004Lc-Jx for architecture-discuss@ietf.org; Fri, 24 Nov 2006 11:06:23 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc11) with ESMTP id <20061124160607b1100skchge>; Fri, 24 Nov 2006 16:06:17 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DCF9E88A@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCF9E88A@tayexc14.americas.cpqcorp.net> Date: Fri, 24 Nov 2006 11:00:31 -0500 To: "Bound, Jim" , "David Barak" , From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Just to totally confuse, my own investigations of this have indicated that for very large systems of identification, identification systems become systems of locating although it is locating in a context which is non-spatial. (Think about a thesaurus or a dictionary.) Take care, John At 10:52 -0500 2006/11/24, Bound, Jim wrote: >agree but think identification have many locations. also identification >while we are here is important for nothing that has to do with location. >If we can figure out identification transparent to location we can >change how the SPI is determined/calculated/etc for IPsec not using >location at all. > >/jim > >> -----Original Message----- >> From: David Barak [mailto:thegameiam@yahoo.com] >> Sent: Friday, November 24, 2006 10:07 AM >> To: architecture-discuss@ietf.org >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is global(wasRe: thou... >> >> >> --- John Day wrote: >> >> > At 5:39 -0500 2006/11/24, HeinerHummel@aol.com >> > wrote: >> > >Quote from below:Fundamentally one can not "locate" >> > without "identifying." >> > >But also: Pure identifying does not help either. >> > Try to send a >> > >letter to somebody just by writing his passport >> > number on the >> > >envelope. >> > >> > Actually you can. For all intents and purposes, this is what an IP >> > address was pre-CIDR, a name. >> >> I don't understand - are you saying that knowledge of a >> unique identifier automatically provides locational >> information about that identifier? >> >> In the realm of the real, neither a passport number nor a US >> SSN (both of which uniquely identify humans) provide any >> useful locational information about the humans who are >> identified thereby. It is possible to derive some locational >> information (i.e. person gets job, uses SSN, that gets >> communicated to credit companies, ask them what city s/he's >> in) - but that is indirect, coarse, and often quite wrong (my >> job's in DC, but I'm in Albuquerque). >> >> And just to be clear, it is absolutely possible to locate >> 8199 parkway drive NW in New Mexico without having the >> foggiest idea what is there. I could develop algorithms >> which provide me the optimum route to reach that location >> without knowing anything about why I'm going or what's there. >> >> So location is a prerequisite of identification, not the >> other way around. >> >> >> > >> > >In the realm of ITU-T you would use address >> > (locator) plus >> > >sub-address(identifier). >> > >Heiner >> > >> > The next thing to understand is why one should not use >> elements of a >> > lower layer address as elements of a higher layer address. >> >> That was always one of my pet peeves with the IPv6 >> implementation of autoconf. >> >> -David >> >> David Barak >> Need Geek Rock? Try The Franchise: >> http://www.listentothefranchise.com >> >> >> >> ______________________________________________________________ >> ______________________ >> Do you Yahoo!? >> Everyone is raving about the all-new Yahoo! Mail beta. >> http://new.mail.yahoo.com >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 11:47:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneCd-0001TB-Ot; Fri, 24 Nov 2006 11:47:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneCc-0001T6-TN for architecture-discuss@ietf.org; Fri, 24 Nov 2006 11:47:02 -0500 Received: from nz-out-0102.google.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GneCZ-0006Qu-HF for architecture-discuss@ietf.org; Fri, 24 Nov 2006 11:47:02 -0500 Received: by nz-out-0102.google.com with SMTP id z6so492656nzd for ; Fri, 24 Nov 2006 08:46:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=e3Z56k+BbM9Yg99ugx+qdOSh9TyU2cVMaNoLvB2k4CmwxzGs8fmt59Og0fIxqedz/RNsJNH7IMd3QmsNcHjGkW2P6np5TuxR61UkGKjXNYsZlUJZHuozMha6HL8F7kvnFAq+2IlGAAiXHmWOgd+WA+anSFT8D2/vXvAeYDeDsI0= Received: by 10.35.54.1 with SMTP id g1mr6212023pyk.1164386816789; Fri, 24 Nov 2006 08:46:56 -0800 (PST) Received: by 10.35.100.11 with HTTP; Fri, 24 Nov 2006 08:46:56 -0800 (PST) Message-ID: <8ddf76f50611240846w231ae0ceq3b52cf3a19a519be@mail.gmail.com> Date: Fri, 24 Nov 2006 17:46:56 +0100 From: "William Lipkind" To: architecture-discuss@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: williamlipkind@gmail.com Subject: [arch-d] About Location and Identifier X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0671803795==" Errors-To: architecture-discuss-bounces@ietf.org --===============0671803795== Content-Type: multipart/alternative; boundary="----=_Part_58001_21336398.1164386816709" ------=_Part_58001_21336398.1164386816709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, First, thank you all for this interesting discussion! I'd like to bring another view to this ongoing debate on id-locator split: While it seems useful to "empty" the current IP address from any identification meaning and assign such task to another separate value, I've been wondering what it can mean if we look to the location in a (maybe) different way, which is close to how it is dealt (with high success) with a "target" in a military field. In fact, would it be useful to think about an approach which considers a "very" precise location as an identity by itself? This means that we drop the need to add an "explicit" identifier and we take another approach to deal with locations alone but with an identity burried inside? Does this make sense? Regards, William ------=_Part_58001_21336398.1164386816709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

First, thank you all for this interesting discussion!

I'd like to bring another view to this ongoing debate on id-locator split:

While it seems useful to "empty" the current IP address from any
identification meaning and assign such task to another separate value,
I've been wondering what it can mean if we look to the location in a
(maybe) different way, which is close to how it is dealt (with high
success) with a "target" in a military field.

In fact, would it be useful to think about an approach which considers a
"very" precise location as an identity by itself? This means that we drop
the need to add an "explicit" identifier and we take another approach to
deal with locations alone but with an identity burried inside?

Does this make sense?


Regards,

William
------=_Part_58001_21336398.1164386816709-- --===============0671803795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0671803795==-- From architecture-discuss-bounces@ietf.org Fri Nov 24 12:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnf6r-0005LU-FF; Fri, 24 Nov 2006 12:45:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnf6q-0005LP-Fh for architecture-discuss@ietf.org; Fri, 24 Nov 2006 12:45:08 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnf6p-0000UO-AG for architecture-discuss@ietf.org; Fri, 24 Nov 2006 12:45:08 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 048EC8733C; Fri, 24 Nov 2006 12:45:06 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] About Location and Identifier Message-Id: <20061124174506.048EC8733C@mercury.lcs.mit.edu> Date: Fri, 24 Nov 2006 12:45:06 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "William Lipkind" > While it seems useful to "empty" the current IP address from any > identification meaning Actually, we're mostly all proposing doing the exact opposite: removing any location meaning from the current IPv4/6 addresses. > would it be useful to think about an approach which considers a "very" > precise location as an identity by itself? No, because then, if you change your location, you change your identity - which is the very thing we are trying to avoid. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 14:26:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GngfM-0002N4-Is; Fri, 24 Nov 2006 14:24:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GngfK-0002Kr-Vj for architecture-discuss@ietf.org; Fri, 24 Nov 2006 14:24:50 -0500 Received: from web58711.mail.re1.yahoo.com ([66.196.100.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GngfJ-0003FJ-HN for architecture-discuss@ietf.org; Fri, 24 Nov 2006 14:24:50 -0500 Received: (qmail 85884 invoked by uid 60001); 24 Nov 2006 19:24:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3T2UuZdAm8At4/mm1o/0/w801HkwcUuVEyPOqENYgJ+V4c+rm2TthOJu1xnM6M78rrPAkBzdjedHBEarhFk+toGzhSPz6lPF/XbszUTGSCKItlUU3F9YQjMPxFV44rJgA5+FHL2nR+VJou4c9Z5/P0+SN8ZgbC59x6V4Bm+MXp4=; X-YMail-OSG: tjc8sisVM1mkbT3S.vfxLBIufHYzF0SkQ.pbXGLVYTMrxWE2g7Prts8Zw82Y5mbQzQ-- Received: from [207.107.50.100] by web58711.mail.re1.yahoo.com via HTTP; Fri, 24 Nov 2006 11:24:32 PST Date: Fri, 24 Nov 2006 11:24:32 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... To: Noel Chiappa , architecture-discuss@ietf.org In-Reply-To: <20061123204843.653F28731A@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <343704.84557.qm@web58711.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > (once IPvN addresses are actually location-independent names for higher-level > entities), yes, we do want to avoid that. Does the above "location" refer to geography or network topology? Peter --- Noel Chiappa wrote: > > From: David Conrad > > >> If a user changes his ISP then he would get a different address anyway! > > > This is what we're trying to avoid. > > Use of "address", without making clear which meaning is intended, again! > Let me say it with qualifiers, and see if you all agree: > > If you mean "get a new routing-name", that is exactly what we *do* want to > happen, we don't want to avoid it. If you meant "get a new IPvN address" > (once IPvN addresses are actually location-independent names for higher-level > entities), yes, we do want to avoid that. > > Noel > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 14:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnh0o-0004to-W6; Fri, 24 Nov 2006 14:47:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnh0n-0004t0-Qp for architecture-discuss@ietf.org; Fri, 24 Nov 2006 14:47:01 -0500 Received: from iceblock01.tropos.com ([12.108.168.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gnh0m-0005NA-Fs for architecture-discuss@ietf.org; Fri, 24 Nov 2006 14:47:01 -0500 Received: (qmail 31201 invoked from network); 24 Nov 2006 19:46:46 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 24 Nov 2006 19:46:46 -0000 Received: from LIPC ([192.168.1.159]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 11:46:45 -0800 From: "Tony Li" To: "'John Day'" , "'Bound, Jim'" , "'David Barak'" , Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Date: Fri, 24 Nov 2006 11:46:41 -0800 Message-ID: <000001c71001$43812fa0$9f01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccP4ofgf+X4lUV9SfOtbUNvLHfLLwAFg2JQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 24 Nov 2006 19:46:45.0871 (UTC) FILETIME=[45FF27F0:01C71001] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Just to totally confuse, my own investigations of this have indicated > that for very large systems of identification, identification systems > become systems of locating although it is locating in a context which > is non-spatial. (Think about a thesaurus or a dictionary.) You're right, that's confusing. ;-) I think it would be safer to say that systems of identifiers are necessarily structured. At the very least, administration of a large flat unstructured name space doesn't scale. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 14:56:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnh9i-0000vg-7K; Fri, 24 Nov 2006 14:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnh9g-0000vW-Hr for architecture-discuss@ietf.org; Fri, 24 Nov 2006 14:56:12 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnh9f-0006EI-A1 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 14:56:12 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20061124195609m1100t9bfle>; Fri, 24 Nov 2006 19:56:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <000001c71001$43812fa0$9f01a8c0@tropos.com> References: <000001c71001$43812fa0$9f01a8c0@tropos.com> Date: Fri, 24 Nov 2006 14:50:09 -0500 To: , "'John Day'" , "'Bound, Jim'" , "'David Barak'" , From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 11:46 -0800 2006/11/24, Tony Li wrote: > > >> Just to totally confuse, my own investigations of this have indicated >> that for very large systems of identification, identification systems >> become systems of locating although it is locating in a context which >> is non-spatial. (Think about a thesaurus or a dictionary.) > > >You're right, that's confusing. ;-) > >I think it would be safer to say that systems of identifiers are >necessarily structured. At the very least, administration of a large >flat unstructured name space doesn't scale. Indeed. But even here concepts of distance and locality may have meaning in the strict sense of a topology. I believe this is more in the direction that the semantic web is trying to pursue and others have in the past with variously named structures such as entailment diagrams, etc. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 15:02:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnhFd-0004A5-Fh; Fri, 24 Nov 2006 15:02:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnhFc-0004A0-RU for architecture-discuss@ietf.org; Fri, 24 Nov 2006 15:02:20 -0500 Received: from web58708.mail.re1.yahoo.com ([66.196.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnhFb-000727-Fs for architecture-discuss@ietf.org; Fri, 24 Nov 2006 15:02:20 -0500 Received: (qmail 58744 invoked by uid 60001); 24 Nov 2006 20:02:19 -0000 Message-ID: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=wa9LNbMiN9vAATyegAz9AZSzKRzlA7seVZBSiIjR0ieipcjjNYcPwxvF3XBypPnmyZuldQpju5zsmAfSKCt9FWyOb/ioolOz/ErLbu1o7sgWt8MYiX/fetwKostTSFy9FsnbyH06HYdkp635vbL3Q7b8CXpvJaOhARaPzfvsyrE=; X-YMail-OSG: 2fg0_tQVM1lA9zChOWvxEsTHOhDMVyltQtTLEEAL Received: from [207.107.50.100] by web58708.mail.re1.yahoo.com via HTTP; Fri, 24 Nov 2006 12:02:19 PST Date: Fri, 24 Nov 2006 12:02:19 -0800 (PST) From: Peter Sherbin Subject: RE: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. To: "Schliesser, Benson" , Pekka Nikander , architecture-discuss@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > system size could be made explicit: must we inherently make assumptions > about the relationships between networks in order to produce a more > scalable routing and addressing architecture? As a user I want: 1. an IP address pool assigned to me for a lifetime 2. a selection of competing networks to put my traffic on for as long/short as I chose 3. a complete control on what goes out with my source addresses 4. an assurance that what is coming in has come from its true originator 5. an ability to prevent receiving from unwanted senders Thanks, Peter --- "Schliesser, Benson" wrote: > > Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] wrote: > > In the current architecture [...] > > From a mathematical point of > > view, one could say that the better the topology of the addressing > > space can be matched with the topology with of the network, the less > > information needs to be stored elsewhere. > > Perhaps somebody with better mathematical understanding could comment... > > When I envision an Internet with lots of network-hierarchy, I understand > your statement to mean that aggregation is possible if addressing and > connectivity are essentially aligned. But when I envision an Internet > with no hierarchy this is no longer true. (As an extreme example, > picture an Internet where every AS was directly connected to every other > AS; compression of the address space through aggregation is only > possible at the expense of path information.) Of course, the current > Internet is somewhere in between. But who knows about the future? > > It seems to me that this relationship between connectivity and routing > system size could be made explicit: must we inherently make assumptions > about the relationships between networks in order to produce a more > scalable routing and addressing architecture? > > Cheers, > -Benson > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 15:15:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnhRb-0003iw-8g; Fri, 24 Nov 2006 15:14:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnhRa-0003in-4S for architecture-discuss@ietf.org; Fri, 24 Nov 2006 15:14:42 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnhRY-0008I1-RC for architecture-discuss@ietf.org; Fri, 24 Nov 2006 15:14:42 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061124201429b1400s45moe>; Fri, 24 Nov 2006 20:14:40 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> References: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> Date: Fri, 24 Nov 2006 15:14:04 -0500 To: Peter Sherbin , "Schliesser, Benson" , Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: RE: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Aw shucks! You don't want much, do you!? ;-) As for the first one, let me ask you something. Is your postal address the same as the place you were born? And before you tell me your phone number follows you around, refer back to previous emails on this list. Your phone number isn't a point of attachment address. The others are not that hard. Although, I would say 3 is your problem. ;-) Take care, John At 12:02 -0800 2006/11/24, Peter Sherbin wrote: > > system size could be made explicit: must we inherently make assumptions >> about the relationships between networks in order to produce a more >> scalable routing and addressing architecture? > >As a user I want: >1. an IP address pool assigned to me for a lifetime >2. a selection of competing networks to put my traffic on for as >long/short as I >chose >3. a complete control on what goes out with my source addresses >4. an assurance that what is coming in has come from its true originator >5. an ability to prevent receiving from unwanted senders > >Thanks, > >Peter > >--- "Schliesser, Benson" wrote: > >> >> Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] wrote: >> > In the current architecture [...] >> > From a mathematical point of >> > view, one could say that the better the topology of the addressing >> > space can be matched with the topology with of the network, the less >> > information needs to be stored elsewhere. >> >> Perhaps somebody with better mathematical understanding could comment... >> >> When I envision an Internet with lots of network-hierarchy, I understand >> your statement to mean that aggregation is possible if addressing and >> connectivity are essentially aligned. But when I envision an Internet >> with no hierarchy this is no longer true. (As an extreme example, >> picture an Internet where every AS was directly connected to every other >> AS; compression of the address space through aggregation is only >> possible at the expense of path information.) Of course, the current >> Internet is somewhere in between. But who knows about the future? >> >> It seems to me that this relationship between connectivity and routing >> system size could be made explicit: must we inherently make assumptions >> about the relationships between networks in order to produce a more >> scalable routing and addressing architecture? >> >> Cheers, >> -Benson >> >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 16:27:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GniYz-0004DG-Jk; Fri, 24 Nov 2006 16:26:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GniYx-00047i-RH for architecture-discuss@ietf.org; Fri, 24 Nov 2006 16:26:23 -0500 Received: from web58701.mail.re1.yahoo.com ([66.196.100.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GniYw-00035Q-47 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 16:26:23 -0500 Received: (qmail 65758 invoked by uid 60001); 24 Nov 2006 21:26:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bf0OtkQZlKfdIbjYJ2/DGhQCQRngIvCoPvMpcZBNKF6PcO6z3vIKwIHaapXqrTYy/+ivTuo+y/QSbhBQFZrIOOG6WE8ZEGeLlnU9igKWmTRCoYKDWK3chdV+EyNrRG0xRFnvXq1tr2pK+Ss0NuubgdhtarHKmfnIxNzZbxcFvq4=; X-YMail-OSG: dVStTYwVM1kUFQpxpu5EMJ6OSZ4UVj_H1u.o29jmRwVPwRqQRZ5e1_6_CG2rQNq5K8j0_U0aB0Il5vyylcjEA7qJ8pHKEy_qYEfBiULqlWan3MboF2omjxD232MOUuEbWpB3pzuXnfB2lw-- Received: from [207.107.50.100] by web58701.mail.re1.yahoo.com via HTTP; Fri, 24 Nov 2006 13:26:21 PST Date: Fri, 24 Nov 2006 13:26:21 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: David Barak , architecture-discuss@ietf.org In-Reply-To: <866404.59443.qm@web31808.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <900518.59247.qm@web58701.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org So location is a prerequisite of identification What is "location" - geography, topology, virtual? Thanks, Peter --- David Barak wrote: > > --- John Day wrote: > > > At 5:39 -0500 2006/11/24, HeinerHummel@aol.com > > wrote: > > >Quote from below:Fundamentally one can not "locate" > > without "identifying." > > >But also: Pure identifying does not help either. > > Try to send a > > >letter to somebody just by writing his passport > > number on the > > >envelope. > > > > Actually you can. For all intents and purposes, > > this is what an IP > > address was pre-CIDR, a name. > > I don't understand - are you saying that knowledge of > a unique identifier automatically provides locational > information about that identifier? > > In the realm of the real, neither a passport number > nor a US SSN (both of which uniquely identify humans) > provide any useful locational information about the > humans who are identified thereby. It is possible to > derive some locational information (i.e. person gets > job, uses SSN, that gets communicated to credit > companies, ask them what city s/he's in) - but that is > indirect, coarse, and often quite wrong (my job's in > DC, but I'm in Albuquerque). > > And just to be clear, it is absolutely possible to > locate 8199 parkway drive NW in New Mexico without > having the foggiest idea what is there. I could > develop algorithms which provide me the optimum route > to reach that location without knowing anything about > why I'm going or what's there. > > So location is a prerequisite of identification, not > the other way around. > > > > > > >In the realm of ITU-T you would use address > > (locator) plus > > >sub-address(identifier). > > >Heiner > > > > The next thing to understand is why one should not > > use elements of a > > lower layer address as elements of a higher layer > > address. > > That was always one of my pet peeves with the IPv6 > implementation of autoconf. > > -David > > David Barak > Need Geek Rock? Try The Franchise: > http://www.listentothefranchise.com > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 16:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnin0-0001ZF-7J; Fri, 24 Nov 2006 16:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnimz-0001ZA-Sx for architecture-discuss@ietf.org; Fri, 24 Nov 2006 16:40:53 -0500 Received: from web58713.mail.re1.yahoo.com ([66.196.100.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gnimy-0005VA-K4 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 16:40:53 -0500 Received: (qmail 3615 invoked by uid 60001); 24 Nov 2006 21:40:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=uYhA3w6PsS9mPSBLZfgWqYrXozMNtrawv5XCbfhv7MZZycL6XCqWdun0hkO8QYSQhtrekqIJiCDEVxtkUaeuRh3TcTfI3bz7xc/epwQXR82JbWHdpRRV6My4DtdG/M0ToPr1u+4KO9XImmaUAOn0IBRZgpNJsjXGr6ThAdb1GLg=; X-YMail-OSG: 1IrH.xEVM1kcWLwYSp0UyMk65hqSc5JP1O1NpOa7H8lPeL0S5U7nlV4_c8abRn.2jw-- Received: from [207.107.50.100] by web58713.mail.re1.yahoo.com via HTTP; Fri, 24 Nov 2006 13:40:52 PST Date: Fri, 24 Nov 2006 13:40:52 -0800 (PST) From: Peter Sherbin Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... To: tony.li@tony.li, 'John Day' , "'Bound, Jim'" , 'David Barak' , architecture-discuss@ietf.org In-Reply-To: <000001c71001$43812fa0$9f01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <295858.97970.qm@web58713.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > I think it would be safer to say that systems of identifiers are > necessarily structured. I can identify a taste of a beer from a running rabbit. In both cases all info neurons get is sequences of elctromagnetic pulses. > At the very least, administration of a large > flat unstructured name space doesn't scale. Will Social Security office ever run out of numbers? Thanks, Peter --- Tony Li wrote: > > > > Just to totally confuse, my own investigations of this have indicated > > that for very large systems of identification, identification systems > > become systems of locating although it is locating in a context which > > is non-spatial. (Think about a thesaurus or a dictionary.) > > > You're right, that's confusing. ;-) > > I think it would be safer to say that systems of identifiers are > necessarily structured. At the very least, administration of a large > flat unstructured name space doesn't scale. > > Tony > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 16:57:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnj1x-0007wE-7T; Fri, 24 Nov 2006 16:56:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnj1w-0007w8-0e for architecture-discuss@ietf.org; Fri, 24 Nov 2006 16:56:20 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnj1u-0000Dc-B8 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 16:56:19 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006112421561201100rhlnue>; Fri, 24 Nov 2006 21:56:17 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <295858.97970.qm@web58713.mail.re1.yahoo.com> References: <295858.97970.qm@web58713.mail.re1.yahoo.com> Date: Fri, 24 Nov 2006 16:47:55 -0500 To: Peter Sherbin , tony.li@tony.li, 'John Day' , "'Bound, Jim'" , 'David Barak' , architecture-discuss@ietf.org From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 13:40 -0800 2006/11/24, Peter Sherbin wrote: > > I think it would be safer to say that systems of identifiers are >> necessarily structured. > >I can identify a taste of a beer from a running rabbit. In both cases all info >neurons get is sequences of elctromagnetic pulses. > >> At the very least, administration of a large >> flat unstructured name space doesn't scale. > >Will Social Security office ever run out of numbers? Yes, and it isn't a flat space. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 17:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnjEh-0004D4-7u; Fri, 24 Nov 2006 17:09:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnjEf-0004Cy-V8 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 17:09:29 -0500 Received: from web58701.mail.re1.yahoo.com ([66.196.100.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnjEe-0002kZ-FW for architecture-discuss@ietf.org; Fri, 24 Nov 2006 17:09:29 -0500 Received: (qmail 959 invoked by uid 60001); 24 Nov 2006 22:09:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=is0mfYWU+2egf2JBCldXXw9x8fli9fTR+X+B7x5GNQJLiUn7/rhy6ShfMZ9Ml8gwzlwFQtgnFredhI9cXKD9y6gEECyznOHE7oFrv56mk2mH4HbJsuzO2ia0AiEkJPjeS7jjT7O57N/HEzrmKWpZYWSgHLZyTsn+lWJTzD+vmkY=; X-YMail-OSG: qOPXRUMVM1mIryfm7vDUaDwF5ww_1lTOpsvVxh1puURzYqIKgdfhiJmJHmUFmDOm3XwANQIhcT72ad8PufOJlJlPdW4pVu7yFn8JbL6p.n.p29XI9lC67zq_iwuE0e.s1lJjHXNHEFO5G2jlrzloApBBJOFIjioEQ48BoOWP652KzaOb0Jp0Zv3OmLE- Received: from [207.107.50.100] by web58701.mail.re1.yahoo.com via HTTP; Fri, 24 Nov 2006 14:09:27 PST Date: Fri, 24 Nov 2006 14:09:27 -0800 (PST) From: Peter Sherbin Subject: RE: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. To: John Day , "Schliesser, Benson" , Pekka Nikander , architecture-discuss@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <234206.267.qm@web58701.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > As for the first one, let me ask you something. Is your postal > address the same as the place you were born? I did not mention geography on purpose because depending on the finalized architecture it may or may not play a critical role. If it does then when I change geography I just give up old addresses and get new ones at the new geography. In this context geography must be something significant like e.g. a continent. This is kind of neat to have id+locator to follow you around. Isn't it what the mobility is about? Wrt a phone number it follows me when I travel. I like the feature and the number and want to keep it this way. > Although, I would say 3 is your problem. These are just requirements for the end product. Thanks, Peter --- John Day wrote: > Aw shucks! You don't want much, do you!? ;-) > > As for the first one, let me ask you something. Is your postal > address the same as the place you were born? And before you tell me > your phone number follows you around, refer back to previous emails > on this list. Your phone number isn't a point of attachment address. > > The others are not that hard. Although, I would say 3 is your problem. ;-) > > Take care, > John > > At 12:02 -0800 2006/11/24, Peter Sherbin wrote: > > > system size could be made explicit: must we inherently make assumptions > >> about the relationships between networks in order to produce a more > >> scalable routing and addressing architecture? > > > >As a user I want: > >1. an IP address pool assigned to me for a lifetime > >2. a selection of competing networks to put my traffic on for as > >long/short as I > >chose > >3. a complete control on what goes out with my source addresses > >4. an assurance that what is coming in has come from its true originator > >5. an ability to prevent receiving from unwanted senders > > > >Thanks, > > > >Peter > > > >--- "Schliesser, Benson" wrote: > > > >> > >> Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] wrote: > >> > In the current architecture [...] > >> > From a mathematical point of > >> > view, one could say that the better the topology of the addressing > >> > space can be matched with the topology with of the network, the less > >> > information needs to be stored elsewhere. > >> > >> Perhaps somebody with better mathematical understanding could comment... > >> > >> When I envision an Internet with lots of network-hierarchy, I understand > >> your statement to mean that aggregation is possible if addressing and > >> connectivity are essentially aligned. But when I envision an Internet > >> with no hierarchy this is no longer true. (As an extreme example, > >> picture an Internet where every AS was directly connected to every other > >> AS; compression of the address space through aggregation is only > >> possible at the expense of path information.) Of course, the current > >> Internet is somewhere in between. But who knows about the future? > >> > >> It seems to me that this relationship between connectivity and routing > >> system size could be made explicit: must we inherently make assumptions > >> about the relationships between networks in order to produce a more > >> scalable routing and addressing architecture? > >> > >> Cheers, > >> -Benson > >> > >> > >> > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > >> > > > > > >__________________________________________________ > >Do You Yahoo!? > >Tired of spam? Yahoo! Mail has the best spam protection around > >http://mail.yahoo.com > > > >_______________________________________________ > >Architecture-discuss mailing list > >Architecture-discuss@ietf.org > >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 17:24:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnjRz-0001f0-Bx; Fri, 24 Nov 2006 17:23:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnjRx-0001eP-Rk for architecture-discuss@ietf.org; Fri, 24 Nov 2006 17:23:13 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnjRt-0006AL-E2 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 17:23:13 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GnjRq-0005fv-6n for architecture-discuss@ietf.org; Fri, 24 Nov 2006 14:23:07 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Nov 2006 20:03:27 +0100 To: John Day ,"Bound, Jim" , "David Barak" , From: Jefsey_Morfin Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DCF9E88A@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2101391590==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============2101391590== Content-Type: multipart/alternative; boundary="----MTkfupcqyoilferzqroctdgwslzebeajkj" ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-487A3D48 At 17:00 24/11/2006, John Day wrote: >Just to totally confuse, my own investigations of this have >indicated that for very large systems of identification, >identification systems become systems of locating although it is >locating in a context which is non-spatial. (Think about a >thesaurus or a dictionary.) I tried to synthesise, in my own way, a consistent summary which simultaneously addresses the different (often opposite) requirements documented. This seems interesting as its seems to scale whatever the nature of the considered networking: physical, logical, intellectual. Considering that exchanged content is shipped in containers - an IP address is a topology plane related information sub-container. - a name is an application plane related information sub-container - an identity is a user/user_agent plane related information sub-container. They permit to uncouple the informations in those sub-containers. One can resolve one into the other(s) through any process agreed by the two or more ends participating to an exchange, or imposed by one of them. An authentication is a verification of the consistence of the content of these sub-containers. The information they contain may result from one or several registries, represent any concept, be organised in any order, support any type of additional function, such as authentication, encrypting, location, extensions, etc., as long as they include the appropriate information in the appropriate order and format to permit to compute the required hop/end to hop/end routing, along with the algorithm and parameters agreed by the end or imposed by some of them. Depending on the size (local, wide, very wide, very very wide), nature (centralised, decentralised, distributed), constraints (new, transition from, addition to a deployed system) different technologies can be exclusively, successively or complementary used to determine, compute, and follow the resulting route. The resulting Route (list of transited nodes and ends) can be stored in the nodes, sent to them in a route routing information container, or locally dynamically computed. Nodes can be physical, logical, or intellectual depending if the process is at data, information, or knowledge layer. Tranmission protocols are orthogonal but they probably should carry all the sub-containers information or a pointer in each fragment being transmitted. Very wide decentralised systems must constrain their options not to be strangled by complexity. This is probably not enough for very very wide systems which must be designed along a different paradigm. This paradigm seems to be granular distribution, where specialised smart standalone cells (to avoid the word node) only react to the information container, and to the part to the carried information they are interested in. As experimented in the DNS model this distributed paradigm permits to seamlessly replace complex centralised/decentralised systems (like Host.txt) by a multiplicity of much simpler elements. Most difficult issue: many users tend to confuse the address, name, identity, route sub-containers with (a part of) their content. jfc ------MTkfupcqyoilferzqroctdgwslzebeajkj Content-Type: text/html At 17:00 24/11/2006, John Day wrote:
>Just to totally confuse, my own investigations of this have
>indicated that for very large systems of identification,
>identification systems become systems of locating although it is
>locating in a context which is non-spatial.  (Think about a
>thesaurus or a dictionary.)

I tried to synthesise, in my own way, a consistent summary which
simultaneously addresses the different (often opposite) requirements
documented. This seems interesting as its seems to scale whatever the
nature of the considered networking: physical, logical, intellectual.

Considering that exchanged content is shipped in containers
- an IP address is a topology plane related information sub-container.
- a name is an application plane related information sub-container
- an identity is a user/user_agent plane related information sub-container.

They permit to uncouple the informations in those sub-containers. One
can resolve one into the other(s) through any process agreed by the
two or more ends participating to an exchange, or imposed by one of them.

An authentication is a verification of the consistence of the content
of these sub-containers.

The information they contain may result from one or several
registries, represent any concept, be organised in any order, support
any type of additional function, such as authentication, encrypting,
location, extensions, etc., as long as they include the appropriate
information in the appropriate order and format to permit to compute
the required hop/end to hop/end routing, along with the algorithm and
parameters agreed by the end or imposed by some of them.

Depending on the size (local, wide, very wide, very very wide),
nature (centralised, decentralised, distributed), constraints (new,
transition from, addition to a deployed system) different
technologies can be exclusively, successively or complementary used
to determine, compute, and follow the resulting route. The resulting
Route (list of transited nodes and ends) can be stored in the nodes,
sent to them in a route routing information container, or locally
dynamically computed. Nodes can be physical, logical, or intellectual
depending if the process is at data, information, or knowledge layer.

Tranmission protocols are orthogonal but they probably should carry
all the sub-containers information or a pointer in each fragment
being transmitted.

Very wide decentralised systems must constrain their options not to
be strangled by complexity. This is probably not enough for very very
wide systems which must be designed along a different paradigm. This
paradigm seems to be granular distribution, where specialised smart
standalone cells (to avoid the word node) only react to the
information container, and to the part to the carried information
they are interested in.

As experimented in the DNS model this distributed paradigm permits to
seamlessly replace complex centralised/decentralised systems (like
Host.txt) by a multiplicity of much simpler elements.

Most difficult issue: many users tend to confuse the address, name,
identity, route sub-containers with (a part of) their content.
jfc

------MTkfupcqyoilferzqroctdgwslzebeajkj-- --===============2101391590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============2101391590==-- From architecture-discuss-bounces@ietf.org Fri Nov 24 17:26:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnjUy-0002oc-QZ; Fri, 24 Nov 2006 17:26:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnjUx-0002oX-K9 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 17:26:19 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnjUv-00078G-P4 for architecture-discuss@ietf.org; Fri, 24 Nov 2006 17:26:19 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006112422261301100rfsv5e>; Fri, 24 Nov 2006 22:26:17 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <234206.267.qm@web58701.mail.re1.yahoo.com> References: <234206.267.qm@web58701.mail.re1.yahoo.com> Date: Fri, 24 Nov 2006 17:19:10 -0500 To: Peter Sherbin , John Day , "Schliesser, Benson" , Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: RE: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 14:09 -0800 2006/11/24, Peter Sherbin wrote: > > As for the first one, let me ask you something. Is your postal >> address the same as the place you were born? > >I did not mention geography on purpose because depending on the finalized >architecture it may or may not play a critical role. If it does then >when I change >geography I just give up old addresses and get new ones at the new >geography. In >this context geography must be something significant like e.g. a continent. >This is kind of neat to have id+locator to follow you around. Isn't >it what the >mobility is about? >Wrt a phone number it follows me when I travel. I like the feature >and the number >and want to keep it this way. Those are application names, not addresses. > > Although, I would say 3 is your problem. >These are just requirements for the end product. > >Thanks, > >Peter > >--- John Day wrote: > >> Aw shucks! You don't want much, do you!? ;-) >> >> As for the first one, let me ask you something. Is your postal >> address the same as the place you were born? And before you tell me >> your phone number follows you around, refer back to previous emails >> on this list. Your phone number isn't a point of attachment address. >> >> The others are not that hard. Although, I would say 3 is your problem. ;-) >> >> Take care, >> John >> >> At 12:02 -0800 2006/11/24, Peter Sherbin wrote: >> > > system size could be made explicit: must we inherently make assumptions >> >> about the relationships between networks in order to produce a more >> >> scalable routing and addressing architecture? >> > >> >As a user I want: >> >1. an IP address pool assigned to me for a lifetime >> >2. a selection of competing networks to put my traffic on for as >> >long/short as I >> >chose >> >3. a complete control on what goes out with my source addresses >> >4. an assurance that what is coming in has come from its true originator >> >5. an ability to prevent receiving from unwanted senders >> > >> >Thanks, >> > >> >Peter >> > >> >--- "Schliesser, Benson" wrote: >> > >> >> >> >> Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] wrote: >> >> > In the current architecture [...] >> >> > From a mathematical point of >> >> > view, one could say that the better the topology of the addressing >> >> > space can be matched with the topology with of the network, the less >> >> > information needs to be stored elsewhere. >> >> >> >> Perhaps somebody with better mathematical understanding could comment... >> >> >> >> When I envision an Internet with lots of network-hierarchy, I understand >> >> your statement to mean that aggregation is possible if addressing and >> >> connectivity are essentially aligned. But when I envision an Internet >> >> with no hierarchy this is no longer true. (As an extreme example, >> >> picture an Internet where every AS was directly connected to every other >> >> AS; compression of the address space through aggregation is only >> >> possible at the expense of path information.) Of course, the current >> >> Internet is somewhere in between. But who knows about the future? >> >> >> >> It seems to me that this relationship between connectivity and routing >> >> system size could be made explicit: must we inherently make assumptions >> >> about the relationships between networks in order to produce a more >> >> scalable routing and addressing architecture? >> >> >> >> Cheers, >> >> -Benson >> >> >> >> >> >> >> >> _______________________________________________ >> >> Architecture-discuss mailing list >> >> Architecture-discuss@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> >> > >> > >> >__________________________________________________ >> >Do You Yahoo!? >> >Tired of spam? Yahoo! Mail has the best spam protection around > > >http://mail.yahoo.com >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> > > > > >____________________________________________________________________________________ >Cheap talk? >Check out Yahoo! Messenger's low PC-to-Phone call rates. >http://voice.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 24 23:31:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnp9b-0008EJ-Ay; Fri, 24 Nov 2006 23:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnp9Z-0008ED-FP for architecture-discuss@ietf.org; Fri, 24 Nov 2006 23:28:37 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnp9T-0006HX-5P for architecture-discuss@ietf.org; Fri, 24 Nov 2006 23:28:37 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id ED20A340CF; Fri, 24 Nov 2006 23:28:32 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 23:28:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Date: Fri, 24 Nov 2006 23:28:28 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9E8B6@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Thread-Index: AccQA4Jv2CbK0a9GTJ+/wfpr9ByYnAARqBqg From: "Bound, Jim" To: "Peter Sherbin" , "Schliesser, Benson" , "Pekka Nikander" , X-OriginalArrivalTime: 25 Nov 2006 04:28:30.0086 (UTC) FILETIME=[28C34A60:01C7104A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org hmmmm me too. /jim=20 > -----Original Message----- > From: Peter Sherbin [mailto:pesherb@yahoo.com]=20 > Sent: Friday, November 24, 2006 3:02 PM > To: Schliesser, Benson; Pekka Nikander; architecture-discuss@ietf.org > Subject: RE: [arch-d] Thoughts about addresses,or why the=20 > overall architecture affects routing. >=20 > > system size could be made explicit: must we inherently make=20 > > assumptions about the relationships between networks in order to=20 > > produce a more scalable routing and addressing architecture? >=20 > As a user I want: > 1. an IP address pool assigned to me for a lifetime 2. a=20 > selection of competing networks to put my traffic on for as=20 > long/short as I chose 3. a complete control on what goes out=20 > with my source addresses 4. an assurance that what is coming=20 > in has come from its true originator 5. an ability to prevent=20 > receiving from unwanted senders >=20 > Thanks, >=20 > Peter >=20 > --- "Schliesser, Benson" wrote: >=20 > >=20 > > Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] wrote: > > > In the current architecture [...] > > > From a mathematical point of > > > view, one could say that the better the topology of the=20 > addressing=20 > > > space can be matched with the topology with of the=20 > network, the less=20 > > > information needs to be stored elsewhere. > >=20 > > Perhaps somebody with better mathematical understanding=20 > could comment... > >=20 > > When I envision an Internet with lots of network-hierarchy, I=20 > > understand your statement to mean that aggregation is possible if=20 > > addressing and connectivity are essentially aligned. But when I=20 > > envision an Internet with no hierarchy this is no longer=20 > true. (As an=20 > > extreme example, picture an Internet where every AS was directly=20 > > connected to every other AS; compression of the address=20 > space through=20 > > aggregation is only possible at the expense of path=20 > information.) Of=20 > > course, the current Internet is somewhere in between. But=20 > who knows about the future? > >=20 > > It seems to me that this relationship between connectivity=20 > and routing=20 > > system size could be made explicit: must we inherently make=20 > > assumptions about the relationships between networks in order to=20 > > produce a more scalable routing and addressing architecture? > >=20 > > Cheers, > > -Benson > >=20 > >=20 > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 01:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZqT-0002ZJ-DV; Mon, 27 Nov 2006 01:20:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZqS-0002Xw-0y for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:20:00 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoZqQ-0008SE-K3 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:20:00 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAR6F6rS073012; Sun, 26 Nov 2006 22:16:05 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 26 Nov 2006 22:19:35 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 26 Nov 2006 22:19:35 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <58D0C56F-781C-469D-B4C6-F873BAC2029E@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (was Re: thou... Date: Sun, 26 Nov 2006 01:08:28 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Heiner, On Nov 24, 2006, at 1:03 AM, HeinerHummel@aol.com wrote: > H.H: Well, that is a matter of how you deal/handle/operate/ > manipulate with the 16-Byte-sized entity. By choosing a sub- > structure which is capable to support routing then I think > something is accomplished. In theory, I would agree. 16 bytes is an insane amount of address space and you should be able to shoehorn sufficient location information into the high order bits (particularly given the RIRs are allocating /32s to their customers). However, in reality, since IPv6 made the same mistake IPv4 did by including the entire IP address in the pseudo-header checksum, if you include location with identity information in the "address", you get the following choices: 1) don't ever change providers 2) renumber when you change providers 3) modify every deployed end point TCP/IP stack that will be part of the communication such that it won't look at the high order bits of the "address" that contain the location information. 1 & 2 won't fly according to every large scale enterprise network operator I've ever spoken to. If you're going to go around mucking about with deployed end point TCP/IP stacks, then it would probably make more sense to go back to the drawing board and come up with IPv7 (IMHO). > And the same is true with respect to addressing=identifying : Look > E164 is done via DNS which is fine for the moment. Not exactly sure what you mean here. ENUM hasn't really been a rousing success and it merely provides a way of using the DNS to translate one name (E.164 strings) into another name (the target DNS names). > But if you go for the profound redesign then that should not be > necessary anymore, should it? I'm arguing that we don't really have the luxury to do a profound redesign. I believe the best we can pragmatically do at this stage is to make a clear distinction between identifier and locator by providing an indirection mapping. At the very least, this would allow us to redeploy a routing layer without impacting end users/ applications that only know about identifiers. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 01:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpp-00029N-0T; Mon, 27 Nov 2006 01:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpn-00028S-TN for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:19 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoZpm-0008MD-HI for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:19 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAR6F6rK073012; Sun, 26 Nov 2006 22:15:28 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 26 Nov 2006 22:18:58 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 26 Nov 2006 22:18:58 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5C96EC4F-9856-46CA-BFDD-C3796BCC6405@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Sat, 25 Nov 2006 21:37:37 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Heiner, On Nov 24, 2006, at 2:39 AM, HeinerHummel@aol.com wrote: > Quote from below: Fundamentally one can not "locate" without > "identifying." True. However, the vast majority of users (and applications) care about the inverse. One _can_ identify without knowing location: we do it every day. > But also: Pure identifying does not help either. Sure it can. Flat routing works very well. It just doesn't scale very well. > In the realm of ITU-T you would use address (locator) plus sub- > address(identifier). I don't think anyone is suggesting separation of identity from location is a new idea. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 01:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpl-00028J-PO; Mon, 27 Nov 2006 01:19:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpk-00027P-DA for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:16 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoZpj-0008LK-16 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:16 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAR6F6rG073012; Sun, 26 Nov 2006 22:15:15 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 26 Nov 2006 22:18:45 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 26 Nov 2006 22:18:45 -0800 In-Reply-To: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> References: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Date: Sun, 26 Nov 2006 22:18:35 -0800 To: Peter Sherbin X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Peter, I find this sort of list is very useful. A couple of questions: On Nov 24, 2006, at 12:02 PM, Peter Sherbin wrote: >> system size could be made explicit: must we inherently make >> assumptions >> about the relationships between networks in order to produce a more >> scalable routing and addressing architecture? > > As a user I want: > 1. an IP address pool assigned to me for a lifetime Which of these are you willing to pay? a) a periodic (e.g., monthly) "routing fee" to offset the costs of your "IP address pool" being "globally" announced? b) redeploy all software/firmware on your network? c) have limited in your visibility into inter-AS network topology (that is, would you be willing to give up traceroute as a usable tool and lose the ability to use source address as a way of determining a network path)? To be clear, you're going to have to pay one way or another (TANSTAAFL). There may be other costs or alternatives I'm not listing. I'd be interested in understanding what flexibility there is in paying for a change in architecture from your perspective. > 2. a selection of competing networks to put my traffic on for as > long/short as I > chose Presumably you want this ability without renumbering (that is, you can have (1) today if you use your ISP's address space). > 3. a complete control on what goes out with my source addresses Presumably, in as much as you have the ability today. Or do you mean something else? > 4. an assurance that what is coming in has come from its true > originator Again, this has a cost. If IPSEC is used, there is a complexity and performance hit. Is that acceptable? > 5. an ability to prevent receiving from unwanted senders Same question as #3. Thanks, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 01:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpp-00029N-0T; Mon, 27 Nov 2006 01:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpn-00028S-TN for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:19 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoZpm-0008MD-HI for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:19 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAR6F6rK073012; Sun, 26 Nov 2006 22:15:28 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 26 Nov 2006 22:18:58 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 26 Nov 2006 22:18:58 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5C96EC4F-9856-46CA-BFDD-C3796BCC6405@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Sat, 25 Nov 2006 21:37:37 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Heiner, On Nov 24, 2006, at 2:39 AM, HeinerHummel@aol.com wrote: > Quote from below: Fundamentally one can not "locate" without > "identifying." True. However, the vast majority of users (and applications) care about the inverse. One _can_ identify without knowing location: we do it every day. > But also: Pure identifying does not help either. Sure it can. Flat routing works very well. It just doesn't scale very well. > In the realm of ITU-T you would use address (locator) plus sub- > address(identifier). I don't think anyone is suggesting separation of identity from location is a new idea. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 01:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpl-00028J-PO; Mon, 27 Nov 2006 01:19:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoZpk-00027P-DA for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:16 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoZpj-0008LK-16 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 01:19:16 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAR6F6rG073012; Sun, 26 Nov 2006 22:15:15 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sun, 26 Nov 2006 22:18:45 -0800 X-PGP-Universal: processed; by terminus.local on Sun, 26 Nov 2006 22:18:45 -0800 In-Reply-To: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> References: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Date: Sun, 26 Nov 2006 22:18:35 -0800 To: Peter Sherbin X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Peter, I find this sort of list is very useful. A couple of questions: On Nov 24, 2006, at 12:02 PM, Peter Sherbin wrote: >> system size could be made explicit: must we inherently make >> assumptions >> about the relationships between networks in order to produce a more >> scalable routing and addressing architecture? > > As a user I want: > 1. an IP address pool assigned to me for a lifetime Which of these are you willing to pay? a) a periodic (e.g., monthly) "routing fee" to offset the costs of your "IP address pool" being "globally" announced? b) redeploy all software/firmware on your network? c) have limited in your visibility into inter-AS network topology (that is, would you be willing to give up traceroute as a usable tool and lose the ability to use source address as a way of determining a network path)? To be clear, you're going to have to pay one way or another (TANSTAAFL). There may be other costs or alternatives I'm not listing. I'd be interested in understanding what flexibility there is in paying for a change in architecture from your perspective. > 2. a selection of competing networks to put my traffic on for as > long/short as I > chose Presumably you want this ability without renumbering (that is, you can have (1) today if you use your ISP's address space). > 3. a complete control on what goes out with my source addresses Presumably, in as much as you have the ability today. Or do you mean something else? > 4. an assurance that what is coming in has come from its true > originator Again, this has a cost. If IPSEC is used, there is a complexity and performance hit. Is that acceptable? > 5. an ability to prevent receiving from unwanted senders Same question as #3. Thanks, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 02:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoaxB-0005l9-Q3; Mon, 27 Nov 2006 02:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoaxA-0005l1-41 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 02:31:00 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goax7-00043M-M8 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 02:31:00 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAR7UurP072774 for ; Mon, 27 Nov 2006 07:30:56 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAR7YVDU2973948 for ; Mon, 27 Nov 2006 08:34:31 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAR7Utwj012667 for ; Mon, 27 Nov 2006 08:30:55 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAR7UtCw012657; Mon, 27 Nov 2006 08:30:55 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA112050; Mon, 27 Nov 2006 08:30:53 +0100 Message-ID: <456A942E.2010201@zurich.ibm.com> Date: Mon, 27 Nov 2006 08:30:54 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global ... References: <866404.59443.qm@web31808.mail.mud.yahoo.com> <9960E87B-6893-4F85-873B-C1ED06339E0A@virtualized.org> In-Reply-To: <9960E87B-6893-4F85-873B-C1ED06339E0A@virtualized.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Conrad wrote: ... > Since a primary goal (at least of enterprise network folks) is to be > able to change providers, I think that understates it. - ability to use multiple simultaneous providers - ability to add and drop providers - ability to have multiple points of attachment - both while preserving business continuity > the easiest (at least from my perspective) > way of implementing this is to have uniqueness within all possible > providers, that is, global uniqueness for identifiers used for the > enterprise. It may be the easiest from the PoV of the enterprise, but it certainly isn't the easiest from the PoV of the service providers, which is why we are having this conversation, I think. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 03:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goc6y-0001eR-ML; Mon, 27 Nov 2006 03:45:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goc6w-0001bc-Si for architecture-discuss@ietf.org; Mon, 27 Nov 2006 03:45:10 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goc6v-000180-CF for architecture-discuss@ietf.org; Mon, 27 Nov 2006 03:45:10 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 067D6212DAA; Mon, 27 Nov 2006 10:44:57 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D4DD8212DA9; Mon, 27 Nov 2006 10:44:55 +0200 (EET) In-Reply-To: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> References: <20061124200219.58742.qmail@web58708.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03693C5E-2AC5-4DA0-B822-35BB046D65E7@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Date: Mon, 27 Nov 2006 10:45:01 +0200 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Peter, A very interesting list of requirements. While I like very much David's questions about what you would be =20 willing to pay for and what not, and would like to see your answers =20 to them, I'd like to ask a few more questions, from a slightly =20 different point of view. The reason I'm asking these question is =20 that we (or at least I) would understand what users *really* want, =20 and not only what they think they want, in the terms of the current =20 architecture=10, so that those *real* needs could be fulfilled by the =20= future architecture(s). On Nov 24, 2006, at 22:02, Peter Sherbin wrote: > As a user I want: > 1. an IP address pool assigned to me for a lifetime Why, exactly? Are you trying to avoid a cost or a number of costs? =20 What are the costs then? (Note that I am not only talking about =20 monetary costs but also things such as re-education of users, time =20 required from administration, errors involved in renumbering leading =20 to loss of productivity, etc. Basically, my understanding is that today users want to have their =20 "own" IP addresses due to the costs involved in changing the IP =20 addresses. However, I have relatively poor understanding of what are =20= the *exact* costs involved. Secondly, I suspect there may be other issues but costs, but I have =20 no good idea what. > 2. a selection of competing networks to put my traffic on for as =20 > long/short as I > chose What would you imagine to be the smallest desirable shortest time? =20 One day? An hour? Change providers per-packet bases, on sub-second =20 time-scale? On other words, into who small time scales do you think we would need =20= to go in order to deconstruct the current switching costs, thereby =20 leading to a more even market and presumably lower prices? > 3. a complete control on what goes out with my source addresses This is something that I don't understand at all. I am sorry. What is the motivation for this requirement? To put it bluntly, why =20 do you care in the first place what goes into the source address? [For the background, you may want to consider an half-tongue-in-the-=20 cheek papers by us: Catharina Candolin and Pekka Nikander, "IPv6 Source Addresses =20 Considered Harmful," in Hanne Riis Nielson (ed.), Proceedings of =20 NordSec 2001, Sixth Nordoc Workshop on Secure IT Systems, November =20 1-2, Lyngby, Denmark, Technical Report IMM-TR-2001-14, pp. 54-68, =20 Technical University of Denmark, November 2001.] > 4. an assurance that what is coming in has come from its true =20 > originator > 5. an ability to prevent receiving from unwanted senders These I have no further questions on, other than those by David, =20 i.e., how much you would be willing to pay for them. Again, when you =20= consider "how much", I think it would be instructive to think about =20 all costs, not only money. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 04:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GocT6-0003SV-BV; Mon, 27 Nov 2006 04:08:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GocT5-0003SP-1R for architecture-discuss@ietf.org; Mon, 27 Nov 2006 04:08:03 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GocT3-00051B-Ga for architecture-discuss@ietf.org; Mon, 27 Nov 2006 04:08:03 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C8746212DAA; Mon, 27 Nov 2006 11:08:00 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7472B212DA9; Mon, 27 Nov 2006 11:08:00 +0200 (EET) In-Reply-To: References: <000001c71001$43812fa0$9f01a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6923D1FD-FDB1-4528-9379-A50636DBDF98@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: what is virtual and what is global) Date: Mon, 27 Nov 2006 11:08:05 +0200 To: John Day , Tony Li X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John Day once wot: >>> Just to totally confuse, my own investigations of this have >>> indicated >>> that for very large systems of identification, identification >>> systems >>> become systems of locating although it is locating in a context >>> which >>> is non-spatial. (Think about a thesaurus or a dictionary.) At 11:46 -0800 2006/11/24, Tony Li wrote: >> You're right, that's confusing. ;-) >> >> I think it would be safer to say that systems of identifiers are >> necessarily structured. At the very least, administration of a large >> flat unstructured name space doesn't scale. On Nov 24, 2006, at 21:50, John Day wrote: > Indeed. But even here concepts of distance and locality may have > meaning in the strict sense of a topology. I believe this is more > in the direction that the semantic web is trying to pursue and > others have in the past with variously named structures such as > entailment diagrams, etc. But doesn't the recent work on distributed hash tables (DHTs) indicate that you can make a flat identifier space of any size to scale roughly O(log n)? For example, we estimated that for storing reasonably dynamic information about 10^7 mobile nodes, each o f them changing its location every few minutes, requires under certain architectural assumptions in the order of a few hundreds of servers, resulting in look-up times in the order of 1-2 seconds. [Andrei Gurtov, Dmitry Korzun, Pekka Nikander, "Hi3: An Efficient and Secure Networking Architecture for Mobile Hosts," Technical report 2005-2, Helsinki Institute for Information Technology, June 2005] Hence, my tentative conclusions are that for a very large flat name space, you need - enough of bits in the identifier, in order to make the probability of random collisions considerably smaller than the probability of double-assignment due to human errors. 256 bits seems to be enough (assuming an order of 10^10 nodes or so). - good enough random number generators - some genuine randomness (entropy) during identifier generation time, e.g., current time down to millisecond - an DHT-like infrastructure to store and look up data associated with the identifiers For the infrastructure, a few hundred or at most a few thousand nodes seems to suffice, giving a reasonable look-up time and enough of redundancy, and keeping the capacity requirements of each infrastructure node small enough. So, what I am missing? Why do identifier systems necessarily need to be structured? --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 04:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goct1-0006cQ-8p; Mon, 27 Nov 2006 04:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gocsz-0006cF-SI for architecture-discuss@ietf.org; Mon, 27 Nov 2006 04:34:49 -0500 Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gocsy-000154-Kv for architecture-discuss@ietf.org; Mon, 27 Nov 2006 04:34:49 -0500 Received: from HeinerHummel@aol.com by imo-m24.mx.aol.com (mail_out_v38_r7.6.) id i.bdc.6ea0cc6 (32915); Mon, 27 Nov 2006 04:34:33 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 27 Nov 2006 04:34:32 EST Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... To: pekka.nikander@nomadiclab.com, jeanjour@comcast.net, tony.li@tony.li MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1349721665==" Errors-To: architecture-discuss-bounces@ietf.org --===============1349721665== Content-Type: multipart/alternative; boundary="-----------------------------1164620072" -------------------------------1164620072 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit So, what I am missing? Why do identifier systems necessarily need to be structured? --Pekka Nikander Answer: because of the many advantages: It is not only the capability to pick the right one in a very short time. Diverse properties can be looked up! Filtering. Statistics. In Germany the social security number is much bigger than in the US. It contains somehow the date-of-birth, the first letter of the name, some administrative organisationals,... IMO the address should contain some part related to the individual user, plus eventually also some address family characteristics ( private, org, edu, gov,... ) and definitely some locating part (ASN, geographic coordinates). Of course, only part of such an address can be checksummed. Heiner Hummel -------------------------------1164620072 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 So, what I am missing?  Why do identifier systems necess= arily=20 need to 
be structured?

--Pekka Nikander
 
Answer: because of the many advantages: It is not only the capability t= o=20 pick the right one in a very short time. Diverse properties can be looked up= !=20 Filtering. Statistics.
In Germany the social security number is much bigger than in the US. It= =20 contains somehow the date-of-birth, the first letter of the name, some=20 administrative organisationals,...
 
IMO the address should contain some part related to the individual=20 user, plus eventually also some address family characteristics (=20 private, org, edu, gov,...  ) and definitely some locating part (A= SN,=20 geographic coordinates). Of course, only part of such an address can be=20 checksummed.
 
Heiner Hummel
 
 -------------------------------1164620072-- --===============1349721665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1349721665==-- From architecture-discuss-bounces@ietf.org Mon Nov 27 05:44:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Godxk-0000gt-64; Mon, 27 Nov 2006 05:43:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Godxj-0000gn-Di for architecture-discuss@ietf.org; Mon, 27 Nov 2006 05:43:47 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Godxh-0001I5-UR for architecture-discuss@ietf.org; Mon, 27 Nov 2006 05:43:47 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kARAhiru023946 for ; Mon, 27 Nov 2006 10:43:45 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kARAlJWW2433042 for ; Mon, 27 Nov 2006 11:47:20 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kARAhivn011752 for ; Mon, 27 Nov 2006 11:43:44 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kARAhhcS011737; Mon, 27 Nov 2006 11:43:43 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA48204; Mon, 27 Nov 2006 11:43:42 +0100 Message-ID: <456AC15E.3020708@zurich.ibm.com> Date: Mon, 27 Nov 2006 11:43:42 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: what is virtual and what is global) References: <000001c71001$43812fa0$9f01a8c0@tropos.com> <6923D1FD-FDB1-4528-9379-A50636DBDF98@nomadiclab.com> In-Reply-To: <6923D1FD-FDB1-4528-9379-A50636DBDF98@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org ... > Hence, my tentative conclusions are that for a very large flat name > space, you need > > - enough of bits in the identifier, in order to make the probability of > random collisions considerably smaller than the probability of > double-assignment due to human errors. Surely the risk you need to evaluate is the probability of double assignment due to random loss of messages in a distributed assignment system? ... > So, what I am missing? Why do identifier systems necessarily need to > be structured? That depends whether "look-up times in the order of 1-2 seconds" are considered sufficient. If, for example, that is 6 orders of magnitude too long, you'd have a problem. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 09:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohaP-0004C1-I9; Mon, 27 Nov 2006 09:35:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohaO-0004Bd-UR for architecture-discuss@ietf.org; Mon, 27 Nov 2006 09:35:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GohaL-00005u-IR for architecture-discuss@ietf.org; Mon, 27 Nov 2006 09:35:56 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 27 Nov 2006 06:35:52 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAREZmad020077; Mon, 27 Nov 2006 09:35:48 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAREZlYJ014425; Mon, 27 Nov 2006 09:35:47 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 09:35:47 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 09:35:47 -0500 Date: Mon, 27 Nov 2006 09:35:33 -0500 From: Scott W Brim To: tony.li@tony.li Subject: Re: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Message-ID: <20061127143530.GB3040@sbrim-wxp01> Mail-Followup-To: Scott W Brim , tony.li@tony.li, 'John Day' , "'Bound, Jim'" , 'David Barak' , architecture-discuss@ietf.org References: <000001c71001$43812fa0$9f01a8c0@tropos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c71001$43812fa0$9f01a8c0@tropos.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 27 Nov 2006 14:35:47.0385 (UTC) FILETIME=[53E96290:01C71231] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org, "'Bound, Jim'" , 'John Day' X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Excerpts from Tony Li on Fri, Nov 24, 2006 11:46:41AM -0800: > > Just to totally confuse, my own investigations of this have indicated > > that for very large systems of identification, identification systems > > become systems of locating although it is locating in a context which > > is non-spatial. (Think about a thesaurus or a dictionary.) > > You're right, that's confusing. ;-) > > I think it would be safer to say that systems of identifiers are > necessarily structured. At the very least, administration of a large > flat unstructured name space doesn't scale. ... but the structure in the "identifier" space does not need to be the same as in the address space. Just because structure is useful in both does not mean the structure has to be interdependent. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 10:18:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiFe-0002yv-Cd; Mon, 27 Nov 2006 10:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiFd-0002yl-8P for architecture-discuss@ietf.org; Mon, 27 Nov 2006 10:18:33 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoiFW-0008JH-0y for architecture-discuss@ietf.org; Mon, 27 Nov 2006 10:18:33 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id B15C434180; Mon, 27 Nov 2006 10:18:25 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 10:18:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Mon, 27 Nov 2006 10:18:23 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9EB77@tayexc14.americas.cpqcorp.net> In-Reply-To: <58D0C56F-781C-469D-B4C6-F873BAC2029E@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccR7FJMt8Fj6Ap5TkSYMVgQfRllIQASmcDw From: "Bound, Jim" To: "David Conrad" , X-OriginalArrivalTime: 27 Nov 2006 15:18:25.0428 (UTC) FILETIME=[489FC540:01C71237] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Just on this point: > If you're going to go around mucking about with deployed end=20 > point TCP/IP stacks, then it would probably make more sense=20 > to go back to the drawing board and come up with IPv7 (IMHO). I don't agree. There can be a transition and it can be done transparently as will any significant change from this effort. shim6 is very friendly to such a transition as one data point. =20 But more importantly the identifier architecture in shim6 is approaching the use of identifiers far different than for routing. We need to define crisply what we want from an identifier for routing and how it works with routing and if it is to be global. =20 Also this only addresses the multihoming problem and the question is if that is addressed in this manner per the IAB Report does this buy us more time to work on the routing? /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 11:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goitg-0003D6-Na; Mon, 27 Nov 2006 10:59:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goite-0003BP-Pi for architecture-discuss@ietf.org; Mon, 27 Nov 2006 10:59:55 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoitE-00069a-J4 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 10:59:54 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 533513418F; Mon, 27 Nov 2006 10:59:28 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 10:59:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Mon, 27 Nov 2006 10:59:26 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF9EBF4@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccSPBj21yT+lZCpQ32ObqDOTa+xMQAAME2g From: "Bound, Jim" To: "John Day" , "David Conrad" , X-OriginalArrivalTime: 27 Nov 2006 15:59:28.0005 (UTC) FILETIME=[046F3350:01C7123D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I have no idea what your input is at all I think we agree on the mission though. But shim6 is not a kludge if that is what you meant? Best, /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Monday, November 27, 2006 10:53 AM > To: Bound, Jim; David Conrad; HeinerHummel@aol.com > Cc: architecture-discuss@ietf.org > Subject: RE: [arch-d] On identifiers: what is virtual and=20 > what is global (wasRe: thou... >=20 > We have had 20 years to get it right and frankly we have=20 > avoided working on the problem. To a large extent we have=20 > allowed superficial success, i.e. success in the market and=20 > the popular press, to be confused as good science. They=20 > aren't the same thing at all. It is interesting that most of=20 > us would not consider DOS a good OS even though it was wildly=20 > successful in the market place, but we accept that measure=20 > for what we have created. >=20 > This thing can't go on indefinitely as a collection of=20 > band-aids on an unfinished demo. It is far too important for=20 > that. We have to get a good idea what the end state should=20 > look like and then and only then begin to consider=20 > incremental steps that will take us there.=20 > This is arch-d. Let us do what we know needs to be done and=20 > leave the band-aids and kludges to their proper place: on ark b. >=20 > Take care, > John >=20 >=20 > At 10:18 -0500 2006/11/27, Bound, Jim wrote: > >Just on this point: > > > >> If you're going to go around mucking about with deployed=20 > end point=20 > >> TCP/IP stacks, then it would probably make more sense to=20 > go back to=20 > >> the drawing board and come up with IPv7 (IMHO). > > > >I don't agree. There can be a transition and it can be done=20 > >transparently as will any significant change from this=20 > effort. shim6=20 > >is very friendly to such a transition as one data point. > > > >But more importantly the identifier architecture in shim6 is=20 > >approaching the use of identifiers far different than for routing. > > > >We need to define crisply what we want from an identifier=20 > for routing=20 > >and how it works with routing and if it is to be global. > > > >Also this only addresses the multihoming problem and the=20 > question is if=20 > >that is addressed in this manner per the IAB Report does this buy us=20 > >more time to work on the routing? > > > >/jim > > > >_______________________________________________ > >Architecture-discuss mailing list > >Architecture-discuss@ietf.org > >https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 11:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiuE-0003lN-77; Mon, 27 Nov 2006 11:00:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goip5-0000fu-A0 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 10:55:11 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Goimr-0000JH-GG for architecture-discuss@ietf.org; Mon, 27 Nov 2006 10:52:55 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20061127155249m13004r3nhe>; Mon, 27 Nov 2006 15:52:50 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DCF9EB77@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCF9EB77@tayexc14.americas.cpqcorp.net> Date: Mon, 27 Nov 2006 10:52:44 -0500 To: "Bound, Jim" , "David Conrad" , From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org We have had 20 years to get it right and frankly we have avoided working on the problem. To a large extent we have allowed superficial success, i.e. success in the market and the popular press, to be confused as good science. They aren't the same thing at all. It is interesting that most of us would not consider DOS a good OS even though it was wildly successful in the market place, but we accept that measure for what we have created. This thing can't go on indefinitely as a collection of band-aids on an unfinished demo. It is far too important for that. We have to get a good idea what the end state should look like and then and only then begin to consider incremental steps that will take us there. This is arch-d. Let us do what we know needs to be done and leave the band-aids and kludges to their proper place: on ark b. Take care, John At 10:18 -0500 2006/11/27, Bound, Jim wrote: >Just on this point: > >> If you're going to go around mucking about with deployed end >> point TCP/IP stacks, then it would probably make more sense >> to go back to the drawing board and come up with IPv7 (IMHO). > >I don't agree. There can be a transition and it can be done >transparently as will any significant change from this effort. shim6 is >very friendly to such a transition as one data point. > >But more importantly the identifier architecture in shim6 is approaching >the use of identifiers far different than for routing. > >We need to define crisply what we want from an identifier for routing >and how it works with routing and if it is to be global. > >Also this only addresses the multihoming problem and the question is if >that is addressed in this manner per the IAB Report does this buy us >more time to work on the routing? > >/jim > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 11:23:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojFm-00072y-F0; Mon, 27 Nov 2006 11:22:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojFl-00071o-1B for architecture-discuss@ietf.org; Mon, 27 Nov 2006 11:22:45 -0500 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GojEz-000289-1c for architecture-discuss@ietf.org; Mon, 27 Nov 2006 11:22:45 -0500 Received: (qmail 19148 invoked from network); 27 Nov 2006 16:21:47 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 27 Nov 2006 16:21:47 -0000 Received: from LIPC ([192.168.1.151]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 08:21:47 -0800 From: "Tony Li" To: "'Scott W Brim'" , Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Date: Mon, 27 Nov 2006 08:21:43 -0800 Message-ID: <003801c71240$2094ad50$9f01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccSMVkLz8bWyFEDQ5Sb2PkJk9U+rAADmZIA In-Reply-To: <20061127143530.GB3040@sbrim-wxp01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 27 Nov 2006 16:21:47.0550 (UTC) FILETIME=[22DD8BE0:01C71240] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org, "'Bound, Jim'" , 'John Day' X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > ... but the structure in the "identifier" space does not need to be > the same as in the address space. Just because structure is useful in > both does not mean the structure has to be interdependent. In fact, creating any kind of interdependence in the structures would suggest that we've allowed semantic overload to creep in again. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 11:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojQB-0001iB-6c; Mon, 27 Nov 2006 11:33:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojQ9-0001gv-Sl for architecture-discuss@ietf.org; Mon, 27 Nov 2006 11:33:29 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GojPi-0004Gm-22 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 11:33:29 -0500 Received: from [10.0.1.20] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <2006112716330001200oq997e>; Mon, 27 Nov 2006 16:33:01 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <003801c71240$2094ad50$9f01a8c0@tropos.com> References: <003801c71240$2094ad50$9f01a8c0@tropos.com> Date: Mon, 27 Nov 2006 11:24:04 -0500 To: , "'Scott W Brim'" From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org, "'Bound, Jim'" , 'John Day' X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Very much agree. At 8:21 -0800 2006/11/27, Tony Li wrote: > > >> ... but the structure in the "identifier" space does not need to be >> the same as in the address space. Just because structure is useful in >> both does not mean the structure has to be interdependent. > >In fact, creating any kind of interdependence in the structures would >suggest that we've allowed semantic overload to creep in again. > >Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 12:06:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojvD-0001xq-Jf; Mon, 27 Nov 2006 12:05:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gojuu-0001as-OX for architecture-discuss@ietf.org; Mon, 27 Nov 2006 12:05:16 -0500 Received: from web58706.mail.re1.yahoo.com ([66.196.100.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gojuq-0001Gg-3z for architecture-discuss@ietf.org; Mon, 27 Nov 2006 12:05:16 -0500 Received: (qmail 15170 invoked by uid 60001); 27 Nov 2006 17:05:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rVB+ORCbZr0rnVOq/QJf8NujQk5gdLfgb0N8u2vFovJ4/OCGlTp1Le/nkSwkMbKcButD8aVH2lQDV5pRztSY2iHVhit89gQyZB7ewCsgVvkEs8JvcOSDucSZJ3ssAZA4IEEtQmzrFlS6/VXDgDUjKU4nHJcdweaHHFooLUcEX6E=; X-YMail-OSG: t2QUPqEVM1l64NRpfUBkMLrg9DJoxxjCELawLt38x.TJ2OWZHN0fwSeXpnCC98rOhWDF.s4h4oqSu.MgA00M5raeqRGixRQnUoNwqxmscAlRCXy3l7DQXTrK_ITZWsnwVjvnQBQIEnRjnm1Hzh6uUxyc3nWc7ylhO9FBfz3t3.OXctNiCzwOdkgIf4Q- Received: from [207.107.50.100] by web58706.mail.re1.yahoo.com via HTTP; Mon, 27 Nov 2006 09:05:09 PST Date: Mon, 27 Nov 2006 09:05:09 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. To: Pekka Nikander In-Reply-To: <03693C5E-2AC5-4DA0-B822-35BB046D65E7@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <672862.14388.qm@web58706.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka, I will try to address yours and David's questions > > 1. an IP address pool assigned to me for a lifetime > > Why, exactly? The assumption is that IPv6 addresses will be used primarily to automate processes and/or run real time databases of dispersed items on private networks both enterprise and individual. Hence renumbering must be avoided. Address pools will be large, e.g. for an individual about /80 (roughly 3 times the number of cells in human body), for an enterprise about /46 (based on 17 billion humans with /80 each). Understanding that not all individuals and enterprises will ask for the above but those who ask should be able to get it. The big question (under discussion here) is how routing will support global announcement of the above (assuming that about 98% of traffic will remain private). > What are the costs then? EU incurs costs: 1. to set / run a private network 2. to send packets outside a private network (these are reflected in providers' fees where competition makes prices acceptable). Cost model assumes that: 1. originator owns the information 2. originator has a need to move that information within or outside of her network 3. originator must cover cost for moving her packets Providers on their side are supposed to capture the amount of traffic from each sender for billing. > Basically, my understanding is that today users want to have their > "own" IP addresses due to the costs involved in changing the IP > addresses. There are at least two drivers to keep addresses unchanged, which does not preclude not-owning them: 1. Re-numbering could be very time consuming, i.e. costly 2. No dependency on a provider, which stimulates creation of long term processes, services, etc. > > 2. a selection of competing networks to put my traffic on for as > > long/short as I chose > > What would you imagine to be the smallest desirable shortest time? > One day? An hour? Change providers per-packet bases, on sub-second > time-scale? The model: I turn on a mobile device and a screen shows: Network A $/min, B $$/min, C $$$/min. I select to place a call via B's network because I like their pricing. For my next call I may choose the network C because their price is better. In addition to pricing there are other considerations to stay with a provider for a longer period: - network based services they offer - customer support - billing, etc. > On other words, into who small time scales do you think we would need > to go in order to deconstruct the current switching costs, thereby > leading to a more even market and presumably lower prices? A basic cost driver in a voice world was/is 1min of call. In a packet world it is 1 bit, which could be expressed in MB, GB, etc. > > 3. a complete control on what goes out with my source addresses > > This is something that I don't understand at all. I am sorry. Private network operator (individual or business) collects data from/through that network. All this information is proprietary to its collector. E.g. a fridge company collects statistics on how I use the device and what do I keep in there. I could buy into an argument that they need the data to adjust fridge settings remotely for my benefit. For that purpose the company uses IP addresses from their pool. Packets from my fridge will have company's source address and the company will get a bill from my provider if they use my connection to send their data. The company may also supply a fridge with their own connection. When I have a home network and I monitor my pet in the backyard, my kid in school, my boat in marina 50 miles away I need to be sure that all packets with the source address from my pool are authentic. > What is the motivation for this requirement? To put it bluntly, why > do you care in the first place what goes into the source address? That the source is authentic and has not been compromised. > > 4. an assurance that what is coming in has come from its true > > originator IPv6 enables end-to-end security, which is an opportunity for manufacturers to build it into devices. For providers this is an opportunity to collect more because longer overhead drives more traffic. But at some point overhead may become prohibitive. E.g. from my understanding in G.729.a VOIP overhead is about 80%, which makes G.711 with about 67% more appealing. Thanks, Peter ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 12:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gojz5-000683-Lq; Mon, 27 Nov 2006 12:09:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gojz4-00064U-Mg for architecture-discuss@ietf.org; Mon, 27 Nov 2006 12:09:34 -0500 Received: from imo-d04.mx.aol.com ([205.188.157.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gojyr-0001sr-CJ for architecture-discuss@ietf.org; Mon, 27 Nov 2006 12:09:34 -0500 Received: from HeinerHummel@aol.com by imo-d04.mx.aol.com (mail_out_v38_r7.6.) id i.cb1.487f558 (32913); Mon, 27 Nov 2006 12:08:53 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 27 Nov 2006 12:08:53 EST Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: jeanjour@comcast.net, Jim.Bound@hp.com, drc@virtualized.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0652446161==" Errors-To: architecture-discuss-bounces@ietf.org --===============0652446161== Content-Type: multipart/alternative; boundary="-----------------------------1164647333" -------------------------------1164647333 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit "We have had 20 years to get it right..." I am glad that this arch-d list provides the opportunity to openly discuss routing & addressing essentials. Some more that breaks with tradition: Why do we have multicast addresses at all? Since IPv6, we have also Anycast addresses. And what about mp2mp-addresses ? Sorry, I do not speak in favor of further address ranges, but instead in favor of an IP-header operation-field which indicates either Unicast, anycast, multicast(=p2mp), mp2mp or mp2p. Look, a multicast address gives you less information than is given by the sender's unicast address combined with a Multicast-operation-indication. We do have multicast address just because we have had them all the time. Just like we do have compartments in a train, because the first lok was towing coaches:-) Will say that we now have a discussion on what should an address consist of and soon we will be backfired by some problem how shall the locator for multicast look like. The thing is such simple: There are only addresses. No unicast and no other-cast addresses but just simple addresses, which, of course, must not be ambiguous. A particular Multicast-fsm inside the network (still) needs to be uniquely identified - e.g. with one of the multicast sender's identifiers (without the locator) :-) Heiner jeanjour@comcast.net: We have had 20 years to get it right and frankly we have avoided working on the problem. To a large extent we have allowed superficial success, i.e. success in the market and the popular press, to be confused as good science. They aren't the same thing at all. It is interesting that most of us would not consider DOS a good OS even though it was wildly successful in the market place, but we accept that measure for what we have created. This thing can't go on indefinitely as a collection of band-aids on an unfinished demo. It is far too important for that. We have to get a good idea what the end state should look like and then and only then begin to consider incremental steps that will take us there. This is arch-d. Let us do what we know needs to be done and leave the band-aids and kludges to their proper place: on ark b. Take care, John At 10:18 -0500 2006/11/27, Bound, Jim wrote: >Just on this point: > >> If you're going to go around mucking about with deployed end >> point TCP/IP stacks, then it would probably make more sense >> to go back to the drawing board and come up with IPv7 (IMHO). > >I don't agree. There can be a transition and it can be done >transparently as will any significant change from this effort. shim6 is >very friendly to such a transition as one data point. > >But more importantly the identifier architecture in shim6 is approaching >the use of identifiers far different than for routing. > >We need to define crisply what we want from an identifier for routing >and how it works with routing and if it is to be global. > >Also this only addresses the multihoming problem and the question is if >that is addressed in this manner per the IAB Report does this buy us >more time to work on the routing? > >/jim > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1164647333 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
"We have had 20 years to get it right..."
 
I am glad that this arch-d list provides the opportunity to openly disc= uss=20 routing & addressing essentials. Some more that breaks with tradition:
Why do we have multicast addresses at all? Since IPv6, we have also Any= cast=20 addresses.
And what about mp2mp-addresses ? Sorry, I do not speak in favor=20 of further address ranges, but instead in favor of an IP-header=20 operation-field which indicates either Unicast, anycast, multicast(=3Dp2mp),= mp2mp=20 or mp2p. Look, a multicast address gives you less information than is given=20= by=20 the sender's unicast address combined with a=20 Multicast-operation-indication.
We do have multicast address just because we have had them all the time= .=20 Just like we do have compartments in a train, because the first lok was towi= ng=20 coaches:-)
 
Will say that we now have a discussion on what should an address consis= t of=20 and soon we will be backfired by some  problem how shall the=20 locator for multicast look like.
The thing is such simple: There are only addresses. No unicast and no=20 other-cast addresses but just simple addresses, which, of course, must=20= not=20 be ambiguous. A particular Multicast-fsm inside the network (still)  ne= eds=20 to be uniquely identified - e.g. with one of the multicast sender's identifi= ers=20 (without the locator) :-)
 
 
 
Heiner
 
 
 
 
 
 
 
 
  jeanjour@comcast.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>We have=20 had 20 years to get it right and frankly we have avoided
working on th= e=20 problem.  To a large extent we have allowed
superficial success,=20= i.e.=20 success in the market and the popular
press, to be confused as good=20 science.  They aren't the same thing at
all.  It is interest= ing=20 that most of us would not consider DOS a good
OS even though it was wi= ldly=20 successful in the market place, but we
accept that measure for what we= =20 have created.

This thing can't go on indefinitely as a collection o= f=20 band-aids on
an unfinished demo.  It is far too important for=20 that.  We have to
get a good idea what the end state should look=20= like=20 and then and only
then begin to consider incremental steps that will t= ake=20 us there.
This is arch-d.  Let us do what we know needs to be don= e=20 and leave
the band-aids and kludges to their proper place: on ark=20 b.

Take care,
John


At 10:18 -0500 2006/11/27, Bound,=20= Jim=20 wrote:
>Just on this point:
>
>>  If you're goin= g to=20 go around mucking about with deployed end
>>  point TCP/IP=20 stacks, then it would probably make more sense
>>  to go bac= k to=20 the drawing board and come up with IPv7 (IMHO).
>
>I don't=20 agree.  There can be a transition and it can be done
>transpare= ntly=20 as will any significant change from this effort.  shim6 is
>ver= y=20 friendly to such a transition as one data point.
>
>But more=20 importantly the identifier architecture in shim6 is approaching
>the= use=20 of identifiers far different than for routing.
>
>We need to=20 define crisply what we want from an identifier for routing
>and how=20= it=20 works with routing and if it is to be global.
>
>Also this on= ly=20 addresses the multihoming problem and the question is if
>that is=20 addressed in this manner per the IAB Report does this buy us
>more t= ime=20 to work on the=20 routing?
>
>/jim
>
>______________________________= _________________
>Architecture-discuss=20 mailing=20 list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mai= lman/listinfo/architecture-discuss


______________________________= _________________
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164647333-- --===============0652446161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0652446161==-- From architecture-discuss-bounces@ietf.org Mon Nov 27 12:11:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gok0z-0000ke-Vx; Mon, 27 Nov 2006 12:11:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gok0z-0000kV-BK for architecture-discuss@ietf.org; Mon, 27 Nov 2006 12:11:33 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gok0y-0000hf-14 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 12:11:33 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7292986AE9; Mon, 27 Nov 2006 12:11:27 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] On identifiers: what is virtual and what is global ... Message-Id: <20061127171127.7292986AE9@mercury.lcs.mit.edu> Date: Mon, 27 Nov 2006 12:11:27 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Conrad > Pre-CIDR IP address allocation was FCFS with no relationship to any > sort of location information. The values allocated by "The NIC" were > simply flat routed 32 bit "names". This obviously made aggregation > hard. When the Internet became popular, it should have surprised no one > that we started to run into routing scalability problems -- there was > no way to hide information via aggregation. > So we came up with (and deployed in the nick of time) CIDR. Minor historical correction, which I'll package up with a more substantive reply to someone else. Subnets, which long preceded CIDR, were designed to do exactly the same thing - localize the scope of routing data, and aggregate routing data outside that scope. Yes, the original motivation of subnets was back in the days of class-A addresses only (~1978), and its original motivation was to deal with limits on network numbers. However, by the time it was widely adopted, A/B/C had arrived, and at that point people were going with subnets - as opposed to a flock of C's - to minimize pollution of the "default-free" (although we didn't call it that, back then) routing tables. (Anyone else remember the PDP-11 core routers, and the size limits on their routing tables? :-) So CIDR was really just an attempt (among other issues, such as efficient allocation of address space, e.g. running out of class B's) to add *another* layer(s) of aggregation. I don't know how well it has worked, outside of provider-based addresses, though; as far as I can tell, not a lot of aggregation happens above an individual ISP. > From: "Bound, Jim" > this only addresses the multihoming problem and the question is if that > is addressed in this manner per the IAB Report does this buy us more > time to work on the routing? If we can de-couple the routing-names (whatever they turn out to look like) from anything except saying *where* in the network's connectivity patterns the thing they name is, then yeah, that's a major, necessary step to solving any routing problems one wants to tackle. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 13:17:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gol19-000074-S9; Mon, 27 Nov 2006 13:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gol19-00006y-9o for architecture-discuss@ietf.org; Mon, 27 Nov 2006 13:15:47 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gol17-00045A-Ku for architecture-discuss@ietf.org; Mon, 27 Nov 2006 13:15:47 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kARIF6Ia085784; Tue, 28 Nov 2006 05:15:09 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061128051037.042aed80@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 28 Nov 2006 05:12:25 +1100 To: Scott W Brim , tony.li@tony.li From: Geoff Huston Subject: Re: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... In-Reply-To: <20061127143530.GB3040@sbrim-wxp01> References: <000001c71001$43812fa0$9f01a8c0@tropos.com> <20061127143530.GB3040@sbrim-wxp01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'John Day' , architecture-discuss@ietf.org, "'Bound, Jim'" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > > > I think it would be safer to say that systems of identifiers are > > necessarily structured. At the very least, administration of a large > > flat unstructured name space doesn't scale. > >... but the structure in the "identifier" space does not need to be >the same as in the address space. Just because structure is useful in >both does not mean the structure has to be interdependent. agreed - the structure in the identifier space is one that should be capable of supporting a "mapping" function to provide one (or possibly more) viable locators du jour. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 14:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Golto-00026R-GC; Mon, 27 Nov 2006 14:12:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goltm-0001wT-TG for architecture-discuss@ietf.org; Mon, 27 Nov 2006 14:12:14 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goltl-00045w-2V for architecture-discuss@ietf.org; Mon, 27 Nov 2006 14:12:14 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kARJBxbk006384; Mon, 27 Nov 2006 11:11:59 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kARJBsk8006383; Mon, 27 Nov 2006 11:11:54 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 27 Nov 2006 11:11:54 -0800 From: David Meyer To: Geoff Huston Subject: Re: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Message-ID: <20061127191154.GA6373@1-4-5.net> References: <000001c71001$43812fa0$9f01a8c0@tropos.com> <20061127143530.GB3040@sbrim-wxp01> <7.0.0.16.2.20061128051037.042aed80@apnic.net> Mime-Version: 1.0 In-Reply-To: <7.0.0.16.2.20061128051037.042aed80@apnic.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: architecture-discuss@ietf.org, "'Bound, Jim'" , 'John Day' X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992825032==" Errors-To: architecture-discuss-bounces@ietf.org --===============0992825032== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 28, 2006 at 05:12:25AM +1100, Geoff Huston wrote: >=20 > >> > >> I think it would be safer to say that systems of identifiers are > >> necessarily structured. At the very least, administration of a large > >> flat unstructured name space doesn't scale. > > > >... but the structure in the "identifier" space does not need to be > >the same as in the address space. Just because structure is useful in > >both does not mean the structure has to be interdependent. Exactly, and in many cases, the "incongruence" is by design (for any number of reasons). > agreed - the structure in the identifier space is one that should be=20 > capable of supporting a "mapping" function to provide one (or=20 > possibly more) viable locators du jour. Yep. --dmm =09 --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFazh6ORgD1qCZ2KcRAgPuAJ9IsOrg56m/tz80Dk4gpSafOf0ITQCghsJ2 AohHt2urnWsNHR7ZqmY7E0A= =VWUO -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- --===============0992825032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0992825032==-- From architecture-discuss-bounces@ietf.org Mon Nov 27 14:22:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom3B-0000CU-Fa; Mon, 27 Nov 2006 14:21:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom3A-0000CJ-Em for architecture-discuss@ietf.org; Mon, 27 Nov 2006 14:21:56 -0500 Received: from outmail128153.authsmtp.com ([62.13.128.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gom35-0005UG-Pb for architecture-discuss@ietf.org; Mon, 27 Nov 2006 14:21:56 -0500 Received: from outmail128177.authsmtp.com (outmail128177.authsmtp.com [62.13.128.177]) by punt2.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id kARJLahu046447 for ; Mon, 27 Nov 2006 19:21:36 GMT Received: from IAN (203-217-34-245.dyn.iinet.net.au [203.217.34.245]) (authenticated bits=0) by mail.authsmtp.com (8.13.6/8.13.6/Kp) with ESMTP id kARJLS7N079420 for ; Mon, 27 Nov 2006 19:21:30 GMT From: "Ian Peter" To: Subject: Re: [arch-d] On identifiers: what is virtual and what isglobal(wasRe: thou... Date: Tue, 28 Nov 2006 06:21:22 +1100 Message-ID: <00f601c71259$3beb1580$4a02a8c0@IAN> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccPlBsh5Dpw8hMJR2uTLio2682ujgAQHtXQAKEBoMA= X-Server-Quench: 7d22f259-7e4c-11db-b4dc-001185d377ca X-AuthRoute: OCdyZgEQClZURQJc Ei4YATVoSAwjPhBQ DAVFJgxfNlMTXgRQ LktRMkdJPRgQREpS RiVIKw0BFAtvBiEi JQhWcnsCJFVMXwVs QElASFBTHgZpTx4B BQAcUx5sdAFYenp1 ekRnXHVEXAohBCQH Pi1Ta20BbGNiaC4Z VEZeOQQAcgEcfBpM d1cqUCAQYGRTNGcy QwM4emhpZGwPdSgO HV4GJEQoTBRDLTcm TBBHEQBnOktNRik+ KQAnJF8RBl1Deloy OEdpWElQLR4IFhBX GwlEBiMROFkIW2Iq FgxeWkQXFH1CSDxm D09gPh9PH3oUHEJp X-Authentic-SMTP: 61633136393539.squirrel.dmpriest.net.uk:315/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Interestingly there is a related discussion currently on the GENI mailing list - here is an excerpt Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: Medhi, Deep [mailto:DMedhi@umkc.edu] Sent: 25 November 2006 02:37 To: discuss@lists.geni.net Subject: RE: [Discuss] Net Result of GENI > John Leong wrote: > > Jon Turner wrote: > > Again, the reasons for the non-deployment of IPv6 have little to do > > with technology. They have to do with the fact that no one make a > > profit next quarter by investing in a move to IPv6. It has > to happen > > universally before it's much use to anyone, and in a system > with such > > diverse ownership as the Internet, universal agreement is > hard to come > > by. > > Not completely sure about the above. > > An example of a technology that get adopted very quickly and > widely even though it may not have have gained universal > agreement (particularly from the E2E purists) is, ironically, > the nemisis of IPV6 - NAT. > While NAT has provided relief in the IPv4 address space and "delayed" the need for IPv6, I believe, there is more to it. Note that IPv6 was designed with a hierarchical addressing structure (sort of similar to E.164 addressing for telephony), which can be simply stated as a "provider-dependent" model (using "provider" to mean a country or an ISP, and so on). The difficulty with this approach is that it doesn't easily allow multi-homing; that is, if you get an IPv6 address block from an RIR, you cannot home to two different providers. Multihoming has become a necessity for customers for diversity etc; it that works quite well in IPv4 because at 'net-id' level IPv4 address can be thought of as based on flat addressing. A related benefit of IPv4 address block (IP prefix), even without multihoming, is that if as a customer you don't like your provider, you can change your provider *without* having to renumber your network/devices; this isn't possible in the provider-dependent IPv6 addressing. IMO, the provider-dependent issue is one of the key reasons for the 'non-popularity' of IPv6 address deployment. A question then is: can IPv6 addressing be made provider-INdependent? Since IPv6 address space is so large, this is possible by carving out a subset. Tony Hain, I believe, is the first one to propose IPv6 provider-independent addressing based on lat-long, several years ago (please, see the updated draft http://tools.ietf.org/wg/ipv6/draft-hain-ipv6-pi-addr-use-10.txt). So, perhaps, this could make barrier-to-entry easier for IPv6 addressing, if this proposal (or similar one) is widely accepted. Secondly, the mobile world has essentially made it a requirement to use IPv6 (check out 3GPP, IMS). That is, the mobile services are already going toward IPv6 addressing--here the provider deploys IPv6 addressing; the end user lives on E.164 (certainly, SIP-based approach). Thirdly, another need for IPv6 is when 10-net (NAT) cannot provide enough address space. In fact, Comcast (a cable provider in US) is already facing that as their estimate says that each household needs several addresses for different devices such as (cable modem, set-top boxes etc) and they don't have enough space if their business continues to grow --- they have temporarily borrowed IPv4 public address block, 73-net (i.e., 73.0.0.0/8) as a stop gap measure. But their plan is to deploy IPv6 address (and run Integrate IS-IS for routing within their nationwide intra-domain network). That is, a business need does require moving to IPv6. Here provider-dependency suites fine. (see Alain Durand's presentation from NANOG, June'06: http://www.nanog.org/mtg-0606/durand.html). I'm not saying that IPv6 is the end thing; but 'needs' do require us to look at addressing beyond IPv4. Yet, provider-independency remains a key barrier-to-entry for IPv6. A quick comment about E.164. Although E.164 is a hierarchical addressing format, it has been able to essentially get rid of the 'netmask' problem; note that for E.164, the netmask can be thought of at the country code level, area code (city code level, a term commonly used outside US), and at the central office level---the netmask traditionally used for routing. This has been made somewhat possible by the requirement for number portability---either geographic or non-geographic. Note that number portability is analogous to provider-independence, certainly number portability is more at the end user level. In essence, the number portability has forced the E.164 address space to become "elevated" to more of a name. In other words, it might be possible to get away from netmasking as used in E.164 by introducing a level of indirection (i.e., elevating to naming)---this however puts a tremendous burden (need?) on having efficient lookup algorithms/processes, for example, for the notion of 'all call query' etc (see RFC3482 for a discussion on number portability in PSTN). Finally, it seems that different addressing will have to live together in today's and tomorrow's networks. I couldn't have said it better than Jon Turner when he wrote in an earlir mail: "We need to move beyond a system in which progress requires universal agreement. We don't require universal agreement in any other technology domain. There is no longer any reason to require it in networking either." Regards, -- Deep Medhi _______________________________________________ Discuss mailing list Discuss@lists.geni.net https://lists.geni.net/mailman/listinfo/discuss -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.14/548 - Release Date: 23/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.16/552 - Release Date: 26/11/2006 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 16:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GooPe-0000a8-D6; Mon, 27 Nov 2006 16:53:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GooPd-0000Zy-B6 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 16:53:17 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GooPb-00057w-Pr for architecture-discuss@ietf.org; Mon, 27 Nov 2006 16:53:17 -0500 Received: from [10.0.1.20] (vpn-oncampus-85083.bu.edu[168.122.85.83]) by comcast.net (alnrmhc14) with ESMTP id <20061127215311b1400rf2q3e>; Mon, 27 Nov 2006 21:53:15 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 27 Nov 2006 16:48:52 -0500 To: HeinerHummel@aol.com, jeanjour@comcast.net, Jim.Bound@hp.com, drc@virtualized.org From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0677256990==" Errors-To: architecture-discuss-bounces@ietf.org --===============0677256990== Content-Type: multipart/alternative; boundary="============_-1047458104==_ma============" --============_-1047458104==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" We beat this horse to death several days ago. At 12:08 -0500 2006/11/27, HeinerHummel@aol.com wrote: >"We have had 20 years to get it right..." > >I am glad that this arch-d list provides the opportunity to openly >discuss routing & addressing essentials. Some more that breaks with >tradition: >Why do we have multicast addresses at all? Since IPv6, we have also >Anycast addresses. >And what about mp2mp-addresses ? Sorry, I do not speak in favor >of further address ranges, but instead in favor of an IP-header >operation-field which indicates either Unicast, anycast, >multicast(=p2mp), mp2mp or mp2p. Look, a multicast address gives you >less information than is given by the sender's unicast address >combined with a Multicast-operation-indication. >We do have multicast address just because we have had them all the >time. Just like we do have compartments in a train, because the >first lok was towing coaches:-) > >Will say that we now have a discussion on what should an address >consist of and soon we will be backfired by some problem how shall >the locator for multicast look like. >The thing is such simple: There are only addresses. No unicast and >no other-cast addresses but just simple addresses, which, of >course, must not be ambiguous. A particular Multicast-fsm inside the >network (still) needs to be uniquely identified - e.g. with one of >the multicast sender's identifiers (without the locator) :-) > > > >Heiner > > > > > > > > > jeanjour@comcast.net: > >We have had 20 years to get it right and frankly we have avoided >working on the problem. To a large extent we have allowed >superficial success, i.e. success in the market and the popular >press, to be confused as good science. They aren't the same thing at >all. It is interesting that most of us would not consider DOS a good >OS even though it was wildly successful in the market place, but we >accept that measure for what we have created. > >This thing can't go on indefinitely as a collection of band-aids on >an unfinished demo. It is far too important for that. We have to >get a good idea what the end state should look like and then and only >then begin to consider incremental steps that will take us there. >This is arch-d. Let us do what we know needs to be done and leave >the band-aids and kludges to their proper place: on ark b. > >Take care, >John > > >At 10:18 -0500 2006/11/27, Bound, Jim wrote: >>Just on this point: >> >>> If you're going to go around mucking about with deployed end >>> point TCP/IP stacks, then it would probably make more sense >>> to go back to the drawing board and come up with IPv7 (IMHO). >> >>I don't agree. There can be a transition and it can be done >>transparently as will any significant change from this effort. shim6 is >>very friendly to such a transition as one data point. >> >>But more importantly the identifier architecture in shim6 is approaching >>the use of identifiers far different than for routing. >> >>We need to define crisply what we want from an identifier for routing >>and how it works with routing and if it is to be global. >> >>Also this only addresses the multihoming problem and the question is if >>that is addressed in this manner per the IAB Report does this buy us >>more time to work on the routing? >> >>/jim >> >>_______________________________________________ >>Architecture-discuss mailing list >>Architecture-discuss@ietf.org >>https://www1.ietf.org/mailman/listinfo/architecture-discuss > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > --============_-1047458104==_ma============ Content-Type: text/html; charset="us-ascii" Re: [arch-d] On identifiers: what is virtual and what is g
We beat this horse to death several days ago.


At 12:08 -0500 2006/11/27, HeinerHummel@aol.com wrote:
"We have had 20 years to get it right..."
 
I am glad that this arch-d list provides the opportunity to openly discuss routing & addressing essentials. Some more that breaks with tradition:
Why do we have multicast addresses at all? Since IPv6, we have also Anycast addresses.
And what about mp2mp-addresses ? Sorry, I do not speak in favor of further address ranges, but instead in favor of an IP-header operation-field which indicates either Unicast, anycast, multicast(=p2mp), mp2mp or mp2p. Look, a multicast address gives you less information than is given by the sender's unicast address combined with a Multicast-operation-indication.
We do have multicast address just because we have had them all the time. Just like we do have compartments in a train, because the first lok was towing coaches:-)
 
Will say that we now have a discussion on what should an address consist of and soon we will be backfired by some  problem how shall the locator for multicast look like.
The thing is such simple: There are only addresses. No unicast and no other-cast addresses but just simple addresses, which, of course, must not be ambiguous. A particular Multicast-fsm inside the network (still)  needs to be uniquely identified - e.g. with one of the multicast sender's identifiers (without the locator) :-)
 
 
 
Heiner
 
 
 
 
 
 
 
 
  jeanjour@comcast.net:
We have had 20 years to get it right and frankly we have avoided
working on the problem.  To a large extent we have allowed
superficial success, i.e. success in the market and the popular
press, to be confused as good science.  They aren't the same thing at
all.  It is interesting that most of us would not consider DOS a good
OS even though it was wildly successful in the market place, but we
accept that measure for what we have created.

This thing can't go on indefinitely as a collection of band-aids on
an unfinished demo.  It is far too important for that.  We have to
get a good idea what the end state should look like and then and only
then begin to consider incremental steps that will take us there.
This is arch-d.  Let us do what we know needs to be done and leave
the band-aids and kludges to their proper place: on ark b.

Take care,
John


At 10:18 -0500 2006/11/27, Bound, Jim wrote:
>Just on this point:
>
>>  If you're going to go around mucking about with deployed end
>>  point TCP/IP stacks, then it would probably make more sense
>>  to go back to the drawing board and come up with IPv7 (IMHO).
>
>I don't agree.  There can be a transition and it can be done
>transparently as will any significant change from this effort.  shim6 is
>very friendly to such a transition as one data point.
>
>But more importantly the identifier architecture in shim6 is approaching
>the use of identifiers far different than for routing.
>
>We need to define crisply what we want from an identifier for routing
>and how it works with routing and if it is to be global.
>
>Also this only addresses the multihoming problem and the question is if
>that is addressed in this manner per the IAB Report does this buy us
>more time to work on the routing?
>
>/jim
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/architecture-discuss
 

--============_-1047458104==_ma============-- --===============0677256990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0677256990==-- From architecture-discuss-bounces@ietf.org Mon Nov 27 16:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GooSV-0003b8-7d; Mon, 27 Nov 2006 16:56:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GooSU-0003ay-5L for architecture-discuss@ietf.org; Mon, 27 Nov 2006 16:56:14 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GooSS-0005bT-S3 for architecture-discuss@ietf.org; Mon, 27 Nov 2006 16:56:14 -0500 Received: from [10.0.1.20] (vpn-oncampus-85083.bu.edu[168.122.85.83]) by comcast.net (alnrmhc11) with ESMTP id <20061127215558b1100s10a3e>; Mon, 27 Nov 2006 21:56:12 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061127171127.7292986AE9@mercury.lcs.mit.edu> References: <20061127171127.7292986AE9@mercury.lcs.mit.edu> Date: Mon, 27 Nov 2006 16:53:37 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global ... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel is right about the original idea behind Classes A, B, and C. But at some point we started handing out Bs and Cs with no regard to "where" they were. The majority of Class As were at best at an organizational level and even before that most blocks that providers had were for their internal use and small customers. Most customers then tried to get their own IP addresses which bore no relation to anything. While it was an attempt, it seems it broke down fairly soon. John At 12:11 -0500 2006/11/27, Noel Chiappa wrote: > > From: David Conrad > > > Pre-CIDR IP address allocation was FCFS with no relationship to any > > sort of location information. The values allocated by "The NIC" were > > simply flat routed 32 bit "names". This obviously made aggregation > > hard. When the Internet became popular, it should have surprised no one > > that we started to run into routing scalability problems -- there was > > no way to hide information via aggregation. > > So we came up with (and deployed in the nick of time) CIDR. > >Minor historical correction, which I'll package up with a more substantive >reply to someone else. > >Subnets, which long preceded CIDR, were designed to do exactly the same thing >- localize the scope of routing data, and aggregate routing data outside that >scope. Yes, the original motivation of subnets was back in the days of >class-A addresses only (~1978), and its original motivation was to deal with >limits on network numbers. However, by the time it was widely adopted, A/B/C >had arrived, and at that point people were going with subnets - as opposed to >a flock of C's - to minimize pollution of the "default-free" (although we >didn't call it that, back then) routing tables. (Anyone else remember the >PDP-11 core routers, and the size limits on their routing tables? :-) > >So CIDR was really just an attempt (among other issues, such as efficient >allocation of address space, e.g. running out of class B's) to add *another* >layer(s) of aggregation. I don't know how well it has worked, outside of >provider-based addresses, though; as far as I can tell, not a lot of >aggregation happens above an individual ISP. > > > > From: "Bound, Jim" > > > this only addresses the multihoming problem and the question is if that > > is addressed in this manner per the IAB Report does this buy us more > > time to work on the routing? > >If we can de-couple the routing-names (whatever they turn out to look like) >from anything except saying *where* in the network's connectivity patterns >the thing they name is, then yeah, that's a major, necessary step to solving >any routing problems one wants to tackle. > > Noel > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 27 20:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorMk-00050s-MK; Mon, 27 Nov 2006 20:02:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorMj-00050f-MW for architecture-discuss@ietf.org; Mon, 27 Nov 2006 20:02:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GorMc-0006vP-VJ for architecture-discuss@ietf.org; Mon, 27 Nov 2006 20:02:29 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 27 Nov 2006 17:02:22 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAS12K4F021884; Mon, 27 Nov 2006 17:02:20 -0800 Received: from cisco.com (vaf-lnx1.cisco.com [171.71.142.83]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAS12JdE015375; Mon, 27 Nov 2006 17:02:20 -0800 (PST) Received: from vaf-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.13.1/8.13.1) with ESMTP id kAS12JPh020228; Mon, 27 Nov 2006 17:02:19 -0800 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.13.1/8.13.1/Submit) id kAS12Jwe020227; Mon, 27 Nov 2006 17:02:19 -0800 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Mon, 27 Nov 2006 17:02:19 -0800 From: Vince Fuller To: Noel Chiappa Subject: Re: [arch-d] On identifiers: what is virtual and what is global ... Message-ID: <20061128010219.GA18347@vaf-lnx1.cisco.com> References: <20061127171127.7292986AE9@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <20061127171127.7292986AE9@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19295; t=1164675740; x=1165539740; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[arch-d]=20On=20identifiers=3A=20what=20is=20virtual= 20and=20what=20is=20global=20... |Sender:=20; bh=kF/lw8sdzD5zI+KrW6a/O3oFakQ0cJDLjWxor4DNe8c=; b=RtrYCPfmfB7QDchLanG0NixpU4uTqcqrM7RXTGnrItun1DFqvoj4oQCMB/8rnjx56TJBYGTG 7w/hBkf/efj3sPMdJq/tjCDm/0UkdAVwkAmrzBfae9RFtXVY/6w6xPpG; Authentication-Results: sj-dkim-6; header.From=vaf@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 27, 2006 at 12:11:27PM -0500, Noel Chiappa wrote: > > From: David Conrad > > > Pre-CIDR IP address allocation was FCFS with no relationship to any > > sort of location information. The values allocated by "The NIC" were > > simply flat routed 32 bit "names". This obviously made aggregation > > hard. When the Internet became popular, it should have surprised no one > > that we started to run into routing scalability problems -- there was > > no way to hide information via aggregation. > > So we came up with (and deployed in the nick of time) CIDR. > > Minor historical correction, which I'll package up with a more substantive > reply to someone else. > > Subnets, which long preceded CIDR, were designed to do exactly the same thing > - localize the scope of routing data, and aggregate routing data outside that > scope. Yes, the original motivation of subnets was back in the days of > class-A addresses only (~1978), and its original motivation was to deal with > limits on network numbers. However, by the time it was widely adopted, A/B/C > had arrived, and at that point people were going with subnets - as opposed to > a flock of C's - to minimize pollution of the "default-free" (although we > didn't call it that, back then) routing tables. (Anyone else remember the > PDP-11 core routers, and the size limits on their routing tables? :-) > > So CIDR was really just an attempt (among other issues, such as efficient > allocation of address space, e.g. running out of class B's) to add *another* > layer(s) of aggregation. I don't know how well it has worked, outside of > provider-based addresses, though; as far as I can tell, not a lot of > aggregation happens above an individual ISP. At the risk of more digression into ancient history, I'll expand on the above a little bit. First, a little context: CIDR was a product of the ROAD group, chartered in 1991 with the task of dealing with issues surrounding the scaling of Internet ROuting and ADdressing. The group identified three issues, later referred to as the "three trucks that would run us over": 1. Running out of "Class-B" networks (blocks of /16's in the range 128/8 through 191/8) 2. Apparently-exponential growth in the number of routable prefixes 3. Eventual exhaustion of the 32-bit address space Supernetting (RFC1338) and is successor, CIDR, was primarily aimed at solving problem #1, the most pressing at the time, without making problem #2 worse (the only pre-CIDR alternative to a "Class B" was a block of "Class Cs", which vastly increased the number of globally-visible routing table entries). CIDR's first goal when conceived was simply to allow prefixes of sizes other than /8, /16, and /24 to be used (this was sometimes known as the "three bears" - /8 was too big, /24 was too small, but /16 was "just right" in the minds of many). As it was refined, aggregation to help with problem #2 became more appealing; the availability of more flexible address assignment blocks also took some heat off of problem #3. CIDR was intended as a short-to-medium term fix in the face of urgent problems; the members of the ROAD group fully expected a more long-term solution (the ipng effort) to be developed and deployed within 5 to 10 years. Unfortunately, it seems that we were excesseively optimistic. For more historical description, check out "The Long and Windy ROAD" at http://rms46.vlsm.org/1/42.html. --Vince P.S. FWIW, my original thinking about CIDR was inspired by a presentation that you gave about CLNS addressing at the 19th IETF in Boulder, CO, back in December, 1990. Attached is the original piece of email that I sent to the ROAD in January, 1992, describing my thoughts. I also have vague recollections of discussions about Supernetting between Jessica Yu, Kannan Varadhan, and me (I don't recall Tony Li being there as he wasn't a regional net operator) at an NSFNET Regional Techs meeting in Ann Arbor probably 6 months before or after that email and the subsequent Tucson ROAD meeting in February, 1992. --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cidr >From "Vince Fuller " Wed Jan 29 15:52:51 1992 Flags: 000000000001 Return-Path: Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA16867; Wed, 29 Jan 92 15:52:48 -0800 Full-Name: Vince Fuller Date: Wed, 29 Jan 92 15:52:47 PST From: Vince Fuller To: road@lanl.gov Cc: vaf Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: BGP+masks and making more efficient use of IP address space Message-Id: Status: RO Content-Length: 14006 Lines: 257 Peter Ford has asked me to attend tomorrow's ROAD meeting in Tucson to discuss how some of IP's addressing and routing shortcomings might be alleviated in the short-to-medium term by adding network mask support to BGP. Here are some thoughts, rather hastily written down, on this matter. After the NSFNET meeting in Ann Arbor last week, I volunteered to write something about this, but I had expected to have more time to do so, so these notes are probably incomplete and definitely not polished. Please send any comments to me, as I don't believe I'm on the ROAD mailing list. --Vince -------------------- Adding mask support to BGP to implement IP "supernetting" or: the evolution of the classless Internet (or is that the Internet with no class...?) 1. Introduction -- The problem It is clear that current methods of IP address allocation have resulted in a grossly under-utilized address space made of an exponentially-growing number of sparsely-populated IP network numbers. It is projected that if current practice continues, the Internet will run out of network numbers to assign in Two factors have most contributed to this problem: 1. the limited range in IP network number classes. In raw host count, most sites fit somewhere between class B and class C, but assigning either a class B or multiple class C's to such sites both cause difficulty. 2. the lack of mechanisms for effectively subdividing assigned network numbers. Historically, IGP's have tended to only support fixed-size subnets, forcing sites to make each subnet be as large as the largest subnet actually used. For wide-area networks, where most (but not all) subnets have but two host numbers assigned, this results in effective network number utilization in the < 5% range. Solving problem #1 requires the availability of better IGP technology which supports variable-length subnets. With the advent of new IGPs such as OSPF and IP-IS-IS, this problem is close to a solution, assuming that the new IGPs can be deployed in a timely manner and that network managers can be convinced to use the new technology to make more efficient use of their assigned space. Problem #2 requires that the Internet re-think how network numbers are assigned and how routing information is collapsed. This document describes the changes required in IP address allocation and in the Border Gateway Protocol to limit the explosive growth of globally-known network numbers. It should be noted that the techniques described here are intended to both reduce the amount of routing table space in Internet routers and in improve the efficiency of use of the current IP address space. To this end, it is necessary to make one important assumption: that the overwhelming majority of sites which connect to the Internet are and will continue to be single-homed (in other words, they are "stub" networks). Networks which are truly multi-homed will continue to be explicitly advertised through at least part of the Internet. It is also usful to mention that these schemes are incrementally deplyoable in the current Internet and are meant to reduce the growth rate of network number usage and routing table size by largely eliminating the use of new network numbers for stub sites. Existing network number assignments can coexist peacefully with new number assignments, though for maximum efficiency it may be desireable that some renumbering occur over time. Author's note: My first thoughts on this problem solution occurred during Noel Chiappa's presentation on Internet address growth during the Boulder IETF in December, 1990 -- if CLNP can solve the Internet's problems by using a loose hierarchy to summarize routing information, why can't IP do likewise? It has more recently been addressed (no pun intended...) by the BGP working group at the November, 1991 IETF in Santa Fe and again on the BGP mailing list and among some members of the ROAD group. 2. One partial solution - subnetting larger network numbers One proposed solution to this problem, which does not require any changes to BGP, is to assign a relatively small number of larger network numbers (some combination of class A and class B) to mid-level service providers and have them assign variable-sized pieces of this address space to their clients. This might be a reasonable thing to do, but it has one big problem: a client which chooses to change service providers is faced with a huge renumbering problem which cannot be done gradually. For example, mid-level "B" is assigned net 36.0.0.0 to divide among its clients. It assignes 36.1.0.0/255.255.0.0 to client organization "X". Now, if "X" decides to disconnect from "B" and reconnect to provider "A", he'll have to either: - obtain a piece of "A"'s address space and renumber all of his systems on a flag-day *before* he starts using his connection to "A". He could continue to use part of "B"'s space if he didn't mind that some of his systems would be reachable via "A" and some via "B", but that sort of engineering of assymetry seems like a bad idea (plus, he'll have to retain his connection to "B" during any transition) or: - obtain a separate network number that isn't part of "A" or "B" and renumber his hosts to use it. Of course, this defeats the purpose of assigning him a piece of "B"'s space (which was to reduce the number of globally-known network numbers assigned), unless he eventually decides to renumber everything again to use "A"'s space (unlikely, given the amount of pain he probably suffered in doing this...) This problem exists because there is no way, given the current exterior routing protocols, for "B" to own most of 36.0.0.0 but for "A" to have just a piece of it, and to advertise just that piece to the rest of the Internet. The same problem also applies to multi-homed sites and to sites later become multi-homed after initially agreeing to use a subnet of its provider's address space. Criteria for determining the acceptability of this solution: - how often will sites change providers or become multi-homed? and - how much pain should they be forced to endure to do so? Politically, this problem is likely to make this solution difficult to sell to organizations who wish to connect to the Internet, since it tends to "lock them in" to one network provider (which, I suppose, could be viewed as an advantage by some network providers...:-). 3. Another idea - "supernetting" the existing address structure One proposed alternative to subnetting provider-assigned large network numbers is to assign providers bitmask-oriented ranges of smaller network numbers which they then hand out to their clients. For example, a mid-level network might be assigned all of the class C's in the range 192.31.1 through 192.31.254 and would assign one to each of its small clients. It would then need a mechanism to advertise to *its* provider (a "backbone") that it had a route to 192.31.*. This shares most of the advantages and disadvantages of the "subnetting" solution but requires some help from the exterior routing protocol (BGP, in particular). The case of a "migrating" site requires that some mechanism be available to "punch a hole" in the summarized advertisement in order to allow individual pieces of 192.31.* to be re-advertised elsewhere. 4. Fixing the exterior routing protocol Technically, the solution to this problem is fairly simple - change BGP to represent destinations not as simple network numbers but as network number+mask pairs (this is exactly what the OSPF IGP does). There are some pitfalls to making such a change, however. A border router which is advertising some portion of its knowledge *must* be configured to perform summarization before it can announce any "subnet" information. Failure to do this would result in all "subnet" routing information, which is largely irrelevant, being flooded to all BGP peers. This would not have a positive effect on routing within the Internet... For this reason, implementations of BGP+masks must provide mechanisms for configuring route summarization and must by default NOT announce any routing information which is known to be subnetted within the AS. Border routers MUST be configured to know how subnetting is being performed. Systems which process BGP announcements must also be able to verify that information which they receive is correct. Thus, in the new world of BGP+masks, the NSFNET policy database would list not only the network numbers it expects to learn from a connected mid-level but also the masks associated with those networks. Instead of something like: accept 128.32.0.0 from AS 201 primary accept 128.120.0.0 from AS 201 primary accept 134.139.0.0 from AS 201 secondary the configuration would look something like: accept 128.32.0.0 255.255.0.0 from AS 201 primary accept 128.120.0.0 255.255.0.0 from AS 201 primary accept 134.139.0.0 255.255.0.0 from AS 201 secondary accept 36.1.0.0 255.255.0.0 from AS 201 primary accept 36.2.0.0 255.255.0.0 from AS 201 secondary accept 36.0.0.0 255.0.0.0 from AS 201 primary This is merely making explicit the network mask which was implied by the class-A/B/C classification of network numbers. 5. Other changes to routing semantics There are a few other, mostly minor changes, which need to be made to the way border routers function in the Internet in order for this scheme to work. First, routing to all destinations must be done on a best-match basis. This means that destinations which are multi-homed relative to a routing domain must always be explicitly announced into that routing domain - they cannot be summarized (this makes intuitive sense - if a network is multi-homed, all of its paths into a routing domain which is "higher" in the hierarchy must be known). Example: given two routing domains MA and MB which are connected to a common "backbone" BB. MA is assigned 36.0.0.0/255.0.0.0 and allocates 36.1.0.0/255.255.0.0 to one its sites, S1. S1 is additionally connected to MB. MA advertises both 36.1.0.0/255.255.0.0 and 36.0.0.0/255.0.0.0 into the backbone while MB advertises 36.1.0.0/255.255.0.0. While one might expect that MA could omit the advertisement of 36.1.0.0/255.255.0.0 if MB were the primary path to S1, this turns out to be undesireable (see below). Second, a routing domain which is advertising summarized information into another domain MUST NOT follow any "default" route when making forwarding decisions for any IP address which matches its summarized network+mask. To to otherwise creates routing loops during network outages. Returning to the example above, assume MA has a default route into backbone BB. Also, add a new site, S2, with network assignment 36.2.0.0/255.255.0.0 but which is only connected to MB (i.e. it was once connected to MA but has moved to MB). Now, if S2 becomes unreachable, the backbone BB will no longer have a route to 36.2.0.0/255.255.0.0 via MB and will route traffic for anything on 36.2 to MA due to best match (MA is advertising 36.0.0.0/255.0.0.0). If MA then attempts to use its default to route to such addresses, a stable routing loop will occur. Third, routing domains should, if possible, maintain negative caches of unreachable information which they learn via BGP. In the example given immediately above, this would permit the backbone BB to discard traffic to 36.2 without forwarding it to MA. Note that this is desireable functionality but is only an optimization - the system should still be stable without it. (yes, these examples are probably easier to describe using some simple diagrams...) It has also been suggested that BGP+masks could be used in special situations where a border router needs to learn subnet information from its peer network but does not want to or cannot participate in the peer network IGP. To deal with this particular case, it would probably make sense to define a "local subnet" attribute for BGP which specifies that the information learned is of local significance only and must not be re-advertised to other BGP peers. This would, of course, assume that other BGP peers would learn some piece of routing information which effectively aggregated the subnets. 6. "Classless" network numbers It is worthwhile to note that these two techniques, "supernetting" and "subnetting a class A", are really just specific cases of the general practice of representing all destinations in the Internet as a network number+mask. Adding this support to BGP will allow assignment of network numbers without the "class-A-B-C" restriction and will permit more creative ways of dividing the address space. For example, how about designating pieces of address space which will be subdivided using "Kampai" address assignment - this should be easy to do, given proper support in the routing protocols. 7. Changes to host software One of the nice attributes of this scheme is that it should require minimal, if any, changes to most hosts. One exception would, of course, be hosts which are directly connected to subnets where routing is complex (for example, a host which is directly connected to the FIX). It may also be necessary to "lie" to some systems which think they are smarter than their manegers (i.e. which insist on treating a network number as class-A/B/C), but that shouldn't be too difficult to manage using some combination of proxy-ARP and default gateway assignments. One area which does present difficulty is in the domain system. As currently defined, the mechanism for performing address-to-name translations using the DNS (the "IN-ADDR.ARPA" kluge) only permits delegation of naming authority along octet boundaries. As those who have subnetted their networks along other bit field sizes know, this makes it difficult-to-impossible to delegate the inverse naming authority for subnetted addresses. The "supernetting" solution described above --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --2fHTh5uZTiUOsy+g-- From architecture-discuss-bounces@ietf.org Tue Nov 28 04:35:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozLR-0003dA-LJ; Tue, 28 Nov 2006 04:33:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozLP-0003bP-QW for architecture-discuss@ietf.org; Tue, 28 Nov 2006 04:33:39 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GozLM-0004jo-Aa for architecture-discuss@ietf.org; Tue, 28 Nov 2006 04:33:39 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 74D23212DAD; Tue, 28 Nov 2006 11:33:26 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 39E8D212DAA; Tue, 28 Nov 2006 11:33:26 +0200 (EET) In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DCF9EB77@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] Long term and short term fixes in parallel Date: Tue, 28 Nov 2006 11:33:22 +0200 To: John Day , Jim Bound , David Conrad X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Conrad once opinionated: >>> If you're going to go around mucking about with deployed end >>> point TCP/IP stacks, then it would probably make more sense >>> to go back to the drawing board and come up with IPv7 (IMHO). Then Jim Bound wrote: >> I don't agree. There can be a transition and it can be done >> transparently as will any significant change from this effort. >> shim6 is >> very friendly to such a transition as one data point. >> But more importantly the identifier architecture in shim6 is >> approaching >> the use of identifiers far different than for routing. As an answer, John Day wrote: > We have had 20 years to get it right and frankly we have avoided > working on the problem. --- As I stated in towards the very beginning of this discussion, apparently we need both long term and shorter term approaches. It looks like that we'll need to work on them in parallel, for number of years. Then, again, we have three "things" (assets) that can be and should be each changed individually; their natural life cycles differ: 1. Applications. It takes a long time to update all apps (or even most) to use a new API. Many popular, developing apps change fast, though. 2. OS stacks. Most of them are replaced every 3-5 years. 3. Routers. I have no real idea about life cycles. Our experience (from IPv6) seems to show that trying to change them all at once is, well, problematic. Now that we have IPv6 there in the routers and in the APIs for many apps, IMHO we should try to leverage that, even though such changes might be classified as kludges from the architectural point of view. In other words, changes that change only one of the three instead of them all seem to be easier to deploy, taking less time. What I understand less well is that there seems to be also other factors. Both SHIM6 and HIP attempt to change only the OS stack. However, SHIM6 seems to be much easier for most people to swallow, perhaps because it is felt as a "smaller" change. OTOH, if you compare SHIM6 and HIP using the number of lines needed to implement, the difference is pretty small. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 04:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozZt-0006eE-Uu; Tue, 28 Nov 2006 04:48:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozZr-0006cY-SZ for architecture-discuss@ietf.org; Tue, 28 Nov 2006 04:48:35 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GozZp-0000q7-Eg for architecture-discuss@ietf.org; Tue, 28 Nov 2006 04:48:35 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAS9mW3A074392 for ; Tue, 28 Nov 2006 09:48:32 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAS9q8io2527412 for ; Tue, 28 Nov 2006 10:52:08 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAS9mVMN015584 for ; Tue, 28 Nov 2006 10:48:31 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAS9mUHS015565; Tue, 28 Nov 2006 10:48:31 +0100 Received: from zurich.ibm.com (dhcp23-51.zurich.ibm.com [9.4.23.51]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA79630; Tue, 28 Nov 2006 10:48:30 +0100 Message-ID: <456BFFEB.4020306@zurich.ibm.com> Date: Tue, 28 Nov 2006 10:22:51 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] On identifiers: what is virtual and what is global ... References: <20061127171127.7292986AE9@mercury.lcs.mit.edu> In-Reply-To: <20061127171127.7292986AE9@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, > > So CIDR was really just an attempt (among other issues, such as efficient > allocation of address space, e.g. running out of class B's) to add *another* > layer(s) of aggregation. I don't know how well it has worked, outside of > provider-based addresses, though; as far as I can tell, not a lot of > aggregation happens above an individual ISP. But that itself is an enormous win - scaling like the number of ISPs is much more reasonable than scaling like the number of end user sites, which was the pre-CIDR situation. And to restate the obvious, current multihoming practice puts us right back to scaling like the number of end user sites. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 06:14:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0tp-0001mF-No; Tue, 28 Nov 2006 06:13:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0to-0001m8-9K for architecture-discuss@ietf.org; Tue, 28 Nov 2006 06:13:16 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp0tm-0004sW-Pc for architecture-discuss@ietf.org; Tue, 28 Nov 2006 06:13:16 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 03130212DAD; Tue, 28 Nov 2006 13:13:13 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BFD0F212DAA; Tue, 28 Nov 2006 13:13:12 +0200 (EET) In-Reply-To: <672862.14388.qm@web58706.mail.re1.yahoo.com> References: <672862.14388.qm@web58706.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. Date: Tue, 28 Nov 2006 13:13:10 +0200 To: Peter Sherbin X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Peter, Taking your answers and trying to generalise them to apply any networking architectures, not only the current one, how wrong would I be, from your point of view, if I restated your requirements in the following way? Note that I'm using the same numbering as you did in your original message. 1. Application-level identifiers assigned for a lifetime [Originally: an IP address pool assigned to me for a lifetime] These identifiers must work with all applications, with addressable application entities dispersed at all levels, ranging from private individual to global distributed applications. These identifiers should be completely independent from access providers, and not change when the network connectivity changes. They should outlive any "mobility" situations, independent on time scale. The primary motivation for their persistency is to avoid the costs incurring from they being changed, since such identifiers would be located through the systems in various odd locations. [Due to us having only the socket APIs today, and nothing more abstract in wider acceptance, most people seem to think today that the only choice for such identifiers are IP addresses. To an extend I agree; that's the very reason why we have suggested an experimental allocation; see draft-laganier-ipv6-khi-05.txt.] 2. Independent dynamic choice of providers for incoming and outgoing traffic [Originally: selection of competing networks...] It should be possible to dynamically select the best network for any incoming and outgoing traffic, using any local policies based on such factors as per-packet-or-per-bit cost, delay, bandwidth, utilisation, etc. One aim of such ability would be to smoothen the markets and lowering entry barriers. By being able to easily and dynamically select the carriers, even small customers together would have more purchasing power, thereby leading to lower overall prices and less price discrimination. 3-4. Full origin authentication and privacy about the origin of incoming traffic [Originally: 3. complete control on what goes out with my source addresses 4. an assurance that what is coming in has come from its true originator] The end-receiver (organisation) of any incoming traffic should have reasonable assurance that the traffic is coming from a known (or an easily traceable source), while the immediate upstream access providers should have no information from whom the traffic is coming from. This is one aspect of a balanced privacy/accountability that I have stated elsewhere several times. Basically, we seem to need more privacy and more accountability, simultaneously. [Incidentally, I happen to believe that the source address would be a completely wrong vehicle for such property, even in the current architecture.] 5. The ability to limit traffic incoming from unwanted / untraceable senders [Originally: an ability to prevent receiving from unwanted senders] Related to the item 3-4, if there is incoming traffic whose origin is not know, or cannot be easily traced, or is otherwise unwanted based on its source, it should be easy to prevent that traffic from arriving. Indeed, such traffic should be stopped as close to its source as possible. [Ditto.] -------- What I still don't see is how much a) money, b) trouble, and c) pain people would be paying for any of the above mentioned properties. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 06:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp182-00022j-4T; Tue, 28 Nov 2006 06:27:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp180-00022e-W1 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 06:27:56 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp17z-0008Jc-Hg for architecture-discuss@ietf.org; Tue, 28 Nov 2006 06:27:56 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D6223212DAD; Tue, 28 Nov 2006 13:27:54 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6E052212DAA; Tue, 28 Nov 2006 13:27:54 +0200 (EET) In-Reply-To: <456AC15E.3020708@zurich.ibm.com> References: <000001c71001$43812fa0$9f01a8c0@tropos.com> <6923D1FD-FDB1-4528-9379-A50636DBDF98@nomadiclab.com> <456AC15E.3020708@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: what is virtual and what is global) Date: Tue, 28 Nov 2006 13:27:52 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >> Hence, my tentative conclusions are that for a very large flat =20 >> name space, you need >> - enough of bits in the identifier, in order to make the =20 >> probability of random collisions considerably smaller than the =20 >> probability of double-assignment due to human errors. > > Surely the risk you need to evaluate is the probability of double > assignment due to random loss of messages in a distributed > assignment system? Thanks, I missed that! Fool me still thinking that the system would =20 be reliable... >> So, what I am missing? Why do identifier systems necessarily need =20= >> to be structured? > > That depends whether "look-up times in the order of 1-2 seconds" > are considered sufficient. If, for example, that is 6 orders of > magnitude too long, you'd have a problem. Yes. :-) Flat identifier spaces do not seem to be very suitable for large-=20 scale routing. IIRC, the ROFL paper had some numbers. Checking... =20 Yes, from "Summary of results": "host can join across all providers =20 and peers ... with =E2=88=BC445 control messages. An average [routing] =20= stretch of 2.5. .... [Possible to] reduce [host] join overhead to =20 =E2=88=BC100 messages, but requires 74 Mbits of bloom filter state per = AS." =46rom that, the stretch of 2.5 seems pretty bad. I don't have any =20 numbers for the stretch in the current system, though. (stretch =3D =20 the ratio between the traversed path and the shortest path.) --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 08:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2jM-00074o-VQ; Tue, 28 Nov 2006 08:10:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2jL-00074C-S8 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:10:35 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp2jF-0006w1-Cd for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:10:35 -0500 Received: from I2KF03AV-UKBR.domain1.systemhost.net ([193.113.197.42]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:10:23 +0000 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by I2KF03AV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Nov 2006 13:10:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] On scaling of flat identifier spaces (was Re:On identifiers: what is virtual and what is global) Date: Tue, 28 Nov 2006 13:10:21 -0000 Message-ID: <70B775CD6175D84B978C843BDDF683970D776073@i2km96-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On scaling of flat identifier spaces (was Re:On identifiers: what is virtual and what is global) Thread-Index: AccS4F05btq0KN53TeOLIx1cRqJM0AADV6uw From: To: , X-OriginalArrivalTime: 28 Nov 2006 13:10:22.0868 (UTC) FILETIME=[8FDFE540:01C712EE] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0299983989==" Errors-To: architecture-discuss-bounces@ietf.org --===============0299983989== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGVra2EgTmlrYW5kZXIgW21h aWx0bzpwZWtrYS5uaWthbmRlckBub21hZGljbGFiLmNvbV0gDQpTZW50OiAyOCBOb3ZlbWJlciAy MDA2IDExOjI4DQpUbzogQnJpYW4gRSBDYXJwZW50ZXINCkNjOiBhcmNoaXRlY3R1cmUtZGlzY3Vz c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFthcmNoLWRdIE9uIHNjYWxpbmcgb2YgZmxhdCBpZGVu dGlmaWVyIHNwYWNlcyAod2FzIFJlOk9uIGlkZW50aWZpZXJzOiB3aGF0IGlzIHZpcnR1YWwgYW5k IHdoYXQgaXMgZ2xvYmFsKQ0KDQo+PiBIZW5jZSwgbXkgdGVudGF0aXZlIGNvbmNsdXNpb25zIGFy ZSB0aGF0IGZvciBhIHZlcnkgbGFyZ2UgZmxhdCBuYW1lICANCj4+IHNwYWNlLCB5b3UgbmVlZA0K Pj4gLSBlbm91Z2ggb2YgYml0cyBpbiB0aGUgaWRlbnRpZmllciwgaW4gb3JkZXIgdG8gbWFrZSB0 aGUgcHJvYmFiaWxpdHkgIA0KPj4gb2YgcmFuZG9tIGNvbGxpc2lvbnMgY29uc2lkZXJhYmx5IHNt YWxsZXIgdGhhbiB0aGUgcHJvYmFiaWxpdHkgb2YgIA0KPj4gZG91YmxlLWFzc2lnbm1lbnQgZHVl IHRvIGh1bWFuIGVycm9ycy4NCj4NCj4gU3VyZWx5IHRoZSByaXNrIHlvdSBuZWVkIHRvIGV2YWx1 YXRlIGlzIHRoZSBwcm9iYWJpbGl0eSBvZiBkb3VibGUgDQo+IGFzc2lnbm1lbnQgZHVlIHRvIHJh bmRvbSBsb3NzIG9mIG1lc3NhZ2VzIGluIGEgZGlzdHJpYnV0ZWQgYXNzaWdubWVudCANCj4gc3lz dGVtPw0KDQpUaGFua3MsIEkgbWlzc2VkIHRoYXQhICBGb29sIG1lIHN0aWxsIHRoaW5raW5nIHRo YXQgdGhlIHN5c3RlbSB3b3VsZCBiZSByZWxpYWJsZS4uLg0KDQo+PiBTbywgd2hhdCBJIGFtIG1p c3Npbmc/ICBXaHkgZG8gaWRlbnRpZmllciBzeXN0ZW1zIG5lY2Vzc2FyaWx5IG5lZWQgdG8gIA0K Pj4gYmUgc3RydWN0dXJlZD8NCj4NCj4gVGhhdCBkZXBlbmRzIHdoZXRoZXIgImxvb2stdXAgdGlt ZXMgaW4gdGhlIG9yZGVyIG9mIDEtMiBzZWNvbmRzIg0KPiBhcmUgY29uc2lkZXJlZCBzdWZmaWNp ZW50LiBJZiwgZm9yIGV4YW1wbGUsIHRoYXQgaXMgNiBvcmRlcnMgb2YgDQo+IG1hZ25pdHVkZSB0 b28gbG9uZywgeW91J2QgaGF2ZSBhIHByb2JsZW0uDQoNClllcy4gIDotKQ0KDQpGbGF0IGlkZW50 aWZpZXIgc3BhY2VzIGRvIG5vdCBzZWVtIHRvIGJlIHZlcnkgc3VpdGFibGUgZm9yIGxhcmdlLSAN CnNjYWxlIHJvdXRpbmcuICBJSVJDLCB0aGUgUk9GTCBwYXBlciBoYWQgc29tZSBudW1iZXJzLiAg Q2hlY2tpbmcuLi4gICANClllcywgZnJvbSAiU3VtbWFyeSBvZiByZXN1bHRzIjogImhvc3QgY2Fu IGpvaW4gYWNyb3NzIGFsbCBwcm92aWRlcnMgYW5kIHBlZXJzIC4uLiB3aXRoIOKIvDQ0NSBjb250 cm9sIG1lc3NhZ2VzLiAgQW4gYXZlcmFnZSBbcm91dGluZ10gc3RyZXRjaCBvZiAyLjUuIC4uLi4g W1Bvc3NpYmxlIHRvXSByZWR1Y2UgW2hvc3RdIGpvaW4gb3ZlcmhlYWQgdG8g4oi8MTAwIG1lc3Nh Z2VzLCBidXQgcmVxdWlyZXMgNzQgTWJpdHMgb2YgYmxvb20gZmlsdGVyIHN0YXRlIHBlciBBUy4i DQoNCiBGcm9tIHRoYXQsIHRoZSBzdHJldGNoIG9mIDIuNSBzZWVtcyBwcmV0dHkgYmFkLiAgSSBk b24ndCBoYXZlIGFueSBudW1iZXJzIGZvciB0aGUgc3RyZXRjaCBpbiB0aGUgY3VycmVudCBzeXN0 ZW0sIHRob3VnaC4gIChzdHJldGNoID0gdGhlIHJhdGlvIGJldHdlZW4gdGhlIHRyYXZlcnNlZCBw YXRoIGFuZCB0aGUgc2hvcnRlc3QgcGF0aC4pDQoNClthbGJdIEZyb20gd2hhdCBJIHJlYWQsIHN0 cmV0Y2ggIGlzIHByZXR0eSBiYWQgdG9kYXkgdGhlbg0KW2FsYl0gd3d3LmVlY3MudW1pY2guZWR1 L356bWFvL2VlY3M1ODkvbm90ZXMvbGVjNV82LnBkZg0KW2FsYl0gaHR0cDovL2NpdGVzZWVyLmlz dC5wc3UuZWR1L2NhY2hlL3BhcGVycy9jcy8xODAzNC9odHRwOnpTenpTend3dy5pc2kuZWR1elN6 fmhvbmdzdWRhelN6cHVibGljYXRpb256U3ppbmZvMjAwMS5wZGYvdGFuZ211bmFydW5raXQwMWlt cGFjdC5wZGYNCg0KW2FsYl0gQWxzbywgSSB3b3VsZCBzdXNwZWN0IHRoYXQgY2hhbmdlIG1hbmFn ZW1lbnQgcmF0aGVyIHRoYW4gYWJzb2x1dGUgc2l6ZSB3b3VsZCBiZSB0aGUgaXNzdWUgd2l0aCBh IGZsYXQgc3lzdGVtDQoNClthbGJdIEkgYW0gcmF0aGVyIG9mIHRoZSBmZWVsaW5nIHRoYXQgYSBv bmUgb2ZmIGxvb2stdXAgdGltZSAoc2F5IHJlc29sdmluZyBhIGZsYXQgbmFtZSB0byBhIGxvY2F0 b3IpIG1pZ2h0IGJlIHBvc3NpYmxlLCBidXQgW2FsYl0geW91IG1pZ2h0IHdhbnQgdG8gc3RpY2sg d2l0aCBzdHJ1Y3R1cmUgaW4gdGhlIGxvY2F0b3IgZm9yIHJvdXRpbmcgcHVycG9zZXMNCg0KW2Fs Yl0gTG91aXNlDQoNCi0tUGVra2EgTmlrYW5kZXINCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGluZyBs aXN0DQpBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MNCg== --===============0299983989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0299983989==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 08:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2nc-0002VR-Oc; Tue, 28 Nov 2006 08:15:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2nZ-0002V3-Gz for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:14:57 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp2nX-0007qR-U8 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:14:57 -0500 Received: from afrinic5-55.afrinic.net (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kASDAhrK095865; Tue, 28 Nov 2006 05:10:57 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by afrinic5-55.afrinic.net (PGP Universal service); Tue, 28 Nov 2006 05:14:48 -0800 X-PGP-Universal: processed; by afrinic5-55.afrinic.net on Tue, 28 Nov 2006 05:14:48 -0800 In-Reply-To: <456A942E.2010201@zurich.ibm.com> References: <866404.59443.qm@web31808.mail.mud.yahoo.com> <9960E87B-6893-4F85-873B-C1ED06339E0A@virtualized.org> <456A942E.2010201@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <602626D8-B66F-4444-866C-184FB17A6BAB@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global ... Date: Tue, 28 Nov 2006 00:34:48 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian, On Nov 26, 2006, at 11:30 PM, Brian E Carpenter wrote: > David Conrad wrote: >> Since a primary goal (at least of enterprise network folks) is to >> be able to change providers, > > I think that understates it. Yes, as I said, "a" not "the". > - ability to use multiple simultaneous providers > - ability to add and drop providers > - ability to have multiple points of attachment > - both while preserving business continuity Yep. > [global uniqueness of identifiers] may be the easiest from the PoV > of the enterprise, but it certainly isn't the easiest from the PoV > of the service providers, which is why we are having this > conversation, I think. Wouldn't this would argue for NAT? I believe we want uniqueness in the identifier space sufficient to cover all sources and destinations who may want to communicate in an end-to-end fashion (although saying "globally unique" is easier). Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 08:15:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2no-0002iI-74; Tue, 28 Nov 2006 08:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2nm-0002hT-OE for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:15:10 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp2nk-0007wC-QV for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:15:10 -0500 Received: from afrinic5-55.afrinic.net (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kASDAhrO095865; Tue, 28 Nov 2006 05:11:09 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by afrinic5-55.afrinic.net (PGP Universal service); Tue, 28 Nov 2006 05:15:02 -0800 X-PGP-Universal: processed; by afrinic5-55.afrinic.net on Tue, 28 Nov 2006 05:15:02 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... Date: Tue, 28 Nov 2006 00:38:22 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pekka.nikander@nomadiclab.com, architecture-discuss@ietf.org, jeanjour@comcast.net X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Heiner, On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: > IMO the address should contain some part related to the individual > user, plus eventually also some address family characteristics > ( private, org, edu, gov,... ) and definitely some locating part > (ASN, geographic coordinates). Of course, only part of such an > address can be checksummed. People interested in privacy might have a few issues with this. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 08:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2o2-00031D-4B; Tue, 28 Nov 2006 08:15:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2o1-00030n-3v for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:15:25 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp2nz-00080N-DI for architecture-discuss@ietf.org; Tue, 28 Nov 2006 08:15:25 -0500 Received: from afrinic5-55.afrinic.net (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kASDAhrS095865; Tue, 28 Nov 2006 05:11:20 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by afrinic5-55.afrinic.net (PGP Universal service); Tue, 28 Nov 2006 05:15:10 -0800 X-PGP-Universal: processed; by afrinic5-55.afrinic.net on Tue, 28 Nov 2006 05:15:10 -0800 In-Reply-To: <816DD9299957E547B5D758D7F977D6DCF9E84E@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCF9E84E@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <866E00AF-B2B4-40F7-B245-366A4ACA9994@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Tue, 28 Nov 2006 01:02:49 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jim, On Nov 23, 2006, at 9:39 PM, Bound, Jim wrote: > Agree and that aggregation is important but will not always be > possible. I agree that it won't always be possible. However, we have changed the Internet scaling characteristics from tending towards O(ISPs +enterprises+end users) to O(ISPs). As we have an existence proof that we can have over 200K entries with today's technology, I think we have some room to grow. >> The whole point of this discussion is that the term "address" >> as it is used today implies the concepts of identity and >> location are merged. > That is where I believe I disagree. I think you misunderstood me as I believe we mostly agree. > What Pekka N. proposed leaves this question > open for now. If ISP1 has prefix for location as FFEE but ISP2 has > prefix FEEF the aggregation is only for the first order bits (leaving > undefined) and without more bits location cannot be known for routing. Right. Since I do not believe it realistic to assume we can aggregate ISPs without changing ISP business models (which they are not particularly inclined to do), I'm implicitly assuming that each ISP would have their own prefix. That is, at the highest level of hierarchy, the locator space would be flat. However, a nice aspect of separating identity from location (and providing a mapping function to translate between the two) is that in the future, we can rip out the location mechanism and replace it with something better without impacting the end users (in fact, they won't even have to know there has been a change), so if we discover the two- tiered approach doesn't scale enough for whatever reason, we can deploy a new/better solution much, much more easily. > The identifier comes into play only for me between the two end-to-end > applications, security enhancements, and transport end-points > possibly. Yes. > Whether that is part of an IP address with the locator for me is > premature discussion and identifying the requirements. As I've said previously, I don't like to use the term "address" as it blurs the line between the two different functions of "identification of end point" and "location of network attachment". These two functions can obviously be merged into a single bit string (albeit, I believe this will require changes to all deployed TCP/IP stacks which I'm skeptical we can do in any reasonable timeframe), but I believe it would be really helpful to keep the functions as conceptually distinct as possible. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 11:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5bZ-0005XV-Gm; Tue, 28 Nov 2006 11:14:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5bY-0005Ws-Ti for architecture-discuss@ietf.org; Tue, 28 Nov 2006 11:14:44 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5bX-0003Lt-O3 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 11:14:44 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc13) with ESMTP id <2006112816144201300atnbke>; Tue, 28 Nov 2006 16:14:43 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Nov 2006 11:13:42 -0500 To: David Conrad , HeinerHummel@aol.com From: John Day Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: pekka.nikander@nomadiclab.com, architecture-discuss@ietf.org, jeanjour@comcast.net X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 0:38 -0800 2006/11/28, David Conrad wrote: >Heiner, > >On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: >>IMO the address should contain some part related to the individual >>user, plus eventually also some address family characteristics ( >>private, org, edu, gov,... ) and definitely some locating part >>(ASN, geographic coordinates). Of course, only part of such an >>address can be checksummed. > >People interested in privacy might have a few issues with this. I agree with David. And would go further, no way. This information has nothing to do with an address. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 11:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5oy-0001K1-KC; Tue, 28 Nov 2006 11:28:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5ow-0001Ju-Mi for architecture-discuss@ietf.org; Tue, 28 Nov 2006 11:28:34 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5ou-0005vY-Gg for architecture-discuss@ietf.org; Tue, 28 Nov 2006 11:28:34 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3687D86AE6; Tue, 28 Nov 2006 11:28:32 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... Message-Id: <20061128162832.3687D86AE6@mercury.lcs.mit.edu> Date: Tue, 28 Nov 2006 11:28:32 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day > And would go further, no way. This information has nothing to do with > an address. No doubt you meant to say "has nothing to do with a routing-name (aka location name)", but it slipped your mind... :-) Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 11:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5yI-00067F-2k; Tue, 28 Nov 2006 11:38:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5yG-00067A-SO for architecture-discuss@ietf.org; Tue, 28 Nov 2006 11:38:12 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5yF-0007R5-M5 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 11:38:12 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20061128163810b1200mulrue>; Tue, 28 Nov 2006 16:38:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061128162832.3687D86AE6@mercury.lcs.mit.edu> References: <20061128162832.3687D86AE6@mercury.lcs.mit.edu> Date: Tue, 28 Nov 2006 11:38:06 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 11:28 -0500 2006/11/28, Noel Chiappa wrote: > > From: John Day > > > And would go further, no way. This information has nothing to do with > > an address. > >No doubt you meant to say "has nothing to do with a routing-name (aka >location name)", but it slipped your mind... :-) > > Noel ;-) Same thing in my book! ;-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 13:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7Pc-0005gf-4p; Tue, 28 Nov 2006 13:10:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7Pb-0005ga-Ma for architecture-discuss@ietf.org; Tue, 28 Nov 2006 13:10:31 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp7PZ-00053X-8j for architecture-discuss@ietf.org; Tue, 28 Nov 2006 13:10:31 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kASIARTo061318 for ; Tue, 28 Nov 2006 18:10:27 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kASIE4RA3084496 for ; Tue, 28 Nov 2006 19:14:04 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kASIARZ9030837 for ; Tue, 28 Nov 2006 19:10:27 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kASIAQr1030828; Tue, 28 Nov 2006 19:10:27 +0100 Received: from zurich.ibm.com (sig-9-145-254-83.de.ibm.com [9.145.254.83]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA47356; Tue, 28 Nov 2006 19:10:21 +0100 Message-ID: <456C67FB.7020802@zurich.ibm.com> Date: Tue, 28 Nov 2006 17:46:51 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global ... References: <866404.59443.qm@web31808.mail.mud.yahoo.com> <9960E87B-6893-4F85-873B-C1ED06339E0A@virtualized.org> <456A942E.2010201@zurich.ibm.com> <602626D8-B66F-4444-866C-184FB17A6BAB@virtualized.org> In-Reply-To: <602626D8-B66F-4444-866C-184FB17A6BAB@virtualized.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Conrad wrote: ... >> [global uniqueness of identifiers] may be the easiest from the PoV of >> the enterprise, but it certainly isn't the easiest from the PoV of >> the service providers, which is why we are having this conversation, >> I think. > > > Wouldn't this would argue for NAT? That's a juicy worm, let me see if I can avoid the hook buried in it ;-) IMHO, it argues for some way of separating the usage of address prefixes to identify sites from their usage for wide-area routing. But (as you say below) there is also the architectural need for e2e identifiers. What map-and-encap, shim6 and GSE have in common is that they attempt to meet all of those needs simultaneously. NAT doesn't get the e2e one. > > I believe we want uniqueness in the identifier space sufficient to > cover all sources and destinations who may want to communicate in an > end-to-end fashion (although saying "globally unique" is easier). Yep Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 13:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7yq-0005Dt-7i; Tue, 28 Nov 2006 13:46:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp7yo-0005DT-3R for architecture-discuss@ietf.org; Tue, 28 Nov 2006 13:46:54 -0500 Received: from imo-m26.mx.aol.com ([64.12.137.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp7yl-0002HO-OV for architecture-discuss@ietf.org; Tue, 28 Nov 2006 13:46:54 -0500 Received: from HeinerHummel@aol.com by imo-m26.mx.aol.com (mail_out_v38_r7.6.) id i.cd8.43f6549 (30737); Tue, 28 Nov 2006 13:46:30 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 28 Nov 2006 13:46:29 EST Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... To: jeanjour@comcast.net, drc@virtualized.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1372691124==" Errors-To: architecture-discuss-bounces@ietf.org --===============1372691124== Content-Type: multipart/alternative; boundary="-----------------------------1164739589" -------------------------------1164739589 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 John, I completely respect your NO. And indeed, it is not a requirement in order=20 to be able to accomplish something (e.g. like routing). However, it is a =20 political offer and does allow differentiating (filtering). And here we get=20= to =20 some other topics like political priorities. And I think we should understan= d =20 such other priorities/issues/wishes. =20 I also pointed out that -in my view a mistake - we merge technical operatio= n=20 into the address (unicast, anycast, multicast) which is neither necessary=20 nor favorable and which can be handled better.=20 However we should think about what else might be merged into an address =20 because it is appropriate to do so. There are also other groups (ITU-T e.g.)= =20 which have developed some ideas on addresses. And also: New ideas and new =20 arguments should be welcome. I am not a politician. But (who knows) maybe a= n address=20 is also something to be protected/defended/scoped ? =20 I can assure you: I do not know the right or the whole answer. But I think=20 we should invite politicians to come up with their wishes, too. =20 Heiner =20 =20 In einer eMail vom 28.11.2006 17:14:51 Westeurop=E4ische Normalzeit schreibt= =20 jeanjour@comcast.net: At 0:38 -0800 2006/11/28, David Conrad wrote: >Heiner, > >On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: >>IMO the address should contain some part related to the individual=20 >>user, plus eventually also some address family characteristics (=20 >>private, org, edu, gov,... ) and definitely some locating part=20 >>(ASN, geographic coordinates). Of course, only part of such an=20 >>address can be checksummed. > >People interested in privacy might have a few issues with this. I agree with David. And would go further, no way. This information=20 has nothing to do with an address. John -------------------------------1164739589 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
John,
I completely respect your NO. And indeed, it is not a requirement=20= in=20 order to be able to accomplish something (e.g. like routing). However, it is= a=20 political offer and does allow differentiating (filtering). And here we get=20= to=20 some other topics like political priorities. And I think we should understan= d=20 such other priorities/issues/wishes.=20
 
I also pointed out that -in my view a mistake - we merge technical=20 operation into the address (unicast, anycast, multicast) which is neither=20 necessary nor favorable and which can be handled better. 
However we should think about what else might be merged into an address= =20 because it is appropriate to do so. There are also other groups (ITU-T e.g.)= =20 which have developed some ideas on addresses. And also: New ideas and new=20 arguments should be welcome. I am not a politician. But (who knows)=20 maybe an address is also something to be protected/defended/scoped ?
 
I can assure you: I do not know the right or the whole answer. But= I=20 think we should invite politicians to come up with their wishes, too.
 
Heiner
 
 
In einer eMail vom 28.11.2006 17:14:51 Westeurop=E4ische Normalzeit sch= reibt=20 jeanjour@comcast.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>At 0:38=20 -0800 2006/11/28, David Conrad wrote:
>Heiner,
>
>On Nov= 27,=20 2006, at 1:34 AM, HeinerHummel@aol.com wrote:
>>IMO the address=20 should contain some part related to the individual
>>user, plus=20 eventually also some address family characteristics (
>>private,= =20 org, edu, gov,...  ) and definitely some locating part
>>(A= SN,=20 geographic coordinates). Of course, only part of such an
>>addre= ss=20 can be checksummed.
>
>People interested in privacy might have= a=20 few issues with this.

I agree with David.  And would go furthe= r,=20 no way.  This information
has nothing to do with an=20 address.

John
 
-------------------------------1164739589-- --===============1372691124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1372691124==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 14:03:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8Dv-0004s8-6d; Tue, 28 Nov 2006 14:02:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8Du-0004qE-Fq for architecture-discuss@ietf.org; Tue, 28 Nov 2006 14:02:30 -0500 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gp8Dt-0004mw-3b for architecture-discuss@ietf.org; Tue, 28 Nov 2006 14:02:30 -0500 Received: (qmail 8627 invoked from network); 28 Nov 2006 19:02:28 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 28 Nov 2006 19:02:28 -0000 Received: from LIPC ([192.168.1.158]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 11:02:27 -0800 From: "Tony Li" To: , , Subject: RE: [arch-d] On scaling of flat identifier spaces (was Re: Onidentifiers: wh... Date: Tue, 28 Nov 2006 11:02:23 -0800 Message-ID: <002201c7131f$bd2ff860$9e01a8c0@tropos.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccTHaGgHHvNJ5WJQouYlju+aOUZGwAAbLDA X-OriginalArrivalTime: 28 Nov 2006 19:02:27.0780 (UTC) FILETIME=[BF4DA840:01C7131F] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1359678154==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============1359678154== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C712DC.AF0CB860" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C712DC.AF0CB860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I can assure you: I do not know the right or the whole answer. But I think we should invite politicians to come up with their wishes, too. I'm hopeful that this will remain a technical discussion. Tony ------=_NextPart_000_0023_01C712DC.AF0CB860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
I can assure you: I do not know the right or the whole = answer. But I=20 think we should invite politicians to come up with their wishes,=20 too.
 
I'm hopeful that this = will remain a=20 technical discussion.
 
Tony
 
------=_NextPart_000_0023_01C712DC.AF0CB860-- --===============1359678154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1359678154==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 14:17:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8QD-0002bj-MJ; Tue, 28 Nov 2006 14:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8QB-0002aV-Hg for architecture-discuss@ietf.org; Tue, 28 Nov 2006 14:15:11 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp8MV-00063m-HJ for architecture-discuss@ietf.org; Tue, 28 Nov 2006 14:11:25 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20061128191111m1100smnghe>; Tue, 28 Nov 2006 19:11:22 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Nov 2006 14:11:01 -0500 To: HeinerHummel@aol.com, jeanjour@comcast.net, drc@virtualized.org From: John Day Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0823366897==" Errors-To: architecture-discuss-bounces@ietf.org --===============0823366897== Content-Type: multipart/alternative; boundary="============_-1047381415==_ma============" --============_-1047381415==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Having played the electro-political engineering=20 game for more than a few decades, I can assure=20 you that if given the chance politicians will=20 screw up anything they touch. We are lucky in=20 this case however, since there is absolutely no=20 part of *addressing* that is political. Any=20 attempt otherwise is simply misguided. (The same=20 can not be said of application names, however.) Addresses are topologically-dependent names whose=20 use is internal to a layer. There is never any=20 need (in a well-formed architecture) for=20 addresses to be visible to any but the internal=20 machinery of the layer. There is no rationale=20 for them to have any other visibility to=20 applications or anything else outside the layer,=20 certainly none political. Take care, John At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote: >John, >I completely respect your NO. And indeed, it is=20 >not a requirement in order to be able to=20 >accomplish something (e.g. like routing).=20 >However, it is a political offer and does allow=20 >differentiating (filtering). And here we get to=20 >some other topics like political priorities. And=20 >I think we should understand such other=20 >priorities/issues/wishes. > >I also pointed out that -in my view a mistake -=20 >we merge technical operation into the address=20 >(unicast, anycast, multicast) which is neither=20 >necessary nor favorable and which can be handled=20 >better. >However we should think about what else might be=20 >merged into an address because it is appropriate=20 >to do so. There are also other groups (ITU-T=20 >e.g.) which have developed some ideas on=20 >addresses. And also: New ideas and new arguments=20 >should be welcome. I am not a politician. But=20 >(who knows) maybe an address is also something=20 >to be protected/defended/scoped ? > >I can assure you: I do not know the right or the=20 >whole answer. But I think we should invite=20 >politicians to come up with their wishes, too. > >Heiner > > >In einer eMail vom 28.11.2006 17:14:51=20 >Westeurop=E4ische Normalzeit schreibt=20 >jeanjour@comcast.net: > >At 0:38 -0800 2006/11/28, David Conrad wrote: >>Heiner, >> >>On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: >>>IMO the address should contain some part related to the individual >>>user, plus eventually also some address family characteristics ( >>>private, org, edu, gov,... ) and definitely some locating part >>>(ASN, geographic coordinates). Of course, only part of such an >>>address can be checksummed. >> >>People interested in privacy might have a few issues with this. > >I agree with David. And would go further, no way. This information >has nothing to do with an address. > >John > > --============_-1047381415==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [arch-d] On scaling of flat identifier spaces (was Re:
Having played the electro-political engineering game for more than a few decades, I can assure you that if given the chance politicians will screw up anything they touch.  We are lucky in this case however, since there is absolutely no part of *addressing* that is political.  Any attempt otherwise is simply misguided.  (The same can not be said of application names, however.)

Addresses are topologically-dependent names whose use is internal to a layer.  There is never any need (in a well-formed architecture) for addresses to be visible to any but the internal machinery of the layer.  There is no rationale for them to have any other visibility to applications or anything else outside the layer, certainly none political.

Take care,
John

At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote:
John,
I completely respect your NO. And indeed, it is not a requirement in order to be able to accomplish something (e.g. like routing). However, it is a political offer and does allow differentiating (filtering). And here we get to some other topics like political priorities. And I think we should understand such other priorities/issues/wishes.
 
I also pointed out that -in my view a mistake - we merge technical operation into the address (unicast, anycast, multicast) which is neither necessary nor favorable and which can be handled better.
However we should think about what else might be merged into an address because it is appropriate to do so. There are also other groups (ITU-T e.g.) which have developed some ideas on addresses. And also: New ideas and new arguments should be welcome. I am not a politician. But (who knows) maybe an address is also something to be protected/defended/scoped ?
 
I can assure you: I do not know the right or the whole answer. But I think we should invite politicians to come up with their wishes, too.
 
Heiner
 
 
In einer eMail vom 28.11.2006 17:14:51 Westeurop=E4ische Normalzeit schreibt jeanjour@comcast.net:
At 0:38 -0800 2006/11/28, David Conrad wrote:
>Heiner,
>
>On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote:
>>IMO the address should contain some part related to the individual
>>user, plus eventually also some address family characteristics (
>>private, org, edu, gov,...  ) and definitely some locating part
>>(ASN, geographic coordinates). Of course, only part of such an
>>address can be checksummed.
>
>People interested in privacy might have a few issues with this.

I agree with David.  And would go further, no way.  This information
has nothing to do with an address.

John
 

--============_-1047381415==_ma============-- --===============0823366897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0823366897==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 14:48:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8v6-0007sK-QP; Tue, 28 Nov 2006 14:47:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp8v6-0007sE-9B for architecture-discuss@ietf.org; Tue, 28 Nov 2006 14:47:08 -0500 Received: from web58703.mail.re1.yahoo.com ([66.196.100.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gp8v3-00032S-P7 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 14:47:08 -0500 Received: (qmail 86263 invoked by uid 60001); 28 Nov 2006 19:47:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KPQvD9SXwiYz5Wa1SjrVTZVCEpDTVKOvP7TiqRF6daUvVwQFy6U259h/i3k9y+p66dkpNwb9/5p/SjPuqqshCWS7HIrTidK97rvlFapZ5anfXVkmuu7b3+Eb8IrpS+AohgEj+/9/nePkfpqr1yuL9RvtpkPf1PN9vG1MsZReL78=; X-YMail-OSG: ipgDdK8VM1kJF1yHe8nwhRJWJbsEo7d_QEebro2oX2A43uRkt5XFNN6BezZegma.2ynPX4yT0dQzbzPv2Cz6nxR7ioGuHdJD2zE9ZmljaYJ.pOBk_DNXLLK6UEAe9ubd6I1yBOgPgETdYA3w2sbXXVnAo1S6g8DP3.gSIr52WapQuTtvKVwQg2X5LAg- Received: from [207.107.50.100] by web58703.mail.re1.yahoo.com via HTTP; Tue, 28 Nov 2006 11:47:04 PST Date: Tue, 28 Nov 2006 11:47:04 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: David Conrad , "Bound, Jim" In-Reply-To: <866E00AF-B2B4-40F7-B245-366A4ACA9994@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <437164.85404.qm@web58703.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > blurs the line between the two different functions of "identification > of end point" and "location of network attachment" Just a thought: - person's name = ID - person's address = location (geo, topo, any physical) - ID does not change - location changes often to reach a person an envelope needs a combination: ID + location Could the same principle apply to a network: - ID's and locators are independent - Uniqueness realizes at the attachment point = ID + location Result - No dependency on a provider - No scaling problem because the routing table is fixed in a robust hierarchy Thank you, Peter --- David Conrad wrote: > Jim, > > On Nov 23, 2006, at 9:39 PM, Bound, Jim wrote: > > Agree and that aggregation is important but will not always be > > possible. > > I agree that it won't always be possible. However, we have changed > the Internet scaling characteristics from tending towards O(ISPs > +enterprises+end users) to O(ISPs). As we have an existence proof > that we can have over 200K entries with today's technology, I think > we have some room to grow. > > >> The whole point of this discussion is that the term "address" > >> as it is used today implies the concepts of identity and > >> location are merged. > > That is where I believe I disagree. > > I think you misunderstood me as I believe we mostly agree. > > > What Pekka N. proposed leaves this question > > open for now. If ISP1 has prefix for location as FFEE but ISP2 has > > prefix FEEF the aggregation is only for the first order bits (leaving > > undefined) and without more bits location cannot be known for routing. > > Right. Since I do not believe it realistic to assume we can > aggregate ISPs without changing ISP business models (which they are > not particularly inclined to do), I'm implicitly assuming that each > ISP would have their own prefix. That is, at the highest level of > hierarchy, the locator space would be flat. > > However, a nice aspect of separating identity from location (and > providing a mapping function to translate between the two) is that in > the future, we can rip out the location mechanism and replace it with > something better without impacting the end users (in fact, they won't > even have to know there has been a change), so if we discover the two- > tiered approach doesn't scale enough for whatever reason, we can > deploy a new/better solution much, much more easily. > > > The identifier comes into play only for me between the two end-to-end > > applications, security enhancements, and transport end-points > > possibly. > > Yes. > > > Whether that is part of an IP address with the locator for me is > > premature discussion and identifying the requirements. > > As I've said previously, I don't like to use the term "address" as it > blurs the line between the two different functions of "identification > of end point" and "location of network attachment". These two > functions can obviously be merged into a single bit string (albeit, I > believe this will require changes to all deployed TCP/IP stacks which > I'm skeptical we can do in any reasonable timeframe), but I believe > it would be really helpful to keep the functions as conceptually > distinct as possible. > > Rgds, > -drc > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 15:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9In-0002WV-H4; Tue, 28 Nov 2006 15:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9Im-0002W2-CJ for architecture-discuss@ietf.org; Tue, 28 Nov 2006 15:11:36 -0500 Received: from web58701.mail.re1.yahoo.com ([66.196.100.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gp9Ik-0006wV-UT for architecture-discuss@ietf.org; Tue, 28 Nov 2006 15:11:36 -0500 Received: (qmail 64657 invoked by uid 60001); 28 Nov 2006 20:11:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=fhQHDTlm7a0XxNjPIKP0T3aJrlpV6y+VipoRPEi0KyJMHSLOWN0jTfldT6p9Bu+uNlYFr5vtUBYUcHinQSgFAz8GZ4co8dvS9FaI3QmhzNAyZ8xsQEdQ9Q2idF2XOaxIG2YgVgLk4eYP7eYAtoW54aedYRC93xmuGpjEgZ9U5ew=; X-YMail-OSG: CLK99VQVM1nIVSYajOTm6RtujhHvjQj1ROj7NoE3MUsd_CfCM4TCAn50p28K6wihYCl2BsSBgalRkJevthf9U9NmoklSZdCkp.Q.mLWVamDFOuXzX78UVIwgajBmUyGBLhSCwYDD3CFAcByZjXH3WGFzcTOHuxRBhtJMcrncpSH3jLCgnE69Wqbhl80- Received: from [207.107.50.100] by web58701.mail.re1.yahoo.com via HTTP; Tue, 28 Nov 2006 12:11:34 PST Date: Tue, 28 Nov 2006 12:11:34 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] Thoughts about addresses, or why the overall architecture affects routing. To: Pekka Nikander In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <727384.64465.qm@web58701.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka, This generalization looks great. Thank you. > arriving. Indeed, such traffic should be stopped as close to its > source as possible. Regarding unwanted traffic as an EU I need an option to look safely at the message and if I do not like it I has to be able to drop all packets from that source on arrival. Let cyberpolice worry about the malicious source. > What I still don't see is how much a) money, b) trouble, and c) pain > people would be paying... Those properties are expected features of the product. It would be still the same Internet with costs determined by the amount of traffic crossing networks. Hardware / software could be gradually upgraded on three fronts as per your earlier message. Thanks, Peter --- Pekka Nikander wrote: > Peter, > > Taking your answers and trying to generalise them to apply any > networking architectures, not only the current one, how wrong would I > be, from your point of view, if I restated your requirements in the > following way? Note that I'm using the same numbering as you did in > your original message. > > 1. Application-level identifiers assigned for a lifetime > [Originally: an IP address pool assigned to me for a lifetime] > > These identifiers must work with all applications, with addressable > application entities dispersed at all levels, ranging from private > individual to global distributed applications. These identifiers > should be completely independent from access providers, and not > change when the network connectivity changes. They should outlive > any "mobility" situations, independent on time scale. > > The primary motivation for their persistency is to avoid the costs > incurring from they being changed, since such identifiers would be > located through the systems in various odd locations. > > [Due to us having only the socket APIs today, and nothing more > abstract in wider acceptance, most people seem to think today that > the only choice for such identifiers are IP addresses. To an extend > I agree; that's the very reason why we have suggested an experimental > allocation; see draft-laganier-ipv6-khi-05.txt.] > > 2. Independent dynamic choice of providers for incoming and outgoing > traffic > [Originally: selection of competing networks...] > > It should be possible to dynamically select the best network for any > incoming and outgoing traffic, using any local policies based on such > factors as per-packet-or-per-bit cost, delay, bandwidth, utilisation, > etc. > > One aim of such ability would be to smoothen the markets and lowering > entry barriers. By being able to easily and dynamically select the > carriers, even small customers together would have more purchasing > power, thereby leading to lower overall prices and less price > discrimination. > > 3-4. Full origin authentication and privacy about the origin of > incoming traffic > [Originally: 3. complete control on what goes out with my > source addresses > 4. an assurance that what is coming in has come > from its true originator] > > The end-receiver (organisation) of any incoming traffic should have > reasonable assurance that the traffic is coming from a known (or an > easily traceable source), while the immediate upstream access > providers should have no information from whom the traffic is coming > from. > > This is one aspect of a balanced privacy/accountability that I have > stated elsewhere several times. Basically, we seem to need more > privacy and more accountability, simultaneously. > > [Incidentally, I happen to believe that the source address would be a > completely wrong vehicle for such property, even in the current > architecture.] > > 5. The ability to limit traffic incoming from unwanted / untraceable > senders > [Originally: an ability to prevent receiving from unwanted senders] > > Related to the item 3-4, if there is incoming traffic whose origin is > not know, or cannot be easily traced, or is otherwise unwanted based > on its source, it should be easy to prevent that traffic from > arriving. Indeed, such traffic should be stopped as close to its > source as possible. > > [Ditto.] > > -------- > > What I still don't see is how much a) money, b) trouble, and c) pain > people would be paying for any of the above mentioned properties. > > --Pekka Nikander > > > > ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 15:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9Ns-0004DT-Hl; Tue, 28 Nov 2006 15:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9Nr-0004AD-Ij for architecture-discuss@ietf.org; Tue, 28 Nov 2006 15:16:51 -0500 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9Nq-0007WM-9X for architecture-discuss@ietf.org; Tue, 28 Nov 2006 15:16:51 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc15) with ESMTP id <20061128201638m15000f81de>; Tue, 28 Nov 2006 20:16:49 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <437164.85404.qm@web58703.mail.re1.yahoo.com> References: <437164.85404.qm@web58703.mail.re1.yahoo.com> Date: Tue, 28 Nov 2006 15:15:40 -0500 To: Peter Sherbin , David Conrad , "Bound, Jim" From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Peter, Very good. This is a good start. At 11:47 -0800 2006/11/28, Peter Sherbin wrote: > > blurs the line between the two different functions of "identification >> of end point" and "location of network attachment" > >Just a thought: > >- person's name = ID >- person's address = location (geo, topo, any physical) >- ID does not change >- location changes often > >to reach a person an envelope needs a combination: ID + location This is the conclusion in John Shoch's paper. "Internetwork Naming, Addressing, and Routing," IEEE Proc. COMPCON Fall 1978, pp. 72-79. > >Could the same principle apply to a network: >- ID's and locators are independent >- Uniqueness realizes at the attachment point = ID + location > >Result >- No dependency on a provider >- No scaling problem because the routing table is fixed in a robust hierarchy While necessary, this is not sufficient. As worked out few years later in, Saltzer, Jerry. "On the Naming and Binding of Network Destinations" in Local Computer Networks, edited by P. Ravasio et al. P North-Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498. I can't recommend strongly enough that you very carefully read and understand this paper. Then you will understand why loc;/id split is not the whole story and if by concentrating on that and that alone is a red-herring. As we have seen it gets one as far as Shoch's conclusions, but it doesn't go far enough. Saltzer concludes rightly, that a network architecture requires at a minimum application names, node addresses, and point of attachment addresses. The current Internet has only the latter. As I have pointed out earlier on this list, Salzter does miss one important point (understandably), but that can wait until you have worked through the paper. Take care, John Day _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 17:38:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBY1-0007V5-Em; Tue, 28 Nov 2006 17:35:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBY0-0007Ur-2R for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:35:28 -0500 Received: from imo-m20.mx.aol.com ([64.12.137.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBXx-0005rp-KM for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:35:28 -0500 Received: from HeinerHummel@aol.com by imo-m20.mx.aol.com (mail_out_v38_r7.6.) id i.488.12bf4b26 (29672); Tue, 28 Nov 2006 17:35:01 -0500 (EST) From: HeinerHummel@aol.com Message-ID: <488.12bf4b26.329e1392@aol.com> Date: Tue, 28 Nov 2006 17:34:58 EST Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... To: jeanjour@comcast.net, drc@virtualized.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1137504793==" Errors-To: architecture-discuss-bounces@ietf.org --===============1137504793== Content-Type: multipart/alternative; boundary="-----------------------------1164753298" -------------------------------1164753298 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I am neither pro nor con. Things can be used and abused. I remember that in=20= =20 Florida license plate numbers of rented cars used to have some special=20 character (X or Y, I am not sure). Then several robberies incl. killing happened where visitors from abroad =20 were the victims. Then policy was changed so that such an information cannot= be =20 derived anymore. =20 But I think this topic is worth to be discussed seriously. =20 Heiner =20 =20 In einer eMail vom 28.11.2006 20:11:59 Westeurop=E4ische Normalzeit schreibt= =20 jeanjour@comcast.net: Having played the electro-political engineering game for more than a few =20 decades, I can assure you that if given the chance politicians will screw up= =20 anything they touch. We are lucky in this case however, since there is =20 absolutely no part of *addressing* that is political. Any attempt otherwis= e is=20 simply misguided. (The same can not be said of application names, however.= ) Addresses are topologically-dependent names whose use is internal to a =20 layer. There is never any need (in a well-formed architecture) for address= es to=20 be visible to any but the internal machinery of the layer. There is no=20 rationale for them to have any other visibility to applications or anything= else=20 outside the layer, certainly none political. Take care, John At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote: John, I completely respect your NO. And indeed, it is not a requirement in order=20 to be able to accomplish something (e.g. like routing). However, it is a=20 political offer and does allow differentiating (filtering). And here we get= to=20 some other topics like political priorities. And I think we should understa= nd=20 such other priorities/issues/wishes. I also pointed out that -in my view a mistake - we merge technical operatio= n=20 into the address (unicast, anycast, multicast) which is neither necessary =20 nor favorable and which can be handled better. However we should think about what else might be merged into an address=20 because it is appropriate to do so. There are also other groups (ITU-T e.g.= )=20 which have developed some ideas on addresses. And also: New ideas and new=20 arguments should be welcome. I am not a politician. But (who knows) maybe a= n address=20 is also something to be protected/defended/scoped ? I can assure you: I do not know the right or the whole answer. But I think=20 we should invite politicians to come up with their wishes, too. Heiner In einer eMail vom 28.11.2006 17:14:51 Westeurop=E4ische Normalzeit schreib= t =20 jeanjour@comcast.net: At 0:38 -0800 2006/11/28, David Conrad wrote: >Heiner, > >On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: >>IMO the address should contain some part related to the individual >>user, plus eventually also some address family characteristics ( >>private, org, edu, gov,... ) and definitely some locating part >>(ASN, geographic coordinates). Of course, only part of such an >>address can be checksummed. > >People interested in privacy might have a few issues with this. I agree with David. And would go further, no way. This information has nothing to do with an address. John -------------------------------1164753298 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I am neither pro nor con. Things can be used and abused. I remember tha= t in=20 Florida license plate numbers of rented cars used to have some special chara= cter=20 (X or Y, I am not sure).
Then several robberies incl. killing happened where visitors from abroa= d=20 were the victims. Then policy was changed so that such an information cannot= be=20 derived anymore.
 
But I think this topic is worth to be discussed seriously.
 
Heiner
 
 
In einer eMail vom 28.11.2006 20:11:59 Westeurop=E4ische Normalzeit sch= reibt=20 jeanjour@comcast.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
Having played the electro-political engineering game for more than a=20= few=20 decades, I can assure you that if given the chance politicians will screw=20= up=20 anything they touch.  We are lucky in this case however, since there=20= is=20 absolutely no part of *addressing* that is political.  Any attempt=20 otherwise is simply misguided.  (The same can not be said of applicat= ion=20 names, however.)

Addresses are topologically-dependent names whose use is internal to=20= a=20 layer.  There is never any need (in a well-formed architecture) for=20 addresses to be visible to any but the internal machinery of the layer.&nb= sp;=20 There is no rationale for them to have any other visibility to application= s or=20 anything else outside the layer, certainly none political.

Take care,
John

At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote:
John,
I completely respect your NO. And indeed, it is not a=20 requirement in order to be able to accomplish something (e.g. like routi= ng).=20 However, it is a political offer and does allow differentiating (filteri= ng).=20 And here we get to some other topics like political priorities. And I th= ink=20 we should understand such other priorities/issues/wishes.
 
I=20 also pointed out that -in my view a mistake - we merge technical operati= on=20 into the address (unicast, anycast, multicast) which is neither necessar= y=20 nor favorable and which can be handled better.
However we should think about what else might be merged into a= n=20 address because it is appropriate to do so. There are also other groups=20 (ITU-T e.g.) which have developed some ideas on addresses. And also: New= =20 ideas and new arguments should be welcome. I am not a politician. B= ut=20 (who knows) maybe an address is also something to be=20 protected/defended/scoped ?
 
I can=20 assure you: I do not know the right or the whole answer. But I thin= k we=20 should invite politicians to come up with their wishes,=20 too.
 
Heiner
 
 
In=20 einer eMail vom 28.11.2006 17:14:51 Westeurop=E4ische Normalzeit schreib= t=20 jeanjour@comcast.net:
At 0:38 -0800=20 2006/11/28, David Conrad wrote:
>Heiner,
>
>On Nov 2= 7,=20 2006, at 1:34 AM, HeinerHummel@aol.com wrote:
>>IMO the addre= ss=20 should contain some part related to the individual
>>user, pl= us=20 eventually also some address family characteristics (
>>priva= te,=20 org, edu, gov,...  ) and definitely some locating=20 part
>>(ASN, geographic coordinates). Of course, only part of= =20 such an
>>address can be checksummed.
>
>People=20 interested in privacy might have a few issues with this.

I agre= e=20 with David.  And would go further, no way.  This=20 information
has nothing to do with an=20 address.

John
 

 
-------------------------------1164753298-- --===============1137504793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1137504793==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 17:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBjH-0000Sp-Fs; Tue, 28 Nov 2006 17:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBjG-0000S8-NH for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:06 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBjG-0007bs-9M for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:06 -0500 Received: from [10.0.1.39] (failure[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006112822470401100rkhgme>; Tue, 28 Nov 2006 22:47:05 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <488.12bf4b26.329e1392@aol.com> References: <488.12bf4b26.329e1392@aol.com> Date: Tue, 28 Nov 2006 17:42:14 -0500 To: HeinerHummel@aol.com, jeanjour@comcast.net, drc@virtualized.org From: John Day Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... X-Spam-Score: 0.1 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0683840879==" Errors-To: architecture-discuss-bounces@ietf.org --===============0683840879== Content-Type: multipart/alternative; boundary="============_-1047368472==_ma============" --============_-1047368472==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Sure, discuss away. However, license plates are not addresses. Network addresses indicate "where" an entity is=20 relative to the topology of the layer in which it=20 occurs. Not quite sure what might be political=20 about that but I am sure a politician could find=20 something. Take care, John At 17:34 -0500 2006/11/28, HeinerHummel@aol.com wrote: >I am neither pro nor con. Things can be used and=20 >abused. I remember that in Florida license plate=20 >numbers of rented cars used to have some special=20 >character (X or Y, I am not sure). >Then several robberies incl. killing happened=20 >where visitors from abroad were the victims.=20 >Then policy was changed so that such an=20 >information cannot be derived anymore. > >But I think this topic is worth to be discussed seriously. > >Heiner > > >In einer eMail vom 28.11.2006 20:11:59=20 >Westeurop=E4ische Normalzeit schreibt=20 >jeanjour@comcast.net: > >Having played the electro-political engineering=20 >game for more than a few decades, I can assure=20 >you that if given the chance politicians will=20 >screw up anything they touch. We are lucky in=20 >this case however, since there is absolutely no=20 >part of *addressing* that is political. Any=20 >attempt otherwise is simply misguided. (The=20 >same can not be said of application names,=20 >however.) > >Addresses are topologically-dependent names=20 >whose use is internal to a layer. There is=20 >never any need (in a well-formed architecture)=20 >for addresses to be visible to any but the=20 >internal machinery of the layer. There is no=20 >rationale for them to have any other visibility=20 >to applications or anything else outside the=20 >layer, certainly none political. > >Take care, >John > >At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote: > >>John, >> >I completely respect your NO. And indeed, it is=20 >not a requirement in order to be able to=20 >accomplish something (e.g. like routing).=20 >However, it is a political offer and does allow=20 >differentiating (filtering). And here we get to=20 >some other topics like political priorities. And=20 >I think we should understand such other=20 >priorities/issues/wishes. > > > >I also pointed out that -in my view a mistake -=20 >we merge technical operation into the address=20 >(unicast, anycast, multicast) which is neither=20 >necessary nor favorable and which can be handled=20 >better. > >However we should think about what else might be=20 >merged into an address because it is appropriate=20 >to do so. There are also other groups (ITU-T=20 >e.g.) which have developed some ideas on=20 >addresses. And also: New ideas and new arguments=20 >should be welcome. I am not a politician. But=20 >(who knows) maybe an address is also something=20 >to be protected/defended/scoped ? > > > >I can assure you: I do not know the right or the=20 >whole answer. But I think we should invite=20 >politicians to come up with their wishes, too. > > > >Heiner > > > > > >In einer eMail vom 28.11.2006 17:14:51=20 >Westeurop=E4ische Normalzeit schreibt=20 >jeanjour@comcast.net: > >At 0:38 -0800 2006/11/28, David Conrad wrote: >>Heiner, >> >>On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: >>>IMO the address should contain some part related to the individual >>>user, plus eventually also some address family characteristics ( >>>private, org, edu, gov,... ) and definitely some locating part >>>(ASN, geographic coordinates). Of course, only part of such an >>>address can be checksummed. >> >>People interested in privacy might have a few issues with this. > >I agree with David. And would go further, no way. This information >has nothing to do with an address. > >John > > > > > --============_-1047368472==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [arch-d] On scaling of flat identifier spaces (was Re:
Sure, discuss away.  However, license plates are not addresses.

Network addresses indicate "where" an entity is relative to the topology of the layer in which it occurs.  Not quite sure what might be political about that but I am sure a politician could find something.

Take care,
John

At 17:34 -0500 2006/11/28, HeinerHummel@aol.com wrote:
I am neither pro nor con. Things can be used and abused. I remember that in Florida license plate numbers of rented cars used to have some special character (X or Y, I am not sure).
Then several robberies incl. killing happened where visitors from abroad were the victims. Then policy was changed so that such an information cannot be derived anymore.
 
But I think this topic is worth to be discussed seriously.
 
Heiner
 
 
In einer eMail vom 28.11.2006 20:11:59 Westeurop=E4ische Normalzeit schreibt jeanjour@comcast.net:
Having played the electro-political engineering game for more than a few decades, I can assure you that if given the chance politicians will screw up anything they touch.  We are lucky in this case however, since there is absolutely no part of *addressing* that is political.  Any attempt otherwise is simply misguided.  (The same can not be said of application names, however.)

Addresses are topologically-dependent names whose use is internal to a layer.  There is never any need (in a well-formed architecture) for addresses to be visible to any but the internal machinery of the layer.  There is no rationale for them to have any other visibility to applications or anything else outside the layer, certainly none political.

Take care,
John

At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote:
John,
I completely respect your NO. And indeed, it is not a requirement in order to be able to accomplish something (e.g. like routing). However, it is a political offer and does allow differentiating (filtering). And here we get to some other topics like political priorities. And I think we should understand such other priorities/issues/wishes.
 
I also pointed out that -in my view a mistake - we merge technical operation into the address (unicast, anycast, multicast) which is neither necessary nor favorable and which can be handled better.
However we should think about what else might be merged into an address because it is appropriate to do so. There are also other groups (ITU-T e.g.) which have developed some ideas on addresses. And also: New ideas and new arguments should be welcome. I am not a politician. But (who knows) maybe an address is also something to be protected/defended/scoped ?
 
I can assure you: I do not know the right or the whole answer. But I think we should invite politicians to come up with their wishes, too.
 
Heiner
 
 
In einer eMail vom 28.11.2006 17:14:51 Westeurop=E4ische Normalzeit schreibt jeanjour@comcast.net:
At 0:38 -0800 2006/11/28, David Conrad wrote:
>Heiner,
>
>On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote:
>>IMO the address should contain some part related to the individual
>>user, plus eventually also some address family characteristics (
>>private, org, edu, gov,...  ) and definitely some locating part
>>(ASN, geographic coordinates). Of course, only part of such an
>>address can be checksummed.
>
>People interested in privacy might have a few issues with this.

I agree with David.  And would go further, no way.  This information
has nothing to do with an address.

John
 

 

--============_-1047368472==_ma============-- --===============0683840879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0683840879==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 17:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBjg-0000W2-2q; Tue, 28 Nov 2006 17:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBje-0000Vr-Sm for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:30 -0500 Received: from imo-m16.mx.aol.com ([64.12.138.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBje-0007gr-DG for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:30 -0500 Received: from HeinerHummel@aol.com by imo-m16.mx.aol.com (mail_out_v38_r7.6.) id r.ce5.4072751 (29672); Tue, 28 Nov 2006 17:47:13 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 28 Nov 2006 17:47:13 EST Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: pesherb@yahoo.com, drc@virtualized.org, Jim.Bound@hp.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0543788464==" Errors-To: architecture-discuss-bounces@ietf.org --===============0543788464== Content-Type: multipart/alternative; boundary="-----------------------------1164754033" -------------------------------1164754033 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Great. But there is a price to pay in routing. How to recognize the=20 egress-ISP ? What if ISP-A delivers to the ground floor whereas ISP-B deliv= ers to=20 the second floor of the same building ?=20 Therefore, I am still in favor of integrating at least the primary ISP's=20 ASN as well. =20 Heiner =20 In einer eMail vom 28.11.2006 20:50:01 Westeurop=E4ische Normalzeit schreibt= =20 pesherb@yahoo.com: > blurs the line between the two different functions of "identification =20 > of end point" and "location of network attachment" Just a thought: - person's name =3D ID - person's address =3D location (geo, topo, any physical) - ID does not change - location changes often to reach a person an envelope needs a combination: ID + location Could the same principle apply to a network: - ID's and locators are independent - Uniqueness realizes at the attachment point =3D ID + location Result - No dependency on a provider - No scaling problem because the routing table is fixed in a robust hierarc= hy Thank you, Peter --- David Conrad wrote: > Jim, >=20 > On Nov 23, 2006, at 9:39 PM, Bound, Jim wrote: > > Agree and that aggregation is important but will not always be =20 > > possible. >=20 > I agree that it won't always be possible. However, we have changed =20 > the Internet scaling characteristics from tending towards O(ISPs=20 > +enterprises+end users) to O(ISPs). As we have an existence proof =20 > that we can have over 200K entries with today's technology, I think =20 > we have some room to grow. >=20 > >> The whole point of this discussion is that the term "address" > >> as it is used today implies the concepts of identity and > >> location are merged. > > That is where I believe I disagree. >=20 > I think you misunderstood me as I believe we mostly agree. >=20 > > What Pekka N. proposed leaves this question > > open for now. If ISP1 has prefix for location as FFEE but ISP2 has > > prefix FEEF the aggregation is only for the first order bits (leaving > > undefined) and without more bits location cannot be known for routing. >=20 > Right. Since I do not believe it realistic to assume we can =20 > aggregate ISPs without changing ISP business models (which they are =20 > not particularly inclined to do), I'm implicitly assuming that each =20 > ISP would have their own prefix. That is, at the highest level of =20 > hierarchy, the locator space would be flat. >=20 > However, a nice aspect of separating identity from location (and =20 > providing a mapping function to translate between the two) is that in =20 > the future, we can rip out the location mechanism and replace it with =20 > something better without impacting the end users (in fact, they won't =20 > even have to know there has been a change), so if we discover the two-=20 > tiered approach doesn't scale enough for whatever reason, we can =20 > deploy a new/better solution much, much more easily. >=20 > > The identifier comes into play only for me between the two end-to-end > > applications, security enhancements, and transport end-points =20 > > possibly. >=20 > Yes. >=20 > > Whether that is part of an IP address with the locator for me is > > premature discussion and identifying the requirements. >=20 > As I've said previously, I don't like to use the term "address" as it =20 > blurs the line between the two different functions of "identification =20 > of end point" and "location of network attachment". These two =20 > functions can obviously be merged into a single bit string (albeit, I =20 > believe this will require changes to all deployed TCP/IP stacks which =20 > I'm skeptical we can do in any reasonable timeframe), but I believe =20 > it would be really helpful to keep the functions as conceptually =20 > distinct as possible. > =20 > Rgds, > -drc >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > =20 __________________________________ __________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1164754033 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Great.   But there is a price to pay in routing. How to=20 recognize the egress-ISP ? What if ISP-A delivers to the ground floor wherea= s=20 ISP-B delivers to the second floor of the same building ?
Therefore, I am still in favor of integrating at least the  primar= y=20 ISP's ASN as well.
 
Heiner
 
In einer eMail vom 28.11.2006 20:50:01 Westeurop=E4ische Normalzeit sch= reibt=20 pesherb@yahoo.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>>=20 blurs the line between the two different functions of "identification = ;=20
> of end point" and "location of network attachment"

Just a=20 thought:

- person's name =3D ID
- person's address =3D location=20= (geo,=20 topo, any physical)
- ID does not change
- location changes=20 often

to reach a person an envelope needs a combination: ID +=20 location

Could the same principle apply to a network:
- ID's and= =20 locators are independent
- Uniqueness realizes at the attachment point=20= =3D ID=20 + location

Result
- No dependency on a provider
- No scaling=20 problem because the routing table is fixed in a robust hierarchy

Th= ank=20 you,

Peter

--- David Conrad <drc@virtualized.org>=20 wrote:

> Jim,
>
> On Nov 23, 2006, at 9:39 PM, Boun= d,=20 Jim wrote:
> > Agree and that aggregation is important but will n= ot=20 always be 
> > possible.
>
> I agree that it w= on't=20 always be possible.  However, we have changed 
> the Inte= rnet=20 scaling characteristics from tending towards O(ISPs
> +enterprises+= end=20 users) to O(ISPs).  As we have an existence proof 
> that= we=20 can have over 200K entries with today's technology, I think 
>= we=20 have some room to grow.
>
> >> The whole point of this=20 discussion is that the term "address"
> >> as it is used today= =20 implies the concepts of identity and
> >> location are =20 merged.
> > That is where I believe I disagree.
>
>=20= I=20 think you misunderstood me as I believe we mostly agree.
>
>=20= >=20 What Pekka N. proposed leaves this question
> > open for now. If=20= ISP1=20 has prefix for location as FFEE but ISP2 has
> > prefix FEEF the=20 aggregation is only for the first order bits (leaving
> > undefin= ed)=20 and without more bits location cannot be known for routing.
>
&g= t;=20 Right.  Since I do not believe it realistic to assume we can =20
> aggregate ISPs without changing ISP business models (which they=20 are 
> not particularly inclined to do), I'm implicitly assumi= ng=20 that each 
> ISP would have their own prefix.  That is, a= t=20 the highest level of 
> hierarchy, the locator space would be=20 flat.
>
> However, a nice aspect of separating identity from=20 location (and 
> providing a mapping function to translate bet= ween=20 the two) is that in 
> the future, we can rip out the location= =20 mechanism and replace it with 
> something better without=20 impacting the end users (in fact, they won't 
> even have to k= now=20 there has been a change), so if we discover the two-
> tiered appro= ach=20 doesn't scale enough for whatever reason, we can 
> deploy a=20 new/better solution much, much more easily.
>
> > The=20 identifier comes into play only for me between the two end-to-end
>=20= >=20 applications, security enhancements, and transport end-points 
&g= t;=20 > possibly.
>
> Yes.
>
> > Whether that is= =20 part of an IP address with the locator for me is
> > premature=20 discussion and identifying the requirements.
>
> As I've said= =20 previously, I don't like to use the term "address" as it 
> bl= urs=20 the line between the two different functions of "identification 
= >=20 of end point" and "location of network attachment".  These two =20
> functions can obviously be merged into a single bit string (albei= t,=20 I 
> believe this will require changes to all deployed TCP/IP=20 stacks which 
> I'm skeptical we can do in any reasonable=20 timeframe), but I believe 
> it would be really helpful to kee= p=20 the functions as conceptually 
> distinct as possible.
>= =20
> Rgds,
> -drc
>
>
>=20 _______________________________________________
> Architecture-discu= ss=20 mailing list
> Architecture-discuss@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/architecture-discuss
>=20




______________________________________________________= ______________________________
Do=20 you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail=20 beta.
http://new.mail.yahoo.com

________________________________= _______________
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164754033-- --===============0543788464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0543788464==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 17:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBjH-0000Sp-Fs; Tue, 28 Nov 2006 17:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBjG-0000S8-NH for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:06 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBjG-0007bs-9M for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:06 -0500 Received: from [10.0.1.39] (failure[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006112822470401100rkhgme>; Tue, 28 Nov 2006 22:47:05 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <488.12bf4b26.329e1392@aol.com> References: <488.12bf4b26.329e1392@aol.com> Date: Tue, 28 Nov 2006 17:42:14 -0500 To: HeinerHummel@aol.com, jeanjour@comcast.net, drc@virtualized.org From: John Day Subject: Re: [arch-d] On scaling of flat identifier spaces (was Re: On identifiers: wh... X-Spam-Score: 0.1 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0683840879==" Errors-To: architecture-discuss-bounces@ietf.org --===============0683840879== Content-Type: multipart/alternative; boundary="============_-1047368472==_ma============" --============_-1047368472==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Sure, discuss away. However, license plates are not addresses. Network addresses indicate "where" an entity is=20 relative to the topology of the layer in which it=20 occurs. Not quite sure what might be political=20 about that but I am sure a politician could find=20 something. Take care, John At 17:34 -0500 2006/11/28, HeinerHummel@aol.com wrote: >I am neither pro nor con. Things can be used and=20 >abused. I remember that in Florida license plate=20 >numbers of rented cars used to have some special=20 >character (X or Y, I am not sure). >Then several robberies incl. killing happened=20 >where visitors from abroad were the victims.=20 >Then policy was changed so that such an=20 >information cannot be derived anymore. > >But I think this topic is worth to be discussed seriously. > >Heiner > > >In einer eMail vom 28.11.2006 20:11:59=20 >Westeurop=E4ische Normalzeit schreibt=20 >jeanjour@comcast.net: > >Having played the electro-political engineering=20 >game for more than a few decades, I can assure=20 >you that if given the chance politicians will=20 >screw up anything they touch. We are lucky in=20 >this case however, since there is absolutely no=20 >part of *addressing* that is political. Any=20 >attempt otherwise is simply misguided. (The=20 >same can not be said of application names,=20 >however.) > >Addresses are topologically-dependent names=20 >whose use is internal to a layer. There is=20 >never any need (in a well-formed architecture)=20 >for addresses to be visible to any but the=20 >internal machinery of the layer. There is no=20 >rationale for them to have any other visibility=20 >to applications or anything else outside the=20 >layer, certainly none political. > >Take care, >John > >At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote: > >>John, >> >I completely respect your NO. And indeed, it is=20 >not a requirement in order to be able to=20 >accomplish something (e.g. like routing).=20 >However, it is a political offer and does allow=20 >differentiating (filtering). And here we get to=20 >some other topics like political priorities. And=20 >I think we should understand such other=20 >priorities/issues/wishes. > > > >I also pointed out that -in my view a mistake -=20 >we merge technical operation into the address=20 >(unicast, anycast, multicast) which is neither=20 >necessary nor favorable and which can be handled=20 >better. > >However we should think about what else might be=20 >merged into an address because it is appropriate=20 >to do so. There are also other groups (ITU-T=20 >e.g.) which have developed some ideas on=20 >addresses. And also: New ideas and new arguments=20 >should be welcome. I am not a politician. But=20 >(who knows) maybe an address is also something=20 >to be protected/defended/scoped ? > > > >I can assure you: I do not know the right or the=20 >whole answer. But I think we should invite=20 >politicians to come up with their wishes, too. > > > >Heiner > > > > > >In einer eMail vom 28.11.2006 17:14:51=20 >Westeurop=E4ische Normalzeit schreibt=20 >jeanjour@comcast.net: > >At 0:38 -0800 2006/11/28, David Conrad wrote: >>Heiner, >> >>On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: >>>IMO the address should contain some part related to the individual >>>user, plus eventually also some address family characteristics ( >>>private, org, edu, gov,... ) and definitely some locating part >>>(ASN, geographic coordinates). Of course, only part of such an >>>address can be checksummed. >> >>People interested in privacy might have a few issues with this. > >I agree with David. And would go further, no way. This information >has nothing to do with an address. > >John > > > > > --============_-1047368472==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [arch-d] On scaling of flat identifier spaces (was Re:
Sure, discuss away.  However, license plates are not addresses.

Network addresses indicate "where" an entity is relative to the topology of the layer in which it occurs.  Not quite sure what might be political about that but I am sure a politician could find something.

Take care,
John

At 17:34 -0500 2006/11/28, HeinerHummel@aol.com wrote:
I am neither pro nor con. Things can be used and abused. I remember that in Florida license plate numbers of rented cars used to have some special character (X or Y, I am not sure).
Then several robberies incl. killing happened where visitors from abroad were the victims. Then policy was changed so that such an information cannot be derived anymore.
 
But I think this topic is worth to be discussed seriously.
 
Heiner
 
 
In einer eMail vom 28.11.2006 20:11:59 Westeurop=E4ische Normalzeit schreibt jeanjour@comcast.net:
Having played the electro-political engineering game for more than a few decades, I can assure you that if given the chance politicians will screw up anything they touch.  We are lucky in this case however, since there is absolutely no part of *addressing* that is political.  Any attempt otherwise is simply misguided.  (The same can not be said of application names, however.)

Addresses are topologically-dependent names whose use is internal to a layer.  There is never any need (in a well-formed architecture) for addresses to be visible to any but the internal machinery of the layer.  There is no rationale for them to have any other visibility to applications or anything else outside the layer, certainly none political.

Take care,
John

At 13:46 -0500 2006/11/28, HeinerHummel@aol.com wrote:
John,
I completely respect your NO. And indeed, it is not a requirement in order to be able to accomplish something (e.g. like routing). However, it is a political offer and does allow differentiating (filtering). And here we get to some other topics like political priorities. And I think we should understand such other priorities/issues/wishes.
 
I also pointed out that -in my view a mistake - we merge technical operation into the address (unicast, anycast, multicast) which is neither necessary nor favorable and which can be handled better.
However we should think about what else might be merged into an address because it is appropriate to do so. There are also other groups (ITU-T e.g.) which have developed some ideas on addresses. And also: New ideas and new arguments should be welcome. I am not a politician. But (who knows) maybe an address is also something to be protected/defended/scoped ?
 
I can assure you: I do not know the right or the whole answer. But I think we should invite politicians to come up with their wishes, too.
 
Heiner
 
 
In einer eMail vom 28.11.2006 17:14:51 Westeurop=E4ische Normalzeit schreibt jeanjour@comcast.net:
At 0:38 -0800 2006/11/28, David Conrad wrote:
>Heiner,
>
>On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote:
>>IMO the address should contain some part related to the individual
>>user, plus eventually also some address family characteristics (
>>private, org, edu, gov,...  ) and definitely some locating part
>>(ASN, geographic coordinates). Of course, only part of such an
>>address can be checksummed.
>
>People interested in privacy might have a few issues with this.

I agree with David.  And would go further, no way.  This information
has nothing to do with an address.

John
 

 

--============_-1047368472==_ma============-- --===============0683840879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0683840879==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 17:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBjg-0000W2-2q; Tue, 28 Nov 2006 17:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBje-0000Vr-Sm for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:30 -0500 Received: from imo-m16.mx.aol.com ([64.12.138.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBje-0007gr-DG for architecture-discuss@ietf.org; Tue, 28 Nov 2006 17:47:30 -0500 Received: from HeinerHummel@aol.com by imo-m16.mx.aol.com (mail_out_v38_r7.6.) id r.ce5.4072751 (29672); Tue, 28 Nov 2006 17:47:13 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 28 Nov 2006 17:47:13 EST Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: pesherb@yahoo.com, drc@virtualized.org, Jim.Bound@hp.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0543788464==" Errors-To: architecture-discuss-bounces@ietf.org --===============0543788464== Content-Type: multipart/alternative; boundary="-----------------------------1164754033" -------------------------------1164754033 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Great. But there is a price to pay in routing. How to recognize the=20 egress-ISP ? What if ISP-A delivers to the ground floor whereas ISP-B deliv= ers to=20 the second floor of the same building ?=20 Therefore, I am still in favor of integrating at least the primary ISP's=20 ASN as well. =20 Heiner =20 In einer eMail vom 28.11.2006 20:50:01 Westeurop=E4ische Normalzeit schreibt= =20 pesherb@yahoo.com: > blurs the line between the two different functions of "identification =20 > of end point" and "location of network attachment" Just a thought: - person's name =3D ID - person's address =3D location (geo, topo, any physical) - ID does not change - location changes often to reach a person an envelope needs a combination: ID + location Could the same principle apply to a network: - ID's and locators are independent - Uniqueness realizes at the attachment point =3D ID + location Result - No dependency on a provider - No scaling problem because the routing table is fixed in a robust hierarc= hy Thank you, Peter --- David Conrad wrote: > Jim, >=20 > On Nov 23, 2006, at 9:39 PM, Bound, Jim wrote: > > Agree and that aggregation is important but will not always be =20 > > possible. >=20 > I agree that it won't always be possible. However, we have changed =20 > the Internet scaling characteristics from tending towards O(ISPs=20 > +enterprises+end users) to O(ISPs). As we have an existence proof =20 > that we can have over 200K entries with today's technology, I think =20 > we have some room to grow. >=20 > >> The whole point of this discussion is that the term "address" > >> as it is used today implies the concepts of identity and > >> location are merged. > > That is where I believe I disagree. >=20 > I think you misunderstood me as I believe we mostly agree. >=20 > > What Pekka N. proposed leaves this question > > open for now. If ISP1 has prefix for location as FFEE but ISP2 has > > prefix FEEF the aggregation is only for the first order bits (leaving > > undefined) and without more bits location cannot be known for routing. >=20 > Right. Since I do not believe it realistic to assume we can =20 > aggregate ISPs without changing ISP business models (which they are =20 > not particularly inclined to do), I'm implicitly assuming that each =20 > ISP would have their own prefix. That is, at the highest level of =20 > hierarchy, the locator space would be flat. >=20 > However, a nice aspect of separating identity from location (and =20 > providing a mapping function to translate between the two) is that in =20 > the future, we can rip out the location mechanism and replace it with =20 > something better without impacting the end users (in fact, they won't =20 > even have to know there has been a change), so if we discover the two-=20 > tiered approach doesn't scale enough for whatever reason, we can =20 > deploy a new/better solution much, much more easily. >=20 > > The identifier comes into play only for me between the two end-to-end > > applications, security enhancements, and transport end-points =20 > > possibly. >=20 > Yes. >=20 > > Whether that is part of an IP address with the locator for me is > > premature discussion and identifying the requirements. >=20 > As I've said previously, I don't like to use the term "address" as it =20 > blurs the line between the two different functions of "identification =20 > of end point" and "location of network attachment". These two =20 > functions can obviously be merged into a single bit string (albeit, I =20 > believe this will require changes to all deployed TCP/IP stacks which =20 > I'm skeptical we can do in any reasonable timeframe), but I believe =20 > it would be really helpful to keep the functions as conceptually =20 > distinct as possible. > =20 > Rgds, > -drc >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > =20 __________________________________ __________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1164754033 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Great.   But there is a price to pay in routing. How to=20 recognize the egress-ISP ? What if ISP-A delivers to the ground floor wherea= s=20 ISP-B delivers to the second floor of the same building ?
Therefore, I am still in favor of integrating at least the  primar= y=20 ISP's ASN as well.
 
Heiner
 
In einer eMail vom 28.11.2006 20:50:01 Westeurop=E4ische Normalzeit sch= reibt=20 pesherb@yahoo.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>>=20 blurs the line between the two different functions of "identification = ;=20
> of end point" and "location of network attachment"

Just a=20 thought:

- person's name =3D ID
- person's address =3D location=20= (geo,=20 topo, any physical)
- ID does not change
- location changes=20 often

to reach a person an envelope needs a combination: ID +=20 location

Could the same principle apply to a network:
- ID's and= =20 locators are independent
- Uniqueness realizes at the attachment point=20= =3D ID=20 + location

Result
- No dependency on a provider
- No scaling=20 problem because the routing table is fixed in a robust hierarchy

Th= ank=20 you,

Peter

--- David Conrad <drc@virtualized.org>=20 wrote:

> Jim,
>
> On Nov 23, 2006, at 9:39 PM, Boun= d,=20 Jim wrote:
> > Agree and that aggregation is important but will n= ot=20 always be 
> > possible.
>
> I agree that it w= on't=20 always be possible.  However, we have changed 
> the Inte= rnet=20 scaling characteristics from tending towards O(ISPs
> +enterprises+= end=20 users) to O(ISPs).  As we have an existence proof 
> that= we=20 can have over 200K entries with today's technology, I think 
>= we=20 have some room to grow.
>
> >> The whole point of this=20 discussion is that the term "address"
> >> as it is used today= =20 implies the concepts of identity and
> >> location are =20 merged.
> > That is where I believe I disagree.
>
>=20= I=20 think you misunderstood me as I believe we mostly agree.
>
>=20= >=20 What Pekka N. proposed leaves this question
> > open for now. If=20= ISP1=20 has prefix for location as FFEE but ISP2 has
> > prefix FEEF the=20 aggregation is only for the first order bits (leaving
> > undefin= ed)=20 and without more bits location cannot be known for routing.
>
&g= t;=20 Right.  Since I do not believe it realistic to assume we can =20
> aggregate ISPs without changing ISP business models (which they=20 are 
> not particularly inclined to do), I'm implicitly assumi= ng=20 that each 
> ISP would have their own prefix.  That is, a= t=20 the highest level of 
> hierarchy, the locator space would be=20 flat.
>
> However, a nice aspect of separating identity from=20 location (and 
> providing a mapping function to translate bet= ween=20 the two) is that in 
> the future, we can rip out the location= =20 mechanism and replace it with 
> something better without=20 impacting the end users (in fact, they won't 
> even have to k= now=20 there has been a change), so if we discover the two-
> tiered appro= ach=20 doesn't scale enough for whatever reason, we can 
> deploy a=20 new/better solution much, much more easily.
>
> > The=20 identifier comes into play only for me between the two end-to-end
>=20= >=20 applications, security enhancements, and transport end-points 
&g= t;=20 > possibly.
>
> Yes.
>
> > Whether that is= =20 part of an IP address with the locator for me is
> > premature=20 discussion and identifying the requirements.
>
> As I've said= =20 previously, I don't like to use the term "address" as it 
> bl= urs=20 the line between the two different functions of "identification 
= >=20 of end point" and "location of network attachment".  These two =20
> functions can obviously be merged into a single bit string (albei= t,=20 I 
> believe this will require changes to all deployed TCP/IP=20 stacks which 
> I'm skeptical we can do in any reasonable=20 timeframe), but I believe 
> it would be really helpful to kee= p=20 the functions as conceptually 
> distinct as possible.
>= =20
> Rgds,
> -drc
>
>
>=20 _______________________________________________
> Architecture-discu= ss=20 mailing list
> Architecture-discuss@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/architecture-discuss
>=20




______________________________________________________= ______________________________
Do=20 you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail=20 beta.
http://new.mail.yahoo.com

________________________________= _______________
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164754033-- --===============0543788464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0543788464==-- From architecture-discuss-bounces@ietf.org Tue Nov 28 22:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFjX-0001wZ-Tl; Tue, 28 Nov 2006 22:03:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFjX-0001wU-0b for architecture-discuss@ietf.org; Tue, 28 Nov 2006 22:03:39 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpFjT-0006yV-I4 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 22:03:38 -0500 Received: from afrinic5-55.afrinic.net (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAT2wvrG097619; Tue, 28 Nov 2006 18:59:28 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by afrinic5-55.afrinic.net (PGP Universal service); Tue, 28 Nov 2006 19:03:20 -0800 X-PGP-Universal: processed; by afrinic5-55.afrinic.net on Tue, 28 Nov 2006 19:03:20 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0D807014-B0B7-4AF9-A2F5-666973370C03@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Tue, 28 Nov 2006 19:02:47 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Heiner, On Nov 28, 2006, at 2:47 PM, HeinerHummel@aol.com wrote: > Therefore, I am still in favor of integrating at least the primary > ISP's ASN as well. What happens when you change the 'primary ISP", keeping in mind that the current socket APIs result in applications caching the "address" within the running application itself (struct sockaddr) and people need to transcribe "addresses" into firewall, DNS, and other services? Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 22:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFw5-0005jE-Kl; Tue, 28 Nov 2006 22:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpFw4-0005f9-Q4 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 22:16:36 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpFw3-0000fK-Ez for architecture-discuss@ietf.org; Tue, 28 Nov 2006 22:16:36 -0500 Received: from afrinic5-55.afrinic.net (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kAT3C9rG097650; Tue, 28 Nov 2006 19:12:24 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by afrinic5-55.afrinic.net (PGP Universal service); Tue, 28 Nov 2006 19:16:16 -0800 X-PGP-Universal: processed; by afrinic5-55.afrinic.net on Tue, 28 Nov 2006 19:16:16 -0800 In-Reply-To: References: <437164.85404.qm@web58703.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <818019A2-F508-450F-984C-1C043B21E2BE@virtualized.org> From: David Conrad Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Tue, 28 Nov 2006 19:16:00 -0800 To: John Day X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, A quibble: On Nov 28, 2006, at 12:15 PM, John Day wrote: > Saltzer concludes rightly, that a network architecture requires at > a minimum application names, node addresses, and point of > attachment addresses. The current Internet has only the latter. No. The Internet has all three. The problem is that these three namespaces are overloaded onto the same bit string, resulting in significant loss of functionality and greatly limiting scalability. I suspect what you meant to say was something along the lines of "a scalable network architecture requires at a minimum separate application names, node addresses, and point of attachment addresses." Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 28 22:47:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGPY-0003Gm-VI; Tue, 28 Nov 2006 22:47:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGPY-0003Gd-1q for architecture-discuss@ietf.org; Tue, 28 Nov 2006 22:47:04 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpGPW-0006hi-R6 for architecture-discuss@ietf.org; Tue, 28 Nov 2006 22:47:04 -0500 Received: from [10.0.1.39] (failure[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061129034701b1400phft6e>; Wed, 29 Nov 2006 03:47:02 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <818019A2-F508-450F-984C-1C043B21E2BE@virtualized.org> References: <437164.85404.qm@web58703.mail.re1.yahoo.com> <818019A2-F508-450F-984C-1C043B21E2BE@virtualized.org> Date: Tue, 28 Nov 2006 22:36:44 -0500 To: David Conrad , John Day From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I will quibble with your quibble. ;-) The Internet was built with only one of them. Over the past 30 years, the Internet has tried one band-aid, kludge and hack after another to try to avoid actually fixing the problem, yielding your perception that it has all 3 one bit string. It remains that that bit string only names one thing: the interface. Isn't it interesting that the *Internet* address names a subnet point of attachment? A little cognitive dissonance. Harkens to what one might expect from a bellhead rather than netizen, doesn't it? Maybe we never finished the paradigm shift. At 19:16 -0800 2006/11/28, David Conrad wrote: >John, > >A quibble: > >On Nov 28, 2006, at 12:15 PM, John Day wrote: >>Saltzer concludes rightly, that a network architecture requires at >>a minimum application names, node addresses, and point of >>attachment addresses. The current Internet has only the latter. > >No. The Internet has all three. The problem is that these three >namespaces are overloaded onto the same bit string, resulting in >significant loss of functionality and greatly limiting scalability. >I suspect what you meant to say was something along the lines of "a >scalable network architecture requires at a minimum separate >application names, node addresses, and point of attachment >addresses." > >Rgds, >-drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 02:58:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKIm-0005gF-J8; Wed, 29 Nov 2006 02:56:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpKIm-0005gA-0A for architecture-discuss@ietf.org; Wed, 29 Nov 2006 02:56:20 -0500 Received: from imo-d21.mx.aol.com ([205.188.144.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpKIk-0000sZ-O7 for architecture-discuss@ietf.org; Wed, 29 Nov 2006 02:56:19 -0500 Received: from HeinerHummel@aol.com by imo-d21.mx.aol.com (mail_out_v38_r7.6.) id b.cd4.2ebc3e0 (29679); Wed, 29 Nov 2006 02:56:02 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Wed, 29 Nov 2006 02:56:01 EST Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: drc@virtualized.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1630552341==" Errors-To: architecture-discuss-bounces@ietf.org --===============1630552341== Content-Type: multipart/alternative; boundary="-----------------------------1164786961" -------------------------------1164786961 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 You are right. I only wanted to be cautious.=20 Nowadays i.e. in Ebay-times I can observe every now and then a different =20 postal service car curving around: Deutsche Post, DHL, UPS, Hermes,...They a= ll =20 manage to deliver without a primary postal service provider written on the =20 envelopes and packages. =20 I like this more ambitious goal "without primary ISP's ASN". =20 Heiner =20 =20 =20 In einer eMail vom 29.11.2006 04:06:02 Westeurop=E4ische Normalzeit schreibt= =20 drc@virtualized.org: Heiner, On Nov 28, 2006, at 2:47 PM, HeinerHummel@aol.com wrote: > Therefore, I am still in favor of integrating at least the primary =20 > ISP's ASN as well. What happens when you change the 'primary ISP", keeping in mind that =20 the current socket APIs result in applications caching the "address" =20 within the running application itself (struct sockaddr) and people =20 need to transcribe "addresses" into firewall, DNS, and other services? Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1164786961 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
You are right. I only wanted to be cautious.
Nowadays i.e. in Ebay-times I can observe every now and then a differen= t=20 postal service car curving around: Deutsche Post, DHL, UPS, Hermes,...They a= ll=20 manage to deliver without a primary postal service provider written on the=20 envelopes and packages.
 
I like this more ambitious goal "without primary ISP's ASN".
 
Heiner
 
 
 
In einer eMail vom 29.11.2006 04:06:02 Westeurop=E4ische Normalzeit sch= reibt=20 drc@virtualized.org:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>Heiner,

On Nov 28, 2006, at 2:47 PM, HeinerHummel@aol.com=20 wrote:
> Therefore, I am still in favor of integrating at least=20 the  primary 
> ISP's ASN as well.

What happens wh= en=20 you change the 'primary ISP", keeping in mind that 
the current=20 socket APIs result in applications caching the "address" 
within=20= the=20 running application itself (struct sockaddr) and people 
need to=20 transcribe "addresses" into firewall, DNS, and other=20 services?

Rgds,
-drc


________________________________= _______________
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164786961-- --===============1630552341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1630552341==-- From architecture-discuss-bounces@ietf.org Wed Nov 29 10:59:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRpA-0002oJ-7G; Wed, 29 Nov 2006 10:58:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRp8-0002nu-Cb for architecture-discuss@ietf.org; Wed, 29 Nov 2006 10:58:14 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRoe-0005ul-Ne for architecture-discuss@ietf.org; Wed, 29 Nov 2006 10:58:14 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 08C5E34172; Wed, 29 Nov 2006 10:57:49 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 10:57:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Wed, 29 Nov 2006 10:57:40 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCFF311F@tayexc14.americas.cpqcorp.net> In-Reply-To: <866E00AF-B2B4-40F7-B245-366A4ACA9994@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccS70Obb/u68Wv7QdSOZOxnkeHVeAA3kOMA From: "Bound, Jim" To: "David Conrad" X-OriginalArrivalTime: 29 Nov 2006 15:57:42.0854 (UTC) FILETIME=[1A95EE60:01C713CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dave, Good responses. How I want to respond now I think supports the abstract view and assumptions from Pekka N. and Brian C. concerns for optimizations to continue to work on the Internet (as I paraphrase multiple conversations). Also we are in complete synch on the benefits of aggregation below. I leave your mail in tact below I hope that works for readers of the thread I am never sure when to reduce the text in a thread? 1. If we are not going to call the "thing" that sits in the IP header as src and dst address can we please pick a reference point for these I think that will help us not enter forever do-loop for analysis and discussion. A suggestion route-identifiers (RI). What I like about this and why I suggest it is I think end-to-end identifiers may be different and become EIs. But we need a term other than address for routing it seems to me. 2. Regarding the RI or the identifier in conjunction with location: a. I do not believe we can assume the Internet will work or any network with billions of transactions if router-infrastructure (that can mean many things and not just routers) have to do a DNS, LDAP, or other name-space to be invented look-up on the identifiers within the location-ID (RI). So as implementer I am highly concerned we address this issue sooner rather than later in the model discussion. b. Given seamless mobility which to me is the node changes its location coordinates to a new routing area with different high-order aggregation first order bits, I don't see how it can be avoided to report that new RI back to the Home Agent, Nemo Router, etc. Thus I do believe in and buy into the current IETF RFCs for Network Mobility and that should be transparent to the work here. This I think is important to the model discussion and any assumptions about mobility or nomadicity. Thus I would be happy camper at this point if we could adopt a new name for address such as RI, determine how the identifier will be used for routing (different than the EI), and what are our initial thoughts on impact to mobility. =20 At least as a start for this point from our threads. Best, /jim > -----Original Message----- > From: David Conrad [mailto:drc@virtualized.org]=20 > Sent: Tuesday, November 28, 2006 4:03 AM > To: Bound, Jim > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] On identifiers: what is virtual and=20 > what is global (wasRe: thou... >=20 > Jim, >=20 > On Nov 23, 2006, at 9:39 PM, Bound, Jim wrote: > > Agree and that aggregation is important but will not always be=20 > > possible. >=20 > I agree that it won't always be possible. However, we have=20 > changed the Internet scaling characteristics from tending=20 > towards O(ISPs=20 > +enterprises+end users) to O(ISPs). As we have an existence proof > that we can have over 200K entries with today's technology, I=20 > think we have some room to grow. >=20 > >> The whole point of this discussion is that the term "address" > >> as it is used today implies the concepts of identity and=20 > location are =20 > >> merged. > > That is where I believe I disagree. >=20 > I think you misunderstood me as I believe we mostly agree. >=20 > > What Pekka N. proposed leaves this question open for now.=20 > If ISP1 has=20 > > prefix for location as FFEE but ISP2 has prefix FEEF the=20 > aggregation=20 > > is only for the first order bits (leaving > > undefined) and without more bits location cannot be known=20 > for routing. >=20 > Right. Since I do not believe it realistic to assume we can=20 > aggregate ISPs without changing ISP business models (which=20 > they are not particularly inclined to do), I'm implicitly=20 > assuming that each ISP would have their own prefix. That is,=20 > at the highest level of hierarchy, the locator space would be flat. >=20 > However, a nice aspect of separating identity from location=20 > (and providing a mapping function to translate between the=20 > two) is that in the future, we can rip out the location=20 > mechanism and replace it with something better without=20 > impacting the end users (in fact, they won't even have to=20 > know there has been a change), so if we discover the two-=20 > tiered approach doesn't scale enough for whatever reason, we=20 > can deploy a new/better solution much, much more easily. >=20 > > The identifier comes into play only for me between the two=20 > end-to-end=20 > > applications, security enhancements, and transport end-points=20 > > possibly. >=20 > Yes. >=20 > > Whether that is part of an IP address with the locator for me is=20 > > premature discussion and identifying the requirements. >=20 > As I've said previously, I don't like to use the term=20 > "address" as it blurs the line between the two different=20 > functions of "identification of end point" and "location of=20 > network attachment". These two functions can obviously be=20 > merged into a single bit string (albeit, I believe this will=20 > require changes to all deployed TCP/IP stacks which I'm=20 > skeptical we can do in any reasonable timeframe), but I=20 > believe it would be really helpful to keep the functions as=20 > conceptually distinct as possible. >=20 > Rgds, > -drc >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 11:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRsB-0003Z7-Ls; Wed, 29 Nov 2006 11:01:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRsA-0003Yt-MP for architecture-discuss@ietf.org; Wed, 29 Nov 2006 11:01:22 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRrq-0006Wt-2n for architecture-discuss@ietf.org; Wed, 29 Nov 2006 11:01:22 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id B919434196; Wed, 29 Nov 2006 11:01:01 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 11:01:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On scaling of flat identifier spaces (was Re: Onidentifiers: wh... Date: Wed, 29 Nov 2006 11:00:59 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCFF312B@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On scaling of flat identifier spaces (was Re: Onidentifiers: wh... Thread-Index: AccTCIhs14N2WlLuQy6xhoKjV1exBwAxpyAg From: "Bound, Jim" To: "John Day" , "David Conrad" , X-OriginalArrivalTime: 29 Nov 2006 16:01:01.0131 (UTC) FILETIME=[90C499B0:01C713CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: pekka.nikander@nomadiclab.com, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I don't agree an identifier to assist with routing path should be the same as end-to-end identifiers at all. The privacy and security ramifications are to wide and dangerous. I want to be able at some point in time world wide to be able to encrypt the packet from my mobile node so the only thing exposed in the clear is the IP header and any options and everything else is simply not available to routers, network node managers, mid-com boxes, etc as a tool to move my packet across the Internet. Putting my identity in the src and dst address of my IP header is not acceptable. Best, /jim > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Tuesday, November 28, 2006 11:14 AM > To: David Conrad; HeinerHummel@aol.com > Cc: pekka.nikander@nomadiclab.com;=20 > architecture-discuss@ietf.org; jeanjour@comcast.net > Subject: Re: [arch-d] On scaling of flat identifier spaces=20 > (was Re: Onidentifiers: wh... >=20 > At 0:38 -0800 2006/11/28, David Conrad wrote: > >Heiner, > > > >On Nov 27, 2006, at 1:34 AM, HeinerHummel@aol.com wrote: > >>IMO the address should contain some part related to the individual=20 > >>user, plus eventually also some address family characteristics (=20 > >>private, org, edu, gov,... ) and definitely some locating=20 > part (ASN,=20 > >>geographic coordinates). Of course, only part of such an=20 > address can=20 > >>be checksummed. > > > >People interested in privacy might have a few issues with this. >=20 > I agree with David. And would go further, no way. This=20 > information has nothing to do with an address. >=20 > John >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 13:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUb1-0000Rv-Bg; Wed, 29 Nov 2006 13:55:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpUb0-0000Rq-GK for architecture-discuss@ietf.org; Wed, 29 Nov 2006 13:55:50 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpUay-00023D-W1 for architecture-discuss@ietf.org; Wed, 29 Nov 2006 13:55:50 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 243194AC9C; Wed, 29 Nov 2006 13:55:45 -0500 (EST) Date: Wed, 29 Nov 2006 13:55:45 -0500 From: John Leslie To: "Bound, Jim" Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Message-ID: <20061129185545.GA2467@verdi> References: <866E00AF-B2B4-40F7-B245-366A4ACA9994@virtualized.org> <816DD9299957E547B5D758D7F977D6DCFF311F@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <816DD9299957E547B5D758D7F977D6DCFF311F@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bound, Jim wrote: > > 1. If we are not going to call the "thing" that sits in the IP header > as src and dst address can we please pick a reference point for these I strongly recommend that we call the "thing" that sits in the IPv4 header as destination address an "IPv4 destination address", and the "thing" that sits in the IPv6 header as a destination address an "IPv6 destination address". That, after all is exactly and _only_ what they are. (The "things" which sit in those headers as source addresses are something else entirely, I agree; and I'm open to any suggestions...) IPv4 and IPv6 are, after all, protocols for sending packets to addresses which may be on a different network. IPv4 and IPv6 destination addresses, except for the trivial case where the address can be shown to be on the same network, are opaque strings to be passed to a gateway "closer" to the destination. Thus, they are not "locators" in the general case to the forwarders that must process them -- they are only "locators" to routers which have a "complete" view of internetworking routes. (The actual parameters passed to operating systems to open TCP sockets and connections are _also_ something else entirely: we must not confuse TCP endpoints with IPvN destination addresses.) I quite agree with John Day that these "things" are "point of attachment" addresses; not "node addresses" or "application names". TCP, alas, tends to use them as if they were node addresses. :^( (One could argue, indeed, that the IPvN "source address" is in fact a "node address", but I'd rather steer clear of that flamewar...) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 15:49:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWLk-0000gG-DU; Wed, 29 Nov 2006 15:48:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWLj-0000g4-Gf for architecture-discuss@ietf.org; Wed, 29 Nov 2006 15:48:11 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWLe-0002tz-7H for architecture-discuss@ietf.org; Wed, 29 Nov 2006 15:48:11 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id EAAC43410D; Wed, 29 Nov 2006 15:48:05 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 15:48:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Wed, 29 Nov 2006 15:48:04 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCFF33E5@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061129185545.GA2467@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccT6AXKQvaO+0pITZulqItsVnOE+gADjAlQ From: "Bound, Jim" To: "John Leslie" X-OriginalArrivalTime: 29 Nov 2006 20:48:05.0687 (UTC) FILETIME=[AB674470:01C713F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I right now agree with your input. Two points I do want to note for discussion are what is passed to transport connections are end-to-end identifiers in my view and should not be exposed in the IPvN headers or used for loc+id. Also on source addresses my pain has been if they get altered then I am unclear how I respond back at the OS transport end. But if I am no longer using the notion of a current source address at the transport end I don't care about that anymore and if that is possible that is a good thing. I believe shim6 and hip get us very close to this model for the transport with current architecturs and specifications. NB: In particular not for this thread it opens up brand new use of ingress/egress filtering, use of anycast address concepts for deployment, and moves us to using an identifier for IPsec, but will need that provided to the dst entity in some form or derived from what is in the IPvN header and that still gets complex. I am assuming all but the IPvN header and possibly options with IPv6 are encrypted. Though we can continue to use the IPvN dst address for IPsec and tackle that problem later but make note to ietf-arch-self it is a problem now. Best, /jim=20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Wednesday, November 29, 2006 1:56 PM > To: Bound, Jim > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] On identifiers: what is virtual and=20 > what is global (wasRe: thou... >=20 > Bound, Jim wrote: > >=20 > > 1. If we are not going to call the "thing" that sits in the=20 > IP header > > as src and dst address can we please pick a reference point for=20 > > these >=20 > I strongly recommend that we call the "thing" that sits in=20 > the IPv4 header as destination address an "IPv4 destination=20 > address", and the "thing" that sits in the IPv6 header as a=20 > destination address an > "IPv6 destination address". That, after all is exactly and=20 > _only_ what they are. >=20 > (The "things" which sit in those headers as source=20 > addresses are something else entirely, I agree; and I'm open=20 > to any suggestions...) >=20 > IPv4 and IPv6 are, after all, protocols for sending=20 > packets to addresses which may be on a different network.=20 > IPv4 and IPv6 destination addresses, except for the trivial=20 > case where the address can be shown to be on the same=20 > network, are opaque strings to be passed to a gateway=20 > "closer" to the destination. >=20 > Thus, they are not "locators" in the general case to the=20 > forwarders that must process them -- they are only "locators"=20 > to routers which have a "complete" view of internetworking routes. >=20 > (The actual parameters passed to operating systems to open=20 > TCP sockets and connections are _also_ something else=20 > entirely: we must not confuse TCP endpoints with IPvN=20 > destination addresses.) >=20 > I quite agree with John Day that these "things" are "point=20 > of attachment" addresses; not "node addresses" or "application names". > TCP, alas, tends to use them as if they were node addresses. :^( >=20 > (One could argue, indeed, that the IPvN "source address"=20 > is in fact a "node address", but I'd rather steer clear of=20 > that flamewar...) >=20 > -- > John Leslie >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 16:13:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWix-0000Pe-Kt; Wed, 29 Nov 2006 16:12:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWiw-0000PY-1x for architecture-discuss@ietf.org; Wed, 29 Nov 2006 16:12:10 -0500 Received: from web58708.mail.re1.yahoo.com ([66.196.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpWiu-0006Ik-Lv for architecture-discuss@ietf.org; Wed, 29 Nov 2006 16:12:10 -0500 Received: (qmail 21096 invoked by uid 60001); 29 Nov 2006 21:12:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bTWkV2aID/KMv3XOWPRVKCAhfWCAjs2slKlJcNnCsQ3W4BClZNaszOH9nBYfuucP8MaFbnK2g5LtPheO/NGRpfpOCZ8DEM1iOyAhaoVCTE4NHXff+YwVFQqzkLzzBE2qflq4y17Jj4qgRdUfCvozidBRMv+yz7iZgtcG9HOzRqY=; X-YMail-OSG: yjy9JyAVM1nM9sCM4sWgp20bTDY3gOK7AwrfkOhMujJggnLmVpDdINATkahHOllX0Pe1m6xLDMjVz6OeX4ZQm0oERxXR0I2Jk2j1mznSu1NyDBiEMYlpFlb_.2Fh4fo5xpi8ljWV8wkLAOvursM8nZZ00aEkWcquEH4Pxs8lhEVD_oicPOGQYpH3yO8- Received: from [207.107.50.100] by web58708.mail.re1.yahoo.com via HTTP; Wed, 29 Nov 2006 13:12:06 PST Date: Wed, 29 Nov 2006 13:12:06 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: John Day , David Conrad , "Bound, Jim" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <484534.19606.qm@web58708.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > RFC 1498 Saltzer identifies 4 network objects: 1.Service/aka Application; 2.Node; 3.Network Attachment Point/aka Interface; 4.Path Routing only needs a unique Interface, which reduces objects to 2: 1.Interface and 2.Path. But too many nets to remember still choke routers. Could the split work as follows: - AS hierarchy constructs a backbone - Providers get AS numbers bound to a given physical space - EU get IPv6 addresses bound to a given physical space - no change for routing on private networks - for public routing a source and a destination addresses must add ASN - when a mobile interface attaches to a foreign AS it already knows its home ASN to reach its home node(s) - receiving node learns about sending node's ASN and establishes communication There are some limitations: - unless a mobile node on a foreign AS sends a packet, home node does not know where the mobile node is - private networks who want to communicate have to acquire each other ASN in advance and put them into destination address - scalability of AS hierarchy - scalability of routing within AS Thanks, Peter ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 16:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpX9b-0002bF-El; Wed, 29 Nov 2006 16:39:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpX9a-0002b6-8p for architecture-discuss@ietf.org; Wed, 29 Nov 2006 16:39:42 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpX9Z-0000zC-0y for architecture-discuss@ietf.org; Wed, 29 Nov 2006 16:39:42 -0500 Received: from [10.0.1.39] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <20061129213939014006hga8e>; Wed, 29 Nov 2006 21:39:40 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <484534.19606.qm@web58708.mail.re1.yahoo.com> References: <484534.19606.qm@web58708.mail.re1.yahoo.com> Date: Wed, 29 Nov 2006 16:36:35 -0500 To: Peter Sherbin , John Day , David Conrad , "Bound, Jim" From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 13:12 -0800 2006/11/29, Peter Sherbin wrote: > > RFC 1498 > >Saltzer identifies 4 network objects: >1.Service/aka Application; 2.Node; 3.Network Attachment Point/aka >Interface; 4.Path > >Routing only needs a unique Interface, which reduces objects to 2: >1.Interface and >2.Path. But too many nets to remember still choke routers. Actually he says routes, not paths. And he says that application names map to node addresses and node addresses are mapped to point of attachment addresses which are mapped to routes. But this is where he goes a bit astray (and understandably) because at the time he wrote there were no cases (or very very few) of multiple paths to the next hop. SO, if you adjust his model for that: Application names are mapped to node addresses by a directory. Routes are calculated from node addresses. From the routing calculation, you determine the next hop. Then you need the mapping of node address to point of attachment address for all of your nearest neighbors. From this, a subset gives you know all of the possible paths from this point to the next hop, so by some criteria you choose one. It is fundamentally a two step process. Now notice something interesting. The mapping of application names to node addresses and the mapping of node addresses to points of attachments for all nearest neighbors are essentially the same mapping. They are both all mappings one hop away. Hmmmm. > >Could the split work as follows: >- AS hierarchy constructs a backbone >- Providers get AS numbers bound to a given physical space >- EU get IPv6 addresses bound to a given physical space >- no change for routing on private networks >- for public routing a source and a destination addresses must add ASN >- when a mobile interface attaches to a foreign AS it already knows >its home ASN to >reach its home node(s) >- receiving node learns about sending node's ASN and establishes communication You are looking for a kludge. This is the arch-d list. We are looking for the right solution. Then we will worry about how to get there. Once you know where you are going, it will be easier to figure out how to get there. Don't skip steps. You will drop a sign or worse! (metaphorically). > >There are some limitations: >- unless a mobile node on a foreign AS sends a packet, home node >does not know where >the mobile node is >- private networks who want to communicate have to acquire each >other ASN in advance >and put them into destination address >- scalability of AS hierarchy >- scalability of routing within AS These are all show stoppers. I would suggest that a more interesting exercise is to answer the following questions: what protocol carries the point of attachment address? what protocol carries the node address? what protocol carries the application name? For the whole thing to work, they must be managed independently. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 16:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXLs-00062p-4j; Wed, 29 Nov 2006 16:52:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXLq-0005vI-Ps for architecture-discuss@ietf.org; Wed, 29 Nov 2006 16:52:22 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXLp-0002ew-HO for architecture-discuss@ietf.org; Wed, 29 Nov 2006 16:52:22 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id BD9F74AC6E; Wed, 29 Nov 2006 16:52:19 -0500 (EST) Date: Wed, 29 Nov 2006 16:52:19 -0500 From: John Leslie To: "Bound, Jim" Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Message-ID: <20061129215219.GB2467@verdi> References: <20061129185545.GA2467@verdi> <816DD9299957E547B5D758D7F977D6DCFF33E5@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <816DD9299957E547B5D758D7F977D6DCFF33E5@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bound, Jim wrote: >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly recommend that we call the "thing" that sits in >> the IPv4 header as destination address an "IPv4 destination >> address", and the "thing" that sits in the IPv6 header as a >> destination address an "IPv6 destination address". >>... >> (The actual parameters passed to operating systems to open >> TCP sockets and connections are _also_ something else >> entirely: we must not confuse TCP endpoints with IPvN >> destination addresses.) > > Two points I do want to note for discussion are > > what is passed to transport connections are end-to-end identifiers > in my view and should not be exposed in the IPvN headers or used > for loc+id. I agree they are end-to-end identifiers, even if they look exactly like IPvN addresses. That they currently are exposed in IPvN headers is an accident of history: TCP never defined a standard for exchanging anything else as endpoint identifiers. (Clearly, both ends of a TCP connection need to agree how to distinguish that a packet belongs to that connection: IPvN addresses have worked OK for that purpose. Endpoint identifiers _could_ be something else entirely; and need not be visible at all to the IPvN layer.) We must allow _something_ to be used for loc+id within IPvN; but it'd be fine if, for example, the application passed FQDNs as the endpoint IDs and the operating system did a DNS-like query to find loc+id. > Also on source addresses my pain has been if they get altered then > I am unclear how I respond back at the OS transport end. This is indeed a mess right now. NAT boxes routinely alter these and "try" to maintain enough state to alter them back. :*( > But if I am no longer using the notion of a current source address > at the transport end I don't care about that anymore and if that is > possible that is a good thing. IPvN source addresses are used to report routing problems: other than that, they can mostly be ignored. (Indeed, they can't even be trusted for that much: the less we depend on them, the better.) (There was a time when we believed routing based on source address would help. Most of us would like to bury that idea...) > I believe shim6 and hip get us very close to this model for the > transport with current architecturs and specifications. I must admit that I view both shim6 and hip as moving targets trying to be too many things to too many people. I suspect I'm not alone. In any case, both of those are engineering, not architecture; for purposes of this list I suggest explaining which features of them you'd like to compare, rather than just naming a protocol. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 20:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpb8T-0002bB-J7; Wed, 29 Nov 2006 20:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpb8S-0002JF-SY for architecture-discuss@ietf.org; Wed, 29 Nov 2006 20:54:48 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpb6f-0007YL-RQ for architecture-discuss@ietf.org; Wed, 29 Nov 2006 20:53:03 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 79DCB340D4; Wed, 29 Nov 2006 20:52:57 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 20:49:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Wed, 29 Nov 2006 20:49:50 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCFF3573@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061129215219.GB2467@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccUAKnotXERqNixQNuDeDV+dnJXRgAIItDA From: "Bound, Jim" To: "John Leslie" X-OriginalArrivalTime: 30 Nov 2006 01:49:52.0047 (UTC) FILETIME=[D3A28BF0:01C71421] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org agree again. also no attachment to src addresses at my end. agree on identifying transport points of the protocols to the architecture but want to go offline with Pekka N. on that one and can do as I can around the day job of course. the reason to do this arch exercise is the potential of freeing the transport layer from IPvN layer and components, which affords routing more freedom in thinking models. but to note both shim6 and hip have done this and some implementation exists. Best, /jim =20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Wednesday, November 29, 2006 4:52 PM > To: Bound, Jim > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] On identifiers: what is virtual and=20 > what is global (wasRe: thou... >=20 > Bound, Jim wrote: > >> From: John Leslie [mailto:john@jlc.net] > >>=20 > >> I strongly recommend that we call the "thing" that sits in=20 > the IPv4=20 > >>header as destination address an "IPv4 destination =20 > address", and the=20 > >>"thing" that sits in the IPv6 header as a destination address an=20 > >>"IPv6 destination address". > >>... > >> (The actual parameters passed to operating systems to open TCP=20 > >>sockets and connections are _also_ something else > >> entirely: we must not confuse TCP endpoints with IPvN destination=20 > >>addresses.) > >=20 > > Two points I do want to note for discussion are > >=20 > > what is passed to transport connections are end-to-end=20 > identifiers in=20 > > my view and should not be exposed in the IPvN headers or used for=20 > > loc+id. >=20 > I agree they are end-to-end identifiers, even if they look=20 > exactly like IPvN addresses. >=20 > That they currently are exposed in IPvN headers is an accident of > history: TCP never defined a standard for exchanging anything=20 > else as endpoint identifiers. (Clearly, both ends of a TCP=20 > connection need to agree how to distinguish that a packet=20 > belongs to that > connection: IPvN addresses have worked OK for that purpose.=20 > Endpoint identifiers _could_ be something else entirely; and=20 > need not be visible at all to the IPvN layer.) >=20 > We must allow _something_ to be used for loc+id within=20 > IPvN; but it'd be fine if, for example, the application=20 > passed FQDNs as the endpoint IDs and the operating system did=20 > a DNS-like query to find > loc+id. >=20 > > Also on source addresses my pain has been if they get=20 > altered then I=20 > > am unclear how I respond back at the OS transport end. >=20 > This is indeed a mess right now. NAT boxes routinely alter=20 > these and "try" to maintain enough state to alter them back. :*( >=20 > > But if I am no longer using the notion of a current source=20 > address at=20 > > the transport end I don't care about that anymore and if that is=20 > > possible that is a good thing. >=20 > IPvN source addresses are used to report routing problems:=20 > other than that, they can mostly be ignored. (Indeed, they=20 > can't even be trusted for that much: the less we depend on=20 > them, the better.) >=20 > (There was a time when we believed routing based on source=20 > address would help. Most of us would like to bury that idea...) >=20 > > I believe shim6 and hip get us very close to this model for the=20 > > transport with current architecturs and specifications. >=20 > I must admit that I view both shim6 and hip as moving=20 > targets trying to be too many things to too many people. I=20 > suspect I'm not alone. In any case, both of those are=20 > engineering, not architecture; for purposes of this list I=20 > suggest explaining which features of them you'd like to=20 > compare, rather than just naming a protocol. >=20 > -- > John Leslie >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 21:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpba7-0008TA-M8; Wed, 29 Nov 2006 21:23:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpba6-0008T2-7U for architecture-discuss@ietf.org; Wed, 29 Nov 2006 21:23:22 -0500 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpba3-00061t-Rq for architecture-discuss@ietf.org; Wed, 29 Nov 2006 21:23:22 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc15) with ESMTP id <20061130022318m150007on3e>; Thu, 30 Nov 2006 02:23:19 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DCFF3573@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCFF3573@tayexc14.americas.cpqcorp.net> Date: Wed, 29 Nov 2006 21:14:19 -0500 To: "Bound, Jim" , "John Leslie" From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Not quite. Sooner or later you are going to realize that that there are no such thing as Transport Addresses. In fact, transport is sort of a minor layer at best. As far as this problem is concerned, Transport is irrelevant to the solution. Transport has no effect on the routing and its components and doesn't constrain its possibilities in the least. QED At 20:49 -0500 2006/11/29, Bound, Jim wrote: >agree again. also no attachment to src addresses at my end. agree on >identifying transport points of the protocols to the architecture but >want to go offline with Pekka N. on that one and can do as I can around >the day job of course. the reason to do this arch exercise is the >potential of freeing the transport layer from IPvN layer and components, >which affords routing more freedom in thinking models. but to note both >shim6 and hip have done this and some implementation exists. > >Best, >/jim > > > >> -----Original Message----- >> From: John Leslie [mailto:john@jlc.net] >> Sent: Wednesday, November 29, 2006 4:52 PM >> To: Bound, Jim >> Cc: architecture-discuss@ietf.org >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Bound, Jim wrote: >> >> From: John Leslie [mailto:john@jlc.net] >> >> >> >> I strongly recommend that we call the "thing" that sits in >> the IPv4 >> >>header as destination address an "IPv4 destination >> address", and the >> >>"thing" that sits in the IPv6 header as a destination address an >> >>"IPv6 destination address". >> >>... >> >> (The actual parameters passed to operating systems to open TCP >> >>sockets and connections are _also_ something else >> >> entirely: we must not confuse TCP endpoints with IPvN destination >> >>addresses.) >> > >> > Two points I do want to note for discussion are >> > >> > what is passed to transport connections are end-to-end >> identifiers in >> > my view and should not be exposed in the IPvN headers or used for >> > loc+id. >> >> I agree they are end-to-end identifiers, even if they look >> exactly like IPvN addresses. >> >> That they currently are exposed in IPvN headers is an accident of >> history: TCP never defined a standard for exchanging anything >> else as endpoint identifiers. (Clearly, both ends of a TCP >> connection need to agree how to distinguish that a packet >> belongs to that >> connection: IPvN addresses have worked OK for that purpose. >> Endpoint identifiers _could_ be something else entirely; and >> need not be visible at all to the IPvN layer.) >> >> We must allow _something_ to be used for loc+id within >> IPvN; but it'd be fine if, for example, the application >> passed FQDNs as the endpoint IDs and the operating system did >> a DNS-like query to find >> loc+id. >> >> > Also on source addresses my pain has been if they get >> altered then I >> > am unclear how I respond back at the OS transport end. >> >> This is indeed a mess right now. NAT boxes routinely alter >> these and "try" to maintain enough state to alter them back. :*( >> >> > But if I am no longer using the notion of a current source >> address at >> > the transport end I don't care about that anymore and if that is >> > possible that is a good thing. >> >> IPvN source addresses are used to report routing problems: >> other than that, they can mostly be ignored. (Indeed, they >> can't even be trusted for that much: the less we depend on >> them, the better.) >> >> (There was a time when we believed routing based on source >> address would help. Most of us would like to bury that idea...) >> >> > I believe shim6 and hip get us very close to this model for the >> > transport with current architecturs and specifications. >> >> I must admit that I view both shim6 and hip as moving >> targets trying to be too many things to too many people. I >> suspect I'm not alone. In any case, both of those are >> engineering, not architecture; for purposes of this list I > > suggest explaining which features of them you'd like to >> compare, rather than just naming a protocol. >> >> -- >> John Leslie >> > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 21:57:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpc65-000604-Gt; Wed, 29 Nov 2006 21:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpc64-0005zz-Ee for architecture-discuss@ietf.org; Wed, 29 Nov 2006 21:56:24 -0500 Received: from web58705.mail.re1.yahoo.com ([66.196.100.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gpc61-0003Tz-4I for architecture-discuss@ietf.org; Wed, 29 Nov 2006 21:56:24 -0500 Received: (qmail 26225 invoked by uid 60001); 30 Nov 2006 02:56:15 -0000 Message-ID: <20061130025615.26223.qmail@web58705.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=gzNXPVTlXRTj3++0rXDtO55cCmn0YJrgDryfru3gscVYPJoFirT37tF/kDorIcvhabye7P5bRRAeNuP/z67ZVIHL67B9RDxOWutdnRFG6YEniqvQ/9ymwxkW36blb8D4YaEOd46wXkOjWrQR6Sf7UTAwQX/BsUCdYBKhizp3e+4=; X-YMail-OSG: y_mlezwVM1n4hkvD1pktGHvmiSN1pNg5.TBK0u6F7Zf67xMf2Y_pWy5Z0HSVOvTqbRCIuYSOLATUEqbFnyp47W8Ht_WTYotRqFzK69TlhIgjPrD1ZJUjrHRVdWMtTLbxi_g5wPsDXN3ht2Ao7AmKP.pKosWst9zqNoaIAk.eTIKE03YNvZlFnkhvNf4- Received: from [74.111.124.141] by web58705.mail.re1.yahoo.com via HTTP; Wed, 29 Nov 2006 18:56:15 PST Date: Wed, 29 Nov 2006 18:56:15 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: John Day , David Conrad , "Bound, Jim" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Actually he says routes, not paths. for the sake of accuracy: "4. Paths. These run between network attachment points,..." [RFC 1498, p.3] >...he says that application names map to node addresses and node addresses are mapped to point of attachment addresses which are mapped to routes. 1. The above requirement is not mandatory for routing. Node hierarchy can be transparent to the network hierarchy. 2. It holds true for a limited sample of relatively big machines supporting several applications and/or multiple interfaces. For the prevailing majority of microcomputers and sensors Application = Node = Interface. > You are looking for a kludge. More thoughts >>- unless a mobile node on a foreign AS sends a packet, home node does not know >> where the mobile node is Which is OK, because home needs an info from the remote node and the remote node first will have to contact home >>- private networks who want to communicate have to acquire each other ASN in >>advance OK, because now I control whom I am going to communicate with >>- scalability of AS hierarchy non issue, there is no need even to extend 16bit ASN to 32bit, instead introduce upper tier ASN >>- scalability of routing within AS mitigate by e.g. limiting number of /32's per AS > what protocol carries the point of attachment address? IP > what protocol carries the node address? IP, where node = interface > what protocol carries the application name? TCP, but does it really need an application name? Thanks, Peter --- John Day wrote: > At 13:12 -0800 2006/11/29, Peter Sherbin wrote: > > > RFC 1498 > > > >Saltzer identifies 4 network objects: > >1.Service/aka Application; 2.Node; 3.Network Attachment Point/aka > >Interface; 4.Path > > > >Routing only needs a unique Interface, which reduces objects to 2: > >1.Interface and > >2.Path. But too many nets to remember still choke routers. > > Actually he says routes, not paths. And he says that application > names map to node addresses and node addresses are mapped to point of > attachment addresses which are mapped to routes. > > But this is where he goes a bit astray (and understandably) because > at the time he wrote there were no cases (or very very few) of > multiple paths to the next hop. SO, if you adjust his model for that: > > Application names are mapped to node addresses by a directory. > Routes are calculated from node addresses. From the routing > calculation, you determine the next hop. > Then you need the mapping of node address to point of attachment > address for all of your nearest neighbors. From this, a subset gives > you know all of the possible paths from this point to the next hop, > so by some criteria you choose one. It is fundamentally a two step > process. > > Now notice something interesting. The mapping of application names > to node addresses and the mapping of node addresses to points of > attachments for all nearest neighbors are essentially the same > mapping. They are both all mappings one hop away. Hmmmm. > > > > >Could the split work as follows: > >- AS hierarchy constructs a backbone > >- Providers get AS numbers bound to a given physical space > >- EU get IPv6 addresses bound to a given physical space > >- no change for routing on private networks > >- for public routing a source and a destination addresses must add ASN > >- when a mobile interface attaches to a foreign AS it already knows > >its home ASN to > >reach its home node(s) > >- receiving node learns about sending node's ASN and establishes communication > > You are looking for a kludge. This is the arch-d list. We are > looking for the right solution. Then we will worry about how to get > there. Once you know where you are going, it will be easier to > figure out how to get there. > > Don't skip steps. You will drop a sign or worse! (metaphorically). > > > > >There are some limitations: > >- unless a mobile node on a foreign AS sends a packet, home node > >does not know where > >the mobile node is > >- private networks who want to communicate have to acquire each > >other ASN in advance > >and put them into destination address > >- scalability of AS hierarchy > >- scalability of routing within AS > > These are all show stoppers. > > > I would suggest that a more interesting exercise is to answer the > following questions: > > what protocol carries the point of attachment address? > what protocol carries the node address? > what protocol carries the application name? > > For the whole thing to work, they must be managed independently. > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 22:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpcHC-00010d-16; Wed, 29 Nov 2006 22:07:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpcHB-00010S-J5 for architecture-discuss@ietf.org; Wed, 29 Nov 2006 22:07:53 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpcGz-0006QH-5z for architecture-discuss@ietf.org; Wed, 29 Nov 2006 22:07:53 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 91F384ACC9; Wed, 29 Nov 2006 22:07:39 -0500 (EST) Date: Wed, 29 Nov 2006 22:07:39 -0500 From: John Leslie To: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Message-ID: <20061130030739.GC2467@verdi> References: <816DD9299957E547B5D758D7F977D6DCFF3573@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John Day wrote: > > Not quite. Sooner or later you are going to realize that that there > are no such thing as Transport Addresses. I try to avoid saying "transport" layer / address / etc. because I believe it means too many different things to too many people. Actually, I agree that TCP-as-we-know-it isn't a "transport layer" and most assuredly lacks anything we should call a "transport address". > In fact, transport is sort of a minor layer at best. It depends... When I do talk of a "transport layer", I mean a layer that worries about reliability, and thus detects and deals with - packet loss, - packet corruption, and - choosing among multiple paths (if available). I cannot agree with John Day that a layer which does that much is just a "minor layer". That much done right would solve - multi-homing, - mobility, - congestion, and - most forgery. > As far as this problem is concerned, Transport is irrelevant to the solution. I'm not sure what "this problem" John Day is talking of, but "transport" isn't "irrelevant" to the problems I'm trying to talk about. > Transport has no effect on the routing and its components and doesn't > constrain its possibilities in the least. Transport _shouldn't_ affect routing; but doing transport wrong (like, e.g. TCP) can constrain routing pretty severely. :^( -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 22:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpcLx-0003Ma-Od; Wed, 29 Nov 2006 22:12:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpcHL-0001AU-3b for architecture-discuss@ietf.org; Wed, 29 Nov 2006 22:08:03 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpcCL-0004cb-L8 for architecture-discuss@ietf.org; Wed, 29 Nov 2006 22:02:58 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GpRL8-00071D-5H for architecture-discuss@ietf.org; Wed, 29 Nov 2006 07:27:14 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Nov 2006 16:26:30 +0100 To: architecture-discuss@ietf.org From: Jefsey_Morfin In-Reply-To: References: MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [arch-d] IPv8 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1808329462==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1808329462== Content-Type: multipart/alternative; boundary="----MTefyjdzhbcwoscraixnilxjjmbwtexmdx" ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-75C44E42 I made a quick search on IPv8 in Google to refresh my memory. It seems not very far from all what is discussed here. It is interesting because it means that if we do not have other solution, NATs could easily update to IPv8 (I understand some code already exists by several sources, or equivalent approaches) and find a grassroots solution outside of the IETF. The natural cost increase of IPv4 addresses as they become scarce will probably free enough IPv4 addresses so every NAT can have an IPv4 address whatever their number (we can already do it). This will naturally lead people to divide the cost of an IPv4 address among thousands of "second level" IPv8 adresses (more than with NATs). The interest is that I do not think there is a big problem to encapsulate IPv6 addresses into such IPv8 so there would be a compatibility with IPv6 existing deployments. I suppose that DNS could be progressively adapt and destination NAT resolvers will be developped: the IPv4 first level of the IPv8 address (which is actually the topology, routing part of the address) would resolve the domain names even in non IPv8 updated nameservers, and the IPv8 second level which is the identification of the user and its further levels for exensions could be supported à la NAT, à la HTTP.1.1 or à la IPv8. Some progressive reorganisation of the IPv4 blocks under the price pressure could permit RIRs to simplify the routing issues in reorganising the addressing along with the main topology organisation. It is a good thing to know the solution the market would most probably adopt, under natural cost considerations, should this debate lead to no solution or to a solution with delays comparable to the IPv6 deployement. May be could we run some simulation, and spend some thinking on that probable grasssroots plan B. Also, on the way it could then migrate from IPv8 to IPv6 and prepare accordingly. The interest of IPv8 is that it leaves free the user part of the address: it permits an understanding diversity. Another interesting possibility is to remove the actual domain name from the packet and to restore it at the "NAT", adressing the problem of long punny code sequence, lack of Unicode support, new language TLD (DNAME or NS). The IPv8 second level could be the numeric ID of the domain name label (permitting to support a variety of services, including linguistic TLDs without new root entries). China having a large deployment of NATs has certainly considered the possibility already. May be IPv10 was not an hoax, but an IPv8+? May be interesting to consider an IETF/WG-INTERNAT(ional)? jfc ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/html I made a quick search on IPv8 in Google to refresh my memory. It
seems not very far from all what is discussed here. It is interesting
because it means that if we do not have other solution, NATs could
easily update to IPv8 (I understand some code already exists by
several sources, or equivalent approaches) and find a grassroots
solution outside of the IETF.

The natural cost increase of IPv4 addresses as they become scarce
will probably free enough IPv4 addresses so every NAT can have an
IPv4 address whatever their number (we can already do it). This will
naturally lead people to divide the cost of an IPv4 address among
thousands of "second level" IPv8 adresses (more than with NATs). The
interest is that I do not think there is a big problem to encapsulate
IPv6 addresses into such IPv8 so there would be a compatibility with
IPv6 existing deployments.

I suppose that DNS could be progressively adapt and destination NAT
resolvers will be developped: the IPv4 first level of the IPv8
address (which is actually the topology, routing part of the address)
would resolve the domain names even in non IPv8 updated nameservers,
and the IPv8  second level which is the identification of the user
and its further levels for exensions could be supported à la NAT, à
la HTTP.1.1 or à la IPv8.

Some progressive reorganisation of the IPv4 blocks under the price
pressure could permit RIRs to simplify the routing issues in
reorganising the addressing along with the main topology organisation.

It is a good thing to know the solution the market would most
probably adopt, under natural cost considerations, should this debate
lead to no solution or to a solution with delays comparable to the
IPv6 deployement. May be could we run some simulation, and spend some
thinking on that probable grasssroots plan B. Also, on the way it
could then migrate from IPv8 to IPv6 and prepare accordingly. The
interest of IPv8 is that it leaves free the user part of the address:
it permits an understanding diversity.

Another interesting possibility is to remove the actual domain name
from the packet and to restore it at the "NAT", adressing the problem
of long punny code sequence, lack of Unicode support, new language
TLD (DNAME or NS). The IPv8 second level could be the numeric ID of
the domain name label (permitting to support a variety of services,
including linguistic TLDs without new root entries). China having a
large deployment of NATs has certainly considered the possibility
already. May be IPv10 was not an hoax, but an IPv8+?

May be interesting to consider an IETF/WG-INTERNAT(ional)?
jfc



------MTefyjdzhbcwoscraixnilxjjmbwtexmdx-- --===============1808329462== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1808329462==-- From architecture-discuss-bounces@ietf.org Wed Nov 29 23:15:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpdId-0007jb-JK; Wed, 29 Nov 2006 23:13:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpdIc-0007jT-RV for architecture-discuss@ietf.org; Wed, 29 Nov 2006 23:13:26 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpdIb-0002gR-Jv for architecture-discuss@ietf.org; Wed, 29 Nov 2006 23:13:26 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006113004131901100rkkk1e>; Thu, 30 Nov 2006 04:13:24 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061130025615.26223.qmail@web58705.mail.re1.yahoo.com> References: <20061130025615.26223.qmail@web58705.mail.re1.yahoo.com> Date: Wed, 29 Nov 2006 23:12:45 -0500 To: Peter Sherbin , John Day , David Conrad , "Bound, Jim" From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 18:56 -0800 2006/11/29, Peter Sherbin wrote: > > Actually he says routes, not paths. > >for the sake of accuracy: "4. Paths. These run between network attachment >points,..." [RFC 1498, p.3] ooops, bad memory! I knew I should have checked it. Although right after that he refers to it as a route service. > >...he says that application names map to node addresses and node >addresses are >mapped to point of attachment addresses which are mapped to routes. > >1. The above requirement is not mandatory for routing. Node hierarchy can be >transparent to the network hierarchy. What node hierarchy? Address assignment hierarchies are used to better manage address space their correspondence to hierarchies of subnets is purely coincidental. It is important not to confuse the two. >2. It holds true for a limited sample of relatively big machines >supporting several >applications and/or multiple interfaces. For the prevailing majority of >microcomputers and sensors Application = Node = Interface. This is science. Our goal is to find the minimal set of concepts that encompass the whole problem.. The attitude that most systems are not multihomed and therefore we don't need to look for a real solution is what got us into this mess to begin with. > >> You are looking for a kludge. >More thoughts >>>- unless a mobile node on a foreign AS sends a packet, home node >>>does not know >>> where the mobile node is >Which is OK, because home needs an info from the remote node and the >remote node >first will have to contact home We have already established that a mobility solution with a concept of "home" is a kludge. > >>- private networks who want to communicate have to acquire each >other ASN in >>>advance >OK, because now I control whom I am going to communicate with > >>>- scalability of AS hierarchy >non issue, there is no need even to extend 16bit ASN to 32bit, >instead introduce >upper tier ASN > >>>- scalability of routing within AS >mitigate by e.g. limiting number of /32's per AS > >> what protocol carries the point of attachment address? >IP Gee, I thought it was MAC protocol. > > what protocol carries the node address? >IP, where node = interface Node does not equal interface. That is why we are having this discussion. But you are right. IP does carry point of attachment and the IETF in its infinite (and misguided) wisdom has decreed that it shall be the case: Full emulation of Faber Marching Band. > > what protocol carries the application name? >TCP, but does it really need an application name? TCP!? Or any such protocol? Nah. Have you looked at these protocols? They are purely single instances of communication. They have no functionality across instances. Very clean. We don't want to destroy that. Don't make them any more complex than they are. What about application connections? Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 29 23:23:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpdS5-0003cT-H4; Wed, 29 Nov 2006 23:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpdS3-0003cM-T5 for architecture-discuss@ietf.org; Wed, 29 Nov 2006 23:23:11 -0500 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpdS2-0004gP-L8 for architecture-discuss@ietf.org; Wed, 29 Nov 2006 23:23:11 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc13) with ESMTP id <20061130042309b1300c16ghe>; Thu, 30 Nov 2006 04:23:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061130030739.GC2467@verdi> References: <816DD9299957E547B5D758D7F977D6DCFF3573@tayexc14.americas.cpqcorp.net> <20061130030739.GC2467@verdi> Date: Wed, 29 Nov 2006 23:18:27 -0500 To: John Leslie , John Day From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 22:07 -0500 2006/11/29, John Leslie wrote: >John Day wrote: >> >> Not quite. Sooner or later you are going to realize that that there >> are no such thing as Transport Addresses. > > I try to avoid saying "transport" layer / address / etc. because I >believe it means too many different things to too many people. > > Actually, I agree that TCP-as-we-know-it isn't a "transport layer" >and most assuredly lacks anything we should call a "transport address". Nor should any transport protocol, > > In fact, transport is sort of a minor layer at best. > > It depends... > > When I do talk of a "transport layer", I mean a layer that worries >about reliability, and thus detects and deals with > >- packet loss, >- packet corruption, and >- choosing among multiple paths (if available). None that I know of do the latter. O, yes, SCTP tries to but how? This is just because we have failed to do the relaying and multiplexing functions well. It really is in no position to do it. > > I cannot agree with John Day that a layer which does that much is >just a "minor layer". That much done right would solve > >- multi-homing, >- mobility, >- congestion, and >- most forgery. Really only congestion in this list has anything to do with Transport, well, that class of protocols. > > As far as this problem is concerned, Transport is irrelevant to the > solution. > > I'm not sure what "this problem" John Day is talking of, but >"transport" isn't "irrelevant" to the problems I'm trying to talk >about. Multihoming, mobility, routing, security, etc. Everything but error and flow control on a single flow. > > Transport has no effect on the routing and its components and doesn't >> constrain its possibilities in the least. > > Transport _shouldn't_ affect routing; but doing transport wrong >(like, e.g. TCP) can constrain routing pretty severely. :^( Well, as one of the best system designers I ever knew often said, "if you don't do it right, it won't work." ;-) Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 02:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpgni-0001AG-FD; Thu, 30 Nov 2006 02:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpgng-00019z-RW for architecture-discuss@ietf.org; Thu, 30 Nov 2006 02:57:44 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpgnb-0000kQ-2a for architecture-discuss@ietf.org; Thu, 30 Nov 2006 02:57:44 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1556D212FD0; Thu, 30 Nov 2006 09:57:25 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CE2A6212DAB; Thu, 30 Nov 2006 09:57:24 +0200 (EET) In-Reply-To: <20061129215219.GB2467@verdi> References: <20061129185545.GA2467@verdi> <816DD9299957E547B5D758D7F977D6DCFF33E5@tayexc14.americas.cpqcorp.net> <20061129215219.GB2467@verdi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...) Date: Thu, 30 Nov 2006 09:57:22 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bound, Jim wrote: >> I believe shim6 and hip get us very close to this model for the >> transport with current architecturs and specifications. > On 29 Nov 2006, at 23:52, John Leslie wrote: > I must admit that I view both shim6 and hip as moving targets > trying to be too many things to too many people. I suspect I'm not > alone. In any case, both of those are engineering, not architecture; > for purposes of this list I suggest explaining which features of them > you'd like to compare, rather than just naming a protocol. I'm certainly digressing below, but I can't help feeling sympathetic to both HIP and SHIM6/CGA, for obvious reasons. :-) From my point of view, HIP and SHIM6 implement the so-called identifier-locator split in the sense that they separate the identifiers that are passed through the socket API from the "addresses" that are placed in the IPvN header. There I completely agree with Jim. What comes to the current state of HIP and SHIM6, I wouldn't call them that moving targets any more. The base HIP specs have been fairly stable for a couple of years now, and are in the final stages of getting through the IESG. In the last calls there's been nothing earth shattering, mostly clarifications on intended usage and behaviour in certain corner cases. There are three open source, interoperable implementations, running on Linux, FreeBSD, Windows, and Mac OS X. The only moving target today seems to be the way the host identities are referred to through the backwards compatibility API; see http://www.ietf.org/internet-drafts/draft-laganier-ipv6- khi-05.txt From my point of view, HIP has never really intended to be very many things. Metaphorically, it has always just tried to be the proverbial Indian elephant, nothing more and nothing less. What cannot be helped is that different blinds feel it in different way; http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant As explained in RFC 4423, the purpose of HIP is to establish a new, cryptographic name space into the stack, somewhere between the internetworking and transport layers. However, by adding this new identity space and thereby a new layer of indirection, it *naturally* creates a way of implementing mobility, a way of implementing multi- address multi-homing, and a provides a name space for security purposes. As an added plus, there comes lots of other properties, including (IMHO) better-engineered NAT traversal, ability to use IPv4 and IPv6 interchangeably, ability to use delegation to implement subnetwork mobility, ability to use delegation to represent "higher- level" names such as application and application instance names, etc. But those are all just consequences of the architectural change. Architecturally speaking, they are all made easy by providing a new secure layer of indirection. Hence, given its purpose, I would consider HIP architectural and not just engineering. A new name space is a new name space, and that is something architectural. On the other hand, the way the new name space is embedded into the stack for backwards compatibility is certainly engineering; depending on your point of view, it can be considered either as very clever engineering or as an utterly ugly kludge. See http://www.ietf.org/internet-drafts/draft-ietf-hip- applications-00.txt and the last call comments to draft-laganier-ipv6- khi-05.txt. Now, considering SHIM6 first from the technical point of view, I see it mainly motivated by the desire of allowing combined id+locators to be still used in the socket API, thereby reducing the pressure to update resolvers, adding new infrastructure to support a new name space, and making it slightly less probable that referrals will break. But then, again, far more than being motivated by technical grounds, SHIM6 represents a political compromise, trying not to aggravate Mobile IP people (by officially stating that that it is not a mobility protocol while in reality being very close to one), trying to satisfy those people who are afraid of burning CPU cycles for any kind of crypto by allowing one to use very little crypto, and trying to comfort those people that still are afraid of breaking application- level IP-address-based referral, in these NATed ages, by allowing the combined id+locs to be used in the socket API. What comes to SHIM6 as an architecture, I would consider it, at least in its current stage, less architecture and more engineering. Half- architectural, if you will, since it kind-of allows you to embed a new name space into the stack (through using CGAs) but does not mandate it (allowing HBAs). My personal view of SHIM6 is that it is a kind-of watered-down version of HIP, officially trying to achieve clearly less than HIP but at the same time unofficially crawling towards the directions where HIP has already boldly gone. :-) Not bad given the committee design. ---- That all said, my personal opinion is that alone both HIP and SHIM6 are still just band aid, buying more time for the current architecture. Perhaps better-than-usual band aid, due to having at least some threads of architecture instead of being completely kludgy, but still band aid. For example, neither of them are able to address the bad traffic problem in any way. Neither of them really help with the balkanisation, spreading of SBGs, closing of ports due to "security" reasons, and everything moving on the the top of HTTP. While it might be possible to use them in engineering solutions to address some of those problems (see e.g. http://www.tml.tkk.fi/~pnr/HIP/draft- nikander-hiprg-hi3-00.xml), I'm not too hopeful about the community ever getting that far. I consider it more likely that the results the NSF and FP7 funded research will mature before the IETF community gets to the stage where HIP, SHIM6, or perhaps some combination of them (CHIMP?) can be used as a genuine tool to address the harder problems that we have, such as bad traffic. On the more positive side, while both HIP and SHIM6 would help with the current "routing crisis" (as identified by the IAB), they still build upon the current routing and addressing paradigm. While in theory they could allow more radical changes of the underlying parts of the stack, that would require more drastic changes than either of the approaches currently support. Again, I am not too hopeful about the IETF community ever getting there. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 03:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphHC-0001ff-IX; Thu, 30 Nov 2006 03:28:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphHB-0001fa-Hq for architecture-discuss@ietf.org; Thu, 30 Nov 2006 03:28:13 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GphH9-0006MF-Vl for architecture-discuss@ietf.org; Thu, 30 Nov 2006 03:28:13 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAU8S6on010800 for ; Thu, 30 Nov 2006 10:28:09 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 10:28:08 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 10:28:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 10:28:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on what we are identifying Thread-Index: AccUVWlfxhzhrCXTTY2Upm1chjt0dwAABY3Q From: To: X-OriginalArrivalTime: 30 Nov 2006 08:28:09.0132 (UTC) FILETIME=[776856C0:01C71459] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [arch-d] Question on what we are identifying X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi all, I've been following the discussions, but one thing that I not been able to wrap my head around is that if we split the identity & locator, what is it that we are identifying. We could be identifying the interface, the stack, the host, the process, the application.=20 For example, with SHIM6, congestion control will be quite difficult (if not impossible) if=20 you try to use SHIM addresses with SCTP. As SCTP calculates congestion control per network path, if the addresses used no long indicate a network path, all bets are off. The discussions on this list have pointed out many possibilities of what & how we can identify things, but when I start to look at how some of the potential identifiers map to transport protocols, to processes, to applications, things get a bit messy. Does anyone have any pointers on background reading on this issue? thanks, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 03:39:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphR8-0005HF-5j; Thu, 30 Nov 2006 03:38:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphR7-0005HA-7w for architecture-discuss@ietf.org; Thu, 30 Nov 2006 03:38:29 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GphR1-0000r4-R2 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 03:38:29 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 4FCCD340C9; Thu, 30 Nov 2006 03:38:23 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 03:38:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Thu, 30 Nov 2006 03:38:20 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCFF35EA@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccUJoGGyOHGCSxKSy+WTFoybGQv5QAM2bVw From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 30 Nov 2006 08:38:22.0916 (UTC) FILETIME=[E5405840:01C7145A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I am working here on engineering (not a computer science research project) for an architecture that will assist routing, but alleviating the business problem for operators that are not just network providers from the multihoming problem to some degree permits us more time to resolve the architecture issue at hand for routing. If the transport layer, which does rely on IPvN addresses in any implementation code I have ever seen for lookups etc., can be made to not be dependent on IPvN addresses, that will permit aggregation of IPvN addresses for some time to avoid the collision presented by the IAB at San Diego potentially. Thus it is important and I don't agree with John Day. Best, /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Wednesday, November 29, 2006 9:14 PM > To: Bound, Jim; John Leslie > Cc: architecture-discuss@ietf.org > Subject: RE: [arch-d] On identifiers: what is virtual and=20 > what is global (wasRe: thou... >=20 > Not quite. Sooner or later you are going to realize that=20 > that there are no such thing as Transport Addresses. In=20 > fact, transport is sort of a minor layer at best. As far as=20 > this problem is concerned, Transport is irrelevant to the solution. >=20 > Transport has no effect on the routing and its components and=20 > doesn't constrain its possibilities in the least. >=20 > QED >=20 > At 20:49 -0500 2006/11/29, Bound, Jim wrote: > >agree again. also no attachment to src addresses at my end.=20 > agree on=20 > >identifying transport points of the protocols to the=20 > architecture but=20 > >want to go offline with Pekka N. on that one and can do as I=20 > can around=20 > >the day job of course. the reason to do this arch exercise is the=20 > >potential of freeing the transport layer from IPvN layer and=20 > >components, which affords routing more freedom in thinking=20 > models. but=20 > >to note both > >shim6 and hip have done this and some implementation exists. > > > >Best, > >/jim > > > > > > > >> -----Original Message----- > >> From: John Leslie [mailto:john@jlc.net] > >> Sent: Wednesday, November 29, 2006 4:52 PM > >> To: Bound, Jim > >> Cc: architecture-discuss@ietf.org > >> Subject: Re: [arch-d] On identifiers: what is virtual and=20 > what is=20 > >> global (wasRe: thou... > >> > >> Bound, Jim wrote: > >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly=20 > >> recommend that we call the "thing" that sits in > >> the IPv4 > >> >>header as destination address an "IPv4 destination =20 > address", and=20 > >> the >>"thing" that sits in the IPv6 header as a =20 > destination address=20 > >> an > >> >>"IPv6 destination address". > >> >>... > >> >> (The actual parameters passed to operating systems to=20 > open TCP =20 > >> >>sockets and connections are _also_ something else >>=20 > entirely: we=20 > >> must not confuse TCP endpoints with IPvN destination > >> >>addresses.) > >> > > >> > Two points I do want to note for discussion are > > what is=20 > >> passed to transport connections are end-to-end =20 > identifiers in > my=20 > >> view and should not be exposed in the IPvN headers or used for >=20 > >> loc+id. > >> > >> I agree they are end-to-end identifiers, even if they look =20 > >> exactly like IPvN addresses. > >> > >> That they currently are exposed in IPvN headers is an=20 > accident of > >> history: TCP never defined a standard for exchanging=20 > anything else=20 > >> as endpoint identifiers. (Clearly, both ends of a TCP connection=20 > >> need to agree how to distinguish that a packet belongs to that > >> connection: IPvN addresses have worked OK for that purpose. > >> Endpoint identifiers _could_ be something else entirely;=20 > and need=20 > >> not be visible at all to the IPvN layer.) > >> > >> We must allow _something_ to be used for loc+id within=20 > IPvN; but=20 > >> it'd be fine if, for example, the application passed FQDNs as the=20 > >> endpoint IDs and the operating system did a DNS-like=20 > query to find =20 > >> loc+id. > >> > >> > Also on source addresses my pain has been if they get altered=20 > >> then I > am unclear how I respond back at the OS transport end. > >> > >> This is indeed a mess right now. NAT boxes routinely=20 > alter these=20 > >> and "try" to maintain enough state to alter them back. :*( > >> > >> > But if I am no longer using the notion of a current source =20 > >> address at > the transport end I don't care about that=20 > anymore and=20 > >> if that is > possible that is a good thing. > >> > >> IPvN source addresses are used to report routing problems: > >> other than that, they can mostly be ignored. (Indeed, they can't=20 > >> even be trusted for that much: the less we depend on them, the=20 > >> better.) > >> > >> (There was a time when we believed routing based on source =20 > >> address would help. Most of us would like to bury that idea...) > >> > >> > I believe shim6 and hip get us very close to this model=20 > for the >=20 > >> transport with current architecturs and specifications. > >> > >> I must admit that I view both shim6 and hip as moving targets=20 > >> trying to be too many things to too many people. I =20 > suspect I'm not=20 > >> alone. In any case, both of those are engineering, not=20 > architecture;=20 > >> for purposes of this list I > > > suggest explaining which features of them you'd like to > >> compare, rather than just naming a protocol. > >> > >> -- > >> John Leslie > >> > > > >_______________________________________________ > >Architecture-discuss mailing list > >Architecture-discuss@ietf.org > >https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 04:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphpC-0005uf-AH; Thu, 30 Nov 2006 04:03:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GphpA-0005uY-Jo for architecture-discuss@ietf.org; Thu, 30 Nov 2006 04:03:20 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gphp5-0006aV-8j for architecture-discuss@ietf.org; Thu, 30 Nov 2006 04:03:20 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 0D91034072; Thu, 30 Nov 2006 04:03:15 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 04:03:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Question on what we are identifying Date: Thu, 30 Nov 2006 04:03:13 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCFF35EC@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Question on what we are identifying Thread-Index: AccUVWlfxhzhrCXTTY2Upm1chjt0dwAABY3QAAHBbbA= From: "Bound, Jim" To: , X-OriginalArrivalTime: 30 Nov 2006 09:03:14.0612 (UTC) FILETIME=[5E5F1740:01C7145E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This is an important reality discussion point that has been an under-tone for some on the discussion. Some thoughts below.=20 > I've been following the discussions, but one thing that I not=20 > been able to wrap my head around is that if we split the=20 > identity & locator, what is it that we are identifying. > We could be identifying the interface, the stack, the host,=20 > the process, the application.=20 5 years ago I would have said the interface. but now I believe the stack. given VM guest OS proliferation. but only in the context of "routing". >=20 > For example, with SHIM6, congestion control will be quite=20 > difficult (if not impossible) if you try to use SHIM=20 > addresses with SCTP. As SCTP calculates congestion control=20 > per network path, if the addresses used no long indicate a=20 > network path, all bets are off. Bingo. At the transport layer given we move to identifiers for end point processes and applications the identifier would have to have associative pointer to IPvN address for network path. If that IPvN dst path has loc+id that requires another lookup on id part and already sent mail concerned simply about the performance. >=20 > The discussions on this list have pointed out many=20 > possibilities of what & how we can identify things, but when=20 > I start to look at how some of the potential identifiers map=20 > to transport protocols, to processes, to applications, things=20 > get a bit messy. I agree thus we need to define and crisply state what is the id part, how is it used for a network path, how do I know from the id what the network path is and then after all that is this truly the right approach for routing, we do not know that for sure yet either IMHO. But I do not think application, process, or an end-to-end identifier represents at all the same identifier for a routing paradigm they are orthogonal and separate. At least right now that is what I think. >=20 > Does anyone have any pointers on background reading on this issue? Per the above context I have never seen anything on such an id for routing or network path other than some very intense views using fractals indirectly, and that was a long time ago. I think its a new space other than indirect subtle references from within the IETF community provided early on in the discussion aka NIMROD. If folks have such pointers that would be highly helpful. Best, /jim >=20 > thanks, > John >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 04:28:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpiCg-0007Pm-34; Thu, 30 Nov 2006 04:27:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpiCf-0007NP-55 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 04:27:37 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpiCe-0003BV-EE for architecture-discuss@ietf.org; Thu, 30 Nov 2006 04:27:37 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 80C02212FD0; Thu, 30 Nov 2006 11:27:30 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 482D8212DAB; Thu, 30 Nov 2006 11:27:30 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9DE9FEE3-24FF-4DD0-983C-79F194E2770B@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [arch-d] Question on what we are identifying Date: Thu, 30 Nov 2006 11:27:28 +0200 To: John Loughney X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, > I've been following the discussions, but one thing that I not been =20 > able to wrap my head around is that if we split the identity & =20 > locator, what is it that we are identifying. We could be =20 > identifying the interface, the stack, the host, the process, the =20 > application. I think part of the problem is that the current discussion is taking =20 place at least at two different levels, maybe at more. To me (and I =20 know I'm at least partially wrong), the two levels seem to be roughly =20= as follows: 1. Most of the time, John Day, Noel, and I are trying to discuss what =20= would be the "right" long term architecture, simultaneously knowing =20 that there aren't no such thing. That is, disregard IP, start from =20 the clean slate, what would be the better ways of doing things. But =20 learning from the existing, including its problems. 2. The discussion RJ started, and many other threads, are less =20 ambitious and attempt to "fix" the current architecture by applying =20 some kind of an identifier/locator split. That is, add a new name =20 space, add a new layer of indirection, or do something else of the =20 same magnitude, which is by no means "small", but pretty much within =20 the current paradigm. To me, both of these two discussions are needed. If we can "fix" the =20= current architecture with something link HIP or SHIM6, that is good =20 since we will get maybe 10-20 years more lifetime for it. On the =20 other hand, developing a new networking paradigm will take at least =20 10 years of focused work, and probably much more. Deploying it will =20 take much longer, if we ever get that far. -- Given that, in the ideal world, the primary things that we want to =20 identify, IMHO, are whatever the applications need to. Most =20 applications want to identify "users" or "services", but then there =20 those odd diagnostic and other applications that will need to =20 identify network interfaces, stacks/hosts, nodes, and even perhaps =20 individual processes. Secondly, there are at least two very different "purposes" or =20 "intentions" for such identification. The applications want to =20 identify their peer entities for their purposes, which differ =20 slightly from application to application. The networking system, on =20 the other hand, want to identify them for the purposes of =20 communication or reachability. The difference may appear subtle but =20 is very real can causes great tensions. Basically, all the app wants is a way of exchanging information with =20 the peer; the desired characteristics of the "way", such as security, =20= reliability, bandwidth, frequency, etc, differ. The networking =20 system, on the other hand, will need to fulfil this need by knowing =20 where the peer entity is, finding a way there, and being able to =20 transport the information. None of which are trivial deeds, =20 especially given the current pretty hostile networking environment. This leads to a desire to have a flexible application-level entity =20 space that can encompass all kinds of entities from "users" and =20 "services" down to network interfaces, for the purpose of =20 _applications_. Due to the different intentions, we apparently need =20 at least two different kinds of name spaces imposed on the top of =20 this entity space. Firstly, we apparently need to have names that =20 fulfil application needs, often dealing with human cognitive needs. =20 Secondly, we apparently also need names that fulfil the networking =20 requirements, including location-independency, security, and =20 reachability. Finally, at this level, it is very important to understand that the =20 names that applications use to name low level entities such as stacks/=20= hosts, nodes, and interfaces need not be the same what are used =20 inside the networking system. For example, I could imagine using a =20 user level name "Pekka Nikander's MacBook Pro WLAN" for my WLAN =20 interface, having a cryptographic public key to denote it in an =20 location-independent, secure way for diagnosis applications, while =20 the network still internally eventually mapping both of those to the =20 MAC address. Note the consequences of this: In things likes WLAN =20 access control lists I would no longer use MAC addresses but probably =20= dual human-friendly--cryptographic names. I would select "Pekka =20 Nikander's MacBook Pro WLAN" in the GUI and the system would =20 internally store an identifying cryptographic key. -- Getting down a level in the discussion, the situation changes. Now =20 we have to consider the realities of the socket API. There the most =20 pressing desire seems to be naming stacks/hosts (abstract entities, =20 host !=3D node). Most people apparently still would like to refer to =20= applications by using stack/host names and ports. I'm fine with =20 that, for the time being, while simultaneously considering that as an =20= archaic notation. > For example, with SHIM6, congestion control will be quite difficult =20= > (if not impossible) if you try to use SHIM addresses with SCTP. As =20 > SCTP calculates congestion control per network path, if the =20 > addresses used no long indicate a network path, all bets are off. That's long been a known problem. I tried to open discussion about =20 that with Randall Stewart and Michael T=FCxen back in Vancouver, but at =20= time we were unable to find a common standing point. The base =20 solution was later discussed at some point of time in some SHIM6 =20 meeting (I don't remember where and when): the interface between =20 SHIM6 and SCTP must be richer than today. Basically, you either =20 store the ULIDs in the IP header and decorate the packet with the =20 locators (external meta data flowing in the stack up and down), or =20 vice versa. > The discussions on this list have pointed out many possibilities of =20= > what & how we can identify things, but when I start to look at how =20 > some of the potential identifiers map to transport protocols, to =20 > processes, to applications, things get a bit messy. As always :-) > Does anyone have any pointers on background reading on this issue? For one, I have never before been able to speak about the =20 architecture at the "higher" level of this discussion. Until =20 recently, I couldn't see beyond IP and the per-packet-send-receive & =20 hop-by-hop-forwarding paradigms that we rely on. For the "lower" level, or merely implementing id/loc split while =20 retaining most of the current architecture and especially the current =20= socket API, there are lots of written-down thoughts in the HIP =20 community, including the following: http://www.ietf.org/rfc/rfc4423.txt http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-00.txt =20 (needs much more work) http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt I think there are similar thoughts and documents written for SHIM6, =20 but I am not aware of the details. Unfortunately, I don't know if any of them addresses especially what =20 you ask for, but maybe RFC 4423 does in some sense. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 07:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpks5-0000Vv-Gh; Thu, 30 Nov 2006 07:18:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpks4-0000NW-HJ for architecture-discuss@ietf.org; Thu, 30 Nov 2006 07:18:32 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpks1-0001q1-78 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 07:18:32 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1Gpkrr-0003fi-UC for architecture-discuss@ietf.org; Thu, 30 Nov 2006 04:18:20 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 30 Nov 2006 13:17:24 +0100 To: John Leslie From: Jefsey_Morfin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... In-Reply-To: <20061129185545.GA2467@verdi> References: <866E00AF-B2B4-40F7-B245-366A4ACA9994@virtualized.org> <816DD9299957E547B5D758D7F977D6DCFF311F@tayexc14.americas.cpqcorp.net> <20061129185545.GA2467@verdi> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.3 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0053460558==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0053460558== Content-Type: multipart/alternative; boundary="----MThepttcbbcuujpltmivvdcbbfrfogjvii" ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-46243E99 On 19:55 29/11/2006, John Leslie said: > I strongly recommend that we call the "thing" that sits in the IPv4 >header as destination address an "IPv4 destination address", and the >"thing" that sits in the IPv6 header as a destination address an >"IPv6 destination address". That, after all is exactly and _only_ >what they are. I know you did not read my mails, but amen. > (The "things" which sit in those headers as source addresses are >something else entirely, I agree; and I'm open to any suggestions...) Why do you care? What have them to do with architecture? The Internet is a smart end to smart end dumb network. What is beyond the edges is not the Internet's cup of tea. What is currently the problem is that RFC 3439 accepts as an exception a growingly smart routing wich hardly qualify the network core as "dumb". And the routing needs to go too smart the way it goes. The only solution is to go back to the Internet's basic nature, and to fix the smart core routing into a smart edge dumb core routing. Or to come back to a situation we know how to manage in decreasing the load on routing in decreasing the demand for IP addresses. This is an architectural decision. The rest is pure engineering. jfc ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/html On 19:55 29/11/2006, John Leslie said:
>    I strongly recommend that we call the "thing" that sits in the IPv4
>header as destination address an "IPv4 destination address", and the
>"thing" that sits in the IPv6 header as a destination address an
>"IPv6 destination address". That, after all is exactly and _only_
>what they are.

I know you did not read my mails, but amen.

>    (The "things" which sit in those headers as source addresses are
>something else entirely, I agree; and I'm open to any suggestions...)

Why do you care?
What have them to do with architecture?

The Internet is a smart end to smart end dumb network. What is beyond
the edges is not the Internet's cup of tea. What is currently the
problem is that RFC 3439 accepts as an exception a growingly smart
routing wich hardly qualify the network core as "dumb". And the
routing needs to go too smart the way it goes. The only solution is
to go back to the Internet's basic nature, and to fix the smart core
routing into a smart edge dumb core routing. Or to come back to a
situation we know how to manage in decreasing the load on routing in
decreasing the demand for IP addresses.

This is an architectural decision. The rest is pure engineering.
jfc






------MThepttcbbcuujpltmivvdcbbfrfogjvii-- --===============0053460558== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0053460558==-- From architecture-discuss-bounces@ietf.org Thu Nov 30 08:34:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpm2D-0005rV-Lk; Thu, 30 Nov 2006 08:33:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpm2C-0005pb-3X for architecture-discuss@ietf.org; Thu, 30 Nov 2006 08:33:04 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpm2A-0005WY-NB for architecture-discuss@ietf.org; Thu, 30 Nov 2006 08:33:04 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAUDX0Wq142874 for ; Thu, 30 Nov 2006 13:33:00 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAUDacwu774228 for ; Thu, 30 Nov 2006 14:36:38 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAUDWttG000409 for ; Thu, 30 Nov 2006 14:32:55 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAUDWpiq032622; Thu, 30 Nov 2006 14:32:51 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA104626; Thu, 30 Nov 2006 14:32:50 +0100 Message-ID: <456EDD84.7050501@zurich.ibm.com> Date: Thu, 30 Nov 2006 14:32:52 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [arch-d] Question on what we are identifying References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > For example, with SHIM6, congestion control will be quite difficult (if > not impossible) if > you try to use SHIM addresses with SCTP. As SCTP calculates congestion > control per network > path, if the addresses used no long indicate a network path, all bets > are off. Which is why the shim6 model has to include the option of allowing the transport layer to switch off the shim. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 10:56:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoFx-0002XC-GL; Thu, 30 Nov 2006 10:55:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoFw-0002Vl-Uz for architecture-discuss@ietf.org; Thu, 30 Nov 2006 10:55:24 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpoFu-0007mN-HI for architecture-discuss@ietf.org; Thu, 30 Nov 2006 10:55:24 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20061130155511b1200t0vi4e>; Thu, 30 Nov 2006 15:55:21 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DCFF35EA@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DCFF35EA@tayexc14.americas.cpqcorp.net> Date: Thu, 30 Nov 2006 10:51:21 -0500 To: "Bound, Jim" , "John Day" , "John Leslie" From: John Day Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I believe that a week or so ago a list was created to address the problem you describe. As I understand it, this list was created to address the fact that for the past 30 years the Internet has shirked its responsibility to do the work necessary to provide a complete and well thought out architecture. As was expressed at the beginning of this discussion a few weeks ago, we have to give up this constant band-aid approach. We have to find the *solutions.* Then we can trade our band-aids in for steps toward an answer. As for transport, yes, we do have a number of bad examples in the data. At 3:38 -0500 2006/11/30, Bound, Jim wrote: >I am working here on engineering (not a computer science research >project) for an architecture that will assist routing, but alleviating >the business problem for operators that are not just network providers >from the multihoming problem to some degree permits us more time to >resolve the architecture issue at hand for routing. If the transport >layer, which does rely on IPvN addresses in any implementation code I >have ever seen for lookups etc., can be made to not be dependent on IPvN >addresses, that will permit aggregation of IPvN addresses for some time >to avoid the collision presented by the IAB at San Diego potentially. >Thus it is important and I don't agree with John Day. > >Best, >/jim > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Wednesday, November 29, 2006 9:14 PM >> To: Bound, Jim; John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Not quite. Sooner or later you are going to realize that >> that there are no such thing as Transport Addresses. In >> fact, transport is sort of a minor layer at best. As far as >> this problem is concerned, Transport is irrelevant to the solution. >> >> Transport has no effect on the routing and its components and >> doesn't constrain its possibilities in the least. >> >> QED >> >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: >> >agree again. also no attachment to src addresses at my end. >> agree on >> >identifying transport points of the protocols to the >> architecture but >> >want to go offline with Pekka N. on that one and can do as I >> can around >> >the day job of course. the reason to do this arch exercise is the >> >potential of freeing the transport layer from IPvN layer and >> >components, which affords routing more freedom in thinking >> models. but >> >to note both >> >shim6 and hip have done this and some implementation exists. >> > >> >Best, >> >/jim >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Wednesday, November 29, 2006 4:52 PM >> >> To: Bound, Jim >> >> Cc: architecture-discuss@ietf.org >> >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is >> >> global (wasRe: thou... >> >> >> >> Bound, Jim wrote: >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly >> >> recommend that we call the "thing" that sits in >> >> the IPv4 >> >> >>header as destination address an "IPv4 destination >> address", and >> >> the >>"thing" that sits in the IPv6 header as a >> destination address >> >> an >> >> >>"IPv6 destination address". >> >> >>... >> >> >> (The actual parameters passed to operating systems to >> open TCP >> >> >>sockets and connections are _also_ something else >> >> entirely: we >> >> must not confuse TCP endpoints with IPvN destination >> >> >>addresses.) >> >> > >> >> > Two points I do want to note for discussion are > > what is >> >> passed to transport connections are end-to-end >> identifiers in > my >> >> view and should not be exposed in the IPvN headers or used for > >> >> loc+id. >> >> >> >> I agree they are end-to-end identifiers, even if they look > > >> exactly like IPvN addresses. >> >> >> >> That they currently are exposed in IPvN headers is an >> accident of >> >> history: TCP never defined a standard for exchanging >> anything else >> >> as endpoint identifiers. (Clearly, both ends of a TCP connection >> >> need to agree how to distinguish that a packet belongs to that >> >> connection: IPvN addresses have worked OK for that purpose. >> >> Endpoint identifiers _could_ be something else entirely; >> and need >> >> not be visible at all to the IPvN layer.) >> >> >> >> We must allow _something_ to be used for loc+id within >> IPvN; but >> >> it'd be fine if, for example, the application passed FQDNs as the >> >> endpoint IDs and the operating system did a DNS-like >> query to find >> >> loc+id. >> >> >> >> > Also on source addresses my pain has been if they get altered >> >> then I > am unclear how I respond back at the OS transport end. >> >> >> >> This is indeed a mess right now. NAT boxes routinely >> alter these >> >> and "try" to maintain enough state to alter them back. :*( >> >> >> >> > But if I am no longer using the notion of a current source >> >> address at > the transport end I don't care about that >> anymore and >> >> if that is > possible that is a good thing. >> >> >> >> IPvN source addresses are used to report routing problems: >> >> other than that, they can mostly be ignored. (Indeed, they can't >> >> even be trusted for that much: the less we depend on them, the >> >> better.) >> >> >> >> (There was a time when we believed routing based on source >> >> address would help. Most of us would like to bury that idea...) >> >> >> >> > I believe shim6 and hip get us very close to this model >> for the > >> >> transport with current architecturs and specifications. >> >> >> >> I must admit that I view both shim6 and hip as moving targets >> >> trying to be too many things to too many people. I >> suspect I'm not >> >> alone. In any case, both of those are engineering, not >> architecture; >> >> for purposes of this list I >> > > suggest explaining which features of them you'd like to >> >> compare, rather than just naming a protocol. >> >> >> >> -- >> >> John Leslie >> >> >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 11:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoQA-0004Tp-S9; Thu, 30 Nov 2006 11:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoQA-0004Tf-6r for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:05:58 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpoQ7-0000bX-OJ for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:05:58 -0500 Received: from webmail02.lax.untd.com (webmail02.lax.untd.com [10.131.27.142]) by smtpout07.lax.untd.com with SMTP id AABCY8ALDARJL5UJ for (sender ); Thu, 30 Nov 2006 08:05:23 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKWiZRTJxPwa1aukpsBqfCzA== Received: (from fergdawg@netzero.net) by webmail02.lax.untd.com (jqueuemail) id L8FGUFM4; Thu, 30 Nov 2006 08:04:57 PST Received: from [24.23.201.115] by webmail02.lax.untd.com with HTTP: Thu, 30 Nov 2006 16:04:00 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Thu, 30 Nov 2006 16:04:00 GMT To: jefsey@jefsey.com Subject: Re: [arch-d] IPv8 X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061130.080457.5614.1569691@webmail02.lax.untd.com> X-ContentStamp: 8:4:627074365 X-MAIL-INFO: 446d79fc08217921211d6d0149bd6191918c69f19178c549890d55a1b1d5d57958ac19fc X-UNTD-Peer-Info: 10.131.27.142|webmail02.lax.untd.com|webmail02.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Jefsey_Morfin wrote: >I made a quick search on IPv8 in Google to refresh my memory. It >seems not very far from all what is discussed here. It is interesting >because it means that if we do not have other solution, NATs could >easily update to IPv8 (I understand some code already exists by >several sources, or equivalent approaches) and find a grassroots >solution outside of the IETF. > Are you sure your name isn't really Jim Fleming? ;-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFbwDqq1pz9mNUZTMRArPjAKCEz60B9Nm8QQJ3lf2cULj5qAJXHgCg7Q6O NZGZEBL7r592d1CaHHrp5OA=3D =3DF9AA -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 11:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpocf-0001S5-UN; Thu, 30 Nov 2006 11:18:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpoce-0001Rz-QP for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:18:52 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpocY-0002Dc-Bj for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:18:52 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 44B98341A5; Thu, 30 Nov 2006 11:18:53 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:18:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Thu, 30 Nov 2006 11:18:44 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038461@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccUl/L0ZXAUO9BeSB2LUPsWt5my9QAArRoQ From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 30 Nov 2006 16:18:45.0665 (UTC) FILETIME=[35B15910:01C7149B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Not to John D. - Note the list is ram@ietf.org but it is silent should we all be using that list, can someone here make an exec decision that we move this discussion to ram? In response to John D. below: None of us here believe the band-aid approach is acceptable so I see no issue at all. What one may consider a bandaid vs. not-a-bandaid probably will require some discussion and analysis. I think we need to get a requirements analysis done for guidance is my thought for this effort. Best, /jim > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Thursday, November 30, 2006 10:51 AM > To: Bound, Jim; John Day; John Leslie > Cc: architecture-discuss@ietf.org > Subject: RE: [arch-d] On identifiers: what is virtual and=20 > what is global (wasRe: thou... >=20 > I believe that a week or so ago a list was created to address=20 > the problem you describe. As I understand it, this list was=20 > created to address the fact that for the past 30 years the=20 > Internet has shirked its responsibility to do the work=20 > necessary to provide a complete and well thought out architecture. >=20 > As was expressed at the beginning of this discussion a few=20 > weeks ago, we have to give up this constant band-aid=20 > approach. We have to find the *solutions.* Then we can=20 > trade our band-aids in for steps toward an answer. >=20 > As for transport, yes, we do have a number of bad examples in=20 > the data. >=20 >=20 > At 3:38 -0500 2006/11/30, Bound, Jim wrote: > >I am working here on engineering (not a computer science research > >project) for an architecture that will assist routing, but=20 > alleviating=20 > >the business problem for operators that are not just network=20 > providers=20 > >from the multihoming problem to some degree permits us more time to=20 > >resolve the architecture issue at hand for routing. If the=20 > transport=20 > >layer, which does rely on IPvN addresses in any=20 > implementation code I=20 > >have ever seen for lookups etc., can be made to not be dependent on=20 > >IPvN addresses, that will permit aggregation of IPvN=20 > addresses for some=20 > >time to avoid the collision presented by the IAB at San=20 > Diego potentially. > >Thus it is important and I don't agree with John Day. > > > >Best, > >/jim > > > >> -----Original Message----- > >> From: John Day [mailto:jeanjour@comcast.net] > >> Sent: Wednesday, November 29, 2006 9:14 PM > >> To: Bound, Jim; John Leslie > >> Cc: architecture-discuss@ietf.org > >> Subject: RE: [arch-d] On identifiers: what is virtual and=20 > what is=20 > >> global (wasRe: thou... > >> > >> Not quite. Sooner or later you are going to realize that that=20 > >> there are no such thing as Transport Addresses. In fact,=20 > transport=20 > >> is sort of a minor layer at best. As far as this problem is=20 > >> concerned, Transport is irrelevant to the solution. > >> > >> Transport has no effect on the routing and its components and =20 > >> doesn't constrain its possibilities in the least. > >> > >> QED > >> > >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: > >> >agree again. also no attachment to src addresses at my end. > >> agree on > >> >identifying transport points of the protocols to the =20 > architecture=20 > >> but >want to go offline with Pekka N. on that one and can=20 > do as I =20 > >> can around >the day job of course. the reason to do this arch=20 > >> exercise is the >potential of freeing the transport layer=20 > from IPvN=20 > >> layer and >components, which affords routing more freedom in=20 > >> thinking models. but >to note both > >> >shim6 and hip have done this and some implementation exists. > >> > > >> >Best, > >> >/jim > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: John Leslie [mailto:john@jlc.net] >> Sent: Wednesday,=20 > >> November 29, 2006 4:52 PM >> To: Bound, Jim >> Cc:=20 > >> architecture-discuss@ietf.org >> Subject: Re: [arch-d] On=20 > >> identifiers: what is virtual and > >> what is > >> >> global (wasRe: thou... > >> >> > >> >> Bound, Jim wrote: > >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I=20 > strongly =20 > >> >> recommend that we call the "thing" that sits in > >> >> the IPv4 > >> >> >>header as destination address an "IPv4 destination =20 > address",=20 > >> and >> the >>"thing" that sits in the IPv6 header as a =20 > destination=20 > >> address >> an >> >>"IPv6 destination address". > >> >> >>... > >> >> >> (The actual parameters passed to operating systems=20 > to open =20 > >> TCP >> >>sockets and connections are _also_ something else >> > >> entirely: we > >> >> must not confuse TCP endpoints with IPvN destination >> =20 > >> >>addresses.) >> > >> > Two points I do want to note for=20 > >> discussion are > > what is >> passed to transport=20 > connections are=20 > >> end-to-end identifiers in > my >> view and should not=20 > be exposed=20 > >> in the IPvN headers or used for > >> loc+id. > >> >> > >> >> I agree they are end-to-end identifiers, even if they look=20 > > > >> exactly like IPvN addresses. > >> >> > >> >> That they currently are exposed in IPvN headers is an > >> accident of > >> >> history: TCP never defined a standard for exchanging =20 > anything =20 > >> else >> as endpoint identifiers. (Clearly, both ends of a TCP =20 > >> connection >> need to agree how to distinguish that a packet =20 > >> belongs to that >> connection: IPvN addresses have worked OK for=20 > >> that purpose. > >> >> Endpoint identifiers _could_ be something else=20 > entirely; and =20 > >> need >> not be visible at all to the IPvN layer.) >> > >> >> We must allow _something_ to be used for loc+id within > >> IPvN; but > >> >> it'd be fine if, for example, the application passed FQDNs as=20 > >> the >> endpoint IDs and the operating system did a=20 > DNS-like query=20 > >> to find >> loc+id. > >> >> > >> >> > Also on source addresses my pain has been if they=20 > get altered =20 > >> >> then I > am unclear how I respond back at the OS transport end. > >> >> > >> >> This is indeed a mess right now. NAT boxes routinely > >> alter these > >> >> and "try" to maintain enough state to alter them back.=20 > :*( >> =20 > >> >> > But if I am no longer using the notion of a current=20 > source >>=20 > >> address at > the transport end I don't care about that =20 > anymore and =20 > >> >> if that is > possible that is a good thing. > >> >> > >> >> IPvN source addresses are used to report routing problems: > >> >> other than that, they can mostly be ignored. (Indeed, they =20 > >> can't >> even be trusted for that much: the less we=20 > depend on them,=20 > >> the >> better.) >> > >> >> (There was a time when we believed routing based on source=20 > >> >> address would help. Most of us would like to bury that=20 > idea...) =20 > >> >> >> > I believe shim6 and hip get us very close to this model =20 > >> for the > >> transport with current architecturs and=20 > >> specifications. > >> >> > >> >> I must admit that I view both shim6 and hip as=20 > moving targets > >> >> trying to be too many things to too many people. I =20 > suspect I'm=20 > >> not >> alone. In any case, both of those are engineering, not =20 > >> architecture; >> for purposes of this list I > > suggest=20 > >> explaining which features of them you'd like to >> =20 > compare, rather=20 > >> than just naming a protocol. > >> >> > >> >> -- > >> >> John Leslie > >> >> > >> > > >> >_______________________________________________ > >> >Architecture-discuss mailing list > >> >Architecture-discuss@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss > >> > >> >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 11:22:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpofv-0002dy-Ql; Thu, 30 Nov 2006 11:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpofu-0002dt-P2 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:22:14 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpofp-0002az-AB for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:22:14 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 9E61C34142; Thu, 30 Nov 2006 11:22:10 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:22:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Question on what we are identifying Date: Thu, 30 Nov 2006 11:22:06 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038472@tayexc14.americas.cpqcorp.net> In-Reply-To: <9DE9FEE3-24FF-4DD0-983C-79F194E2770B@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Question on what we are identifying Thread-Index: AccUYgmTCwGrbEZ/R+qQtN2YfI87/wAOUl2Q From: "Bound, Jim" To: "Pekka Nikander" , "John Loughney" X-OriginalArrivalTime: 30 Nov 2006 16:22:08.0675 (UTC) FILETIME=[AEB23730:01C7149B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka, I am not 100% in agreement with your characterizations but I cannot = state now what it is I am not comfortable with technically. But, I am = thinking regarding this effort we probably need to identify: 1. What is valid IETF work. 2. What is so far out and requires so many models it should be an = Internet Research Task Force (IRTF) effort. 3. Or we need some metric or test case that we do not bottleneck IETF = work debating and agonizing over IRTF work. Best, /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, November 30, 2006 4:27 AM > To: John Loughney > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Question on what we are identifying >=20 > John, >=20 > > I've been following the discussions, but one thing that I not been=20 > > able to wrap my head around is that if we split the identity &=20 > > locator, what is it that we are identifying. We could be=20 > identifying=20 > > the interface, the stack, the host, the process, the application. >=20 > I think part of the problem is that the current discussion is=20 > taking place at least at two different levels, maybe at more.=20 > To me (and I know I'm at least partially wrong), the two=20 > levels seem to be roughly as follows: >=20 > 1. Most of the time, John Day, Noel, and I are trying to=20 > discuss what would be the "right" long term architecture,=20 > simultaneously knowing that there aren't no such thing. That=20 > is, disregard IP, start from the clean slate, what would be=20 > the better ways of doing things. But learning from the=20 > existing, including its problems. >=20 > 2. The discussion RJ started, and many other threads, are=20 > less ambitious and attempt to "fix" the current architecture=20 > by applying some kind of an identifier/locator split. That=20 > is, add a new name space, add a new layer of indirection, or=20 > do something else of the same magnitude, which is by no means=20 > "small", but pretty much within the current paradigm. >=20 > To me, both of these two discussions are needed. If we can=20 > "fix" the current architecture with something link HIP or=20 > SHIM6, that is good since we will get maybe 10-20 years more=20 > lifetime for it. On the other hand, developing a new=20 > networking paradigm will take at least 10 years of focused=20 > work, and probably much more. Deploying it will take much=20 > longer, if we ever get that far. >=20 > -- >=20 > Given that, in the ideal world, the primary things that we=20 > want to identify, IMHO, are whatever the applications need=20 > to. Most applications want to identify "users" or=20 > "services", but then there those odd diagnostic and other=20 > applications that will need to identify network interfaces,=20 > stacks/hosts, nodes, and even perhaps individual processes. >=20 > Secondly, there are at least two very different "purposes" or=20 > "intentions" for such identification. The applications want=20 > to identify their peer entities for their purposes, which=20 > differ slightly from application to application. The=20 > networking system, on the other hand, want to identify them=20 > for the purposes of communication or reachability. The=20 > difference may appear subtle but is very real can causes=20 > great tensions. >=20 > Basically, all the app wants is a way of exchanging=20 > information with the peer; the desired characteristics of the=20 > "way", such as security, reliability, bandwidth, frequency,=20 > etc, differ. The networking system, on the other hand, will=20 > need to fulfil this need by knowing where the peer entity is,=20 > finding a way there, and being able to transport the=20 > information. None of which are trivial deeds, especially=20 > given the current pretty hostile networking environment. >=20 > This leads to a desire to have a flexible application-level=20 > entity space that can encompass all kinds of entities from=20 > "users" and "services" down to network interfaces, for the=20 > purpose of _applications_. Due to the different intentions,=20 > we apparently need at least two different kinds of name=20 > spaces imposed on the top of this entity space. Firstly, we=20 > apparently need to have names that =20 > fulfil application needs, often dealing with human cognitive needs. =20 > Secondly, we apparently also need names that fulfil the=20 > networking requirements, including location-independency,=20 > security, and reachability. >=20 > Finally, at this level, it is very important to understand=20 > that the names that applications use to name low level=20 > entities such as stacks/ hosts, nodes, and interfaces need=20 > not be the same what are used inside the networking system. =20 > For example, I could imagine using a user level name "Pekka=20 > Nikander's MacBook Pro WLAN" for my WLAN interface, having a=20 > cryptographic public key to denote it in an=20 > location-independent, secure way for diagnosis applications,=20 > while the network still internally eventually mapping both of=20 > those to the MAC address. Note the consequences of this: In=20 > things likes WLAN access control lists I would no longer use=20 > MAC addresses but probably dual human-friendly--cryptographic=20 > names. I would select "Pekka Nikander's MacBook Pro WLAN" in=20 > the GUI and the system would internally store an identifying=20 > cryptographic key. >=20 > -- >=20 > Getting down a level in the discussion, the situation=20 > changes. Now we have to consider the realities of the socket=20 > API. There the most pressing desire seems to be naming=20 > stacks/hosts (abstract entities, host !=3D node). Most people=20 > apparently still would like to refer to applications by using=20 > stack/host names and ports. I'm fine with that, for the time=20 > being, while simultaneously considering that as an archaic notation. >=20 > > For example, with SHIM6, congestion control will be quite difficult=20 > > (if not impossible) if you try to use SHIM addresses with SCTP. As=20 > > SCTP calculates congestion control per network path, if the=20 > addresses=20 > > used no long indicate a network path, all bets are off. >=20 > That's long been a known problem. I tried to open discussion=20 > about that with Randall Stewart and Michael T=FCxen back in=20 > Vancouver, but at time we were unable to find a common=20 > standing point. The base solution was later discussed at=20 > some point of time in some SHIM6 meeting (I don't remember=20 > where and when): the interface between > SHIM6 and SCTP must be richer than today. Basically, you=20 > either store the ULIDs in the IP header and decorate the=20 > packet with the locators (external meta data flowing in the=20 > stack up and down), or vice versa. >=20 > > The discussions on this list have pointed out many possibilities of=20 > > what & how we can identify things, but when I start to look at how=20 > > some of the potential identifiers map to transport protocols, to=20 > > processes, to applications, things get a bit messy. >=20 > As always :-) >=20 > > Does anyone have any pointers on background reading on this issue? >=20 > For one, I have never before been able to speak about the=20 > architecture at the "higher" level of this discussion. Until=20 > recently, I couldn't see beyond IP and the=20 > per-packet-send-receive & hop-by-hop-forwarding paradigms=20 > that we rely on. >=20 > For the "lower" level, or merely implementing id/loc split=20 > while retaining most of the current architecture and=20 > especially the current socket API, there are lots of=20 > written-down thoughts in the HIP community, including the following: >=20 > http://www.ietf.org/rfc/rfc4423.txt > http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-00.txt > (needs much more work) > http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt >=20 > I think there are similar thoughts and documents written for=20 > SHIM6, but I am not aware of the details. >=20 > Unfortunately, I don't know if any of them addresses=20 > especially what you ask for, but maybe RFC 4423 does in some sense. >=20 > --Pekka Nikander >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 11:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpohN-0003Xl-8G; Thu, 30 Nov 2006 11:23:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpohL-0003Xg-G3 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:23:43 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpohK-0002n7-AF for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:23:43 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0B35F86AF7; Thu, 30 Nov 2006 11:23:42 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Message-Id: <20061130162342.0B35F86AF7@mercury.lcs.mit.edu> Date: Thu, 30 Nov 2006 11:23:42 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Bound, Jim" > Note the list is ram@ietf.org but it is silent should we all be using > that list, can someone here make an exec decision that we move this > discussion to ram? Well, that list is about routing and routing-names - since most of the discussion here is really about higher-level names (e.g. for transport entities) I think most of the recent discussion is properly here. Now, if we were to start talking about, say, the jack-up model (i.e. sliding a new layer below, to do routing), and how we'd carry existing addresses in the new routing plane, that would be a good topic for there. And that is the hardest problem, I think... Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 11:33:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpoq3-00022s-E7; Thu, 30 Nov 2006 11:32:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpoq2-0001zK-1T for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:32:42 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpopk-0003wu-Os for architecture-discuss@ietf.org; Thu, 30 Nov 2006 11:32:41 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 51082340A9; Thu, 30 Nov 2006 11:32:24 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:32:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Date: Thu, 30 Nov 2006 11:32:22 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010384A9@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061130162342.0B35F86AF7@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Thread-Index: AccUm+nhQ7F7BvzeQM6zZkt1ihobqQAAS4Bw From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 30 Nov 2006 16:32:24.0003 (UTC) FILETIME=[1D75D130:01C7149D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org works for me. thx /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, November 30, 2006 11:24 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [arch-d] On identifiers: what is virtual and=20 > what is global (wasRe: thou... >=20 > > From: "Bound, Jim" >=20 > > Note the list is ram@ietf.org but it is silent should=20 > we all be using > > that list, can someone here make an exec decision that=20 > we move this > > discussion to ram? >=20 > Well, that list is about routing and routing-names - since=20 > most of the discussion here is really about higher-level=20 > names (e.g. for transport > entities) I think most of the recent discussion is properly here. >=20 > Now, if we were to start talking about, say, the jack-up=20 > model (i.e. sliding a new layer below, to do routing), and=20 > how we'd carry existing addresses in the new routing plane,=20 > that would be a good topic for there. And that is the hardest=20 > problem, I think... >=20 > Noel >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 12:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppHS-00020z-Qj; Thu, 30 Nov 2006 12:01:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppHR-00020o-8G for architecture-discuss@ietf.org; Thu, 30 Nov 2006 12:01:01 -0500 Received: from web58702.mail.re1.yahoo.com ([66.196.100.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GppHP-0007u7-JP for architecture-discuss@ietf.org; Thu, 30 Nov 2006 12:01:01 -0500 Received: (qmail 40978 invoked by uid 60001); 30 Nov 2006 17:00:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MTaNkWYe8IL56HzYZyCOhimZPcPPpOlqzPx9cNiLLicEYvcL4BRT+yziUbZlcMh63y1Swfw+fmiv5VhpkcTwS5HYWpHaKEkqsL1wtMnNziiiUgMnRxpEZ8Iawk6dKFXEXUnHOWjY+YI7UWFcTwnJUqwFfamRPaNlTlrTfL7fqLk=; X-YMail-OSG: k2HUOIAVM1kf29WjQSNORMmifyWIByUiLMCH77MNJuXspK4c5VjRkj8xd73pJOCD4kI5aCZ9eBrFE77UJKYVaVew9fzpOCx4I7UEFOsBnK9ZzmelNF7JFR79H.VYODYIIJfH2Oa7eYvnAv07dZGV24dFV3YC2x22Xdnx_ruxKxI4M2tY8XcSRbVFp5I- Received: from [207.107.50.100] by web58702.mail.re1.yahoo.com via HTTP; Thu, 30 Nov 2006 09:00:58 PST Date: Thu, 30 Nov 2006 09:00:58 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] Question on what we are identifying To: john.loughney@nokia.com, architecture-discuss@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <192620.40776.qm@web58702.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Does anyone have any pointers on background reading on this issue? IMO originally people were concerned on how to get computation done on a circuit. Then they have combined a few circuits + I/O into a system. The next step was to get processes in connected systems find each other and talk. This bottom up development for obvious reasons under thought of the global architecture from microcomputers to the Milky Way and beyond. IMHO we are blessed with IPv6 breakthrough and a white board to put such architecture in place. Thanks, Peter --- john.loughney@nokia.com wrote: > Hi all, > > I've been following the discussions, but one thing that I not been able > to wrap my head > around is that if we split the identity & locator, what is it that we > are identifying. > We could be identifying the interface, the stack, the host, the process, > the application. > > For example, with SHIM6, congestion control will be quite difficult (if > not impossible) if > you try to use SHIM addresses with SCTP. As SCTP calculates congestion > control per network > path, if the addresses used no long indicate a network path, all bets > are off. > > The discussions on this list have pointed out many possibilities of what > & how we can > identify things, but when I start to look at how some of the potential > identifiers map > to transport protocols, to processes, to applications, things get a bit > messy. > > Does anyone have any pointers on background reading on this issue? > > thanks, > John > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 12:37:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpppZ-000465-V7; Thu, 30 Nov 2006 12:36:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpppZ-000460-HY for architecture-discuss@ietf.org; Thu, 30 Nov 2006 12:36:17 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpppT-0003Sb-9M for architecture-discuss@ietf.org; Thu, 30 Nov 2006 12:36:17 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id A301A3408E; Thu, 30 Nov 2006 12:36:08 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 12:36:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 12:36:06 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038553@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061129215219.GB2467@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transport layer identifier evolutiion to support multihoming Thread-Index: AccUAKnotXERqNixQNuDeDV+dnJXRgAozugg From: "Bound, Jim" To: "John Leslie" X-OriginalArrivalTime: 30 Nov 2006 17:36:07.0359 (UTC) FILETIME=[045BA4F0:01C714A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: architecture-discuss@ietf.org Subject: [arch-d] transport layer identifier evolutiion to support multihoming X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, To answer your arch transport layer question previously to me, within the context of this list discussion (leap of faith on my part :--)).=20 - Transport protocol end-to-end communications connectivity should evolve to identifiers and ports not using IPvN addresses. - Transport identifiers could also be used as IPsec identifiers for the SPI in conjunction with the IPvN dst address, but the IPvN dst address I believe must stay in tact as archtype for any new routing architecture at least at this point in the discussions, thus also for IPsec SPI. - Transport identifiers need to be cryptographically secure. - Transport identifiers are not the same as routing identifiers. - Transport identifiers can be deferenced to find locators as required for "implementation" of the required stack lookups, interfaces, etc. as best current practice today for connections between two applications/processes/services-instance, and used to identify network path as required by a transport protocol. NB: shim6 and hip IETF contributors (engineers, operators, architects, technologists) are well underway to evolve to the above not exactly in all cases but the bases of such technology evolution is in process. shim6 appears to have the greatest IETF consensus to move forward at this time in the IETF having adopted some of the hip architecture and precepts. And the devil is in the details as always. Best, /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 13:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqOi-0000o2-Ku; Thu, 30 Nov 2006 13:12:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqOh-0000nX-KN for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:12:35 -0500 Received: from web58713.mail.re1.yahoo.com ([66.196.100.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpqOg-0000Fi-9r for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:12:35 -0500 Received: (qmail 16183 invoked by uid 60001); 30 Nov 2006 18:12:34 -0000 Message-ID: <20061130181233.16181.qmail@web58713.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=PmMOPyrNabcY/1rB9TE87mOlw6I30O9WfThmynUpgu5q++HuCTdDHU+59sNNyxdfgxqxC/X8LLBEei+yvT/6TjUoaAp89tV3VsW2HisQ36IE3S+WnoImSLoRCstOMIxaoX4wN5z8GD0+jqLrvj/wxRYAk7IQXT7o+TUaiRg0gnQ=; X-YMail-OSG: tPAjgtQVM1mqjAJkgAR3QlSsOxrkm.1DYy4XTkL9uR7YXgRYRjmt._miIeIYLu3dJS6kVEn6LtGTPl260CFk.unLkaXZBJesuCPB5Edt_mia.pdjrpdElNKY4Di57JoAnd.FadUkoB2BxKXARAJlsxVjoWLLonCf2ttpDg7v.Y0wDUfDcfClqipaQpg- Received: from [207.107.50.100] by web58713.mail.re1.yahoo.com via HTTP; Thu, 30 Nov 2006 10:12:33 PST Date: Thu, 30 Nov 2006 10:12:33 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: John Day , David Conrad , "Bound, Jim" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Although right after that he refers to it as a route service. IMO for him both terms bear the same meaning. > What node hierarchy? Arrangements inside the node that are independent of and transparent to routing. > This is science. Our goal is to find the minimal set of concepts > that encompass the whole problem.. The attitude that most systems > are not multihomed... OK, science describes via definitions and assumptions. That most systems are not multihomed is an assumption, where system = node performing an individual task. Nodes are aggregated in private networks. Most private networks are (or will be) multihomed. A question to all: are we ready to start documenting architectural requirements and assumptions? If yes, by what mechanism? Thanks, Peter --- John Day wrote: > At 18:56 -0800 2006/11/29, Peter Sherbin wrote: > > > Actually he says routes, not paths. > > > >for the sake of accuracy: "4. Paths. These run between network attachment > >points,..." [RFC 1498, p.3] > > ooops, bad memory! I knew I should have checked it. Although right > after that he refers to it as a route service. > > > >...he says that application names map to node addresses and node > >addresses are > >mapped to point of attachment addresses which are mapped to routes. > > > >1. The above requirement is not mandatory for routing. Node hierarchy can be > >transparent to the network hierarchy. > > What node hierarchy? Address assignment hierarchies are used to > better manage address space their correspondence to hierarchies of > subnets is purely coincidental. It is important not to confuse the > two. > > >2. It holds true for a limited sample of relatively big machines > >supporting several > >applications and/or multiple interfaces. For the prevailing majority of > >microcomputers and sensors Application = Node = Interface. > > This is science. Our goal is to find the minimal set of concepts > that encompass the whole problem.. The attitude that most systems > are not multihomed and therefore we don't need to look for a real > solution is what got us into this mess to begin with. > > > > >> You are looking for a kludge. > >More thoughts > >>>- unless a mobile node on a foreign AS sends a packet, home node > >>>does not know > >>> where the mobile node is > >Which is OK, because home needs an info from the remote node and the > >remote node > >first will have to contact home > > We have already established that a mobility solution with a concept > of "home" is a kludge. > > > >>- private networks who want to communicate have to acquire each > >other ASN in > >>>advance > >OK, because now I control whom I am going to communicate with > > > >>>- scalability of AS hierarchy > >non issue, there is no need even to extend 16bit ASN to 32bit, > >instead introduce > >upper tier ASN > > > >>>- scalability of routing within AS > >mitigate by e.g. limiting number of /32's per AS > > > >> what protocol carries the point of attachment address? > >IP > > Gee, I thought it was MAC protocol. > > > > what protocol carries the node address? > >IP, where node = interface > > Node does not equal interface. That is why we are having this discussion. > > But you are right. IP does carry point of attachment and the IETF in > its infinite (and misguided) wisdom has decreed that it shall be the > case: Full emulation of Faber Marching Band. > > > > what protocol carries the application name? > >TCP, but does it really need an application name? > > TCP!? Or any such protocol? Nah. Have you looked at these > protocols? They are purely single instances of communication. They > have no functionality across instances. Very clean. We don't want > to destroy that. Don't make them any more complex than they are. > > What about application connections? > > Take care, > John > ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 13:39:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqnH-0004Mm-JK; Thu, 30 Nov 2006 13:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqnG-0004Ks-G9 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:37:58 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqnE-0003HW-8E for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:37:58 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc13) with ESMTP id <20061130183745b1300btfgce>; Thu, 30 Nov 2006 18:37:55 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061130181233.16181.qmail@web58713.mail.re1.yahoo.com> References: <20061130181233.16181.qmail@web58713.mail.re1.yahoo.com> Date: Thu, 30 Nov 2006 13:37:34 -0500 To: Peter Sherbin , John Day , David Conrad , "Bound, Jim" From: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:12 -0800 2006/11/30, Peter Sherbin wrote: > > Although right after that he refers to it as a route service. >IMO for him both terms bear the same meaning. > >> What node hierarchy? > >Arrangements inside the node that are independent of and transparent >to routing. Huh? Hierarchy within the system? > >> This is science. Our goal is to find the minimal set of concepts >> that encompass the whole problem.. The attitude that most systems >> are not multihomed... > >OK, science describes via definitions and assumptions. That most >systems are not >multihomed is an assumption, where system = node performing an >individual task. >Nodes are aggregated in private networks. Most private networks are >(or will be) >multihomed. Not quite. That only goes as far as natural history. Science finds the smallest number of concepts that describe the widest range of phenomena and from which predictions can be made. As to your definitions, why set your sights so low? You are trying to make simplifying assumptions before you even know if it is necessary. As I pointed out last night, this assumption that most systems are not multihomed is what got us n this mess to start with. Shall we continue it? >A question to all: are we ready to start documenting architectural >requirements and >assumptions? If yes, by what mechanism? I think we need a model. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 13:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxr-0008Hl-3S; Thu, 30 Nov 2006 13:48:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxo-0008FH-Uw for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:48:52 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqvP-00042u-Ga for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:46:26 -0500 Received: from gihm3.apnic.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kAUIk3NO065680; Fri, 1 Dec 2006 05:46:05 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061201053851.02d341e8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 01 Dec 2006 05:42:49 +1100 To: Brian E Carpenter , john.loughney@nokia.com From: Geoff Huston Subject: Re: [arch-d] Question on what we are identifying In-Reply-To: <456EDD84.7050501@zurich.ibm.com> References: <456EDD84.7050501@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:32 AM 1/12/2006, Brian E Carpenter wrote: >>For example, with SHIM6, congestion control will be quite difficult (if >>not impossible) if you try to use SHIM addresses with SCTP. As SCTP >>calculates congestion >>control per network >>path, if the addresses used no long indicate a network path, all bets >>are off. > >Which is why the shim6 model has to include the option of allowing the >transport layer to switch off the shim. Well "not to turn it on the first place" for a particular session is perhaps a better way of phrasing it. And, yes, the SHIM6 effort has thought about SCTP and thought that it would be prudent for such a transport protocol to signal via such a mechanism that it does not require, and would not benefit from, a SHIM6 function further down the stack. But I suspect with my nitpicking here I've strayed off into the undergrowth - sorry! Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 13:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxs-0008J2-BR; Thu, 30 Nov 2006 13:48:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxp-0008FP-O8 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:48:53 -0500 Received: from outmail136005.authsmtp.com ([62.13.136.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpquW-0003zP-4W for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:45:32 -0500 Received: from outmail128179.authsmtp.co.uk (outmail128179.authsmtp.co.uk [62.13.128.179]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id kAUIjQWG019385 for ; Thu, 30 Nov 2006 18:45:27 GMT Received: from IAN (203-217-34-245.dyn.iinet.net.au [203.217.34.245]) (authenticated bits=0) by mail.authsmtp.com (8.13.6/8.13.6/Kp) with ESMTP id kAUIjM33085399 for ; Thu, 30 Nov 2006 18:45:24 GMT From: "Ian Peter" To: Date: Fri, 1 Dec 2006 05:44:09 +1100 Message-ID: <018a01c714af$877f07b0$4a02a8c0@IAN> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccUmCwNQb6aY5/aTEeyGsyclO4L9wAFf2tQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-Server-Quench: f1724e92-80a2-11db-b4dc-001185d377ca X-AuthRoute: OCdyZgEQClZURQJc Ei4YATVoSAwjPhBQ DAVFJgxfNlMTXgRQ LktRMkdJPRgQREpS RiVIKw0BFAtvBiEi JQlRcnsCJFVMXwVs QElBSFZXHgduTx4B BQAcUx5sdAFYenp1 ekRnXHVEXAohBCME GDNXFm0OYGRpYS4X VkdaOVVVdwFOKxZH d1h/BXEQYGRTNGcy QwM4emhpZGwPdSgO HV4GJEQ8QEAHHzgz DxlKAjw+VUMCXTo6 NRBO X-Authentic-SMTP: 61633136393539.squirrel.dmpriest.net.uk:315/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Spam-Score: 0.5 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Subject: [arch-d] Finding a way forward X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Assuming that action is required and this is not just an interesting discussion - Can someone give a best guesstimate as regards what timeframe the = problem is likely to severly affect Internet performance - are we talking 3 years = or 10 or further? That should help to indicate whether a bandaid approach is absolutely necessary or whether a more wholistic approach should be concentrated = on. I certainly suggest you avoid trying to do both on the same list (if = both are necessary) The next step after this preliminary analysis would be to evaluate realistically what could be done (that=92s means implemented, not just a standard) in the timeframe in which action is needed. Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: John Day [mailto:jeanjour@comcast.net]=20 Sent: 01 December 2006 02:51 To: Bound, Jim; John Day; John Leslie Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... I believe that a week or so ago a list was created to address the=20 problem you describe. As I understand it, this list was created to=20 address the fact that for the past 30 years the Internet has shirked=20 its responsibility to do the work necessary to provide a complete and=20 well thought out architecture. As was expressed at the beginning of this discussion a few weeks ago,=20 we have to give up this constant band-aid approach. We have to find=20 the *solutions.* Then we can trade our band-aids in for steps toward=20 an answer. As for transport, yes, we do have a number of bad examples in the data. At 3:38 -0500 2006/11/30, Bound, Jim wrote: >I am working here on engineering (not a computer science research >project) for an architecture that will assist routing, but alleviating >the business problem for operators that are not just network providers >from the multihoming problem to some degree permits us more time to >resolve the architecture issue at hand for routing. If the transport >layer, which does rely on IPvN addresses in any implementation code I >have ever seen for lookups etc., can be made to not be dependent on = IPvN >addresses, that will permit aggregation of IPvN addresses for some time >to avoid the collision presented by the IAB at San Diego potentially. >Thus it is important and I don't agree with John Day. > >Best, >/jim > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Wednesday, November 29, 2006 9:14 PM >> To: Bound, Jim; John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Not quite. Sooner or later you are going to realize that >> that there are no such thing as Transport Addresses. In >> fact, transport is sort of a minor layer at best. As far as >> this problem is concerned, Transport is irrelevant to the solution. >> >> Transport has no effect on the routing and its components and >> doesn't constrain its possibilities in the least. >> >> QED >> >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: >> >agree again. also no attachment to src addresses at my end. >> agree on >> >identifying transport points of the protocols to the >> architecture but >> >want to go offline with Pekka N. on that one and can do as I >> can around >> >the day job of course. the reason to do this arch exercise is the >> >potential of freeing the transport layer from IPvN layer and >> >components, which affords routing more freedom in thinking >> models. but >> >to note both >> >shim6 and hip have done this and some implementation exists. >> > >> >Best, >> >/jim >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Wednesday, November 29, 2006 4:52 PM >> >> To: Bound, Jim >> >> Cc: architecture-discuss@ietf.org >> >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is >> >> global (wasRe: thou... >> >> >> >> Bound, Jim wrote: >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly >> >> recommend that we call the "thing" that sits in >> >> the IPv4 >> >> >>header as destination address an "IPv4 destination=20 >> address", and >> >> the >>"thing" that sits in the IPv6 header as a=20 >> destination address >> >> an >> >> >>"IPv6 destination address". >> >> >>... >> >> >> (The actual parameters passed to operating systems to >> open TCP=20 >> >> >>sockets and connections are _also_ something else >> >> entirely: we >> >> must not confuse TCP endpoints with IPvN destination >> >> >>addresses.) >> >> > >> >> > Two points I do want to note for discussion are > > what is >> >> passed to transport connections are end-to-end=20 >> identifiers in > my >> >> view and should not be exposed in the IPvN headers or used for > >> >> loc+id. >> >> >> >> I agree they are end-to-end identifiers, even if they look=20 > > >> exactly like IPvN addresses. >> >> >> >> That they currently are exposed in IPvN headers is an >> accident of >> >> history: TCP never defined a standard for exchanging >> anything else >> >> as endpoint identifiers. (Clearly, both ends of a TCP connection >> >> need to agree how to distinguish that a packet belongs to that >> >> connection: IPvN addresses have worked OK for that purpose. >> >> Endpoint identifiers _could_ be something else entirely; >> and need >> >> not be visible at all to the IPvN layer.) >> >> >> >> We must allow _something_ to be used for loc+id within >> IPvN; but >> >> it'd be fine if, for example, the application passed FQDNs as = the >> >> endpoint IDs and the operating system did a DNS-like >> query to find=20 >> >> loc+id. >> >> >> >> > Also on source addresses my pain has been if they get altered >> >> then I > am unclear how I respond back at the OS transport end. >> >> >> >> This is indeed a mess right now. NAT boxes routinely >> alter thFrom architecture-discuss-bounces@ietf.org Thu Nov 30 13:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxr-0008Hl-3S; Thu, 30 Nov 2006 13:48:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxo-0008FH-Uw for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:48:52 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqvP-00042u-Ga for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:46:26 -0500 Received: from gihm3.apnic.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kAUIk3NO065680; Fri, 1 Dec 2006 05:46:05 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061201053851.02d341e8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 01 Dec 2006 05:42:49 +1100 To: Brian E Carpenter , john.loughney@nokia.com From: Geoff Huston Subject: Re: [arch-d] Question on what we are identifying In-Reply-To: <456EDD84.7050501@zurich.ibm.com> References: <456EDD84.7050501@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:32 AM 1/12/2006, Brian E Carpenter wrote: >>For example, with SHIM6, congestion control will be quite difficult (if >>not impossible) if you try to use SHIM addresses with SCTP. As SCTP >>calculates congestion >>control per network >>path, if the addresses used no long indicate a network path, all bets >>are off. > >Which is why the shim6 model has to include the option of allowing the >transport layer to switch off the shim. Well "not to turn it on the first place" for a particular session is perhaps a better way of phrasing it. And, yes, the SHIM6 effort has thought about SCTP and thought that it would be prudent for such a transport protocol to signal via such a mechanism that it does not require, and would not benefit from, a SHIM6 function further down the stack. But I suspect with my nitpicking here I've strayed off into the undergrowth - sorry! Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 13:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxs-0008J2-BR; Thu, 30 Nov 2006 13:48:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxp-0008FP-O8 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:48:53 -0500 Received: from outmail136005.authsmtp.com ([62.13.136.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpquW-0003zP-4W for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:45:32 -0500 Received: from outmail128179.authsmtp.co.uk (outmail128179.authsmtp.co.uk [62.13.128.179]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id kAUIjQWG019385 for ; Thu, 30 Nov 2006 18:45:27 GMT Received: from Iese >> >> and "try" to maintain enough state to alter them back. :*( >> >> >> >> > But if I am no longer using the notion of a current source=20 >> >> address at > the transport end I don't care about that >> anymore and >> >> if that is > possible that is a good thing. >> >> >> >> IPvN source addresses are used to report routing problems: >> >> other than that, they can mostly be ignored. (Indeed, they = can't >> >> even be trusted for that much: the less we depend on them, the >> >> better.) >> >> >> >> (There was a time when we believed routing based on source=20 >> >> address would help. Most of us would like to bury that idea...) >> >> >> >> > I believe shim6 and hip get us very close to this model >> for the > >> >> transport with current architecturs and specifications. >> >> >> >> I must admit that I view both shim6 and hip as moving = targets >> >> trying to be too many things to too many people. I=20 >> suspect I'm not >> >> alone. In any case, both of those are engineering, not >> architecture; >> >> for purposes of this list I >> > > suggest explaining which features of them you'd like to >> >> compare, rather than just naming a protocol. >> >> >> >> -- >> >> John Leslie >> >> >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss AN (203-217-34-245.dyn.iinet.net.au [203.217.34.245]) (authenticated bits=0) by mail.authsmtp.com (8.13.6/8.13.6/Kp) with ESMTP id kAUIjM33085399 for ; Thu, 30 Nov 2006 18:45:24 GMT From: "Ian Peter" To: Date: Fri, 1 Dec 2006 05:44:09 +1100 Message-ID: <018a01c714af$877f07b0$4a02a8c0@IAN> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccUmCwNQb6aY5/aTEeyGsyclO4L9wAFf2tQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-Server-Quench: f1724e92-80a2-11db-b4dc-001185d377ca X-AuthRoute: OCdyZgEQClZURQJc Ei4YATVoSAwjPhBQ DAVFJgxfNlMTXgRQ LktRMkdJPRgQREpS RiVIKw0BFAtvBiEi JQlRcnsCJFVMXwVs QElBSFZXHgduTx4B BQAcUx5sdAFYenp1 ekRnXHVEXAohBCME GDNXFm0OYGRpYS4X VkdaOVVVdwFOKxZH d1h/BXEQYGRTNGcy QwM4emhpZGwPdSgO HV4GJEQ8QEAHHzgz DxlKAjw+VUMCXTo6 NRBO X-Authentic-SMTP: 61633136393539.squirrel.dmpriest.net.uk:315/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Spam-Score: 0.5 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Subject: [arch-d] Finding a way forward X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Assuming that action is required and this is not just an interesting discussion - Can someone give a best guesstimate as regards what timeframe the = problem is likely to severly affect Internet performance - are we talking 3 years = or 10 or further? That should help to indicate whether a bandaid approach is absolutely necessary or whether a more wholistic approach should be concentrated = on. I certainly suggest you avoid trying to do both on the same list (if = both are necessary) The next step after this preliminary analysis would be to evaluate realistically what could be done (that=92s means implemented, not just a standard) in the timeframe in which action is needed. Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: John Day [mailto:jeanjour@comcast.net]=20 Sent: 01 December 2006 02:51 To: Bound, Jim; John Day; John Leslie Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... I believe that a week or so ago a list was created to address the=20 problem you describe. As I understand it, this list was created to=20 address the fact that for the past 30 years the Internet has shirked=20 its responsibility to do the work necessary to provide a complete and=20 well thought out architecture. As was expressed at the beginning of this discussion a few weeks ago,=20 we have to give up this constant band-aid approach. We have to find=20 the *solutions.* Then we can trade our band-aids in for steps toward=20 an answer. As for transport, yes, we do have a number of bad examples in the data. At 3:38 -0500 2006/11/30, Bound, Jim wrote: >I am working here on engineering (not a computer science research >project) for an architecture that will assist routing, but alleviating >the business problem for operators that are not just network providers >from the multihoming problem to some degree permits us more time to >resolve the architecture issue at hand for routing. If the transport >layer, which does rely on IPvN addresses in any implementation code I >have ever seen for lookups etc., can be made to not be dependent on = IPvN >addresses, that will permit aggregation of IPvN addresses for some time >to avoid the collision presented by the IAB at San Diego potentially. >Thus it is important and I don't agree with John Day. > >Best, >/jim > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Wednesday, November 29, 2006 9:14 PM >> To: Bound, Jim; John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Not quite. Sooner or later you are going to realize that >> that there are no such thing as Transport Addresses. In >> fact, transport is sort of a minor layer at best. As far as >> this problem is concerned, Transport is irrelevant to the solution. >> >> Transport has no effect on the routing and its components and >> doesn't constrain its possibilities in the least. >> >> QED >> >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: >> >agree again. also no attachment to src addresses at my end. >> agree on >> >identifying transport points of the protocols to the >> architecture but >> >want to go offline with Pekka N. on that one and can do as I >> can around >> >the day job of course. the reason to do this arch exercise is the >> >potential of freeing the transport layer from IPvN layer and >> >components, which affords routing more freedom in thinking >> models. but >> >to note both >> >shim6 and hip have done this and some implementation exists. >> > >> >Best, >> >/jim >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Wednesday, November 29, 2006 4:52 PM >> >> To: Bound, Jim >> >> Cc: architecture-discuss@ietf.org >> >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is >> >> global (wasRe: thou... >> >> >> >> Bound, Jim wrote: >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly >> >> recommend that we call the "thing" that sits in >> >> the IPv4 >> >> >>header as destination address an "IPv4 destination=20 >> address", and >> >> the >>"thing" that sits in the IPv6 header as a=20 >> destination address >> >> an >> >> >>"IPv6 destination address". >> >> >>... >> >> >> (The actual parameters passed to operating systems to >> open TCP=20 >> >> >>sockets and connections are _also_ something else >> >> entirely: we >> >> must not confuse TCP endpoints with IPvN destination >> >> >>addresses.) >> >> > >> >> > Two points I do want to note for discussion are > > what is >> >> passed to transport connections are end-to-end=20 >> identifiers in > my >> >> view and should not be exposed in the IPvN headers or used for > >> >> loc+id. >> >> >> >> I agree they are end-to-end identifiers, even if they look=20 > > >> exactly like IPvN addresses. >> >> >> >> That they currently are exposed in IPvN headers is an >> accident of >> >> history: TCP never defined a standard for exchanging >> anything else >> >> as endpoint identifiers. (Clearly, both ends of a TCP connection >> >> need to agree how to distinguish that a packet belongs to that >> >> connection: IPvN addresses have worked OK for that purpose. >> >> Endpoint identifiers _could_ be something else entirely; >> and need >> >> not be visible at all to the IPvN layer.) >> >> >> >> We must allow _something_ to be used for loc+id within >> IPvN; but >> >> it'd be fine if, for example, the application passed FQDNs as = the >> >> endpoint IDs and the operating system did a DNS-like >> query to find=20 >> >> loc+id. >> >> >> >> > Also on source addresses my pain has been if they get altered >> >> then I > am unclear how I respond back at the OS transport end. >> >> >> >> This is indeed a mess right now. NAT boxes routinely >> alter these >> >> and "try" to maintain enough state to alter them back. :*( >> >> >> >> > But if I am no longer using the notion of a current source=20 >> >> address at > the transport end I don't care about that >> anymore and >> >> if that is > possible that is a good thing. >> >> >> >> IPvN source addresses are used to report routing problems: >> >> other than that, they can mostly be ignored. (Indeed, they = can't >> >> even be trusted for that much: the less we depend on them, the >> >> better.) >> >> >> >> (There was a time when we believed routing based on source=20 >> >> address would help. Most of us would like to bury that idea...) >> >> >> >> > I believe shim6 and hip get us very close to this model >> for the > >> >> transport with current architecturs and specifications. >> >> >> >> I must admit that I view both shim6 and hip as moving = targets >> >> trying to be too many things to too many people. I=20 >> suspect I'm not >> >> alone. In any case, both of those are engineering, not >> architecture; >> >> for purposes of this list I >> > > suggest explaining which features of them you'd like to >> >> compare, rather than just naming a protocol. >> >> >> >> -- >> >> John Leslie >> >> >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 14:00:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpr8D-0005fy-GW; Thu, 30 Nov 2006 13:59:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpr8C-0005ee-8i for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:59:36 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpr8A-0005qI-WC for architecture-discuss@ietf.org; Thu, 30 Nov 2006 13:59:36 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc14) with ESMTP id <20061130185931b1400pd7t5e>; Thu, 30 Nov 2006 18:59:32 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01038553@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC01038553@tayexc14.americas.cpqcorp.net> Date: Thu, 30 Nov 2006 13:56:51 -0500 To: "Bound, Jim" , "John Leslie" From: John Day Subject: Re: [arch-d] transport layer identifier evolutiion to support multihoming Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:36 -0500 2006/11/30, Bound, Jim wrote: >John, > >To answer your arch transport layer question previously to me, within >the context of this list discussion (leap of faith on my part :--)). > >- Transport protocol end-to-end communications connectivity should >evolve to identifiers and ports not using IPvN addresses. We need to be careful here. I have been thinking about this *a lot* and you are on the right track. And I realize that you are using the nomenclature you know. But there are considerable benefits that accrue if the identifiers you speak of are not associated with the protocols we normally associate with the "Transport protocols." The only identifiers they need and should have are the connection-identifier, i.e. source and destination port-ids they have now. > >- Transport identifiers could also be used as IPsec identifiers for the >SPI in conjunction with the IPvN dst address, but the IPvN dst address I >believe must stay in tact as archtype for any new routing architecture >at least at this point in the discussions, thus also for IPsec SPI. > >- Transport identifiers need to be cryptographically secure. > >- Transport identifiers are not the same as routing identifiers. > >- Transport identifiers can be deferenced to find locators as required >for "implementation" of the required stack lookups, interfaces, etc. as >best current practice today for connections between two >applications/processes/services-instance, and used to identify network >path as required by a transport protocol. > >NB: shim6 and hip IETF contributors (engineers, operators, architects, >technologists) are well underway to evolve to the above not exactly in >all cases but the bases of such technology evolution is in process. >shim6 appears to have the greatest IETF consensus to move forward at >this time in the IETF having adopted some of the hip architecture and >precepts. And the devil is in the details as always. > >Best, >/jim > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 14:15:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprLm-0002Pu-Jk; Thu, 30 Nov 2006 14:13:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprLl-0002Mh-Hw for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:13:37 -0500 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprLk-0007Fy-19 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:13:37 -0500 Received: from ([10.160.67.162]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.129246590; Thu, 30 Nov 2006 14:26:44 -0500 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K05.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Nov 2006 14:13:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Finding a way forward Date: Thu, 30 Nov 2006 14:13:06 -0500 Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D041BE@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Finding a way forward Thread-Index: AccUmCwNQb6aY5/aTEeyGsyclO4L9wAFf2tQAAFKVGA= From: "Azinger, Marla" To: "Ian Peter" , X-OriginalArrivalTime: 30 Nov 2006 19:13:07.0083 (UTC) FILETIME=[912F0DB0:01C714B3] X-Spam-Score: 0.5 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hello Ian- Yes, action is required Asking for a best guess timefame is opening a can of warms. You will = receive answers ranging from 4 years, 20 years and never. Lessons learned from the past show us "bandaids" are just that ( they = tend to degrade in worth). Acknowleding this are a number of people = looking for a balanced solution that is technically sound and = acknowledges time to implementation. =20 So you want difinitive answers on solution and time. This really cant = be done. But what can be done and what several people are attempting to = do is accept that we need a solution and that we need it relatively = quickly (1-4 years). Yes, there will always be people that want to = debate the method and the timeframe to the third degree. However, there = are also people willing to take the facts from these debates and pick a = direction and go with it, and that is when solutions are made. It will = happen. Thank you for your time Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: Ian Peter [mailto:ian.peter@ianpeter.com] Sent: Thursday, November 30, 2006 10:44 AM To: architecture-discuss@ietf.org Subject: [arch-d] Finding a way forward Assuming that action is required and this is not just an interesting discussion - Can someone give a best guesstimate as regards what timeframe the = problem is likely to severly affect Internet performance - are we talking 3 years = or 10 or further? That should help to indicate whether a bandaid approach is absolutely necessary or whether a more wholistic approach should be concentrated = on. I certainly suggest you avoid trying to do both on the same list (if = both are necessary) The next step after this preliminary analysis would be to evaluate realistically what could be done (that=92s means implemented, not just a standard) in the timeframe in which action is needed. Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: John Day [mailto:jeanjour@comcast.net]=20 Sent: 01 December 2006 02:51 To: Bound, Jim; John Day; John Leslie Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... I believe that a week or so ago a list was created to address the=20 problem you describe. As I understand it, this list was created to=20 address the fact that for the past 30 years the Internet has shirked=20 its responsibility to do the work necessary to provide a complete and=20 well thought out architecture. As was expressed at the beginning of this discussion a few weeks ago,=20 we have to give up this constant band-aid approach. We have to find=20 the *solutions.* Then we can trade our band-aids in for steps toward=20 an answer. As for transport, yes, we do have a number of bad examples in the data. At 3:38 -0500 2006/11/30, Bound, Jim wrote: >I am working here on engineering (not a computer science research >project) for an architecture that will assist routing, but alleviating >the business problem for operators that are not just network providers >from the multihoming problem to some degree permits us more time to >resolve the architecture issue at hand for routing. If the transport >layer, which does rely on IPvN addresses in any implementation code I >have ever seen for lookups etc., can be made to not be dependent on = IPvN >addresses, that will permit aggregation of IPvN addresses for some time >to avoid the collision presented by the IAB at San Diego potentially. >Thus it is important and I don't agree with John Day. > >Best, >/jim > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Wednesday, November 29, 2006 9:14 PM >> To: Bound, Jim; John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Not quite. Sooner or later you are going to realize that >> that there are no such thing as Transport Addresses. In >> fact, transport is sort of a minor layer at best. As far as >> this problem is concerned, Transport is irrelevant to the solution. >> >> Transport has no effect on the routing and its components and >> doesn't constrain its possibilities in the least. >> >> QED >> >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: >> >agree again. also no attachment to src addresses at my end. >> agree on >> >identifying transport points of the protocols to the >> architecture but >> >want to go offline with Pekka N. on that one and can do as I >> can around >> >the day job of course. the reason to do this arch exercise is the >> >potential of freeing the transport layer from IPvN layer and >> >components, which affords routing more freedom in thinking >> models. but >> >to note both >> >shim6 and hip have done this and some implementation exists. >> > >> >Best, >> >/jim >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Wednesday, November 29, 2006 4:52 PM >> >> To: Bound, Jim >> >> Cc: architecture-discuss@ietf.org >> >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is >> >> global (wasRe: thou... >> >> >> >> Bound, Jim wrote: >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly >> >> recommend that we call the "thing" that sits in >> >> the IPv4 >> >> >>header as destination address an "IPv4 destination=20 >> address", and >> >> the >>"thing" that sits in the IPv6 header as a=20 >> destination address >> >> an >> >> >>"IPv6 destination address". >> >> >>... >> >> >> (The actual parameters passed to operating systems to >> open TCP=20 >> >> >>sockets and connections are _also_ something else >> >> entirely: we >> >> must not confuse TCP endpoints with IPvN destination >> >> >>addresses.) >> >> > >> >> > Two points I do want to note for discussion are > > what is >> >> passed to transport connections are end-to-end=20 >> identifiers in > my >> >> view and should not be exposed in the IPvN headers or used for > >> >> loc+id. >> >> >> >> I agree they are end-to-end identifiers, even if they look=20 > > >> exactly like IPvN addresses. >> >> >> >> That they currently are exposed in IPvN headers is an >> accident of >> >> history: TCP never defined a standard for exchanging >> anything else >> >> as endpoint identifiers. (Clearly, both ends of a TCP connection >> >> need to agree how to distinguish that a packet belongs to that >> >> connection: IPvN addresses have worked OK for that purpose. >> >> Endpoint identifiers _could_ be something else entirely; >> and need >> >> not be visible at all to the IPvN layer.) >> >> >> >> We must allow _something_ to be used for loc+id within >> IPvN; but >> >> it'd be fine if, for example, the application passed FQDNs as = the >> >> endpoint IDs and the operating system did a DNS-like >> query to find=20 >> >> loc+id. >> >> >> >> > Also on source addresses my pain has been if they get altered >> >> then I > am unclear how I respond back at the OS transport end. >> >> >> >> This is indeed a mess right now. NAT boxes routinely >> alter these >> >> and "try" to maintain enough state to alter them back. :*( >> >> >> >> > But if I am no longer using the notion of a current source=20 >> >> address at > the transport end I don't care about that >> anymore and >> >> if that is > possible that is a good thing. >> >> >> >> IPvN source addresses are used to report routing problems: >> >> other than that, they can mostly be ignored. (Indeed, they = can't >> >> even be trusted for that much: the less we depend on them, the >> >> better.) >> >> >> >> (There was a time when we believed routing based on source=20 >> >> address would help. Most of us would like to bury that idea...) >> >> >> >> > I believe shim6 and hip get us very close to this model >> for the > >> >> transport with current architecturs and specifications. >> >> >> >> I must admit that I view both shim6 and hip as moving = targets >> >> trying to be too many things to too many people. I=20 >> suspect I'm not >> >> alone. In any case, both of those are engineering, not >> architecture; >> >> for purposes of this list I >> > > suggest explaining which features of them you'd like to >> >> compare, rather than just naming a protocol. >> >> >> >> -- >> >> John Leslie >> >> >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 14:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprWI-0001rM-JH; Thu, 30 Nov 2006 14:24:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprWH-0001rH-Su for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:24:29 -0500 Received: from outmail128141.authsmtp.com ([62.13.128.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprWF-0000US-4U for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:24:29 -0500 Received: from outmail128179.authsmtp.co.uk (outmail128179.authsmtp.co.uk [62.13.128.179]) by punt2.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id kAUJOOfw094712; Thu, 30 Nov 2006 19:24:24 GMT Received: from IAN (203-217-34-245.dyn.iinet.net.au [203.217.34.245]) (authenticated bits=0) by mail.authsmtp.com (8.13.6/8.13.6/Kp) with ESMTP id kAUJOJGZ011123; Thu, 30 Nov 2006 19:24:21 GMT From: "Ian Peter" To: "'Azinger, Marla'" , Subject: RE: [arch-d] Finding a way forward Date: Fri, 1 Dec 2006 06:24:08 +1100 Message-ID: <019d01c714b5$1d9923c0$4a02a8c0@IAN> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccUmCwNQb6aY5/aTEeyGsyclO4L9wAFf2tQAAFKVGAAAFUAcA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01D041BE@nyrofcs2ke2k01.corp.pvt> X-Server-Quench: 62b3c02d-80a8-11db-b4dc-001185d377ca X-AuthRoute: OCdyZgEQClZURQJc Ei4YATVoSAwjPhBQ DAVFJgxfNl8UURhQ KkJXbgESJgZEAnde RXkJW1RSQFx4U2Fx YQhSIwddYVRMXgJ0 U0xXQFZXCwdtAxke BlBFI3wICH8xEn5x ZEdgXT5aXEN9dgh7 QBxXRm0EMXpoaDEX TUFZI1FJIgceLQJF alF+XHZZYmIANSsu JSJhdwM4Jz5fbShg Ci8MK14TR0lDF3Yj TgFKEzI1AkQfS01p X-Authentic-SMTP: 61633136393539.squirrel.dmpriest.net.uk:315/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Spam-Score: 0.5 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Thanks Marla I think I hear you say that a solution is needed in 1-4 years Ian Peter -----Original Message----- From: Azinger, Marla [mailto:marla.azinger@frontiercorp.com]=20 Sent: 01 December 2006 06:13 To: Ian Peter; architecture-discuss@ietf.org Subject: RE: [arch-d] Finding a way forward Hello Ian- Yes, action is required Asking for a best guess timefame is opening a can of warms. You will receive answers ranging from 4 years, 20 years and never. Lessons learned from the past show us "bandaids" are just that ( they = tend to degrade in worth). Acknowleding this are a number of people looking = for a balanced solution that is technically sound and acknowledges time to implementation. =20 So you want difinitive answers on solution and time. This really cant = be done. But what can be done and what several people are attempting to do = is accept that we need a solution and that we need it relatively quickly = (1-4 years). Yes, there will always be people that want to debate the method = and the timeframe to the third degree. However, there are also people = willing to take the facts from these debates and pick a direction and go with = it, and that is when solutions are made. It will happen. Thank you for your time Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: Ian Peter [mailto:ian.peter@ianpeter.com] Sent: Thursday, November 30, 2006 10:44 AM To: architecture-discuss@ietf.org Subject: [arch-d] Finding a way forward Assuming that action is required and this is not just an interesting discussion - Can someone give a best guesstimate as regards what timeframe the = problem is likely to severly affect Internet performance - are we talking 3 years = or 10 or further? That should help to indicate whether a bandaid approach is absolutely necessary or whether a more wholistic approach should be concentrated = on. I certainly suggest you avoid trying to do both on the same list (if = both are necessary) The next step after this preliminary analysis would be to evaluate realistically what could be done (that=92s means implemented, not just a standard) in the timeframe in which action is needed. Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: John Day [mailto:jeanjour@comcast.net]=20 Sent: 01 December 2006 02:51 To: Bound, Jim; John Day; John Leslie Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... I believe that a week or so ago a list was created to address the=20 problem you describe. As I understand it, this list was created to=20 address the fact that for the past 30 years the Internet has shirked=20 its responsibility to do the work necessary to provide a complete and=20 well thought out architecture. As was expressed at the beginning of this discussion a few weeks ago,=20 we have to give up this constant band-aid approach. We have to find=20 the *solutions.* Then we can trade our band-aids in for steps toward=20 an answer. As for transport, yes, we do have a number of bad examples in the data. At 3:38 -0500 2006/11/30, Bound, Jim wrote: >I am working here on engineering (not a computer science research >project) for an architecture that will assist routing, but alleviating >the business problem for operators that are not just network providers >from the multihoming problem to some degree permits us more time to >resolve the architecture issue at hand for routing. If the transport >layer, which does rely on IPvN addresses in any implementation code I >have ever seen for lookups etc., can be made to not be dependent on = IPvN >addresses, that will permit aggregation of IPvN addresses for some time >to avoid the collision presented by the IAB at San Diego potentially. >Thus it is important and I don't agree with John Day. > >Best, >/jim > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Wednesday, November 29, 2006 9:14 PM >> To: Bound, Jim; John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Not quite. Sooner or later you are going to realize that >> that there are no such thing as Transport Addresses. In >> fact, transport is sort of a minor layer at best. As far as >> this problem is concerned, Transport is irrelevant to the solution. >> >> Transport has no effect on the routing and its components and >> doesn't constrain its possibilities in the least. >> >> QED >> >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: >> >agree again. also no attachment to src addresses at my end. >> agree on >> >identifying transport points of the protocols to the >> architecture but >> >want to go offline with Pekka N. on that one and can do as I >> can around >> >the day job of course. the reason to do this arch exercise is the >> >potential of freeing the transport layer from IPvN layer and >> >components, which affords routing more freedom in thinking >> models. but >> >to note both >> >shim6 and hip have done this and some implementation exists. >> > >> >Best, >> >/jim >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Wednesday, November 29, 2006 4:52 PM >> >> To: Bound, Jim >> >> Cc: architecture-discuss@ietf.org >> >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is >> >> global (wasRe: thou... >> >> >> >> Bound, Jim wrote: >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly >> >> recommend that we call the "thing" that sits in >> >> the IPv4 >> >> >>header as destination address an "IPv4 destination=20 >> address", and >> >> the >>"thing" that sits in the IPv6 header as a=20 >> destination address >> >> an >> >> >>"IPv6 destination address". >> >> >>... >> >> >> (The actual parameters passed to operating systems to >> open TCP=20 >> >> >>sockets and connections are _also_ something else >> >> entirely: we >> >> must not confuse TCP endpoints with IPvN destination >> >> >>addresses.) >> >> > >> >> > Two points I do want to note for discussion are > > what is >> >> passed to transport connections are end-to-end=20 >> identifiers in > my >> >> view and should not be exposed in the IPvN headers or used for > >> >> loc+id. >> >> >> >> I agree they are end-to-end identifiers, even if they look=20 > > >> exactly like IPvN addresses. >> >> >> >> That they currently are exposed in IPvN headers is an >> accident of >> >> history: TCP never defined a standard for exchanging >> anything else >> >> as endpoint identifiers. (Clearly, both ends of a TCP connection >> >> need to agree how to distinguish that a packet belongs to that >> >> connection: IPvN addresses have worked OK for that purpose. >> >> Endpoint identifiers _could_ be something else entirely; >> and need >> >> not be visible at all to the IPvN layer.) >> >> >> >> We must allow _something_ to be used for loc+id within >> IPvN; but >> >> it'd be fine if, for example, the application passed FQDNs as = the >> >> endpoint IDs and the operating system did a DNS-like >> query to find=20 >> >> loc+id. >> >> >> >> > Also on source addresses my pain has been if they get altered >> >> then I > am unclear how I respond back at the OS transport end. >> >> >> >> This is indeed a mess right now. NAT boxes routinely >> alter these >> >> and "try" to maintain enough state to alter them back. :*( >> >> >> >> > But if I am no longer using the notion of a current source=20 >> >> address at > the transport end I don't care about that >> anymore and >> >> if that is > possible that is a good thing. >> >> >> >> IPvN source addresses are used to report routing problems: >> >> other than that, they can mostly be ignored. (Indeed, they = can't >> >> even be trusted for that much: the less we depend on them, the >> >> better.) >> >> >> >> (There was a time when we believed routing based on source=20 >> >> address would help. Most of us would like to bury that idea...) >> >> >> >> > I believe shim6 and hip get us very close to this model >> for the > >> >> transport with current architecturs and specifications. >> >> >> >> I must admit that I view both shim6 and hip as moving = targets >> >> trying to be too many things to too many people. I=20 >> suspect I'm not >> >> alone. In any case, both of those are engineering, not >> architecture; >> >> for purposes of this list I >> > > suggest explaining which features of them you'd like to >> >> compare, rather than just naming a protocol. >> >> >> >> -- >> >> John Leslie >> >> >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 14:32:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprdX-0006r0-SN; Thu, 30 Nov 2006 14:31:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprdW-0006qt-NP for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:31:58 -0500 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprdU-0001N3-6O for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:31:58 -0500 Received: from ([10.160.67.162]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.129248231; Thu, 30 Nov 2006 14:45:10 -0500 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K05.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Nov 2006 14:31:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Finding a way forward Date: Thu, 30 Nov 2006 14:31:33 -0500 Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D041BF@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Finding a way forward Thread-Index: AccUmCwNQb6aY5/aTEeyGsyclO4L9wAFf2tQAAFKVGAAAFUAcAAAVuYg From: "Azinger, Marla" To: "Ian Peter" , X-OriginalArrivalTime: 30 Nov 2006 19:31:32.0427 (UTC) FILETIME=[240529B0:01C714B6] X-Spam-Score: 0.5 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This is my personal belief and the push I get from my customers. It is = also the belief of others but not all. Cheers! Marla -----Original Message----- From: Ian Peter [mailto:ian.peter@ianpeter.com] Sent: Thursday, November 30, 2006 11:24 AM To: Azinger, Marla; architecture-discuss@ietf.org Subject: RE: [arch-d] Finding a way forward Thanks Marla I think I hear you say that a solution is needed in 1-4 years Ian Peter -----Original Message----- From: Azinger, Marla [mailto:marla.azinger@frontiercorp.com]=20 Sent: 01 December 2006 06:13 To: Ian Peter; architecture-discuss@ietf.org Subject: RE: [arch-d] Finding a way forward Hello Ian- Yes, action is required Asking for a best guess timefame is opening a can of warms. You will receive answers ranging from 4 years, 20 years and never. Lessons learned from the past show us "bandaids" are just that ( they = tend to degrade in worth). Acknowleding this are a number of people looking = for a balanced solution that is technically sound and acknowledges time to implementation. =20 So you want difinitive answers on solution and time. This really cant = be done. But what can be done and what several people are attempting to do = is accept that we need a solution and that we need it relatively quickly = (1-4 years). Yes, there will always be people that want to debate the method = and the timeframe to the third degree. However, there are also people = willing to take the facts from these debates and pick a direction and go with = it, and that is when solutions are made. It will happen. Thank you for your time Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: Ian Peter [mailto:ian.peter@ianpeter.com] Sent: Thursday, November 30, 2006 10:44 AM To: architecture-discuss@ietf.org Subject: [arch-d] Finding a way forward Assuming that action is required and this is not just an interesting discussion - Can someone give a best guesstimate as regards what timeframe the = problem is likely to severly affect Internet performance - are we talking 3 years = or 10 or further? That should help to indicate whether a bandaid approach is absolutely necessary or whether a more wholistic approach should be concentrated = on. I certainly suggest you avoid trying to do both on the same list (if = both are necessary) The next step after this preliminary analysis would be to evaluate realistically what could be done (that=92s means implemented, not just a standard) in the timeframe in which action is needed. Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: John Day [mailto:jeanjour@comcast.net]=20 Sent: 01 December 2006 02:51 To: Bound, Jim; John Day; John Leslie Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... I believe that a week or so ago a list was created to address the=20 problem you describe. As I understand it, this list was created to=20 address the fact that for the past 30 years the Internet has shirked=20 its responsibility to do the work necessary to provide a complete and=20 well thought out architecture. As was expressed at the beginning of this discussion a few weeks ago,=20 we have to give up this constant band-aid approach. We have to find=20 the *solutions.* Then we can trade our band-aids in for steps toward=20 an answer. As for transport, yes, we do have a number of bad examples in the data. At 3:38 -0500 2006/11/30, Bound, Jim wrote: >I am working here on engineering (not a computer science research >project) for an architecture that will assist routing, but alleviating >the business problem for operators that are not just network providers >from the multihoming problem to some degree permits us more time to >resolve the architecture issue at hand for routing. If the transport >layer, which does rely on IPvN addresses in any implementation code I >have ever seen for lookups etc., can be made to not be dependent on = IPvN >addresses, that will permit aggregation of IPvN addresses for some time >to avoid the collision presented by the IAB at San Diego potentially. >Thus it is important and I don't agree with John Day. > >Best, >/jim > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Wednesday, November 29, 2006 9:14 PM >> To: Bound, Jim; John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Not quite. Sooner or later you are going to realize that >> that there are no such thing as Transport Addresses. In >> fact, transport is sort of a minor layer at best. As far as >> this problem is concerned, Transport is irrelevant to the solution. >> >> Transport has no effect on the routing and its components and >> doesn't constrain its possibilities in the least. >> >> QED >> >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: >> >agree again. also no attachment to src addresses at my end. >> agree on >> >identifying transport points of the protocols to the >> architecture but >> >want to go offline with Pekka N. on that one and can do as I >> can around >> >the day job of course. the reason to do this arch exercise is the >> >potential of freeing the transport layer from IPvN layer and >> >components, which affords routing more freedom in thinking >> models. but >> >to note both >> >shim6 and hip have done this and some implementation exists. >> > >> >Best, >> >/jim >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Wednesday, November 29, 2006 4:52 PM >> >> To: Bound, Jim >> >> Cc: architecture-discuss@ietf.org >> >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is >> >> global (wasRe: thou... >> >> >> >> Bound, Jim wrote: >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly >> >> recommend that we call the "thing" that sits in >> >> the IPv4 >> >> >>header as destination address an "IPv4 destination=20 >> address", and >> >> the >>"thing" that sits in the IPv6 header as a=20 >> destination address >> >> an >> >> >>"IPv6 destination address". >> >> >>... >> >> >> (The actual parameters passed to operating systems to >> open TCP=20 >> >> >>sockets and connections are _also_ something else >> >> entirely: we >> >> must not confuse TCP endpoints with IPvN destination >> >> >>addresses.) >> >> > >> >> > Two points I do want to note for discussion are > > what is >> >> passed to transport connections are end-to-end=20 >> identifiers in > my >> >> view and should not be exposed in the IPvN headers or used for > >> >> loc+id. >> >> >> >> I agree they are end-to-end identifiers, even if they look=20 > > >> exactly like IPvN addresses. >> >> >> >> That they currently are exposed in IPvN headers is an >> accident of >> >> history: TCP never defined a standard for exchanging >> anything else >> >> as endpoint identifiers. (Clearly, both ends of a TCP connection >> >> need to agree how to distinguish that a packet belongs to that >> >> connection: IPvN addresses have worked OK for that purpose. >> >> Endpoint identifiers _could_ be something else entirely; >> and need >> >> not be visible at all to the IPvN layer.) >> >> >> >> We must allow _something_ to be used for loc+id within >> IPvN; but >> >> it'd be fine if, for example, the application passed FQDNs as = the >> >> endpoint IDs and the operating system did a DNS-like >> query to find=20 >> >> loc+id. >> >> >> >> > Also on source addresses my pain has been if they get altered >> >> then I > am unclear how I respond back at the OS transport end. >> >> >> >> This is indeed a mess right now. NAT boxes routinely >> alter these >> >> and "try" to maintain enough state to alter them back. :*( >> >> >> >> > But if I am no longer using the notion of a current source=20 >> >> address at > the transport end I don't care about that >> anymore and >> >> if that is > possible that is a good thing. >> >> >> >> IPvN source addresses are used to report routing problems: >> >> other than that, they can mostly be ignored. (Indeed, they = can't >> >> even be trusted for that much: the less we depend on them, the >> >> better.) >> >> >> >> (There was a time when we believed routing based on source=20 >> >> address would help. Most of us would like to bury that idea...) >> >> >> >> > I believe shim6 and hip get us very close to this model >> for the > >> >> transport with current architecturs and specifications. >> >> >> >> I must admit that I view both shim6 and hip as moving = targets >> >> trying to be too many things to too many people. I=20 >> suspect I'm not >> >> alone. In any case, both of those are engineering, not >> architecture; >> >> for purposes of this list I >> > > suggest explaining which features of them you'd like to >> >> compare, rather than just naming a protocol. >> >> >> >> -- >> >> John Leslie >> >> >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: = 29/11/2006 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 14:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpre6-00071h-B3; Thu, 30 Nov 2006 14:32:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpre5-00071c-Ak for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:32:33 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpre4-0001ZP-0l for architecture-discuss@ietf.org; Thu, 30 Nov 2006 14:32:33 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 133B04AC7A; Thu, 30 Nov 2006 14:32:30 -0500 (EST) Date: Thu, 30 Nov 2006 14:32:29 -0500 From: John Leslie To: John Day Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Message-ID: <20061130193229.GD2467@verdi> References: <816DD9299957E547B5D758D7F977D6DCFF3573@tayexc14.americas.cpqcorp.net> <20061130030739.GC2467@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John Day wrote: > At 22:07 -0500 2006/11/29, John Leslie wrote: >> >> I try to avoid saying "transport" layer / address / etc. because I >> believe it means too many different things to too many people. >> >> Actually, I agree that TCP-as-we-know-it isn't a "transport layer" >> and most assuredly lacks anything we should call a "transport address". > > Nor should any transport protocol, That doesn't follow. Quoting an authority you should respect: " " [A layer] is a distributed application that provides IPC (Interprocess " Communication). The distributed application is composed of cooperating " application processes on separate systems. As applications they have " application names. Addresses are identifiers *internal* to this " distributed application and used only within it for its internal " coordination in order to provide IPC. Surely one should allow "identifiers internal to" such a distributed application. >> When I do talk of a "transport layer", I mean a layer that worries >> about reliability, and thus detects and deals with >> >> - packet loss, >> - packet corruption, and >> - choosing among multiple paths (if available). > > None that I know of do the latter. O, yes, SCTP tries to but how? "How" is engineering -- for this discussion it's sufficient to say it _does_ choose among multiple paths. It's hardly surprising that we have spent most of the history of the Internet choosing one "best" path: anything else leads to stability problems in cases we have _already_ encountered. (We have, of course, used "bonding" to make "best" paths which use more than one physical medium.) > This is just because we have failed to do the relaying and > multiplexing functions well. It really is in no position to do it. Umm... SCTP would do just fine at choosing amrng multiple paths (AKA multiplexing) if it had a stable enough base to build on. BTW, SCTP is in the ideal position to do multiplexing, IMHO. >> I cannot agree with John Day that a layer which does that much is >> just a "minor layer". That much done right would solve >> >> - multi-homing, >> - mobility, >> - congestion, and >> - most forgery. > > Really only congestion in this list has anything to do with > Transport, well, that class of protocols. You prove my point about "transport" meaning different things to differerent people. >>> As far as this problem is concerned, Transport is irrelevant to the >>> solution. >> >> I'm not sure what "this problem" John Day is talking of, but >> "transport" isn't "irrelevant" to the problems I'm trying to talk >> about. > > Multihoming, mobility, routing, security, etc. Everything but error > and flow control on a single flow. I find it strange you want to divorce error control from your list. "Flow control" is complex enough that I suspect we'll need cooperation among several layers. The rest of your list, IMHO, would benefit greatly from stability of an internetworking layer to build on. >> Transport _shouldn't_ affect routing; but doing transport wrong >> (like, e.g. TCP) can constrain routing pretty severely. :^( > > Well, as one of the best system designers I ever knew often said, "if > you don't do it right, it won't work." ;-) (I wonder if it would help if _you_ tried to avoid the name "transport" for the layer you're talking about. I'd be happy to adopt a different name for mine...) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 15:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gps8e-00022X-SI; Thu, 30 Nov 2006 15:04:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gps8d-00022S-BO for architecture-discuss@ietf.org; Thu, 30 Nov 2006 15:04:07 -0500 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gps8b-0005FU-D7 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 15:04:07 -0500 Received: from HeinerHummel@aol.com by imo-m23.mx.aol.com (mail_out_v38_r7.6.) id q.d0f.12a7ec0 (30739); Thu, 30 Nov 2006 15:03:55 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 30 Nov 2006 15:03:53 EST Subject: Re: [arch-d] Finding a way forward To: marla.azinger@frontiercorp.com, ian.peter@ianpeter.com, architecture-discuss@ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 79668c4a0135b05f663aafe71bc273fd Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380773633==" Errors-To: architecture-discuss-bounces@ietf.org --===============1380773633== Content-Type: multipart/alternative; boundary="-----------------------------1164917033" -------------------------------1164917033 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en =20 It was said at the IETF in July 2000, London: we definitely need a new =20 design. But don't worry, there is no reason to rush: We will have a 10 years= time=20 frame to make it happen. =20 But in a month we will have 2007 ! =20 I am entirely optimistic, a fancy archtitecture can be accomplished, but it=20= =20 takes not only a redesign in addressing but much more in routing. Addressing should care at first about itself e.g. to cater for multiple=20 address families, for scoping and non-scoping, for encryption and non-ecryp= tion,=20 for alias 'es and subaddresses, for a clean cut wrt. operations like=20 unicast, anycast, multicast, mp2p, mp2mp, for multihoming and roaming, for =20= its=20 dependency or better independency from some ISP,... =20 But hand in hand we should also research for a new routing architecture =20 which can easily handle a 1000 times bigger internet - however such that it=20= is =20 not too big for most of the time, then for one moment in time just right, =20= and=20 thereafter urges another call for a new routing architecture. The solution is so obvious: it can only be hierarchical routing. But not =20 static hierarchical routing, instead it must be dynamical hierarchical rout= ing.=20 We have had models that failed: PNNI for example! But a lot can be learned=20= by=20 understanding its inherent deficiencies. PNNI however is not a proof that a= =20 flat model like BGP is the right thing: Being in Europe, why should I be notified if a bike tips over in China - =20 excuse me: if a router drops out in China ?! Much bigger internets and yet=20= much=20 stabler topologies are feasable using a hierarchical model while requiring= =20 much less expenses wrt. message dissemination than in a flat model. But hierarchical models need also hierarchically-constructed locators, righ= t=20 ? =20 Heiner=20 =20 =20 In einer eMail vom 30.11.2006 20:14:48 Westeurop=C3=A4ische Normalzeit schre= ibt =20 marla.azinger@frontiercorp.com: Hello Ian- Yes, action is required Asking for a best guess timefame is opening a can of warms. You will=20 receive answers ranging from 4 years, 20 years and never. Lessons learned from the past show us "bandaids" are just that ( they tend=20 to degrade in worth). Acknowleding this are a number of people looking for= a=20 balanced solution that is technically sound and acknowledges time to=20 implementation. =20 So you want difinitive answers on solution and time. This really cant be=20 done. But what can be done and what several people are attempting to do is= =20 accept that we need a solution and that we need it relatively quickly (1-4=20= =20 years). Yes, there will always be people that want to debate the method an= d the=20 timeframe to the third degree. However, there are also people willing to=20 take the facts from these debates and pick a direction and go with it, and=20= that=20 is when solutions are made. It will happen. Thank you for your time Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: Ian Peter [mailto:ian.peter@ianpeter.com] Sent: Thursday, November 30, 2006 10:44 AM To: architecture-discuss@ietf.org Subject: [arch-d] Finding a way forward Assuming that action is required and this is not just an interesting discussion - Can someone give a best guesstimate as regards what timeframe the problem i= s likely to severly affect Internet performance - are we talking 3 years or 1= 0 or further? That should help to indicate whether a bandaid approach is absolutely necessary or whether a more wholistic approach should be concentrated on. I certainly suggest you avoid trying to do both on the same list (if both are necessary) The next step after this preliminary analysis would be to evaluate realistically what could be done (that=E2=80=99s means implemented, not jus= t a standard) in the timeframe in which action is needed. Ian Peter Ian Peter and Associates Pty Ltd PO Box 10670 Adelaide St Brisbane 4000 Australia Tel (+614) 1966 7772 www.ianpeter.com www.internetmark2.org www.nethistory.info -----Original Message----- From: John Day [mailto:jeanjour@comcast.net]=20 Sent: 01 December 2006 02:51 To: Bound, Jim; John Day; John Leslie Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... I believe that a week or so ago a list was created to address the=20 problem you describe. As I understand it, this list was created to=20 address the fact that for the past 30 years the Internet has shirked=20 its responsibility to do the work necessary to provide a complete and=20 well thought out architecture. As was expressed at the beginning of this discussion a few weeks ago,=20 we have to give up this constant band-aid approach. We have to find=20 the *solutions.* Then we can trade our band-aids in for steps toward=20 an answer. As for transport, yes, we do have a number of bad examples in the data. At 3:38 -0500 2006/11/30, Bound, Jim wrote: >I am working here on engineering (not a computer science research >project) for an architecture that will assist routing, but alleviating >the business problem for operators that are not just network providers >from the multihoming problem to some degree permits us more time to >resolve the architecture issue at hand for routing. If the transport >layer, which does rely on IPvN addresses in any implementation code I >have ever seen for lookups etc., can be made to not be dependent on IPvN >addresses, that will permit aggregation of IPvN addresses for some time >to avoid the collision presented by the IAB at San Diego potentially. >Thus it is important and I don't agree with John Day. > >Best, >/jim > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Wednesday, November 29, 2006 9:14 PM >> To: Bound, Jim; John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: RE: [arch-d] On identifiers: what is virtual and >> what is global (wasRe: thou... >> >> Not quite. Sooner or later you are going to realize that >> that there are no such thing as Transport Addresses. In >> fact, transport is sort of a minor layer at best. As far as >> this problem is concerned, Transport is irrelevant to the solution. >> >> Transport has no effect on the routing and its components and >> doesn't constrain its possibilities in the least. >> >> QED >> >> At 20:49 -0500 2006/11/29, Bound, Jim wrote: >> >agree again. also no attachment to src addresses at my end. >> agree on >> >identifying transport points of the protocols to the >> architecture but >> >want to go offline with Pekka N. on that one and can do as I >> can around >> >the day job of course. the reason to do this arch exercise is the >> >potential of freeing the transport layer from IPvN layer and >> >components, which affords routing more freedom in thinking >> models. but >> >to note both >> >shim6 and hip have done this and some implementation exists. >> > >> >Best, >> >/jim >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Wednesday, November 29, 2006 4:52 PM >> >> To: Bound, Jim >> >> Cc: architecture-discuss@ietf.org >> >> Subject: Re: [arch-d] On identifiers: what is virtual and >> what is >> >> global (wasRe: thou... >> >> >> >> Bound, Jim wrote: >> >> >> From: John Leslie [mailto:john@jlc.net] >> >> I strongly >> >> recommend that we call the "thing" that sits in >> >> the IPv4 >> >> >>header as destination address an "IPv4 destination =20 >> address", and >> >> the >>"thing" that sits in the IPv6 header as a=20 >> destination address >> >> an >> >> >>"IPv6 destination address". >> >> >>... >> >> >> (The actual parameters passed to operating systems to >> open TCP=20 >> >> >>sockets and connections are _also_ something else >> >> entirely: we >> >> must not confuse TCP endpoints with IPvN destination >> >> >>addresses.) >> >> > >> >> > Two points I do want to note for discussion are > > what is >> >> passed to transport connections are end-to-end=20 >> identifiers in > my >> >> view and should not be exposed in the IPvN headers or used for > >> >> loc+id. >> >> >> >> I agree they are end-to-end identifiers, even if they look =20 > > >> exactly like IPvN addresses. >> >> >> >> That they currently are exposed in IPvN headers is an >> accident of >> >> history: TCP never defined a standard for exchanging >> anything else >> >> as endpoint identifiers. (Clearly, both ends of a TCP connection >> >> need to agree how to distinguish that a packet belongs to that >> >> connection: IPvN addresses have worked OK for that purpose. >> >> Endpoint identifiers _could_ be something else entirely; >> and need >> >> not be visible at all to the IPvN layer.) >> >> >> >> We must allow _something_ to be used for loc+id within >> IPvN; but >> >> it'd be fine if, for example, the application passed FQDNs as the >> >> endpoint IDs and the operating system did a DNS-like >> query to find=20 >> >> loc+id. >> >> >> >> > Also on source addresses my pain has been if they get altered >> >> then I > am unclear how I respond back at the OS transport end. >> >> >> >> This is indeed a mess right now. NAT boxes routinely >> alter these >> >> and "try" to maintain enough state to alter them back. :*( >> >> >> >> > But if I am no longer using the notion of a current source=20 >> >> address at > the transport end I don't care about that >> anymore and >> >> if that is > possible that is a good thing. >> >> >> >> IPvN source addresses are used to report routing problems: >> >> other than that, they can mostly be ignored. (Indeed, they can't >> >> even be trusted for that much: the less we depend on them, the >> >> better.) >> >> >> >> (There was a time when we believed routing based on source =20 >> >> address would help. Most of us would like to bury that idea...) >> >> >> >> > I believe shim6 and hip get us very close to this model >> for the > >> >> transport with current architecturs and specifications. >> >> >> >> I must admit that I view both shim6 and hip as moving targets >> >> trying to be too many things to too many people. I=20 >> suspect I'm not >> >> alone. In any case, both of those are engineering, not >> architecture; >> >> for purposes of this list I >> > > suggest explaining which features of them you'd like to >> >> compare, rather than just naming a protocol. >> >> >> >> -- >> >> John Leslie >> >> >> > >> >_______________________________________________ >> >Architecture-discuss mailing list >> >Architecture-discuss@ietf.org >> >https://www1.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -- =20 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: 29/11/2006 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date: 29/11/2006 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss =20 -------------------------------1164917033 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en
It was said at the IETF in July 2000, London: we definitely need a new=20 design. But don't worry, there is no reason to rush: We will have a 10 years= =20 time frame to make it happen.
 
But in a month we will have 2007 !
 
I am entirely optimistic, a fancy archtitecture can be accomplished, bu= t it=20 takes not only a redesign in addressing but much more in routing.
Addressing should care at first about itself  e.g. to cater for=20 multiple address families, for scoping and non-scoping, for encryption and=20 non-ecryption, for alias 'es and subaddresses, for a clean cut wrt. operatio= ns=20 like unicast, anycast, multicast, mp2p, mp2mp, for multihoming and roaming,=20= for=20 its dependency or better  independency from some ISP,...
 
But hand in hand we should also research for a new routing architecture= =20 which can easily handle a 1000 times bigger internet - however such that it=20= is=20 not  too big for most of the time, then for one moment in time just rig= ht,=20 and thereafter urges another call for a new routing architecture.
The solution is so obvious: it can only be hierarchical routing. But no= t=20 static hierarchical routing, instead it must be dynamical hierarchical=20 routing. We have had models that failed: PNNI for example! But a lot can be=20 learned by understanding its inherent deficiencies. PNNI however is not a pr= oof=20 that a flat model like BGP is the right thing:
Being in Europe, why should I be notified if a bike tips over in China=20= -=20 excuse me: if a router drops out in China ?!=20 Much bigger internets and yet much stabler topologies ar= e=20 feasable using a hierarchical model  while requiring much les= s=20 expenses wrt. message dissemination than in a flat model.
But hierarchical models need also hierarchically-constructed locators,=20 right ?
 
Heiner
 
 
In einer eMail vom 30.11.2006 20:14:48 Westeurop=C3=A4ische Normalzeit=20= schreibt=20 marla.azinger@frontiercorp.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Hello=20 Ian-

Yes, action is required

Asking for a best guess timefam= e is=20 opening a can of warms.  You will receive answers ranging from 4 year= s,=20 20 years and never.

Lessons learned from the past show us "bandaids= "=20 are just that ( they tend to degrade in worth).  Acknowleding this ar= e a=20 number of people looking for a balanced solution that is technically sound= and=20 acknowledges time to implementation.  

So you want=20 difinitive answers on solution and time.  This really cant be done.&n= bsp;=20 But what can be done and what several people are attempting to do is accep= t=20 that we need a solution and that we need it relatively quickly (1-4=20 years).  Yes, there will always be people that want to debate the met= hod=20 and the timeframe to the third degree.  However, there are also peopl= e=20 willing to take the facts from these debates and pick a direction and go w= ith=20 it, and that is when solutions are made.  It will happen.

Than= k=20 you for your time
Marla Azinger
Frontier Communications
ARIN=20 AC

-----Original Message-----
From: Ian Peter=20 [mailto:ian.peter@ianpeter.com]
Sent: Thursday, November 30, 2006 10:44= =20 AM
To: architecture-discuss@ietf.org
Subject: [arch-d] Finding a way= =20 forward




Assuming that action is required and this is no= t=20 just an interesting
discussion -

Can someone give a best guessti= mate=20 as regards what timeframe the problem is
likely to severly affect Inter= net=20 performance - are we talking 3 years or 10
or further?

That shou= ld=20 help to indicate whether a bandaid approach is absolutely
necessary or=20 whether a more wholistic approach should be concentrated on.

I=20 certainly suggest you avoid trying to do both on the same list (if bothare=20 necessary)

The next step after this preliminary analysis would be t= o=20 evaluate
realistically what could be done (that=E2=80=99s means impleme= nted, not=20 just a
standard) in the timeframe in which action is=20 needed.




Ian Peter
Ian Peter and Associates Pty LtdPO=20 Box 10670 Adelaide St  Brisbane 4000
Australia
Tel (+614) 1966=20 7772
www.ianpeter.com
www.internetmark2.org
www.nethistory.info

-----Original=20 Message-----
From: John Day [mailto:jeanjour@comcast.net]
Sent: 01=20 December 2006 02:51
To: Bound, Jim; John Day; John Leslie
Cc:=20 architecture-discuss@ietf.org
Subject: RE: [arch-d] On identifiers: wha= t is=20 virtual and what is global
(wasRe: thou...

I believe that a week= or=20 so ago a list was created to address the
problem you describe.  A= s I=20 understand it, this list was created to
address the fact that for the=20= past=20 30 years the Internet has shirked
its responsibility to do the work=20 necessary to provide a complete and
well thought out=20 architecture.

As was expressed at the beginning of this discussion=20= a=20 few weeks ago,
we have to give up this constant band-aid approach.&nbs= p;=20 We have to find
the *solutions.*  Then we can trade our band-aids= in=20 for steps toward
an answer.

As for transport, yes, we do have a= =20 number of bad examples in the data.


At 3:38 -0500 2006/11/30,=20 Bound, Jim wrote:
>I am working here on engineering (not a computer=20 science research
>project) for an architecture that will assist rout= ing,=20 but alleviating
>the business problem for operators that are not jus= t=20 network providers
>from the multihoming problem to some degree permi= ts=20 us more time to
>resolve the architecture issue at hand for=20 routing.  If the transport
>layer, which does rely on IPvN=20 addresses in any implementation code I
>have ever seen for lookups e= tc.,=20 can be made to not be dependent on IPvN
>addresses, that will permit= =20 aggregation of IPvN addresses for some time
>to avoid the collision=20 presented by the IAB at San Diego potentially.
>Thus it is important= and=20 I don't agree with John=20 Day.
>
>Best,
>/jim
>
>>  -----Origi= nal=20 Message-----
>>  From: John Day=20 [mailto:jeanjour@comcast.net]
>>  Sent: Wednesday, November=20= 29,=20 2006 9:14 PM
>>  To: Bound, Jim; John Leslie
>>&nbs= p;=20 Cc: architecture-discuss@ietf.org
>>  Subject: RE: [arch-d]=20= On=20 identifiers: what is virtual and
>>  what is global (wasRe:=20 thou...
>>
>>  Not quite.  Sooner or later you= are=20 going to realize that
>>  that there are no such thing as=20 Transport Addresses.  In
>>  fact, transport is sort of= a=20 minor layer at best.  As far as
>>  this problem is=20 concerned, Transport is irrelevant to the=20 solution.
>>
>>  Transport has no effect on the rou= ting=20 and its components and
>>  doesn't constrain its possibiliti= es=20 in the least.
>>
>>  QED
>>
>>&nb= sp;=20 At 20:49 -0500 2006/11/29, Bound, Jim wrote:
>>  >agree=20 again.  also no attachment to src addresses at my=20 end.
>>   agree on
>>  >identifying=20 transport points of the protocols to the
>>  architecture=20 but
>>  >want to go offline with Pekka N. on that one and= can=20 do as I
>>  can around
>>  >the day job of=20 course.  the reason to do this arch exercise is the
>> = =20 >potential of freeing the transport layer from IPvN layer=20 and
>>  >components, which affords routing more freedom i= n=20 thinking
>>  models.  but
>>  >to note= =20 both
>>  >shim6 and hip have done this and some=20 implementation exists.
>>  >
>> =20 >Best,
>>  >/jim
>>  >
>>&nb= sp;=20 >
>>  >
>>  >>  -----Original= =20 Message-----
>>  >>  From: John Leslie=20 [mailto:john@jlc.net]
>>  >>  Sent: Wednesday,=20 November 29, 2006 4:52 PM
>>  >>  To: Bound,=20 Jim
>>  >>  Cc:=20 architecture-discuss@ietf.org
>>  >>  Subject: Re= :=20 [arch-d] On identifiers: what is virtual and
>>   what=20 is
>>  >> global (wasRe: thou...
>> =20 >>
>>  >>  Bound, Jim <Jim.Bound@hp.com&= gt;=20 wrote:
>>  >>  >> From: John Leslie=20 [mailto:john@jlc.net]  >>  >> I=20 strongly
>>  >> recommend that we call the "thing" tha= t=20 sits in
>>  >>   the IPv4
>> =20 >>  >>header as destination address an "IPv4 destination=20
>>  address", and
>>  >> the =20 >>"thing" that sits in the IPv6 header as a
>> =20 destination address
>>  >> an
>> =20 >>  >>"IPv6 destination address".
>> =20 >>  >>...
>>  >>  >> (The=20 actual parameters passed to operating systems to
>>  open&nb= sp;=20 TCP
>>  >> >>sockets and connections are _also_= =20 something else  >>
>>  entirely: we
>>&n= bsp;=20 >> must not confuse TCP endpoints with IPvN =20 destination
>>  >> =20 >>addresses.)
>>  >>  >
>> = ;=20 >>  > Two points I do want to note for discussion are =20 >  > what is
>>  >> passed to transport=20 connections are end-to-end
>>  identifiers in  >=20 my
>>  >> view and should not be exposed in the IPvN=20 headers or used for  >
>>  >>=20 loc+id.
>>  >>
>>  >> =20    I agree they are end-to-end identifiers, even if they look=20
>  > >> exactly like IPvN addresses.
>> = ;=20 >>
>>  >>     That they currently= are=20 exposed in IPvN headers is an
>>  accident of
>>&nb= sp;=20 >>  history: TCP never defined a standard for=20 exchanging
>>  anything  else
>>  >>= ; as=20 endpoint identifiers. (Clearly, both ends of a TCP =20 connection
>>  >> need to agree how to distinguish tha= t a=20 packet  belongs to that
>>  >>  connection:=20= IPvN=20 addresses have worked OK for that purpose.
>>  >> = ;=20 Endpoint identifiers _could_ be something else entirely;
>> = =20 and  need
>>  >> not be visible at all to the IPv= N=20 layer.)
>>  >>
>>  >> =20    We must allow _something_ to be used for loc+id=20 within
>>   IPvN; but
>>  >> it'd b= e=20 fine if, for example, the application  passed FQDNs as=20 the
>>  >> endpoint IDs and the operating system did&n= bsp;=20 a DNS-like
>>  query to find
>>  >>=20 loc+id.
>>  >>
>>  >>  > A= lso=20 on source addresses my pain has been if they get =20 altered
>>  >> then I  > am unclear how I resp= ond=20 back at the OS transport end.
>>  >>
>> = =20 >>     This is indeed a mess right now. NAT boxes=20 routinely
>>  alter  these
>>  >> a= nd=20 "try" to maintain enough state to alter them back. :*(
>> =20 >>
>>  >>  > But if I am no longer using= the=20 notion of a current source
>>  >> address at  &g= t;=20 the transport end I don't care about that
>>  anymore=20 and
>>  >> if that is  > possible that is a go= od=20 thing.
>>  >>
>>  >> =20    IPvN source addresses are used to report routing=20 problems:
>>  >>  other than that, they can mostl= y be=20 ignored. (Indeed, they  can't
>>  >> even be trus= ted=20 for that much: the less we depend on  them, the
>> =20 >> better.)
>>  >>
>>  >>&nb= sp;=20    (There was a time when we believed routing based on source=20
>>  >> address would help. Most of us would like to b= ury=20 that idea...)
>>  >>
>>  >> =20= >=20 I believe shim6 and hip get us very close to this model
>> =20= for=20 the  >
>>  >> transport with current architect= urs=20 and specifications.
>>  >>
>> =20 >>     I must admit that I view both shim6 and hip as= =20 moving  targets
>>  >> trying to be too many thin= gs=20 to too many people. I
>>  suspect I'm not
>> = =20 >> alone. In any case, both of those are  engineering,=20 not
>>  architecture;
>>  >> for purpose= s of=20 this list I
>>  >  > suggest explaining which=20 features of them you'd like to
>>  >>  compare,=20 rather than just naming a protocol.
>> =20 >>
>>  >>  --
>>  >>&nb= sp;=20 John Leslie <john@jlc.net>
>>  >>
>>&nb= sp;=20 >
>> =20 >_______________________________________________
>> =20 >Architecture-discuss mailing list
>> =20 >Architecture-discuss@ietf.org
>> =20 >https://www1.ietf.org/mailman/listinfo/architecture-discuss
>>= ;
>>


_______________________________________________
= Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss

--=20
No virus found in this incoming message.
Checked by AVG Free=20 Edition.
Version: 7.1.409 / Virus Database: 268.15.0/557 - Release Date= :=20 29/11/2006


--
No virus found in this outgoing=20 message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Datab= ase:=20 268.15.0/557 - Release Date:=20 29/11/2006



_______________________________________________<= BR>Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss

__________________________________________= _____
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1164917033-- --===============1380773633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1380773633==-- From architecture-discuss-bounces@ietf.org Thu Nov 30 15:08:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpsCe-0003O7-MV; Thu, 30 Nov 2006 15:08:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpsCd-0003O2-Lh for architecture-discuss@ietf.org; Thu, 30 Nov 2006 15:08:15 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpsCb-0005nP-Qy for architecture-discuss@ietf.org; Thu, 30 Nov 2006 15:08:15 -0500 Received: from gihm3.apnic.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kAUK7wX6073661; Fri, 1 Dec 2006 07:07:59 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061201065744.02d341e8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 01 Dec 2006 07:07:36 +1100 To: Pekka Nikander , architecture-discuss@ietf.org From: Geoff Huston Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...) In-Reply-To: References: <20061129185545.GA2467@verdi> <816DD9299957E547B5D758D7F977D6DCFF33E5@tayexc14.americas.cpqcorp.net> <20061129215219.GB2467@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > My personal view of SHIM6 is that it is >a kind-of watered-down version of HIP, officially trying to achieve >clearly less than HIP but at the same time unofficially crawling >towards the directions where HIP has already boldly gone. :-) Not >bad given the committee design. My personal view is that there is a significant difference between a host-level approach and a transport session level approach that you seem to have missed in your note. I find myself in strong disagreement with your perspective of SHIM6 as some kind of diluted or compromised version of HIP. Frankly, as the volume, if not the usefulness, of all postings to this list demonstrates, there is much involved here. To expect any particular approach to get it all right first time is asking too much. HIP and SHIM6 are examples of trying to understand what these concepts look like in code and in protocol stacks. They bed down these otherwise abstract discussions with some experience with implementation and the harsh realities of deployment in the network. For you that may well be band aid. For me its part of the scientific investigatory process of devising an hypothesis, and then testing this hypothesis, and then looking very hard to make sure that the hypothesis remains intact. As far as I can see, we (or at least 'I' at any rate - the rest of you may know all there is to know about this subject already! :-) :-) :-) ) still have much to learn here. Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 16:53:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpto0-0006F4-MO; Thu, 30 Nov 2006 16:50:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gptnz-0006ED-64 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 16:50:55 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gptnx-00067C-GP for architecture-discuss@ietf.org; Thu, 30 Nov 2006 16:50:55 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id KAA20552; Fri, 1 Dec 2006 10:50:36 +1300 In-Reply-To: <7.0.0.16.2.20061201065744.02d341e8@apnic.net> References: <20061129185545.GA2467@verdi> <816DD9299957E547B5D758D7F977D6DCFF33E5@tayexc14.americas.cpqcorp.net> <20061129215219.GB2467@verdi> <7.0.0.16.2.20061201065744.02d341e8@apnic.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <236865E6-AC39-48C9-9412-9331CCAE4963@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...) Date: Fri, 1 Dec 2006 10:51:29 +1300 To: Geoff Huston X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org It may not be clear now, given that HIP is *called* the 'Host Identity Protocol', but there's actually nothing in the protocol itself to say what the identities in question belong to. In that sense there's little difference between HIP and SHIM6 in terms of architecture; lots of differences in detail, and some striking and deliberate similarities. In other words, what HIP and SHIM6 both give you is the ability to assert that something accessible at location A is also accessible at locations B through F, prove the assertion, and request changes in the delivery of packets. There are differences in what assertions you can make at what stage of the process, what you have to know a priori, what events can be dealt with as they occur, what you want to put in the DNS, how much security you get, and in how much math you have to do to make assertions, but the core of what the protocols provide is very similar. Andrew On 01/12/2006, at 9:07 AM, Geoff Huston wrote: > >> My personal view of SHIM6 is that it is >> a kind-of watered-down version of HIP, officially trying to achieve >> clearly less than HIP but at the same time unofficially crawling >> towards the directions where HIP has already boldly gone. :-) Not >> bad given the committee design. > > My personal view is that there is a significant difference between > a host-level approach and a transport session level approach that > you seem to have missed in your note. I find myself in strong > disagreement with your perspective of SHIM6 as some kind of diluted > or compromised version of HIP. > > Frankly, as the volume, if not the usefulness, of all postings to > this list demonstrates, there is much involved here. To expect any > particular approach to get it all right first time is asking too > much. HIP and SHIM6 are examples of trying to understand what these > concepts look like in code and in protocol stacks. They bed down > these otherwise abstract discussions with some experience with > implementation and the harsh realities of deployment in the > network. For you that may well be band aid. For me its part of the > scientific investigatory process of devising an hypothesis, and > then testing this hypothesis, and then looking very hard to make > sure that the hypothesis remains intact. As far as I can see, we > (or at least 'I' at any rate - the rest of you may know all there > is to know about this subject already! :-) :-) :-) ) still have > much to learn here. > > Geoff > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 19:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpwQh-00055b-WF; Thu, 30 Nov 2006 19:39:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpwQh-00055W-6i for architecture-discuss@ietf.org; Thu, 30 Nov 2006 19:39:03 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpwQf-0004uO-N2 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 19:39:03 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kB10DjWw010546; Thu, 30 Nov 2006 16:13:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kB10DeMP010545; Thu, 30 Nov 2006 16:13:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 30 Nov 2006 16:13:40 -0800 From: David Meyer To: "Bound, Jim" Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... Message-ID: <20061201001340.GA9832@1-4-5.net> References: <816DD9299957E547B5D758D7F977D6DC01038461@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01038461@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103457496==" Errors-To: architecture-discuss-bounces@ietf.org --===============2103457496== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 30, 2006 at 11:18:44AM -0500, Bound, Jim wrote: > Not to John D. - Note the list is ram@ietf.org but it is silent should > we all be using that list, can someone here make an exec decision that > we move this discussion to ram? Sure, go ahead :-) But really, is anything more needed, other than to provide some context over there for folks not reading this list? And BTW, Fred (Baker) pointed the v6ops over to that list today as well. --dmm --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFb3O0ORgD1qCZ2KcRAqCOAKCDWK3jopWLuYCUMmclSAJaoVJDBACfdLhV /8tuIDAVdpJh3COmUqZYHkk= =vd8v -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- --===============2103457496== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============2103457496==-- From architecture-discuss-bounces@ietf.org Thu Nov 30 22:57:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpzVM-0001Nt-Gh; Thu, 30 Nov 2006 22:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpzVL-0001Nn-FP for architecture-discuss@ietf.org; Thu, 30 Nov 2006 22:56:03 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpzVG-0002hw-5V for architecture-discuss@ietf.org; Thu, 30 Nov 2006 22:56:03 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id D5D1734040; Thu, 30 Nov 2006 22:55:55 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:55:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] transport layer identifier evolutiion to support multihoming Date: Thu, 30 Nov 2006 22:55:53 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0103894B@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] transport layer identifier evolutiion to support multihoming Thread-Index: AccUsa6oSUJZNzVOSX6YYvxISieQEgASo+bA From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 01 Dec 2006 03:55:55.0719 (UTC) FILETIME=[9A590D70:01C714FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > And I realize that=20 > you are using the nomenclature you know.=20 Elitist and insulting please don't do that again. Thank You. We can talk offline not the first time by you to me. I prefer end-point identifiters instead of connection-identifiers. But key is they are not routing identifiers for now. /jim > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Thursday, November 30, 2006 1:57 PM > To: Bound, Jim; John Leslie > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] transport layer identifier evolutiion=20 > to support multihoming >=20 > At 12:36 -0500 2006/11/30, Bound, Jim wrote: > >John, > > > >To answer your arch transport layer question previously to=20 > me, within=20 > >the context of this list discussion (leap of faith on my part :--)). > > > >- Transport protocol end-to-end communications connectivity should=20 > >evolve to identifiers and ports not using IPvN addresses. >=20 > We need to be careful here. I have been thinking about this=20 > *a lot* and you are on the right track. And I realize that=20 > you are using the nomenclature you know. But there are=20 > considerable benefits that accrue if the identifiers you=20 > speak of are not associated with the protocols we normally=20 > associate with the "Transport protocols." The only=20 > identifiers they need and should have are the=20 > connection-identifier, i.e. source and destination port-ids=20 > they have now. >=20 > > > >- Transport identifiers could also be used as IPsec=20 > identifiers for the=20 > >SPI in conjunction with the IPvN dst address, but the IPvN=20 > dst address=20 > >I believe must stay in tact as archtype for any new routing=20 > >architecture at least at this point in the discussions, thus=20 > also for IPsec SPI. > > > >- Transport identifiers need to be cryptographically secure. > > > >- Transport identifiers are not the same as routing identifiers. > > > >- Transport identifiers can be deferenced to find locators=20 > as required=20 > >for "implementation" of the required stack lookups,=20 > interfaces, etc. as=20 > >best current practice today for connections between two=20 > >applications/processes/services-instance, and used to=20 > identify network=20 > >path as required by a transport protocol. > > > >NB: shim6 and hip IETF contributors (engineers, operators,=20 > architects, > >technologists) are well underway to evolve to the above not=20 > exactly in=20 > >all cases but the bases of such technology evolution is in process. > >shim6 appears to have the greatest IETF consensus to move forward at=20 > >this time in the IETF having adopted some of the hip=20 > architecture and=20 > >precepts. And the devil is in the details as always. > > > >Best, > >/jim > > > >_______________________________________________ > >Architecture-discuss mailing list > >Architecture-discuss@ietf.org > >https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 23:09:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpzi5-00061l-MK; Thu, 30 Nov 2006 23:09:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpzi4-00061c-1a for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:09:12 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpzhy-0004tb-NQ for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:09:12 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 8391D3407A; Thu, 30 Nov 2006 23:09:06 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 23:09:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Date: Thu, 30 Nov 2006 23:09:04 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038958@tayexc14.americas.cpqcorp.net> In-Reply-To: <236865E6-AC39-48C9-9412-9331CCAE4963@indranet.co.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Thread-Index: AccUyb/Wsl7Rl9bJRU6tTS90ZoA+3wANEuQw From: "Bound, Jim" To: "Andrew McGregor" , "Geoff Huston" X-OriginalArrivalTime: 01 Dec 2006 04:09:06.0048 (UTC) FILETIME=[716BB000:01C714FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I could go on about this knowing both well. But if we are to keep this as architecture dsicussion we probably only need to know the arch diffs of shim6 and hip. would that be useful? I am not sure? shim6 is not a watered down HIP that is not a valid premise at least to me for the deductions we are or may not be trying to achieve, or it might be using inductive processes is better. Figure out what end state we want and work backwards from what certain proposals suggest to be clear. /jim > -----Original Message----- > From: Andrew McGregor [mailto:andrew@indranet.co.nz]=20 > Sent: Thursday, November 30, 2006 4:51 PM > To: Geoff Huston > Cc: Pekka Nikander; architecture-discuss@ietf.org > Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re:=20 > On identifiers:what is virtual and what...) >=20 > It may not be clear now, given that HIP is *called* the 'Host=20 > Identity Protocol', but there's actually nothing in the=20 > protocol itself to say what the identities in question belong=20 > to. In that sense there's little difference between HIP and=20 > SHIM6 in terms of architecture; lots of differences in=20 > detail, and some striking and deliberate similarities. >=20 > In other words, what HIP and SHIM6 both give you is the=20 > ability to assert that something accessible at location A is=20 > also accessible at locations B through F, prove the=20 > assertion, and request changes in the delivery of packets. =20 > There are differences in what assertions you can make at what=20 > stage of the process, what you have to know a priori, what=20 > events can be dealt with as they occur, what you want to put=20 > in the DNS, how much security you get, and in how much math=20 > you have to do to make assertions, but the core of what the=20 > protocols provide is very similar. >=20 > Andrew >=20 > On 01/12/2006, at 9:07 AM, Geoff Huston wrote: >=20 > > > >> My personal view of SHIM6 is that it is a kind-of watered-down=20 > >> version of HIP, officially trying to achieve clearly less than HIP=20 > >> but at the same time unofficially crawling towards the directions=20 > >> where HIP has already boldly gone. :-) Not bad given the=20 > committee=20 > >> design. > > > > My personal view is that there is a significant difference=20 > between =20 > > a host-level approach and a transport session level=20 > approach that you=20 > > seem to have missed in your note. I find myself in strong=20 > > disagreement with your perspective of SHIM6 as some kind of=20 > diluted or =20 > > compromised version of HIP. > > > > Frankly, as the volume, if not the usefulness, of all=20 > postings to this=20 > > list demonstrates, there is much involved here. To expect any=20 > > particular approach to get it all right first time is=20 > asking too much.=20 > > HIP and SHIM6 are examples of trying to understand what=20 > these concepts=20 > > look like in code and in protocol stacks. They bed down these=20 > > otherwise abstract discussions with some experience with=20 > > implementation and the harsh realities of deployment in the=20 > network.=20 > > For you that may well be band aid. For me its part of the=20 > scientific=20 > > investigatory process of devising an hypothesis, and then=20 > testing this=20 > > hypothesis, and then looking very hard to make sure that the=20 > > hypothesis remains intact. As far as I can see, we (or at=20 > least 'I' at=20 > > any rate - the rest of you may know all there is to know about this=20 > > subject already! :-) :-) :-) ) still have much to learn here. > > > > Geoff > > > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 23:09:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpziV-00065h-HI; Thu, 30 Nov 2006 23:09:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpziT-00065K-Vr for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:09:37 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpziP-0004zt-1l for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:09:37 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id EDC6C34104; Thu, 30 Nov 2006 23:09:32 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 23:09:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Date: Thu, 30 Nov 2006 23:09:31 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038959@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201001340.GA9832@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On identifiers: what is virtual and what is global(wasRe: thou... Thread-Index: AccU4UYturUfd2vETBahxMvnJioxHQAHTYjg From: "Bound, Jim" To: "David Meyer" X-OriginalArrivalTime: 01 Dec 2006 04:09:32.0835 (UTC) FILETIME=[81630F30:01C714FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org ACK. /jim=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: Thursday, November 30, 2006 7:14 PM > To: Bound, Jim > Cc: architecture-discuss@ietf.org; John Day > Subject: Re: [arch-d] On identifiers: what is virtual and=20 > what is global(wasRe: thou... >=20 > On Thu, Nov 30, 2006 at 11:18:44AM -0500, Bound, Jim wrote: > > Not to John D. - Note the list is ram@ietf.org but it is=20 > silent should=20 > > we all be using that list, can someone here make an exec=20 > decision that=20 > > we move this discussion to ram? >=20 > Sure, go ahead :-) But really, is anything more needed, > other than to provide some context over there for folks > not reading this list? And BTW, Fred (Baker) pointed the > v6ops over to that list today as well. >=20 >=20 > --dmm >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 23:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq07D-0003Wm-VL; Thu, 30 Nov 2006 23:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq07C-0003Wh-SG for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:35:10 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq07B-0000uw-Lk for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:35:10 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc15) with ESMTP id <2006120104350901500b02f6e>; Fri, 1 Dec 2006 04:35:09 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0103894B@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC0103894B@tayexc14.americas.cpqcorp.net> Date: Thu, 30 Nov 2006 23:27:42 -0500 To: "Bound, Jim" , "John Day" , "John Leslie" From: John Day Subject: RE: [arch-d] transport layer identifier evolutiion to support multihoming Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 22:55 -0500 2006/11/30, Bound, Jim wrote: > > And I realize that >> you are using the nomenclature you know. > >Elitist and insulting please don't do that again. Thank You. We can >talk offline not the first time by you to me. > >I prefer end-point identifiters instead of connection-identifiers. But >key is they are not routing identifiers for now. Jim, I am terrible sorry if you were offended by my choice of language. It was not intended as elitist or insulting in the least. I think you are reading far too much into it. I have worked (and am working) in more than one of terminology with respect to this work. And I was merely recognizing that. There was no value judgement in it whatsoever. As for preferring to call them endpoint identifiers. If you look at how the use of source and destination port-ids arise in this class of protocols, i.e. not only transport but also data link. (They are basically the same thing.) Working from first principles (consider just two machines trying to communicate), you find that the reason they first appear is to distinguish multiple flows on the line. Since either end may initiate a connection, it is not feasible for just one end to assign the connection-id. If they did, there would always be the chance of collisions. Since both sides already had a port-id that their local IPC was using to distinguish the flow locally. The convention has been to concatenate them as the connection-id. So the reason, I refer to the field as a connection-id is that is its function in the protocol. Each port-id can be seen as a local-identifier of an endpoint. Does that explain it? Take care, John Again, sorry. I have no elitist intentions and not an elitist bone in my body! _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 30 23:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq0By-0004iK-6F; Thu, 30 Nov 2006 23:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq0Bw-0004iA-QU for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:40:04 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq0Bv-0001bM-K6 for architecture-discuss@ietf.org; Thu, 30 Nov 2006 23:40:04 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 24BBC86AFF; Thu, 30 Nov 2006 23:39:54 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...) Message-Id: <20061201043954.24BBC86AFF@mercury.lcs.mit.edu> Date: Thu, 30 Nov 2006 23:39:54 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Andrew McGregor > .. what HIP and SHIM6 both give you is the ability to assert that > something accessible at location A is also accessible at locations B > through ... > .. but the core of what the protocols provide is very similar. Yes and no, I think - but I kind of phased out on the finer details of HIP and SHIM6, so the following comments may not be accurate, and I'd appreciate any corrections to possibly mistaken impressions. My impression is that although to an initial glance (if you consider a few "how do I do thing X" cases) they do look like they provide similar capabilities (as you point out), I think that perhaps at a deeper level HIP is more powerful, architecturally. The reason is simple: HIP brings an extra namespace to bear, and at an architectural level that's very powerful. Also, SHIM6 overloads one more meaning onto an existing namespace (IPv6 addresses), and, architecturally speaking, that's always bad. Yes, yes, I know, the idea is that there will be two separate namespaces that just happen to share a syntax. However... we all know that anytime there is the possibility of kludging something (in this case, by treating a name from sub-space A as if it were a name from sub-space B), someone somewhere will do it, as a "quick hack" to solve some problem they have, and then you're in the soup. Only with a complete separate namespace is there no possibility of hacks that entangle (and strangle) a design. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss