From ram-bounces@ietf.org Thu Nov 16 12:29:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl3M-00010o-Ce; Thu, 16 Nov 2006 12:29:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl3J-0000yq-M0 for ram@iab.org; Thu, 16 Nov 2006 12:29:29 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkkyt-0001Wu-Cw for ram@iab.org; Thu, 16 Nov 2006 12:24:57 -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 kAGHOmPE002732 for ; Thu, 16 Nov 2006 09:24:48 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAGHOiln002730 for ram@iab.org; Thu, 16 Nov 2006 09:24:44 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 16 Nov 2006 09:24:44 -0800 From: David Meyer To: ram@iab.org Message-ID: <20061116172444.GA2723@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: 79899194edc4f33a41f49410777972f8 Cc: Subject: [RAM] test X-BeenThere: ram@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1438940259==" Errors-To: ram-bounces@ietf.org --===============1438940259== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline test --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFXJ7cORgD1qCZ2KcRAqH0AKCEEJDhrUesTYFlkRofVIQrun6KtACfbReK lnpyNpfKLOAiQgxwRK09nn0= =DbC1 -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- --===============1438940259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@ietf.org https://www1.ietf.org/mailman/listinfo/ram --===============1438940259==-- From ram-bounces@ietf.org Thu Nov 16 12:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklH7-0001Ef-Ry; Thu, 16 Nov 2006 12:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklH6-0001EZ-Ux for ram@iab.org; Thu, 16 Nov 2006 12:43:44 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklH6-0004md-NV for ram@iab.org; Thu, 16 Nov 2006 12:43: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 kAGHhi2S003791 for ; Thu, 16 Nov 2006 09:43:44 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAGHhiLS003790 for ram@iab.org; Thu, 16 Nov 2006 09:43:44 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on m106.maoz.com X-Spam-Level: X-Spam-Status: No, score=-3.5 required=4.5 tests=AWL, BAYES_00, SARE_HEAD_XBEEN autolearn=unavailable version=3.1.7 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kAGHgpfg003739 for ; Thu, 16 Nov 2006 09:42:51 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAGHgp0u003738 for dmm@maoz.com; Thu, 16 Nov 2006 09:42:51 -0800 Resent-Message-Id: <200611161742.kAGHgp0u003738@m106.maoz.com> X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kAGHaOx7002983 for ; Thu, 16 Nov 2006 09:36:24 -0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl9s-0003Fb-Pc; 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-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Resent-From: dmm@1-4-5.net Resent-Date: Thu, 16 Nov 2006 09:42:51 -0800 Resent-To: dmm@maoz.com Resent-From: dmm@1-4-5.net Resent-Date: Thu, 16 Nov 2006 09:43:44 -0800 Resent-To: ram@iab.org Cc: iab@ietf.org, iesg@ietf.org Subject: [RAM] New list: The Routing And Addressing Mailing List X-BeenThere: ram@ietf.org List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1951202382==" Sender: ram-bounces@ietf.org Errors-To: ram-bounces@ietf.org --===============1951202382== 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-- --===============1951202382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@ietf.org https://www1.ietf.org/mailman/listinfo/ram --===============1951202382==-- From ram-bounces@iab.org Fri Nov 17 01:30:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxEM-0006vv-QF; Fri, 17 Nov 2006 01:29:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxEM-0006vq-0T for ram@ietf.org; Fri, 17 Nov 2006 01:29:42 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkxEK-0001FQ-NG for ram@ietf.org; Fri, 17 Nov 2006 01:29:41 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net[24.125.117.214]) by comcast.net (sccrmhc11) with SMTP id <2006111706293901100st9i3e>; Fri, 17 Nov 2006 06:29:40 +0000 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: tvest@eyeconomics.com Date: Fri, 17 Nov 2006 01:29:23 -0500 To: ram@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Noel Chiappa Subject: [RAM] Re/directed: [arch-d] It's the routing, people! X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Shifting this to the presumably more appropriate forum... On Nov 14, 2006, at 6:44 PM, 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. Always more room to explore, but this is very tricky space. Yakov's Law should probably be understood as a subset of an even broader law: Code -- architecture, protocols, RIR rules, etc. -- can either define Law (what can and cannot be done at a reasonable cost), or Law can define Code; pick one. The Internet grew out of places where the former model dominated, and nominally technical features like layer 3 transparency / application indifference, and the multihoming requirement* for participating in the AS mesh, helped to meliorate some of the more "extortionate" aspects and outcomes of competitive service provision. In commercial sectors that lack such Code-based constraints (and in the Internet also, in parts of the world where these BCPs are not observed), conventional Law defines the permissible limits of extortion, or else extortion (aka exercise of Significant Market Power) is often the norm. Anyone who wants to try to tackle the "economics without extortion" problem should probably keep this in mind. >> Did you (or anyone) have any other suggestion(s) for ways we can >> "incentivize" (to use that wonderful/horrible neologism) routing >> costs? Wild speculation time... Would geo-topo addressing be more palatable, and more amenable to legitimate TE requirements, if the geo-LIRs were subject to the same policy rules / discipline that's currently defined at the RIR level? Can anyone think of a good reason/justification/mechanism to encode competition for the default route within a geo-LIR area as an (institutional, or better yet technical) requirement for participation in the geo-LIR routing system? With transport costs -- at least those related to routing/multihoming world -- falling through the floor, the market may well take care of routing and addressing concerns by driving regional/national network economies back into the shapes they had before the early/mid-1990s, when addressing, topology, and traffic exchange were quite explicitly geo-topo, and the upper bound for the "routing" problem was n! (number of nation states). Once we know which way things are going to tip, it'll probably be too late... so maybe investigating solutions along these lines could help to hedge against both kinds of scary (expansionary, contractionary) futures... > (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 Maybe we should try harder this year? The distaste for these issues within the ops community seems to me abating a bit... I think...? Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 01:37:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxLb-0003Q4-Ay; Fri, 17 Nov 2006 01:37:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkxLZ-0003OQ-IK for ram@ietf.org; Fri, 17 Nov 2006 01:37:09 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkxLY-0001tq-53 for ram@ietf.org; Fri, 17 Nov 2006 01:37:09 -0500 Received: from webmail45.lax.untd.com (webmail45.lax.untd.com [10.131.27.185]) by smtpout05.lax.untd.com with SMTP id AABCX4YDGA5JR9QS for (sender ); Thu, 16 Nov 2006 22:36:22 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKP6RDS8w42fQN7Q+L1tkJBQ== Received: (from fergdawg@netzero.net) by webmail45.lax.untd.com (jqueuemail) id L7CY5VSF; Thu, 16 Nov 2006 22:36:18 PST Received: from [24.23.201.115] by webmail45.lax.untd.com with HTTP: Fri, 17 Nov 2006 06:36:08 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Fri, 17 Nov 2006 06:36:08 GMT To: tvest@eyeconomics.com Subject: Re: [RAM] Re/directed: [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: <20061116.223618.16672.1477537@webmail45.lax.untd.com> X-ContentStamp: 7:3:1827161307 X-MAIL-INFO: 397aee0f57d7eed7d7677afe2f7fd39a9a4fca639a9e732f8a8b1ef3aea3a3ee436b270f 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: 8abaac9e10c826e8252866cbe6766464 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- tvest@eyeconomics.com wrote: >Maybe we should try harder this year? The distaste for these issues = >within the ops community seems to me abating a bit... I think...? > Nope. They're just not going to even think about deploying v6 until this issue is addressed (no pun intended). - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFXVhRq1pz9mNUZTMRAoyoAJ4q+HdpkY+v0ClLEl8/28BAZiCDKACgkiIC 50rFKR8V5Ux0XriseqXonX0=3D =3DOzi5 -----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/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 05:26:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl0ul-0003zv-8w; Fri, 17 Nov 2006 05:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl0uk-0003zq-2A for ram@ietf.org; Fri, 17 Nov 2006 05:25:42 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl0ue-000758-Ob for ram@ietf.org; Fri, 17 Nov 2006 05:25:42 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 1D394340AC; Fri, 17 Nov 2006 05:25: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); Fri, 17 Nov 2006 05:25: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: [RAM] Re/directed: [arch-d] It's the routing, people! Date: Fri, 17 Nov 2006 05:25:34 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF256A0@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061116.223618.16672.1477537@webmail45.lax.untd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re/directed: [arch-d] It's the routing, people! Thread-Index: AccKEttVweXEK0qdQ8iXwZ4hdFIYeQAHxfxA From: "Bound, Jim" To: "Fergie" , X-OriginalArrivalTime: 17 Nov 2006 10:25:35.0766 (UTC) FILETIME=[B8289B60:01C70A32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org hmmm not sure who your talking about because I know of 3 providers who have deployed today just in the U.S. more in Asia and all of them have it on their roadmaps and from customer requests. Neither of us can identify names but so all know lets not base what IPv6 is doing or not doing from a group but rather from the horses mouth. The largest reason for lack of today deployment whether ops or enterprise or government (just three business segments here) is that the budgets for movement to IPv6 and many technologies (e.g. 3G, IMS, WIMAX, etc) are being driven by technology refresh as opposed to extended budgets for new technology. As we try to kill the myths about IPv6 some present likewise lets kill the myths why IPv6 is not deployed by those in charge of the business as PMs and it is not because of multihoming today at all. Clearly there is wise caution for what we need to be ready for tomorrow but multihoming is not a barrier to IPv6 deployment today for most variants I am aware of in the various segments deploying IPv6. /jim > -----Original Message----- > From: Fergie [mailto:fergdawg@netzero.net]=20 > Sent: Friday, November 17, 2006 1:36 AM > To: tvest@eyeconomics.com > Cc: ram@ietf.org > Subject: Re: [RAM] Re/directed: [arch-d] It's the routing, people! >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > - -- tvest@eyeconomics.com wrote: >=20 > >Maybe we should try harder this year? The distaste for these issues=20 > >within the ops community seems to me abating a bit... I think...? > > >=20 > Nope. >=20 > They're just not going to even think about deploying v6 until > this issue is addressed (no pun intended). >=20 > - - ferg >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.1 (Build 1557) >=20 > wj8DBQFFXVhRq1pz9mNUZTMRAoyoAJ4q+HdpkY+v0ClLEl8/28BAZiCDKACgkiIC > 50rFKR8V5Ux0XriseqXonX0=3D > =3DOzi5 > -----END PGP SIGNATURE----- >=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 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 06:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1ST-0001Kz-8j; Fri, 17 Nov 2006 06:00:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1SR-0001Ke-Al for ram@ietf.org; Fri, 17 Nov 2006 06:00:31 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl1SQ-00051i-1M for ram@ietf.org; Fri, 17 Nov 2006 06:00:31 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2006 03:00:29 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAHB0SRh018089; Fri, 17 Nov 2006 03:00:28 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAHB0Sin012939; Fri, 17 Nov 2006 03:00:28 -0800 (PST) Received: from [144.254.23.146] (dhcp-data-vlan10-23-146.cisco.com [144.254.23.146]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kAHAkaWE013813; Fri, 17 Nov 2006 02:46:37 -0800 Message-ID: <455D9649.8060108@cisco.com> Date: Fri, 17 Nov 2006 12:00:25 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: [RAM] Re/directed: [arch-d] It's the routing, people! References: <816DD9299957E547B5D758D7F977D6DCF256A0@tayexc14.americas.cpqcorp.net> In-Reply-To: <816DD9299957E547B5D758D7F977D6DCF256A0@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=262; t=1163761229; x=1164625229; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Re/directed=3A=20[arch-d]=20It's=20the=20rout ing,=20people! |Sender:=20; bh=C2EkByrC5tAehknP0pjY+E5LBLE2Cbg8K34Mc+IERMA=; b=YlFj3dE/g6dT0uUn69/NGaqILDZ4MYEYcmqNWEmriwLHXfBqfwd38TzhxgU70H0sDl/3EzJk PWDm9CEEhyDssZy99GPRqQXC4Wur4ANSoLA/vGRdSYaLzTXP4f7eNbaW; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=262; t=1163760398; x=1164624398; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Re/directed=3A=20[arch-d]=20It's=20the=20rout ing,=20people! |Sender:=20 |To:=20=22Bound,=20Jim=22=20; bh=C2EkByrC5tAehknP0pjY+E5LBLE2Cbg8K34Mc+IERMA=; b=c/WHT5tKNhGh114Lo3xfM4ecJrmaO/Ak3ZLJFltqDPuO8yyB48s8O/S0oVrlQbcVSuHZV23D XrWhmrSIFWdqnAUzDodV3/yNit79tsh4NZY+cNXjiZ8ZsifcNrEI3gL4; Authentication-Results: sj-dkim-7; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Guys, While not entirely orthogonal to each other, IPv6 and routing concerns are different, and if I understand the IAB's concern correctly, they are more focused on the latter than the former, at least as far as this forum is concerned. No? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 06:04:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1W3-0002Rc-DL; Fri, 17 Nov 2006 06:04:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl1W2-0002P6-AB for ram@ietf.org; Fri, 17 Nov 2006 06:04:14 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl1Vw-0005ch-3E for ram@ietf.org; Fri, 17 Nov 2006 06:04:14 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id BD4B0340FB; Fri, 17 Nov 2006 06:04:07 -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, 17 Nov 2006 06:04: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 Subject: RE: [RAM] Re/directed: [arch-d] It's the routing, people! Date: Fri, 17 Nov 2006 06:04:04 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF256A6@tayexc14.americas.cpqcorp.net> In-Reply-To: <455D9649.8060108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re/directed: [arch-d] It's the routing, people! Thread-Index: AccKN5u60vExngDJSye8L5iGEef+KwAAHIYg From: "Bound, Jim" To: "Eliot Lear" X-OriginalArrivalTime: 17 Nov 2006 11:04:07.0360 (UTC) FILETIME=[19F9DC00:01C70A38] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org That is my read too. But good to ask. /jim=20 > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com]=20 > Sent: Friday, November 17, 2006 6:00 AM > To: Bound, Jim > Cc: Fergie; tvest@eyeconomics.com; ram@ietf.org > Subject: Re: [RAM] Re/directed: [arch-d] It's the routing, people! >=20 > Guys, >=20 > While not entirely orthogonal to each other, IPv6 and routing=20 > concerns are different, and if I understand the IAB's concern=20 > correctly, they are more focused on the latter than the=20 > former, at least as far as this forum is concerned. No? >=20 > Eliot >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 11:59:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl731-0007gf-CT; Fri, 17 Nov 2006 11:58:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl72z-0007ez-Cc for ram@ietf.org; Fri, 17 Nov 2006 11:58:37 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl72u-0004vb-3P for ram@ietf.org; Fri, 17 Nov 2006 11:58:37 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BF4E486AFD; Fri, 17 Nov 2006 11:58:31 -0500 (EST) To: ram@ietf.org Message-Id: <20061117165831.BF4E486AFD@mercury.lcs.mit.edu> Date: Fri, 17 Nov 2006 11:58:31 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: jnc@mercury.lcs.mit.edu Subject: [RAM] Re: Re/directed: [arch-d] It's the routing, people! X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: tvest@eyeconomics.com > Would geo-topo addressing be more palatable First, I'd like to encourage everyone to stop using the word "address" (except where explicitly modified as "IPvN address"). The generic term has just too many meanings (routing-name, old location&identity semantics, packet header field, etc, etc) and it's just too easy to get confused about what someone means if you read "address" and think something different from the person who typed it. "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 I am trying to observe this suggestion to not use the word myself, but don't always succeed. Second, this idea (geographic "addressing") keeps being "re-discovered" by people who wonder why we aren't doing it. (I had a sarcastic rhetorical answer to that ready, but omitted it.) The short answer is that the routing-names have to be organized according to the network's actual connectivity to allow the routing to scale (the latter being the problem we are trying to solve). If you cannot make connectivity follow geo-"addressing", a geo-based organizing principle for organizing routing-names is unable to help the routing scale. Generally connectivity follows traffic patterns, *not* political or geographic boundaries. And the organization of routing-names has to follow that. > the market may well take care of routing and addressing concerns by > driving regional/national network economies back into the shapes they > had before the early/mid-1990s, when addressing, topology, and traffic > exchange were quite explicitly geo-topo "Addressing" and topology were never "geo-topo". IPv4 address patterns have always been a major dog's breakfast, although it's gone through various stages (the earliest - when the network was small, not coincidentally - having no organization at all). Although there remains to this day (and probably always will) some geographic influences on connection, especially towards the edges (it's basically a lot cheaper to connect to a POP that's physically near you), there are a high percentage of links that break that paradigm (see previous comment about connectivity following traffic patterns). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 12:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7xH-0003fG-Ow; Fri, 17 Nov 2006 12:56:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7xG-0003fB-LZ for ram@ietf.org; Fri, 17 Nov 2006 12:56:46 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7x7-00037I-J7 for ram@ietf.org; Fri, 17 Nov 2006 12:56:46 -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 kAHHuHlH004805; Fri, 17 Nov 2006 09:56:17 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAHHuHgW004804; Fri, 17 Nov 2006 09:56:17 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 17 Nov 2006 09:56:17 -0800 From: David Meyer To: Eliot Lear Subject: Re: [RAM] Re/directed: [arch-d] It's the routing, people! Message-ID: <20061117175617.GA4692@1-4-5.net> References: <816DD9299957E547B5D758D7F977D6DCF256A0@tayexc14.americas.cpqcorp.net> <455D9649.8060108@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <455D9649.8060108@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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@ietf.org, "Bound, Jim" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, Nov 17, 2006 at 12:00:25PM +0100, Eliot Lear wrote: > Guys, >=20 > While not entirely orthogonal to each other, IPv6 and routing concerns=20 > are different, and if I understand the IAB's concern correctly, they are= =20 > more focused on the latter than the former, at least as far as this=20 > forum is concerned. No? Yes. Let's not get into whether IPv6 is good, bad, indifferent here (maybe take that discussion over to architecture-discuss, if its architectural?).=20 Rather, what I would like to see us do is construct a solid problem statement, and then start looking at what we can do against that problem statement.=20 BTW, we have a very rough draft of the workshop report in hand, and hope to be able to put it on this list by sometime early next week. --dmm _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 13:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8IV-0006KP-6F; Fri, 17 Nov 2006 13:18:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8IU-0006KK-IE for ram@ietf.org; Fri, 17 Nov 2006 13:18:42 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gl8IN-0002vT-56 for ram@ietf.org; Fri, 17 Nov 2006 13:18:42 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 9A8DE340D4; Fri, 17 Nov 2006 13:18:34 -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, 17 Nov 2006 13:18: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: [RAM] Re/directed: [arch-d] It's the routing, people! Date: Fri, 17 Nov 2006 13:18:33 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF5E518@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061117175617.GA4692@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re/directed: [arch-d] It's the routing, people! Thread-Index: AccKcbwdYg+/0dryT9Odwz5piPaGRgAAmf8Q From: "Bound, Jim" To: "David Meyer" , "Eliot Lear" X-OriginalArrivalTime: 17 Nov 2006 18:18:34.0371 (UTC) FILETIME=[CB201530:01C70A74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org dave, good leadership here and yes be good to have working problem statement et al from IAB report at least to ponder and agree to which will keep us focused too. I agree on v6 or v4 being discussed except in prefix context as Noel just suggested for addresses where its more of an attribute for differentiation technically. But I think we can probably even avoid that. suggest we keep industry deployment opinions to when we get to the part where need to do market will it accept or not accept and how long type business input which I think is a ways off. your mail and the above rhetoric I attempt in the spirit of better together in the IETF will keep us focused to sam hartmans request at the plenary too is my IMHO. thx /jim=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: Friday, November 17, 2006 12:56 PM > To: Eliot Lear > Cc: Bound, Jim; ram@ietf.org > Subject: Re: [RAM] Re/directed: [arch-d] It's the routing, people! >=20 > On Fri, Nov 17, 2006 at 12:00:25PM +0100, Eliot Lear wrote: > > Guys, > >=20 > > While not entirely orthogonal to each other, IPv6 and=20 > routing concerns=20 > > are different, and if I understand the IAB's concern=20 > correctly, they=20 > > are more focused on the latter than the former, at least as far as=20 > > this forum is concerned. No? >=20 > Yes. Let's not get into whether IPv6 is good, bad, > indifferent here (maybe take that discussion over to > architecture-discuss, if its architectural?).=20 >=20 > Rather, what I would like to see us do is construct a > solid problem statement, and then start looking at what > we can do against that problem statement.=20 >=20 > BTW, we have a very rough draft of the workshop report in > hand, and hope to be able to put it on this list by > sometime early next week. >=20 > --dmm >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 14:11:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl97C-00068i-Is; Fri, 17 Nov 2006 14:11:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl97B-00067Q-8t for ram@ietf.org; Fri, 17 Nov 2006 14:11:05 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl976-0004Xk-Rw for ram@ietf.org; Fri, 17 Nov 2006 14:11:05 -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 kAHJAtox007430; Fri, 17 Nov 2006 11:10:55 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAHJAtDa007429; Fri, 17 Nov 2006 11:10:55 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 17 Nov 2006 11:10:55 -0800 From: David Meyer To: "Bound, Jim" Subject: Re: [RAM] Re/directed: [arch-d] It's the routing, people! Message-ID: <20061117191055.GA7406@1-4-5.net> References: <20061117175617.GA4692@1-4-5.net> <816DD9299957E547B5D758D7F977D6DCF5E518@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 In-Reply-To: <816DD9299957E547B5D758D7F977D6DCF5E518@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: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0087619135==" Errors-To: ram-bounces@iab.org --===============0087619135== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jim, > your mail and the above rhetoric I attempt in the spirit of better > together in the IETF will keep us focused to sam hartmans request at the > plenary too is my IMHO. Well, as you know, I'm in the "give peace a chance" on all of this camp. I'm confident we can make progress if we keep that in mind. --dmm --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFXgk/ORgD1qCZ2KcRAtt5AKCOCrSbwpskYdozUKyFpq8RowkFBACeIq07 F9dMVKxebmeLYNrlSw3mwPg= =SyUU -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- --===============0087619135== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0087619135==-- From ram-bounces@iab.org Fri Nov 17 16:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlBLm-0003k7-9g; Fri, 17 Nov 2006 16:34:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlBLl-0003k2-GZ for ram@ietf.org; Fri, 17 Nov 2006 16:34:17 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlBLh-0000sx-UG for ram@ietf.org; Fri, 17 Nov 2006 16:34:17 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GlBLP-0000Ho-Kx for ram@ietf.org; Fri, 17 Nov 2006 13:33:56 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Nov 2006 22:34:15 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) From: Jefsey_Morfin Subject: Re: [RAM] Re: Re/directed: [arch-d] It's the routing, people! In-Reply-To: <20061117165831.BF4E486AFD@mercury.lcs.mit.edu> References: <20061117165831.BF4E486AFD@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: 16c9da4896bf5539ae3547c6c25f06a0 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1739204404==" Errors-To: ram-bounces@iab.org Message-Id: --===============1739204404== Content-Type: multipart/alternative; boundary="----MTnoyriaszutfdxupwrhcqhwehoyeegeom" ------MTnoyriaszutfdxupwrhcqhwehoyeegeom Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5472862 At 17:58 17/11/2006, Noel Chiappa wrote: >First, I'd like to encourage everyone to stop using the word "address" >(except where explicitly modified as "IPvN address"). The generic term has >just too many meanings (routing-name, old location&identity semantics, packet >header field, etc, etc) and it's just too easy to get confused about what >someone means if you read "address" and think something different from the >person who typed it. > > "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 > >I am trying to observe this suggestion to not use the word myself, but don't >always succeed. This is typical problem from using English we know well. English is more an horizontal language which permits quick debugging with people meaning different things with the same words. French is a more vertical language which requires a better common understanding of a problem before discussing it with more precise words. These bottom up vs. Cartesian differences dramatically helps the ISO process. A good way to produce a document is to discuss it in English and to translate in French and to review them one from the other (ISO, MPEG, etc. experience is very interesting). English has an advantage on French: it can do more easily what you request and French intellectuals adore: to define issues more precisely through a contextual nomenclature. However, this is not common to English speakers. So, except if you want this debate to be in French, I would suggest you help us in establishing a site with your own suggested nomenclature of the different types of "addresses". This would probably help a lot both clarifying the issue and your own interesting research about what are we really addressing? >Second, this idea (geographic "addressing") keeps being "re-discovered" by >people who wonder why we aren't doing it. (I had a sarcastic rhetorical >answer to that ready, but omitted it.) > >The short answer is that the routing-names have to be organized according to >the network's actual connectivity to allow the routing to scale (the latter >being the problem we are trying to solve). If you cannot make connectivity >follow geo-"addressing", a geo-based organizing principle for organizing >routing-names is unable to help the routing scale. > >Generally connectivity follows traffic patterns, *not* political or >geographic boundaries. And the organization of routing-names has to follow >that. I am afraid you jump too fast to the geographic nature of the "geo-addressing". As I reminded it, there are four phases in a network: development, topology driven numbering, numbering plan driven topology, and transition. What actually commands is the market. - in the development phase the market says if it is interested or not. - in the deployment phase one follows the market development - in the maturity phase the network continuity must be everywhere and follows the real criteria: human/cpu density which is usually described through the numbering scheme. It is not geographic, but demographic (actually today demomecanographic), which in turn is geographic, historic, climatologic, etc. - in the transition phase, the market has decided to deprecate the technology and the demo-based plan is usually easier to transition. > > the market may well take care of routing and addressing concerns by > > driving regional/national network economies back into the shapes they > > had before the early/mid-1990s, when addressing, topology, and traffic > > exchange were quite explicitly geo-topo > >"Addressing" and topology were never "geo-topo". IPv4 address patterns have >always been a major dog's breakfast, although it's gone through various >stages (the earliest - when the network was small, not coincidentally - >having no organization at all). > >Although there remains to this day (and probably always will) some geographic >influences on connection, especially towards the edges (it's basically a lot >cheaper to connect to a POP that's physically near you), there are a high >percentage of links that break that paradigm (see previous comment about >connectivity following traffic patterns). Please do not make the mistake you want to avoid. Numbering has nothing to do with fluxes. The most important traffic is probably between USA and Europe. You only need one US and one European block to support the traffic between people in the USA and people in Europe. While you will also need one addressing block for people in Tonga. Not because Tonga should be treated as a geographical zone, but because Tonga will be an equal topology hub even if the link and traffic is far lower. jfc ------MTnoyriaszutfdxupwrhcqhwehoyeegeom Content-Type: text/html At 17:58 17/11/2006, Noel Chiappa wrote:
>First, I'd like to encourage everyone to stop using the word "address"
>(except where explicitly modified as "IPvN address"). The generic term has
>just too many meanings (routing-name, old location&identity semantics, packet
>header field, etc, etc) and it's just too easy to get confused about what
>someone means if you read "address" and think something different from the
>person who typed it.
>
>   "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
>
>I am trying to observe this suggestion to not use the word myself, but don't
>always succeed.

This is typical problem from using English we know well. English is
more an horizontal language which permits quick debugging with people
meaning different things with the same words. French is a more
vertical language which requires a better common understanding of a
problem before discussing it with more precise words. These bottom up
vs. Cartesian differences dramatically helps the ISO process. A  good
way to produce a document is to discuss it in English and to
translate in French and to review them one from the other (ISO, MPEG,
etc. experience is very interesting).

English has an advantage on French: it can do more easily what you
request and French intellectuals adore: to define issues more
precisely through a contextual nomenclature. However, this is not
common to English speakers. So, except if you want this debate to be
in French, I would suggest you help us in establishing a site with
your own suggested nomenclature of the different types of "addresses".

This would probably help a lot both clarifying the issue and your own
interesting research about what are we really addressing?

>Second, this idea (geographic "addressing") keeps being "re-discovered" by
>people who wonder why we aren't doing it. (I had a sarcastic rhetorical
>answer to that ready, but omitted it.)
>
>The short answer is that the routing-names have to be organized according to
>the network's actual connectivity to allow the routing to scale (the latter
>being the problem we are trying to solve). If you cannot make connectivity
>follow geo-"addressing", a geo-based organizing principle for organizing
>routing-names is unable to help the routing scale.
>
>Generally connectivity follows traffic patterns, *not* political or
>geographic boundaries. And the organization of routing-names has to follow
>that.

I am afraid you jump too fast to the geographic nature of the
"geo-addressing". As I reminded it, there are four phases in a
network: development, topology driven numbering, numbering plan
driven topology, and transition. What actually commands is the market.
- in the development phase the market says if it is interested or not.
- in the deployment phase one follows the market development
- in the maturity phase the network continuity must be everywhere and
follows the real criteria: human/cpu density which is usually
described through the numbering scheme. It is not geographic, but
demographic (actually today demomecanographic), which in turn is
geographic, historic, climatologic, etc.
- in the transition phase, the market has decided to deprecate the
technology and the demo-based plan is usually easier to transition.

>     > the market may well take care of routing and addressing concerns by
>     > driving regional/national network economies back into the shapes they
>     > had before the early/mid-1990s, when addressing, topology, and traffic
>     > exchange were quite explicitly geo-topo
>
>"Addressing" and topology were never "geo-topo". IPv4 address patterns have
>always been a major dog's breakfast, although it's gone through various
>stages (the earliest - when the network was small, not coincidentally -
>having no organization at all).
>
>Although there remains to this day (and probably always will) some geographic
>influences on connection, especially towards the edges (it's basically a lot
>cheaper to connect to a POP that's physically near you), there are a high
>percentage of links that break that paradigm (see previous comment about
>connectivity following traffic patterns).

Please do not make the mistake you want to avoid. Numbering has
nothing to do with fluxes. The most important traffic is probably
between USA and Europe. You only need one US and one European block
to support the traffic between people in the USA and people in
Europe. While you will also need one addressing block for people in
Tonga. Not because Tonga should be treated as a geographical zone,
but because Tonga will be an equal topology hub even if the link and
traffic is far lower.

jfc



------MTnoyriaszutfdxupwrhcqhwehoyeegeom-- --===============1739204404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1739204404==-- From ram-bounces@iab.org Fri Nov 17 17:15:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlByn-0006Qb-QG; Fri, 17 Nov 2006 17:14:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlByl-0006QP-W6 for ram@ietf.org; Fri, 17 Nov 2006 17:14:36 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlByl-0000Bv-Ct for ram@ietf.org; Fri, 17 Nov 2006 17:14:35 -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 kAHMEAVU010502; Fri, 17 Nov 2006 14:14:10 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kAHME5wC010499; Fri, 17 Nov 2006 14:14:05 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 17 Nov 2006 14:14:05 -0800 From: David Meyer To: Jefsey_Morfin Subject: Re: [RAM] Re: Re/directed: [arch-d] It's the routing, people! Message-ID: <20061117221405.GA10441@1-4-5.net> References: <20061117165831.BF4E486AFD@mercury.lcs.mit.edu> 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: 7e439b86d3292ef5adf93b694a43a576 Cc: ram@ietf.org, Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1627984362==" Errors-To: ram-bounces@iab.org --===============1627984362== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jefsey, Please, note that this list is not about language issues. I know there are plenty of lists were we can have productive discussions about those issues. Let's try to keep this one to the issues I mentioned in the creation of the list, ok? Just a review here: 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. Its much appreciated. thnx, --dmm =09 On Fri, Nov 17, 2006 at 10:34:15PM +0100, Jefsey_Morfin wrote: > At 17:58 17/11/2006, Noel Chiappa wrote: > >First, I'd like to encourage everyone to stop using the word "address" > >(except where explicitly modified as "IPvN address"). The generic term h= as > >just too many meanings (routing-name, old location&identity semantics,= =20 > >packet > >header field, etc, etc) and it's just too easy to get confused about what > >someone means if you read "address" and think something different from t= he > >person who typed it. > > > > "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 genera= lly > > springs from, and always leads to, confusion of ideas." > > > > -- John Louis Petit, "Architectural Studies in France", 1854 > > > >I am trying to observe this suggestion to not use the word myself, but= =20 > >don't > >always succeed. >=20 > This is typical problem from using English we know well. English is=20 > more an horizontal language which permits quick debugging with people=20 > meaning different things with the same words. French is a more=20 > vertical language which requires a better common understanding of a=20 > problem before discussing it with more precise words. These bottom up=20 > vs. Cartesian differences dramatically helps the ISO process. A good=20 > way to produce a document is to discuss it in English and to=20 > translate in French and to review them one from the other (ISO, MPEG,=20 > etc. experience is very interesting). >=20 > English has an advantage on French: it can do more easily what you=20 > request and French intellectuals adore: to define issues more=20 > precisely through a contextual nomenclature. However, this is not=20 > common to English speakers. So, except if you want this debate to be=20 > in French, I would suggest you help us in establishing a site with=20 > your own suggested nomenclature of the different types of "addresses". >=20 > This would probably help a lot both clarifying the issue and your own=20 > interesting research about what are we really addressing? >=20 > >Second, this idea (geographic "addressing") keeps being "re-discovered" = by > >people who wonder why we aren't doing it. (I had a sarcastic rhetorical > >answer to that ready, but omitted it.) > > > >The short answer is that the routing-names have to be organized accordin= g=20 > >to > >the network's actual connectivity to allow the routing to scale (the lat= ter > >being the problem we are trying to solve). If you cannot make connectivi= ty > >follow geo-"addressing", a geo-based organizing principle for organizing > >routing-names is unable to help the routing scale. > > > >Generally connectivity follows traffic patterns, *not* political or > >geographic boundaries. And the organization of routing-names has to foll= ow > >that. >=20 > I am afraid you jump too fast to the geographic nature of the=20 > "geo-addressing". As I reminded it, there are four phases in a=20 > network: development, topology driven numbering, numbering plan=20 > driven topology, and transition. What actually commands is the market. > - in the development phase the market says if it is interested or not. > - in the deployment phase one follows the market development > - in the maturity phase the network continuity must be everywhere and=20 > follows the real criteria: human/cpu density which is usually=20 > described through the numbering scheme. It is not geographic, but=20 > demographic (actually today demomecanographic), which in turn is=20 > geographic, historic, climatologic, etc. > - in the transition phase, the market has decided to deprecate the=20 > technology and the demo-based plan is usually easier to transition. >=20 > > > the market may well take care of routing and addressing concerns by > > > driving regional/national network economies back into the shapes t= hey > > > had before the early/mid-1990s, when addressing, topology, and=20 > > traffic > > > exchange were quite explicitly geo-topo > > > >"Addressing" and topology were never "geo-topo". IPv4 address patterns h= ave > >always been a major dog's breakfast, although it's gone through various > >stages (the earliest - when the network was small, not coincidentally - > >having no organization at all). > > > >Although there remains to this day (and probably always will) some=20 > >geographic > >influences on connection, especially towards the edges (it's basically a= =20 > >lot > >cheaper to connect to a POP that's physically near you), there are a high > >percentage of links that break that paradigm (see previous comment about > >connectivity following traffic patterns). >=20 > Please do not make the mistake you want to avoid. Numbering has=20 > nothing to do with fluxes. The most important traffic is probably=20 > between USA and Europe. You only need one US and one European block=20 > to support the traffic between people in the USA and people in=20 > Europe. While you will also need one addressing block for people in=20 > Tonga. Not because Tonga should be treated as a geographical zone,=20 > but because Tonga will be an equal topology hub even if the link and=20 > traffic is far lower. >=20 > jfc >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFXjQtORgD1qCZ2KcRAtjyAJ4l0Ff/WYbNoiZG5jR6bDzbgtHdWQCgh/Jc FVAnzYxNCGmBB9/d39JL7/A= =YFEi -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- --===============1627984362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1627984362==-- From ram-bounces@iab.org Fri Nov 17 17:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlC1a-0007OX-Pn; Fri, 17 Nov 2006 17:17:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlC1Z-0007OP-Au for ram@ietf.org; Fri, 17 Nov 2006 17:17:29 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlC1T-0001jU-3I for ram@ietf.org; Fri, 17 Nov 2006 17:17:29 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id D6D46340D7; Fri, 17 Nov 2006 17:17:22 -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, 17 Nov 2006 17:17: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: [RAM] Re/directed: [arch-d] It's the routing, people! Date: Fri, 17 Nov 2006 17:17:20 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DCF5E76D@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061117191055.GA7406@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re/directed: [arch-d] It's the routing, people! Thread-Index: AccKfB+3+cWvQf41S3a4wOhdRaEGtwAGf3sA From: "Bound, Jim" To: "David Meyer" X-OriginalArrivalTime: 17 Nov 2006 22:17:22.0336 (UTC) FILETIME=[27420A00:01C70A96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, ACK that. /jim=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: Friday, November 17, 2006 2:11 PM > To: Bound, Jim > Cc: Eliot Lear; ram@ietf.org > Subject: Re: [RAM] Re/directed: [arch-d] It's the routing, people! >=20 > Jim, >=20 > > your mail and the above rhetoric I attempt in the spirit of better=20 > > together in the IETF will keep us focused to sam hartmans=20 > request at=20 > > the plenary too is my IMHO. >=20 > Well, as you know, I'm in the "give peace a chance" on > all of this camp. I'm confident we can make progress if > we keep that in mind. >=20 > --dmm >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Nov 17 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 1GlFRR-0005E2-U7; Fri, 17 Nov 2006 20:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFRQ-0005DS-M2 for ram@ietf.org; Fri, 17 Nov 2006 20:56:24 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlFRP-0002d6-0w for ram@ietf.org; Fri, 17 Nov 2006 20:56:24 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GlFRL-0007yF-P7 for ram@ietf.org; Fri, 17 Nov 2006 17:56:22 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 18 Nov 2006 02:48:35 +0100 To: David Meyer From: Jefsey_Morfin Subject: Re: [RAM] Re: Re/directed: [arch-d] It's the routing, people! In-Reply-To: <20061117221405.GA10441@1-4-5.net> References: <20061117165831.BF4E486AFD@mercury.lcs.mit.edu> <20061117221405.GA10441@1-4-5.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: cdeeb24e6b743a852c396a4af0e53c8f Cc: ram@ietf.org, Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2138251943==" Errors-To: ram-bounces@iab.org Message-Id: --===============2138251943== Content-Type: multipart/alternative; boundary="----MTzeafxiwtzhkvagbnkadsikogdhbsiuro" ------MTzeafxiwtzhkvagbnkadsikogdhbsiuro Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5472862 At 23:14 17/11/2006, David Meyer wrote: > Jefsey, > > Please, note that this list is not about language > issues. I know there are plenty of lists were we can have > productive discussions about those issues. Let's try to > keep this one to the issues I mentioned in the creation > of the list, ok? Just a review here: > >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. > > Its much appreciated. Dear David, I suggest you reread what Noel quoted and what I wrote. Noel has a very pertinent analysis that routing is the issue, but that it cannot be analysed correctly if there is a language confusion about what an address may mean. Look at the debate on "nodes", which will lead to "nodes of what". So he asks that we do not use the word and try using more precise words. To support that he quotes the example of the French thinking approach which is built in a French language supported cartesian point of view, to use a nomenclature. It is very much like if you program the same function in Basic or in C, you need to declare the variable in C, what is a constraint you do not have in Basic but you can support. We currently have an in depth analysis at the French IPv6 TF on the necessary work implied by this very topic and the impact on the IPv6 market interest, technical deployment, and on the very Internet structural architecture. For example, do we need Internet wide addresses (something shared in the idea that only networks should have an address), what might permit to keep IPv4 if necessary due to time pressure, and to consider an IPv4+ solution as a longer transition to IPv6 (where the "+" might represent many things precisely to discuss). I documented my own proposition. I do not say it is a good one, but I am surprised I never saw it proposed anywhere. This debate shows a very neat split between some of us sharing the IETF culture, and others approaching the problem in what I would call a more usual cartesian way. This happens to be productive on both sides (something we commonly observe at ISO or other plurilingual fora, and others of our MPEG members also report). What is interesting is that what Noel suggests is exactly to try to focus on what we consider as our very starter. From experience this is very unusual : and probably why only a few French engineers share in the IETF work. Our culture lead us to think more like Noel or John Days often do. Yesterday a very documented proposition from one of the TF members was to start a WG about it, and he proposed to take that load. The charter would be to understand with periodical review every 6 months "what is an address, technically, architecturally, in peoples mind, for applications, for current R&D, in the various multilateral approaches of the digital ecosystem evolutions and convergences". IMHO this is a topic where CJK people could very interestingly contribute because their culture, thinking and experience are more exposed than others to the manipulation of addressable concepts (ideograms) which is certainly an important part of addressing (handles, metadata, registries). I will not explain to the co-author of RFC 3439 that the first thing to do is to explore how to split the problems to reduce them. And that this is in this process that you can best identify where something does not scale. And that this is in the basic smallest errors that usually lay the biggest problems. From experience I observed that many of these small errors were semantic, confusing several concepts as being a single one, or not documenting a concept people believe they share. And rather than being a problem of amplification due to the size of the system it is simply a statistic increase of the chances of this inner conflict being exposed with results related to the size of the system. From IETF experience, I now know that this approximation amplification effect is very common in the IETF and I suspect that we face it in here. What is appealing in Noel's proposition, if he can carry what I suggest him, is that building a nomenclature with some simple method will start several sub-debates. With probably several parallel propositions for different needs (and more chances to workout a comprehensive, stable, and long term solution). Not a single solution for all the needs, what is IMHO the real limit of the Internet technology. A idea most around me think simple and obvious, and I have an obvious difficulty to make understood at the IETF. Don't rush, we are in hurry. jfc > > > "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 > > > > > >I am trying to observe this suggestion to not use the word myself, but > > >don't > >always succeed. > > > > This is typical problem from using English we know well. English is > > more an horizontal language which permits quick debugging with people > > meaning different things with the same words. French is a more > > vertical language which requires a better common understanding of a > > problem before discussing it with more precise words. These bottom up > > vs. Cartesian differences dramatically helps the ISO process. A good > > way to produce a document is to discuss it in English and to > > translate in French and to review them one from the other (ISO, MPEG, > > etc. experience is very interesting). > > > > English has an advantage on French: it can do more easily what you > > request and French intellectuals adore: to define issues more > > precisely through a contextual nomenclature. However, this is not > > common to English speakers. So, except if you want this debate to be > > in French, I would suggest you help us in establishing a site with > > your own suggested nomenclature of the different types of "addresses". > > > > This would probably help a lot both clarifying the issue and your own > > interesting research about what are we really addressing? ------MTzeafxiwtzhkvagbnkadsikogdhbsiuro Content-Type: text/html At 23:14 17/11/2006, David Meyer wrote:
>         Jefsey,
>
>         Please, note that this list is not about language
>         issues. I know there are plenty of lists were we can have
>         productive discussions about those issues. Let's try to
>         keep this one to the issues I mentioned in the creation
>         of the list, ok? Just a review here:
>
>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.
>
>         Its much appreciated.

Dear David,
I suggest you reread what Noel quoted and what I wrote.

Noel has a very pertinent analysis that routing is the issue, but
that it cannot be analysed correctly if there is a language confusion
about what an address may mean. Look at the debate on "nodes", which
will lead to "nodes of what". So he asks that we do not use the word
and try using more precise words. To support that he quotes the
example of the French thinking approach which is built in a French
language supported cartesian point of view, to use a nomenclature.

It is very much like if you program the same function in Basic or in
C, you need to declare the variable in C, what is a constraint you do
not have in Basic but you can support.

We currently have an in depth analysis at the French IPv6 TF on the
necessary work implied by this very topic and the impact on the IPv6
market interest, technical deployment, and on the very Internet
structural architecture. For example, do we need Internet wide
addresses  (something shared in the idea that only networks should
have an address), what might permit to keep IPv4 if necessary due to
time pressure, and to consider an IPv4+ solution as a longer
transition to IPv6 (where the "+" might represent many things
precisely to discuss). I documented my own proposition. I do not say
it is a good one, but I am surprised I never saw it proposed anywhere.

This debate shows a very neat split between some of us sharing the
IETF culture, and others approaching the problem in what I would call
a more usual cartesian way. This happens to be productive on both
sides (something we commonly observe at ISO or other plurilingual
fora, and others of our MPEG members also report). What is
interesting is that what Noel suggests is exactly to try to focus on
what we consider as our very starter. From experience this is very
unusual : and probably why only a few French engineers share in the
IETF work. Our culture lead us to think more like Noel or John Days often do.

Yesterday a very documented proposition from one of the TF members
was to start a WG about it, and he proposed to take that load. The
charter would be to understand with periodical review every 6 months
"what is an address, technically, architecturally, in peoples mind,
for applications, for current R&D, in the various multilateral
approaches of the digital ecosystem evolutions and convergences".
IMHO this is a topic where CJK people could very interestingly
contribute because their culture, thinking and experience are more
exposed than others to the manipulation of addressable concepts
(ideograms) which is certainly an important part of addressing
(handles, metadata, registries).

I will not explain to the co-author of RFC 3439 that the first thing
to do is to explore how to split the problems to reduce them. And
that this is in this process that you can best identify where
something does not scale. And that this is in the basic smallest
errors that usually lay the biggest problems. From experience I
observed that many of these small errors were semantic, confusing
several concepts as being a single one, or not documenting a concept
people believe they share. And rather than being a problem of
amplification due to the size of the system it is simply a statistic
increase of the chances of this inner conflict being exposed with
results related to the size of the system. From IETF experience, I
now know that this approximation amplification effect is very common
in the IETF and I suspect that we face it in here.

What is appealing in Noel's proposition, if he can carry what I
suggest him, is that building a nomenclature with some simple method
will start several sub-debates. With probably several parallel
propositions for different needs (and more chances to workout a
comprehensive, stable, and long term solution). Not a single solution
for all the needs, what is IMHO the real limit of the Internet
technology. A idea most around me think simple and obvious, and I
have an obvious difficulty to make understood at the IETF. Don't
rush, we are in hurry.

jfc

> > >  "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
> > >
> > >I am trying to observe this suggestion to not use the word myself, but
> > >don't > >always succeed.
> >
> > This is typical problem from using English we know well. English is
> > more an horizontal language which permits quick debugging with people
> > meaning different things with the same words. French is a more
> > vertical language which requires a better common understanding of a
> > problem before discussing it with more precise words. These bottom up
> > vs. Cartesian differences dramatically helps the ISO process. A  good
> > way to produce a document is to discuss it in English and to
> > translate in French and to review them one from the other (ISO, MPEG,
> > etc. experience is very interesting).
> >
> > English has an advantage on French: it can do more easily what you
> > request and French intellectuals adore: to define issues more
> > precisely through a contextual nomenclature. However, this is not
> > common to English speakers. So, except if you want this debate to be
> > in French, I would suggest you help us in establishing a site with
> > your own suggested nomenclature of the different types of "addresses".
> >
> > This would probably help a lot both clarifying the issue and your own
> > interesting research about what are we really addressing?

------MTzeafxiwtzhkvagbnkadsikogdhbsiuro-- --===============2138251943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============2138251943==-- From ram-bounces@iab.org Sat Nov 18 07:56:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlPil-0002mJ-Ba; Sat, 18 Nov 2006 07:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlPik-0002mD-GD for ram@ietf.org; Sat, 18 Nov 2006 07:54:58 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlPih-0003IN-UP for ram@ietf.org; Sat, 18 Nov 2006 07:54:58 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1GlPig-0007OP-PY for ram@ietf.org; Sat, 18 Nov 2006 04:54:55 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 18 Nov 2006 13:55:19 +0100 To: HeinerHummel@aol.com,jnc@mercury.lcs.mit.edu,ram@ietf.org From: Jefsey_Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-7E36273B; boundary="=======AVGMAIL-455F02B77DE7=======" 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: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Subject: [RAM] Re: [arch-d] thoughts X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Message-Id: --=======AVGMAIL-455F02B77DE7======= Content-Type: multipart/alternative; boundary="=====================_6585218==.ALT"; x-avg-checked=avg-ok-7E36273B --=====================_6585218==.ALT Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7E36273B At 11:04 18/11/2006, HeinerHummel@aol.com wrote: >Hello all, >I am new on this mailing-list and I am also interested on the real >architectual problems wrt. addressing, routing, and a one-face-only >model (rather than a model that glues together orthogonal pieces >like BGP, initial OSPF, OSPF-areas). >Nevertheless I like to respond to the following bon-mot of John >Louis Petit first: >Only the differences between what some speaker A wants to say and >some listener B believes to be told will induce progress in the >discussion. Of course not if the differences were too big (e.g. if A >and B do not speak the same language). But also not if there is no >difference in understanding at all. If A says 1+1=2, that won't >trigger any new idea by B. It's the slight misunderstanding which is valuable. Dear Heiner, this is a _key_ remark, however IMHO incorrect: let imagine a soliloque, where B=A. What you mean is that A cannot have a new idea unless he does not understand himself. But your remark is important because it means that an idea is triggered by a difference of potential - some voltage - somewhere. There are at least (from this debate) two ways to obtain it (David Meyer will not be happy :-)): - the way you describe which is by luck, from B misunderstanding A while making evolve a pre-solution. This is a typical English language and culture (ex. Common Law) approach. Also of an interactive mailing list, like this one, brain storming, case study. - the other approach - Noel quotes - is to analyse the semantic of the problem and to clarify the problem and discover the options and the premises of the ideas. This is typical of French language. I used the comparison between Basic (English) and C(omplex French). What is very important in Noel's quote and your remark, is that nomenclature elements have their own addresses. The problem John Day raises is typical of this issue. We want to discuss things in a binary way when actually they are ternary. We have the same problem with metadata-data relations. This is something which is a key point in studying metacoms. You will understand it very easily. Let take an Excel table. The metadata are the first column and first row, the data are the information at the address column,row. Questions: (1) what is that address standing for? For the data you see, or for the underlaying formula (2) where is located an information when it is displayed at a table address, but used by formulas at other addresses? To describe this we (my Intlnet working group on the issue) came to the concept of "syllodata", the syllogism which interlinks the metadata and the data in an intellectual (brain to brain) network, which is the routing in a data (end to end) network, the cabling in an electic layer (plug to plug) network. Let come back to your praxis and to David's and RJ Atchinkson's approach and the way John Day qualifies them (I fully agree with) and to Noel's remcommended praxis (I fully agree with). In a nutshell we can say that they start from a solution they feel correct. You say that if they misuderstand each others while discussing it, they will discover new ideas: this is an a fortiori research method, which permits to verify a rough feasibility first. What Noel and John advocate is an a priori method, which permits to see if that a priori analysis, is not an fortiori result from something else we would have to dig into first. What I see (as many French people working in an English speaking/thinking environment), is that the best way to converge quickly towards a good and stable solution is to iteratively use both approaches. And I explain this is both common and positive at ISO, etc. What is particulary interesting in our case is that this (somewhat esoteric) debate is probably also our very debate (routing and what is an address and how to best use both together). So we might use the way we study the issue as an image of the solution we look for. We have an example of this iterative well working approach with the DNS iteration. jfc >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 --=====================_6585218==.ALT Content-Type: text/html; charset=us-ascii; x-avg-checked=avg-ok-7E36273B At 11:04 18/11/2006, HeinerHummel@aol.com wrote:
Hello all,
I am new on this mailing-list and I am also interested on the real architectual problems wrt. addressing, routing, and a one-face-only model (rather than a model that glues together orthogonal pieces like BGP, initial OSPF, OSPF-areas).
Nevertheless I like to respond to the following bon-mot of John Louis Petit first:
Only the differences between what some speaker A wants to say  and some listener B believes to be told  will induce progress in the discussion. Of course not if the differences were too big (e.g. if A and B do not speak the same language). But also not if there is no difference in understanding at all. If A says 1+1=2, that won't trigger any new idea by B. It's the slight misunderstanding which is valuable.

Dear Heiner,
this is a _key_ remark, however IMHO incorrect: let imagine a soliloque, where B=A. What you mean is that A cannot have a new idea unless he does not understand himself. 

But your remark is important because it means that an idea is triggered by a difference of potential - some voltage - somewhere. There are at least (from this debate) two ways to obtain it (David Meyer will not be happy :-)):
- the way you describe which is by luck, from B misunderstanding A while making evolve a pre-solution. This is a typical English language and culture (ex. Common Law) approach. Also of an interactive mailing list, like this one, brain storming, case study.
- the other approach - Noel quotes - is to analyse the semantic of the problem and to clarify the problem and discover the options and the premises of the ideas. This is typical of French language. I used the comparison between Basic (English) and C(omplex French).

What is very important in Noel's quote and your remark, is that nomenclature elements have their own addresses. The problem John Day raises is typical of this issue. We want to discuss things in a binary way when actually they are ternary.

We have the same problem with metadata-data relations. This is something which is a key point in studying metacoms. You will understand it very easily. Let take an Excel table. The metadata are the first column and first row, the data are the information at the address column,row. Questions: (1) what is that address standing for? For the data you see, or for the underlaying formula (2) where is located an information when it is displayed at a table address, but used by formulas at other addresses?

To describe this we (my Intlnet working group on the issue) came to the concept of "syllodata", the syllogism which interlinks the metadata and the data in an intellectual (brain to brain) network, which is the routing in a data (end to end) network, the cabling in an electic layer (plug to plug) network.

Let come back to your praxis and to David's and RJ Atchinkson's approach and the way John Day qualifies them (I fully agree with) and to Noel's remcommended praxis (I fully agree with). In a nutshell we can say that they start from a solution they feel correct. You say that if they misuderstand each others while discussing it, they will discover new ideas: this is an a fortiori research method, which permits to verify a rough feasibility first. What Noel and John advocate is an a priori method, which permits to see if that a priori analysis, is not an fortiori result from something else we would have to dig into first.

What I see (as many French people working in an English speaking/thinking environment), is that the best way to converge quickly towards a good and stable solution is to iteratively use both approaches. And I explain this is both common and positive at ISO, etc.

What is particulary interesting in our case is that this (somewhat esoteric) debate is probably also our very debate (routing and what is an address and how to best use both together). So we might use the way we study the issue as an image of the solution we look for. We have an example of this iterative well working approach with the DNS iteration.

jfc

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
--=====================_6585218==.ALT-- --=======AVGMAIL-455F02B77DE7======= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --=======AVGMAIL-455F02B77DE7=======-- From ram-bounces@iab.org Sat Nov 18 20:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlbrO-0000R5-My; Sat, 18 Nov 2006 20:52:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlbrN-0000LO-Nq for ram@ietf.org; Sat, 18 Nov 2006 20:52:41 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlbrJ-0005lM-D0 for ram@ietf.org; Sat, 18 Nov 2006 20:52:39 -0500 Received: from [10.0.1.2] (failure[24.125.117.214]) by comcast.net (sccrmhc15) with SMTP id <2006111901522001500r3ijke>; Sun, 19 Nov 2006 01:52:29 +0000 In-Reply-To: <20061117165831.BF4E486AFD@mercury.lcs.mit.edu> References: <20061117165831.BF4E486AFD@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91DCCB41-C870-403E-A74D-2CC8FF1F0179@eyeconomics.com> Content-Transfer-Encoding: 7bit From: tvest@eyeconomics.com Subject: Re: [RAM] Re: Re/directed: [arch-d] It's the routing, people! Date: Sat, 18 Nov 2006 20:51:47 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.2 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Nov 17, 2006, at 11:58 AM, Noel Chiappa wrote: >> From: tvest@eyeconomics.com > >> Would geo-topo addressing be more palatable > > First, I'd like to encourage everyone to stop using the word "address" > (except where explicitly modified as "IPvN address"). The generic > term has > just too many meanings (routing-name, old location&identity > semantics, packet > header field, etc, etc) and it's just too easy to get confused > about what > someone means if you read "address" and think something different > from the > person who typed it. > > "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 > > I am trying to observe this suggestion to not use the word myself, > but don't > always succeed. Duly noted. I think a similar clarification for "connectivity" and "general connectivity" (which you subbed in for my "transport") would be similarly useful. > Second, this idea (geographic "addressing") keeps being "re- > discovered" by > people who wonder why we aren't doing it. (I had a sarcastic > rhetorical > answer to that ready, but omitted it.) Thanks for that indulgence ;-) I'm not entirely ignorant of the earlier "rediscoveries," just inquiring about the relevance of possibly old ideas in light of (what seems to me) a possibly new context. > The short answer is that the routing-names have to be organized > according to > the network's actual connectivity to allow the routing to scale > (the latter > being the problem we are trying to solve). If you cannot make > connectivity > follow geo-"addressing", a geo-based organizing principle for > organizing > routing-names is unable to help the routing scale. > > Generally connectivity follows traffic patterns, *not* political or > geographic boundaries. And the organization of routing-names has to > follow > that. >> the market may well take care of routing and addressing concerns by >> driving regional/national network economies back into the shapes they >> had before the early/mid-1990s, when addressing, topology, and >> traffic >> exchange were quite explicitly geo-topo > > "Addressing" and topology were never "geo-topo". IPv4 address > patterns have > always been a major dog's breakfast, although it's gone through > various > stages (the earliest - when the network was small, not > coincidentally - > having no organization at all). Before 1976, commercial use of generic private line services by non- PSTNs was legal in exactly zero countries, and such use still remains at best expensive and difficult in maybe 50+% of the countries on Earth. In the other times/places, general connectivity and topology follows patterns that were/are explicitly molded by national regulatory borders/rules. So that "always" is both pretty shallow and highly qualified. (From my own latecomer/outsider perspective, the legal change that made such use possible looks like the main reason why multihoming later become both possible and necessary). It goes without saying that the dog's breakfast view is the accepted wisdom. However, direct experience in odd places around the world, followed by too much scrutiny of the Route Views record gives me the impression that the breakfast has a very strong national flavor in many cases. Some observations from the latter: 1. After adjusting (to the best of my abilities) for historical and structural (HD) differences, distribution of public routed IP across public ASes is on average more concentrated today than it was in 1997 in maybe 1/3 of the "national network economies" (NNEs) for which data is available (NNE being the sum of ASes associated via whois with a specific ISO3166 country code). To me this implies that default route options are probably growing slower than the overall Internet for many places, and the people stuck there. 2. The share of ASes that have at least one publicly observable domestic adjacency (same AS-level country codes) *and* at least one publicly observable cross-border adjacency is lower today than it was in 1997 in about 1/5 of NNEs. If these are the primary "dogs", they don't seem to be growing/expanding fast enough to sustain the Internet-as-spaghetti view. 3. In1997, national-level concentration of cross-border AS adjacencies was high enough to raise concerns in 59/95 NNEs -- 44 of which would have been no-brainers for intervention -- if anyone obliged to have such concerns had known how to look. Today there are almost twice as many NNEs (countries which have been voluntarily identified as "home" by at least one AS), but cross-border adjacencies are 100% monopolized in 41 of them. In any other economic sector, another 68 would also be getting a very hard look. Granted, the remaining 60-70 NNEs together constitute the majority of the publicly observable Internet (to date). Granted, differential domestic/international growth rates are properly regarded as evidence of great success in those economies; some combination of factors is making the Internet boom in those places. But to me all of this just reinforces my original point that geography (or geopolitical boundaries) are not irrelevant, and reaffirms my original belief that the contractionary future scenario also represents a risk deserving of consideration. > Although there remains to this day (and probably always will) some > geographic > influences on connection, especially towards the edges (it's > basically a lot > cheaper to connect to a POP that's physically near you), there are > a high > percentage of links that break that paradigm (see previous comment > about > connectivity following traffic patterns). In November 1997, cross-border AS adjacencies represented 27% (1486/5355) of unique AS-to-AS adjacencies from the vantage point of Route Views data contributors. On November 1, 2006, the equivalent percentage was 29% (14862/50559). So the percentage is high, I guess, but not really changing much... Perhaps there are lots more completely invisible private cross-border networks now -- but what difference could that make to routing-names for the the rest of us? Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Nov 19 08:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmGv-0001Fy-IX; Sun, 19 Nov 2006 07:59:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlmGu-0001Fr-7n for ram@ietf.org; Sun, 19 Nov 2006 07:59:44 -0500 Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlmGs-0002ej-0I for ram@ietf.org; Sun, 19 Nov 2006 07:59:44 -0500 Received: from HeinerHummel@aol.com by imo-m27.mx.aol.com (mail_out_v38_r7.6.) id l.c67.57b4ac8 (33856) for ; Sun, 19 Nov 2006 07:59:34 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sun, 19 Nov 2006 07:59:34 EST To: ram@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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [RAM] Routing and Addressing X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1846468986==" Errors-To: ram-bounces@iab.org --===============1846468986== Content-Type: multipart/alternative; boundary="-----------------------------1163941174" -------------------------------1163941174 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Shall addressing support routing ? Example for minimal support: the internet. Prefix building capability is the only support.Even less: The current way of using non-summarizable multicast addresses. Example for maximal support: Postal address consisting of name, floor, suite, building block, street+number, city, state, zip, country. Shall headering support routing ? The answer can only be:yes. And: it is up to the headering as to cater for a tight AND/OR loose relationship between routing and addressing. Obviously there are pros and cons for any approach. Easier administrative handling should not be the striking argument at all. Instead: Providing new capabilities should be the striking argument. Hence, how shall IP-headering and IP-addressing look like in the future? Can we progress to IPv7 ? Heiner Hummel -------------------------------1163941174 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Shall addressing support routing ?
Example for minimal support: the internet. Prefix building capability i= s=20 the only support.Even less: The current way of using non-summarizable=20 multicast addresses.
Example for maximal support: Postal address consisting of name, floor,=20 suite, building block,
street+number, city, state, zip, country.
Shall headering support routing ? The answer can only be:yes. And: it i= s up=20 to the headering as to cater for a tight AND/OR loose relationship= =20 between routing and addressing.
 
Obviously there are pros and cons for any approach. Easier administrati= ve=20  handling should not be the striking argument at all. Instead: Providin= g=20 new capabilities should be the striking argument.
 
Hence, how shall IP-headering and IP-addressing look like in the=20 future?
Can we progress to IPv7 ?
 
Heiner Hummel
 
 
 
 
 
 -------------------------------1163941174-- --===============1846468986== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1846468986==-- From ram-bounces@iab.org Mon Nov 20 19:41:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJgm-00071L-Tn; Mon, 20 Nov 2006 19:40:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJgm-00071G-6m for ram@ietf.org; Mon, 20 Nov 2006 19:40:40 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJgk-0006vh-Qx for ram@ietf.org; Mon, 20 Nov 2006 19:40:40 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAL0ebDs021603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 20 Nov 2006 16:40:38 -0800 Received: from [129.46.225.224] (carbuncle.qualcomm.com [129.46.225.224]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAL0eapi007327 for ; Mon, 20 Nov 2006 16:40:37 -0800 Mime-Version: 1.0 Message-Id: Date: Mon, 20 Nov 2006 16:40:35 -0800 To: ram@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [RAM] Binding X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Re-reading RFC 1498 after John Day's message helped gel a set of thoughts that has been sloshing around my brain as this discussion has gone on. I've tried to put that set into a short set of bullets below, to see if it is the right high level connection between the discussion and the engineering problem which is driving it. * we can model identifiers as the binding of an object to a context, or as Saltzer puts it in RFC 1498: It is more profitable instead to look upon all identifiers as examples of a single phenomenon, and ask instead "where is the context in which a binding for this name (or address, or indentifier, or whatever) will be found?", and "to what object, identified by what kind of name, is it therein bound?" * the current Internet does not explicitly mark context * the same bit pattern has been used in multiple contexts * among the contexts in which that bit pattern has been used is one which Saltzer called "route", associated with a binding service as "Route service, to identify the paths that lead from the requestor's attachment point to the ones found in 2". 2 is "node name location", in Saltzer's terminology, and it identifies attachment points that reach nodes that run services (his "service name"). * a current set of default-free zone operators believes that if they deal only with the "route" context above, the summarization problem that faces them will be more manageable. This apparently derives from a belief that some portion of the current summarization problem derives from identifiers being present in the routing context because they are present in other contexts and they cannot now be distinguished or eliminated. There are clearly other points that have been made here, and I'm not trying to provide a summary of the whole to date. I just want to make sure I understand the tie-in between the architectural discussion and the engineering driver. Does that tie-in seem substantially correct? regards, Ted Hardie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Nov 21 04:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRtq-00041N-6f; Tue, 21 Nov 2006 04:26:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmRto-000417-8p for ram@ietf.org; Tue, 21 Nov 2006 04:26:40 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmRtm-0005GA-Sr for ram@ietf.org; Tue, 21 Nov 2006 04:26:40 -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 kAL9QX0j115486 for ; Tue, 21 Nov 2006 09:26: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 kAL9TN2E2486410 for ; Tue, 21 Nov 2006 09:29:23 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 kAL9QXma030879 for ; Tue, 21 Nov 2006 09:26:33 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 kAL9QXFS030873; Tue, 21 Nov 2006 09:26:33 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 KAA92958; Tue, 21 Nov 2006 10:26:32 +0100 Message-ID: <4562C648.30006@zurich.ibm.com> Date: Tue, 21 Nov 2006 10:26:32 +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: Ted Hardie Subject: Re: [RAM] Binding 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: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > a belief that some portion of the current summarization problem > derives from identifiers being present in the routing context because > they are present in other contexts and they cannot now be > distinguished or eliminated. I think that's an important point. Despite Noel's strictures, I continue to use the forms "identifier-address" and "locator-address", and effectively the routing explosion is due to identifier-addresses appearing in a context where only locator-addresses are wanted. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Nov 21 09:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWFT-0000Gb-9f; Tue, 21 Nov 2006 09:05:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWFS-0000GP-ET for ram@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-0006Pa-5Z for ram@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 1GmWFN-0001Xj-Te for ram@ietf.org; Tue, 21 Nov 2006 06:05:14 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Nov 2006 15:03:29 +0100 To: Brian E Carpenter ,Ted Hardie From: Jefsey_Morfin Subject: Re: [RAM] Binding In-Reply-To: <4562C648.30006@zurich.ibm.com> References: <4562C648.30006@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: 2.0 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0937060554==" Errors-To: ram-bounces@iab.org Message-Id: --===============0937060554== Content-Type: multipart/alternative; boundary="----MTclnlrvogjpwpgsowjjqulfsvtxeughsl" ------MTclnlrvogjpwpgsowjjqulfsvtxeughsl Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-6DFE35B1 At 10:26 21/11/2006, Brian E Carpenter wrote: >>a belief that some portion of the current summarization problem >>derives from identifiers being present in the routing context because >>they are present in other contexts and they cannot now be >>distinguished or eliminated. > >I think that's an important point. Despite Noel's strictures, I >continue to use the forms "identifier-address" and "locator-address", >and effectively the routing explosion is due to identifier-addresses >appearing in a context where only locator-addresses are wanted. Correct, but how do you manage mobility, etc. in an end to end and routing tables context? what ever the solution you know the final destination when you have reached the end. ------MTclnlrvogjpwpgsowjjqulfsvtxeughsl Content-Type: text/html At 10:26 21/11/2006, Brian E Carpenter wrote:
>>a belief that some portion of the current summarization problem
>>derives from identifiers being present in the routing context because
>>they are present in other contexts and they cannot now be
>>distinguished or eliminated.
>
>I think that's an important point. Despite Noel's strictures, I
>continue to use the forms "identifier-address" and "locator-address",
>and effectively the routing explosion is due to identifier-addresses
>appearing in a context where only locator-addresses are wanted.

Correct, but how do you manage mobility, etc. in an end to end and
routing tables context? what ever the solution you know the final
destination when you have reached the end.

------MTclnlrvogjpwpgsowjjqulfsvtxeughsl-- --===============0937060554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0937060554==-- From ram-bounces@iab.org Tue Nov 21 09:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWdF-0006V2-HM; Tue, 21 Nov 2006 09:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWdD-0006PE-2G for ram@ietf.org; Tue, 21 Nov 2006 09:29:51 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmWdB-0000BT-SN for ram@ietf.org; Tue, 21 Nov 2006 09:29:51 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7B70886AE5; Tue, 21 Nov 2006 09:29:49 -0500 (EST) To: ram@ietf.org Subject: Re: [RAM] Binding Message-Id: <20061121142949.7B70886AE5@mercury.lcs.mit.edu> Date: Tue, 21 Nov 2006 09:29:49 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Brian E Carpenter > Despite Noel's strictures, I continue to use the forms > "identifier-address" and "locator-address", Note that Noel doesn't object to use of the terms "identifier-address" and "locator-address", just as he doesn't object to use of "IPv4-address" and "IPv6-address", because in all cases their meaning is much more defined, and thus less potentially confusing (even if not clearly focused, as in the latter two :-). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram